Fighting with computers

Computers are not always friendly.

Wednesday, June 28, 2017

Of cars and goats

Some days ago, while listening to an exam exercise, I learned about an old story that happened in the early nighties. It seems it stirred quite a controversy at the time. It was about a TV show where contestant was offered to chose one door out of three to win a car. The setup was that only behind one of the doors a car was present while the two others contained a goat. Apparently, most people value the car as the good prize but could not care less about the goat, that was the losing item.


The host would open a door different than the one the contestant chose to reveal, invariably a goat. And later the host will offer the contestant to switch to the other remaining door. The controversy was about what was the best choice the contestant could do: to switch or to keep the original choice.

We all agree that, initially, the contestant have one of out of three chances to win the car. However, when the host opens one of the remaining (non chosen) doors showing a goat it is not so clear what the chances are. Many people would think that given the fact that only two doors remain closed and one of them contains, necesarily, a car, then contestant has a 50/50 chance to win now. If that were true, swiching or staying put would make no difference.

However, the recomendation by Marilyn vos Savant in the article linked above was to "always swicth" as a more beneficial policy, which many people failed to understand.

So after my exam, I decided to read the above column and to figure that by myself. The way I shown to myself how the logic of this problem works as follows: Let us assume contestant has chosen the left door.

This selection creates a divide between the chosen door and the other two remaining doors. It is easy to see than the chances of the car to be in the chosen door is 1/3 and the chances of the car to be on the other remaining two doors is 2/3 (the picture shows one of these latter cases).

And what are the implications of the contestant keeping his original choice? Well, he will win in 1/3 of the cases, most people will easily agree on that too.

So the last question is, what are the implications of always switching once the host has shown us a door with a goat? Well, we are then selection the box in the right of the image, the one that has a 2/3 choice of having the car, that we know from a fact the car is not on the open door, so it will be on the closed door with a choice of 2/3.

Therefore, as odd as it might seem, changing to the other remaining door when the host shows us one door containing a goat is the best course of action to maximize our chances to win. That said, we might lose the game if our initial door choice was right, but that will only happen 1/3 of the times. So always switching will grant us a 2/3 chance of winning.

Saturday, June 10, 2017

Hello Clipper, bye JTS

Polygon clipping and polygon offsetting are operations that due to the multitud of cases possible are quite a difficult beast to tame. That is why I have used an external library when I have needed such a feature in a program.

A few days ago, researching for a student's assignment, I learned that "clipper" library had been migrated to Java by Tobias Mahlmann.  I had a minor trouble with one file not using UTF-8 encoding but other than that it compiled and run beautifully (not in my large display though as I am using an scale factor larger than one that messes the Java GUI layout).


Another interesting detail is that the code will need Java 1.8 to compile as it uses a Lambda function in one of the Comparators used. However, I wanted to use it with some older code that was using 1.6 and the compiler was not happy with my version request, so I needed to do a small change to get rid of the Lamba function code in favor of an inner class. 

Once the code was working, I could use it with some code developed with Processing 2.21 and it would work ok.  Now I have to do some tests but my first impression is that Clipper is way faster than Java Topology Suite.

Update: After some tests it seems Clipper is not as robust as JTS, so I am not going to make any change to my software after all.

Thursday, June 08, 2017

OpenSCAD kept crashing on Ubuntu 16.04 with AMD drivers

After the upgrade of my computer's graphics card for a new AMD RX 460 I noticed OpenSCAD program was crashing all the time with a segmentation fault (every time I pressed F5 or F6). But the problem would only happen if I was using AMD native driver (amdgpu-pro). I saw no references online to this specific problem which was weird.

I decided to buy the RX 460 as it apparently had good Linux support, so it was odd to have this kind of problem but no matter what version of the driver I was using or what version of OpenSCAD nightly build I could not use the application. I managed to get an AppImage version that worked without a problem in my system and that is what I have been using for a while.

Today, I have decided to check if somehow problem could he related to my locale, so I invoked the application like this: LC_ALL=C openscad-nightly

And lo and behold, OpenSCAD is working as it should, no problem whatsoever. So it is clear that my Spanish locale was what caused the problem. I wish I have thought sooner about making this simple test.

Update: Oops, there is still something else, as csg example still crashes the program (time to try a stable release now).

Update2: Well, stable release is a compelte no-go.

Update3: When you discover that the crashes happening from command line are gone if program is run from gdb.  WTF? It turns out it is a "Heisenbug" (time-sensitive bug)

Update4: It started to work ok with 17.30 driver update.

Friday, June 02, 2017

Windows 10 on vmplayer

From time to time there is some software I need to use that is only available for Windows. For that I kept an old virtual machine I created ten years ago that was running Windows XP and served me well over the years. But the last instance of software in point was the latest Netfabb  Standard 2017, that is only available as a 64bit Windows version.

So I grabbed a Windows 10 ISO from Microsoft Imagine shop and fed it to my virtual machine. After some time I got a new virtual machine running Windows 10, or almost.

I could see networking was not working nor was audio. I could see many people reporting different problems with various virtualisation tools and Windows 10 but it was not clear what my problem was, so after following several wrong paths I realized the system was complaining about not having a driver for the hardware found. I checked on the configuration file and I could see the network device was "vlance" and I replaced it for "e1000" and the latter was easily recognized by Windows 10 so that was fixed.

The configured card I had in my virtual system was "es1371" that, again, was not apparently supported by Windows 10 (at least not if the network was not working as it was my case). So I replaced it by "hdaudio" and now I have got sound too. Audio quality is not great but just ok.