In class, we’re just starting to delve into the world of floating-point. Professor James joked in lecture this week that “the ideal way to do this would be to spend the first two weeks explaining the details of floating point … but then we’d probably scare you all so much that you’d drop the class.” The mess of dealing with floating-point numbers is precisely why the arcane details of IEEE 754, the standard for binary floating-point arithmetic that was published
over twenty years ago, are known in their entirety by few people.

But the details, obscure as they may be, are incredibly important. In an interview for the March 1998 issue of IEEE Computer, William Kahan (ACM Fellow, Turing Award winner, and so-called “father of floating-point” [4]) described the world before standardized floating-point in this way:

“If you were a programmer of floating-point computations on different computers in the 1960’s and 1970’s, you had to cope with a wide variety of floating-point hardware. Each line of computers supported its own range and precision for its floating point numbers, and rounded off arithmetic operations in its own peculiar way. . . . Arithmetic aberrations like these were not derided as bugs; they were “features” of computers too important commercially for programmers to ignore. Programmers coped by inventing bizarre tricks like inserting an assignment “X = (X + X) - X” into critical spots in a program that would otherwise have delivered grossly inaccurate results on a few aberrant computers. And then there were aberrant compilers . . . . Reliable portable numerical software was becoming more expensive to develop than anyone but AT&T and the Pentagon could afford. As microprocessors began to proliferate, so did fears that some day soon nobody would be able to afford it.” [2]

In 1977, Kahan, who was consulting for Intel at the time, along with his student Jerome Coonen, and a visiting professor Harold Stone, wrote the draft specification that was eventually (in 1985, after many companies had already built their hardware in compliance with the draft) accepted as the standard. They’re not kidding when they call this guy the father of floating-point. [4]

So it is with all due seriousness that I consider the points he makes in an 81-page publication (co-authored by Joseph D. Darcy) entitled “How Java’s Floating Point Hurts Everyone Everywhere.” To introduce the topic, he illustrates the importance of standards adherence in the following way:

“What would happen to the market for automobiles if transmissions and chokes were not automatic, and if brakes and steering were not power-assisted? Would all drivers be dextrous and strong, or would there be fewer cars and more chauffeurs as in ‘the good old days?’ What if standards for vehicular body-strength, lights, brakes, tires, seat-belts, air-bags, safety-glass, … were relaxed? Would cheaper cars and trucks compensate us for the cost of
caring for more cripples?” ([1], p. 6)

If you think the analogy is over the top, you might be interested in the following floating-point disasters. But Kahan’s complaint, to be precise, is that “Java, mistakenly advertised as conforming to IEEE 754 . . ., pretends to lessen its diversity by adding another one to the few extant varieties of floating point.” ([1], p. 19)

Specifically, the Java specification didn’t provide exception flags and directed roundings [5], two capabilities mandated by the standard. Even putting the conveniences of directing rounding aside, Kahan argues that the flags were set in place for a reason: without carefully writing checks to make sure your numbers haven’t overflowed, underflowed, or whatever else, there’s no way to be completely certain that the plausible results your code produces aren’t actually completely invalid because of floating-point exceptions. Furthermore, writing these inline checks slows down computation, not to mention the burden it creates for programmers who have to consider every line of code with extra caution.

Ironically, Kahan alleges in [1] that James Gosling, a co-author of the original Java specification, once said that “Ninety-five percent of programmers know nothing about floating point.” The moral of the story, I guess, is that it’s okay for you to be a little hazy on the details of floating-point, unless you happen to be designing a world-changing programming language.

[1] http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf
[2] http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.html
[3] http://en.wikipedia.org/wiki/IEEE_floating-point_standard
[4] http://en.wikipedia.org/wiki/William_Kahan
[5] http://www.uni-ulm.de/admin/doku/javaspec/javaspec_10.html#HEADING74