Hello Matt, Great question. I’m going to reply first on the normal treatment of error in numerical applications, and separately on the larger question of design mistakes in hardware and software. You are correct that the Pentium bug fits into the second category, but many of the replies have focused on the first and they are both relevant. I’m not actually competent in numerical mathematics, but a spell in 2004-6 conducting full career oral history interviews with numerical software specialists as a subcontractor for the Society for Industrial and Applied Mathematics on a DOE grant exposed me to a lot of the history of this area in ways that have occasionally surfaced in my other work. The oral histories from the project are at http://history.siam.org/oralhistories.htm. One of the things it taught me is that the question of a “correct” numerical answer is not nearly as straightforward as most of us assume. In integer mathematics sure 2+2=4 etc. But the kinds of problems scientists needed early computers for invariably involved some very large and small quantities. So even though the hardware didn’t support floating point they basically had to do the same thing manually, storing a certain number of significant digits and tracking the scaling factor that related these to the actual quantity. If you look at the ENIAC flow diagram on our poster, you’ll see little notations tracking the power of ten scaling factors in front of many of the variable names in the program boxes https://eniacinaction.com/docs/MonteCarloPoster.pdf. That manual process was itself a major source of error and frustration, so from the 1950s onward all large computers intended for scientific use included hardware floating point so that if, for example, a very small quantity was multiplied by a very large constant the computer would figure out both the significant digits and the power of ten (or two) needed to scale them. But whether done manually or automatically, the numbers being represented are only approximations of the actual quantities. When doing calculations manually, scientist and engineers has always had to make a decision on how many digits to use, and doing that responsibly required some knowledge of how reliable the final answer would be based on the initial rounding and the potential of compounding errors as surplus digits were thrown away each time numbers were multiplied. The other important thing to understand here is that in real world computing even things like differential equations, which college calculus might fool you into thinking can be solved exactly, are solved approximately with numerical methods. These methods are usually iterative, based on measuring how far off target the current answer is so that an initial guess eventually converges on an accurate approximation. The conventional numerical methods found in textbooks, etc. were not well suited for automatic computers. Digital computers could carry our operations thousands of times faster than human computers, which in the worst case allowed errors to compound thousands of times faster. The new field of “numerical analysis” grew up at the intersection of computing and applied mathematics to address this. It included new methods to track the compounding of numerical errors through computations, and the development of more efficient and accurate algorithms for common mathematical chores such as calculating the matrix eigenvalues. I heard the terms “overflow,” “underflow,” “truncation error” and “rounding error” a lot in the interviews as well as more esoteric terms such as “successive overrelaxation.” One stream of work on “backward error analysis” led to an early Turing Award, for Jim Wilkinson (https://amturing.acm.org/award_winners/wilkinson_0671216.cfm). Those methods were also more complex and harder for non-specialists to reliably implement, which led to some of the earliest initiatives in software libraries (SHARE), peer-review of software, portable software (BLAS, PFORT), and software packaging and distribution (LINPACK and EISPACK). One side of the story I did tell was through biographies of Cleve Moler (https://tomandmaria.com/Tom/Writing/MolerBio.pdf) and Jack Dongarra (https://tomandmaria.com/Tom/Writing/DongarraBio.pdf). Moler founded Mathworks (which you probably hear sponsoring things on NPR). The specialists also complained that ordinary scientists and engineers didn’t want to develop the skills needed to understand which methods could safely be applied to which classes of equation, and so would introduce errors by grabbing the code for an inappropriate method. (A very popular book, Numerical Recipes, was accused of encouraging this and earned the disdain of some of my interviewees). Doing the interviews, I was struck by the very strong and personal aesthetic preferences the numerical software producers expressed for the floating point arithmetic of particular machines. The IBM 709X machines were acclaimed, whereas the CDC supercomputers were distained. I sneaked a little of this into the Revised History of Modern Computing with Paul Ceruzzi, in terms of the terrible step back introduced with the IBM System/360 arithmetic. This needed expensive fixes to installed computers, like the Pentium bug, but it wasn’t a bug – just the result of the design engineers making decisions without a good idea of how they would impact scientific users. Although System/360 was intended to work equally well for scientific and data processing applications it was much more successful for data processing. The problems began with the System/360 floating point. It used hexadecimal (base 16) rather than binary, which was efficient for smaller, business-oriented machines but would create major problems with rounding errors for scientific users. The new general-purpose registers raised more problems with the handling of single and double precision numbers. When IBM described its new architecture, William Kahan, then of Waterloo University, and others “went nuts” as they “recognized something really perverse about the arithmetic.” IBM found ways to work around some of the issues in software libraries, but Kahan recalls that after the full scale of the problem was acknowledged in 1966, following lobbying by SHARE, the company spent millions tweaking the hardware of machines already installed. The wide range of approaches to floating point arithmetic was also a threat to portability. FORTRAN code could be moved from one system to another, but it would give different answers when run on them. There might also be relatively large shifts in answers based on tiny variations in initial inputs. So the question of error gets complicated as the “right” answer depends on the machine the code is being run on. Also an algorithm might run accurately but give misleading answers because it is being applied to an equation with unsuitable characteristics. Kahan is the central figure in addressing these problems, leading the IEEE standards effort to come up with an optimal floating point design that could be standardized across manufactures. Luckily, Intel was the first adopter thanks to a consulting contract Kahan had. He’s a fascinating figure (I wrote the profile at (https://amturing.acm.org/award_winners/kahan_1023746.cfm) but relatively little known because floating point is seen as such a niche area. When I showed up for the interview he talked for 24 hours spread over four days (http://history.siam.org/pdfs2/Kahan_final.pdf) Here’s how we tell that story in the Revised History: Doing engineering calculations or financial modelling cost a lot less with a personal computer, such as the Apple II, than with a mainframe or timesharing system. But only small jobs would fit into its limited memory and run acceptably quickly. Complex models still needed big computers. That began to change with the IBM PC. Even the original IBM PC could be expanded to much larger memory capacities than the Apple. The other big difference was floating point. Since the 1950s capable floating-point hardware support had been the defining characteristic of large scientifically-oriented computers. The 8088 used in the original PC did not support floating point and its performance on technical calculations was mediocre. But every PC included an empty socket waiting for a new kind of chip, the 8087 “floating point coprocessor.” The 8087 was the first chip to implement a new approach to floating point, proposed by William Kahan and later formalized in the standard IEEE 754. Its adoption by firms including DEC and IBM was a major advance for scientific computing. Code, even in a standard language like FORTRAN, had previously produced inconsistent floating-point results when run on different computers. According to Jerome Coonen, a student of Kahan’s who managed software development for the original Macintosh, this standardization on robust mechanisms was a “huge step forward” from the previous “dismal situation…. Kahan’s achievement was having floating point taken for granted for 40 years.” The 8087 was announced in 1980 but trickled onto the market because it pushed the limits of Intel’s production processes. Writing in Byte, Steven S. Fried called it “a full-blown 80-bit processor that performs numerical operations up to 100 times faster… at the same speed as a medium-sized minicomputer, while providing more accuracy that most mainframes.” The 8088 itself had only 29,000 transistors, but its coprocessor needed 45,000 to implement its own registers and stack. Code had to be rewritten to use special floating-point instructions, were executed in parallel with whatever the main processor was doing. Scientific users quickly embraced the 8087, which made the PC a credible alternative to minicomputers. Fried had promised that “the 8087 can also work wonders with business applications” but software support was limited. Even Lotus-1-2-3, which existed only to crunch numbers, did not utilize it. Fried began a business selling patches to add coprocessor support to such packages. Over time, IEEE style floating point became a core part of every processor. By the time Intel launched the 80486 in 1989, its factories were just about able to manufacture a one million transistor chip with a coprocessor built in. Software developers, particularly videogame programmers, began to use floating point instructions. By the late-1990s PC processors competed largely on the strength of their floating-point capabilities. So that’s two big kinds of error to dig into: errors related to the handling of arithmetic in a particular machine and errors introduced by the algorithm (or as they call it “methods”) chosen to solve an equation numerically. Thanks to reliance on IEEE standard floating point and the eclipse of FORTRAN by modern systems like MATLAB both have been largely black-boxed from typical scientific users. Best wishes, Tom From: Members <members-bounces@lists.sigcis.org> On Behalf Of Matthew Kirschenbaum Sent: Friday, July 3, 2020 12:55 PM To: members <members@sigcis.org> Subject: [SIGCIS-Members] the nature of computational error Hello all, I am interested in a better understanding of the nature of computational error. My sense is that actual, literal (mathematical) mistakes in modern computers are quite rare; the notorious Pentium bug of the early 1990s is the exception that proves the rule. Most bugs are, rather, code proceeding to a perfectly correct logical outcome that just so happens to be inimical or intractable to the user and/or other dependent elements of the system. The Y2K "bug," for instance, was actually code executing in ways that were entirely internally self-consistent, however much havoc the code would wreak (or was expected to wreak). Can anyone recommend reading that will help me formulate such thoughts with greater confidence and accuracy? Or serve as a corrective? I'd like to read something fundamental and even philosophical about, as my subject line has it, the nature of computational error. I'd also be interested in collecting other instances comparable to the Pentium bug--bugs that were actual flaws and mistakes hardwired at the deepest levels of a system. Thank you-- Matt -- Matthew Kirschenbaum Professor of English and Digital Studies Director, Graduate Certificate in Digital Studies Printer's Devil, BookLab University of Maryland mgk@umd.edu <mailto:mgk@umd.edu>