When the penny finaly drops...
The first Monday of the school year has not been easy, but we have pulled it out anyway. Jason complained that he "was not used to two-day weekends" after the long summer and the days before, where they always had 3-day weekends and only went to school every other day, but it did not take much pushing before they got ready and were on their way.
The first part of the morning went into the data processing and a long video-conference with one of our programmers trying to debug a problem I had with my old laptop. During the downtime of the new one, I had to install a number of applications in the old one to try to keep working. It turns out that Flatpak is so good at isolating applications from one another that it occasionally prevents two of them from working together. In the end, I had to resort to the old method of downloading and unpacking the tarball, which use much less hard disk space and worked perfectly well in combination with other applications.
I spent the rest of the morning and a big part of the afternoon in the reading and programming assignments of my online course and then I turned to reading the paper that I had to explain in front of the PhD group. It had been sitting unread for over a month and I decided that it was enough procrastination, so I started to read. Fortunately, it proved to be as interesting as I had estimated on first diagonal read when I found it, so the read was easy and rewarding.
Half-way through the reading my cellphone buzzed with an email from on of the colleagues in the day job. We have been trying for more than two months to understand the discrepancies between my interpretation of the data and his but, hard as we tried, we only reached dead ends. Embedded data processing systems have the big disadvantage that you only have limited access to what is actually happening inside, and line-by-line debugging is out of the question most of the times. Besides, our system has the additional problem of lacking a floating point processor, so it cannot handle decimal numbers (like 1.25). Instead, we have to multiply all the values by a big number, like 256, and do the math with the result. For instance, 1.25 would be represented as 1.25 * 256 = 320, and 2 would be represented as 2 * 256 = 512. Of course, the factor you use to multiply all values is critical in a correct interpretation of numbers, and for months we were unable to reconcile the values that I got with the ones he was expecting to get. Then the penny dropped: all this time I had been reading the values as if they were multiplied by 256 (yes, a surprising number but very common among computer people), but they had been multiplied by 100 all the time.
Photo: pikist.com |
Comments
Post a Comment