"It's not the computer that's wrong, it's your program!" is the universal response nowadays when a newly-written piece of software fails a test and the developer tries to blame something other than his/her own code. But it wasn't always so, youngsters. Back in my undergraduate days (~1973) a roommate at Rice had the first scientific pocket calculator I had ever seen, the marvelous Hewlett-Packard model 35. It cost $400 and came out of the box with a built-in bug: take the natural logarithm of 2.02, then exponentiate that; instead of getting back 2.02 as math demands, the HP-35 calculator stubbornly returned exactly "2". The original algorithm that the little processor used had a glitch at certain critical numbers.

Half a decade later I found a minor flaw in the Microsoft BASIC burned into the ROMs of my own first home computer, a Commodore PET. (I paid $800 to get the 8 kilobyte model instead of the cheaper, standard 4k memory version — woo!) When I ran long monte carlo calculations that relied on pseudorandom numbers, after a day or two the interpreter started to repeat the "random" numbers it generated. I spotted the problem when statistical fluctuations in the results didn't average out properly.

Easy to repair, once you know it's there. "Trust but verify" applies to firmware as it does to everything else in life ...

(cf. PetBibli1 (23 May 2000), CollegeCollage2 (3 Oct 2000), PetBibli2 (14 Jul 2001), ProgrammingProverbs (4 Dec 2001), PersonalComputerHistory (25 Feb 2002), CloseToTheMachine (6 May 2004), ...)

TopicProgramming - TopicPersonalHistory - TopicHumor - 2006-08-10

(correlates: HowToFixIt, DataStructures, ReligionOfTraining, ...)