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)

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.

Thursday, May 18, 2017

Lots of changes at once and one OpenSCAD bump

In order to get my new 4k display connected to my Linux box at work I had to replace the graphics card (actually I was replacing none but the motherboard's one). For the 3840x2160 resolution I selected a cheap ATI board that apparently had decent Linux support, the $100 board RX460.

First problem was my computer did show nothing on the new screen, that was fixed connecting the old one and using the BIOS to switch default video to the new card. Then Ubuntu 14.04 would boot but failed to recognize the new card, which makes sense as the driver was not install. However I would get graphics working using the software rendered (frame buffer). When looking for the Linux drivers I realized I would need to upgrade to Ubuntu 16.04, something I wanted to do for a while but kept leaving for a rainy day.

One colleague at work mentioned to me he have had quite a good experiencing upgrading a couple of systems from 14.04 to 16.04 so I was set to do it then, now that it was supposed to be easy. My experience was not as good as his, as installation complained about unsupported packages and eventually died off stating the upgrade would leave my system into an unstable state so it was cancelled.

However, after booting the system again I realized it was actually running the new version regardless of what it said before (maybe the going back to 14.04 failed too?). However I could no longer succeed with the graphical login, that would fail on me everytime. But text terminals would work ok, so I downloaded the ATI driver for my board and installed it. Next reboot I was back in business with the graphical login and now I could see the graphical interface moved smoothly and efficiently as hardware acceleration was working. I went to the graphics setup to set the scale of menu and title bars to a slighly larger size so I can read them more easily (after all, going to a larger display was done in part to view more and better the screen).

I had a couple of hickups with some leftovers of the 14.04, but eventually managed to remove the old packages and install the new ones. And it all seemed to work ok now. However I realized the OpenSCAD program cause a segmentation fault everytime I tried to start in in GUI mode. Command line operation was working though. So I assumed there was some problem maybe with my current graphics configuration. Unfortunately I was not able to find any complains of a similar problem on the web and removing an reinstalling the package did not cure it either. So I went ahead and installed a newer, nightly build, instead of the stable version and that is working flawlessly with my new hardware. I guess the cause of the fault is gone with one of the changes from the last version.

What is best is the most of the tools I have installed the last three years are already installed and printers, accounts and digital certificates do not need to be setup again. It was not an easy upgrade but it was painless than a new install and longish migration of data to the new system.

After figuring out how to send the audio through the Display Port cable, I realized the audio feature is not the most remarkable one of this 32" display by Benq, so I am keeping my old speakers that deliver richer sound.

Saturday, May 13, 2017

Wifi watching

Like train spotting, bird watching, I guess that wifi watching could become a thing, or so could be if you use this nice app for your Android phone. I avoid the term wardriving because it assumes you drive a vehicle and it has a dubious or evil aim (or may be that is only my interpretation).

I was touched by the work of these artists that visited and gave a talk at our campus a year ago. So I just went out for running an errand and grabbed nearly 900 different SSIDs around the block.

The Wifi Collector app will grab both access point information plus geographical location using the phone location services. Data can later be exported as a CSV file or KML file to be used with Google Earth as the image here shows.

While I did not uncover any political message or funny stuff on the SSIDs names on the surroundings, I guess it can be another way of catching and reviewing your walks (runs?) around the city.  I will use this app more than once just for a new way of perceiving the city that was not possible before.

Saturday, May 06, 2017

Spark on a Printrbot Simple Metal

One dry winter day I noticed a spark jumped from my finger when toughing the metal plate of a Printrbot Simple metal printer. Next time I tried to use that printer the hot-end would ram into the print bed so I had to stop the printer immediately. I remembered the spark incident and I assumed damage was done due to that static discharge.

On to find a solution. Printrbot forums showed several entries about damaged sensors and how to replace them. Others had to replace both the inductive proximity sensor plus the Printrboad control electronics too. But one thing I noticed is that my inductive sensor was apparently working, as the LED will lit when approaching a metal part to it. After testing with M119 command, I realized that as odd as it might seem, now my printer thought the signal on Z-MIN end-stop was reversed. So it was triggered when the LED was off and open when the LED was lit. That was pretty odd but as the sensor seemed to be working I set my path to modify the firmware configuration.

Once I found a suitable source code of the firmware I just changed the polarity of the ZMIN input signal and my printer was able to print again. I could not really explain why that was happening but somehow it was working so it had to be a reason for that. Anyway, the joy was short-lived and two days later the hot-end will ram into the bed at the beginning of a printing, again!

Testing the sensor again shown LED was still working as expected, but this time the M119 command will always show the sensor as opened no matter the status of the LED. After taking out the sensor output signal I would not measure any voltage change on it when detecting metal. And the ZMIN input pin was now stuck to ground so it could not longer be used as an input.

My guess is that the electrostatic damage would eventually caused the pin structure to go through a transient period of inverted polarity but eventually that pin would end up stuck to ground. And that latter phase most likely killed the sensor output driver so sensor was now busted.

Repairing all that would require a new sensor and setting the firmware to use a new input pin (or replacing the printrboard entirely).

I bought a new inductive sensor on eBay and replaced it but this time I tried if the sensor would work powered at 5V instead of the 12V it was using before, which it did. This way the sensor output could be attached directly to any free input pin of the processor. I chose PE5 signal available in ETX1 connector as the new input for ZMIN in the firmware and after uploading the new version the printer is up and running again.

I would need to be more careful in the future touching ground before touching the printer :-)