Dear DDJ,
I'm the "Mr. X" Robert Collins refers to in his article "Inside the Pentium II Math Bug" (DDJ, August 1997). Yes, I have a British accent because I'm British -- and it's "Dr. X" to be accurate. I think Robert ascribes to me more devious motivations than are actually there!
Yes, I'm an investor in AMD and, therefore, I keep a close eye on what's going on with respect to processors. That's how I picked up his Usenet post.
First thing I did was to go to Robert's web site to see if I could confirm that it was a real post or a hoax. From there, I got his home phone number. I felt bad about disturbing Robert and his family, so I kept it short and to the point. At that point, I wanted him to confirm it was his Usenet post and not some mischevious n'ere-do-well. I had nothing to do with the lawyer who phoned him afterwards nor did I speak with any lawyers or anything like that.
I posted an announcement of the bug on Silicon Investor to warn Intel stockholders. That's why these stock bulletin boards are so useful -- you don't have to wait for the professionals to "process" the information. CNET broke the story soon after and I e-mailed them. I also posted on Silicon Investor a warning to AMD stockholders that it could be painful for all semi investors (no I made NO money on this bug).
I did the first port of the NAG (Numerical Algorithms Group) to the 68000 in 1982 before the IEEE floating-point number format was IEEE so I do know about handling floating-point numbers and particularly overflow conditions and rounding errors. I think I may have enough experience to analyze whether a bug is important or not. I am also a widely published PhD physicist with years of research behind me, degrees from Cambridge and Southampton Universities, and a lot of numerical programming under my belt.
When I looked at Robert's web site commentary and the "Dan" bug data I realized that the two did not match. Robert had stated it was the overflow flag wrongly set rather than the PE flag.
I e-mailed Robert to inform him of the correction. Brooke Crothers from CNet then e-mailed me and phone calls came from Wolfe at EE Times and Dean Takahashi from the WSJ -- I presume Robert spoke to them of my e-mail. I discussed the bug and its relevance and told them I was invested in AMD. Wolfe wrote the comments in a rather strange way. He called me a "self-employed physicist," which sounds odd. In fact, the physics I do today is not as an employee, but I also do a lot of statistical and medical work. I work for myself and consider myself professionally a physicist.
Brooke started his series off hesitantly, rather unsure of whether my analysis would hold up. Of course, eventually the Intel statement confirmed what I had said.
I wish I had shorted Intel. The following Monday, the DEC suit came out and then Intel profit warning a few weeks later. Down 20+ points I could have made. Instead AMD dropped from 45 to 38, so I lost money!
I have nothing to hide and I feel everything I did was okay. I still feel that the bug is significant and I would not use a PPro or PII for numerical work, particularly if I was using a compiled library like NAG, which a lot of scientists do.
Martin Atkinson-Barr
mcmab@worldnet.att.net
Dear DDJ,
In "Inside the Pentium II Math Bug," Robert Collins makes reference to the Ariane 5 failure. Robert implies that it (a) involved a conversion between floating-point and fixed-point or (b) a memory dump. Consequently, Robert misstates the significance of such errors; indeed, if the actual error had been ignored, the flight would likely have been a success!
The Ariane 5 uses two redundant computers. The software is designed with the assumption that if any error, such as an overflow occurs, it must be a hardware error. In such an event, the processor shuts down so as not to interfere with the operation of the other, presumably correct, computer.
The Ariane 5 software was ported from that used for a previous version of the vehicle. For the new vehicle, a different flight profile caused a counter to overflow, which had not been anticipated. This caused both processors to automatically shut down, leaving the vehicle with no control whatsoever.
There was no "memory dump;" rather, the computers shut down. (Would the Ariane engineers forget a rocket motor control was not a line printer?) There was no fix<->float conversion; it was an overflow error. Had the error not been trapped (that is, if a processor bug set not the overflow flag but some innocuous flag) the mission would have succeeded!
Louis Baker
lbaker@thuntek.net
Dear DDJ,
In the words of Mark Twain, "Rumors of my death have been greatly exaggerated." It was disappointing to read Eugene Kim's commentary on the DoD's choice to end the "mandate" of Ada as their primary programming language "News & Views," DDJ, August 1997). I am among many, however, who applaud the DoD's decision. Ada is healthy enough to stand on its own against the two competitors: C++ and Java. As a developer very experienced in all three languages, I choose Ada wherever I can. I can generate Java bytecode directly from Ada, allowing me to quickly deliver web-based applets in a language significantly richer than Java. And for those that argue the Ada is too "verbose," it should be noted that the Ada 95 Booch Components are approximately 15 percent smaller than the same Booch Components in C++! Eugene's arguments against tools have some merit, but the most common C++ tools, those that perform bounds-checking and leak-detection, are practically useless for Ada. Those checking features can be turned on and off at a switch from the compiler. Of course, most vendors don't deliver Ada interfaces to their products, but Ada comes with a standard mechanism for incorporating C, Fortran, and Cobol interfaces right away (a novel way to use legacy code in web apps: Write Ada applets in Java bytecode, and let your server apps, also written in Ada, make calls to your legacy systems). Compiler and tool prices are now comparable to that of C++ tools, and Ada already has the advantage of being a stable ISO standard with optional compiler certification. It will be at least another two years before we see that in C++. It's true that there are fewer people trained in Ada, but my personal experience is that C people reach "expert" level significantly faster (about a factor of two) in Ada than they do in C++.
Market forces, indeed. I'll remember my parent's admonishment in this case, "If Eugene jumped off a cliff, would you do it to?" No thanks, Eugene, I'll just watch you and the rest of the lemmings do your thing.
David Weller
dweller@rivatech.com
Dear DDJ,
Regarding Steve Barrett's letter in DDJ, May 1997 ("Old NASA Computers"), in which at one point he wonders about the causes of the Space Shuttle Challenger disaster. You might point out to your readers that Edward R. Tufte's book Visual Explanations, reviewed in the July 1997 issue of DDJ, documents the communication breakdown between Morton Thiokol engineers and NASA officials that precipitated the disaster. The engineers correctly believed that a cold-weather launch was a bad idea, but their presentation to NASA (over video conference if I recall correctly) was unconvincing. The graph of the O-ring damage that appeared with the DDJ review would likely have convinced NASA had they seen it at the time. But as Tufte points out elsewhere, numbers gain significance in relation to other numbers. Analogously, the clarity and significance of Tufte's graph can only fully be grasped in comparison to the engineers' eminently weak presentation of the data. For that I refer readers to the book, which I highly recommend.
Gideon Glass
gid@cs.wisc.edu
Dear DDJ,
I just finished Al Stevens' column on TeamWorx and wanted to compliment him. I, too, discovered the importance of a "shared vision" among prospective team members while leading software development projects at IBM. In the '70s it had to be done as a sub-rosa activity and was viewed as too touchy-feely to become an institutionalized process. However, it had good results and weeded out a few who would, I'm sure, have been detrimental to the team at a later point. I'm now retired from IBM after 31 years of banging my head against its hallowed walls. I've learned how to work to achieve a shared vision among my staff, but am careful not to use those words. Strange world, isn't it? The most obvious needs often draw the strongest resistance.
Dan Clarke
dcclarke@cats.ucsc.edu
Dear DDJ,
As always, I enjoyed Al Stevens column in the August 1997 issue of DDJ. Having attended a workshop (somewhat) similar to TeamWorx, I can relate to Al's enthusiasm. The one I attended back in the '80s was a programming project management class that had been reincarnated for engineers. We too came home with a new outlook on the process. Alas, the requirements people still kept changing the requirements in mid stream, the bean counters kept messing with the budgets and the planners kept changing (shortening) the schedules. It was great, however, to know how the process is supposed to work if all the team can come together. Al's article was a great reminder of those days, and very enjoyable... Al is right, however: You had to be there.
Lou Yovin
72733.2741@compuserve.com
Dear DDJ,
The component-based development metaphor Jonathan Erickson used in his June 1997 "Editorial" to explain modern day learning described by Gertrude Himmelfarb is perfect. Using pre-packaged (pre-discovered) ideas and concepts to build larger reports, expand on ideas and further develop arguments is exactly what the Internet has allowed students, of all ages, to do.
I also concur that this is not necessarily a bad thing -- motivation for learning is spawned by discovery, which the Internet and the WWW facilitate. It is always the case that one must examine, closely, sources of information. Whether the source is a leather-bound dictionary from the Boston Public Library, or a random Web site uncovered on the Internet, the possibility remains that the information contained within each is inadequate. It is the development of critical thinking that leads to determining credible information, as Erickson aptly pointed out.
Tom Morley
Boston, MA
Tom_Morley@lpp.com
DDJ