July 2020 - Members - lists.sigcis.org

Update on SpaceWar!/Spacewar
by thomas.haigh＠gmail.com 16 Jul '20

16 Jul '20

Hello SIGCIS, I had some good off-list replies, so here's a wrap up for the benefit of the community. We've decided to use "Spacewar" in the text, with a note or parenthetical aside that Steve Russell prefers the name with an exclamation point. Eagle eyed readers may note that this is a slight variation from my original suggestion of noting that Spacewar! is the "official name." That's because a couple of responses have made me wonder what "official" would even mean. We already knew the game became famous in the 1970s and 1980s as "Spacewar". We also have a generally accepted idea that Steve Russell is on the record as liking the title more with the exclamation point. Peggy Kidwell of the National Museum of American History pointed me towards this catalog entry for a 1962 paper tape. https://americanhistory.si.edu/collections/search/object/nmah_1064201 That's just one year after the game was written. According to the catalog, "in compartment B - Friden Business Systems - Tape-Talk, X Good Space War. Also marked in punches: SPACEWAR 3.1 24 SEP 62 PT. 1" So it was written for humans as "Space War" and coded on the tape itself as "SPACEWAR". The tape was a gift from DEC itself, which makes sense as DEC is said to have been instrumental in spreading the game to show off and diagnose its display screens. Arthur Daemmrich at the Lemelson Center was also kind enough to look into this. He supplied me with a DEC brochure that used the game to sell the PDP-1. The cover gives the name as "SPACE/WAR" (on two lines) and the interior calls it both "SPACEWAR" and "Spacewar." I was able to find a copy of the brochure here: https://www.masswerk.at/spacewar/pdp-1-computer-and-spacewar.html. Arthur also raised the question with one of the original MIT programmers of the game, who did not recall the exclamation point being an integral part of the name. (I'm reluctant to share the full message without permission). I found a detailed technical examination of the game by Norbert Landsteiner at https://www.masswerk.at/spacewar/inside/. The author calls it Spacewar! throughout, but there is a suggestion that the filenames holding the binary contents of the original paper tapes, such as "spacewar2B_2apr.bin" are transcriptions of the labels on the original tapes. These do not contain the point. (Full list at https://www.masswerk.at/spacewar/sources/) The site also mentions code to punch "SPACEWAR" into tape headers. Since paper tapes didn't have a filename, the filename of the digital image would have presumingly been derived from a handwritten label, right at the start of the tape. Apparently, someone had written "Spacewar SA 5" on the tape. (Or, since there was a little program to punch a pattern reading "SPACEWAR" onto a tape, it might have been the title-punch and a handwritten "SA 5".) Finally, Arthur also sent an early article on the game, from Creative Computing in 1981. This _does_ include the exclamation point in the game's title and is thus the earliest recorded usage of it we've so far stumbled on. Chronologically this is between Brand's 1972 article and Levy's 1984 book. See https://archive.org/details/creativecomputing-1981-08/page/n59/mode/2up. The author, J.M. Graetz, was another of the MIT group behind the game. There's an earlier report by Graetz in the 1962 DECUS proceedings: http://bitsavers.org/pdf/dec/decus/confProceedings/DECUS_1962.pdf in which the name does have the point but is also capitalized: "SPACEWAR!" So putting it all together: "Spacewar!" is the preferred name for at least some of the members of the original hacker collective that produced the game at MIT and (as "SPACEWAR!") has been on record as such since 1962. On the other hand, it is not clear that the point was ever part of the name as written on the MIT program tapes holding the game or used when the name was punched as a header onto the tape. We _do_ have clear evidence that the PDP-1 game as distributed and advertised by DEC was called "Spacewar" with no point. So that would seem to be the "official" name to describe its use and influence beyond MIT. As using the name sometimes with and sometimes without the point depending on context would be confusing we'll standardize on the pointless DEC/Levy/Brand version of the name for the purposes of our book. Some of you may also feel that "pointless" is a good summary of this thread. Best wishes, Tom

1 0

Opinions on "Spacewar" vs. "Spacewar!"
by thomas.haigh＠gmail.com 15 Jul '20

15 Jul '20

Hello SIGCIS, I'm canvassing opinion on a small topic, as I work with Paul Ceruzzi to finalize revisions on the revised History of Modern Computing. There are a lot of style choices like FORTRAN vs Fortran, Internet vs internet, etc. where dominant usage has evolved over the past twenty years, generally in the clear direction of not capitalizing things that aren't acronyms. We're planning to follow that, while still capitalizing Internet and Web to respect the historical context. On the other hand, since the first edition the pioneering PDP-1 video game formerly known as Spacewar has grown an exclamation point to become Spacewar!. This causes problems with punctuation, as in the previous sentence. It did not have one in either of the accounts that made it famous, Levy's Hackers (1984) and Brand's 1972 article "SPACEWAR: Fanatic Life and Symbolic Death Among the Computer Bums." So one might assume that any punctuation attached to it in its original MIT incarnation had fallen by the wayside as it spread. The original Modern History followed this then-standard usage. Wikipedia now has the exclamation point, and so does the Computer History Museum: https://www.computerhistory.org/pdp-1/spacewar/. The Smithsonian appears to have endorsed it in its writeup of the NMAH anniversary event, https://www.smithsonianmag.com/smithsonian-institution/how-first-popular-vid eo-game-kicked-off-generations-virtual-adventure-180971020/. So I assume that this general shift must reflect some kind of movement in video game studies to reattach a lost piece of punctuation. On the other hand, there's a precedent for not using an exclamation point in books or articles even when it is part of a company self presentation: Yahoo!! (The second exclamation point there is my own excitement). The company used it consistently, but the AP Style Guide tells journalists to drop it when writing about Yahoo. We're following that in the revised history. So I'm torn about whether to follow the trend and use "Spacewar!" throughout, despite the punctuation problems it causes, or to apply the same logic as Yahoo and use "Spacewar" with an initial parenthetical observation that the official name is "Spacewar!". Best wishes, Tom

4 3

Ideas Embodied in Metal: Babbage’s Engines Dismembered and Remembered
by Brian Randell 10 Jul '20

10 Jul '20

Hi: I’ve just come across and read a fascinating and though-provoking account that adds significantly to the Babbage canon. Ideas Embodied in Metal: Babbage’s Engines Dismembered and Remembered Chap 6 of The Whipple Museum of the History of Science (Cambridge University Press, August 2019) pp 119-158. Simon Schaffer Abstract This chapter seeks to extend previous studies of Charles Babbage’s celebrated difference engine through an examination of a rare surviving fragment in the Whipple Museum’s collection. Constructed from scrap parts inherited by Charles’s son, Henry, in order to relaunch the engine project, the fragment has much to reveal about the afterlife of Babbage’s most famous failure. An appendix to the chapter also publishes for the first time key documents relating to Henry Babbage’s project. Full text: https://www.cambridge.org/core/books/whipple-museum-of-the-history-of-scien… Cheers Brian Randell — School of Computing, Newcastle University, 1 Science Square, Newcastle upon Tyne, NE4 5TG EMAIL = Brian.Randell(a)ncl.ac.uk PHONE = +44 191 208 7923 URL = http://www.ncl.ac.uk/computing/people/profile/brianrandell.html

1 0

Expert Systems and the Commercialization of Artificial Intelligence
by David C. Brock 08 Jul '20

08 Jul '20

Burt Grad and I are pleased to announce that we will be guest editing a special issue of the IEEE Annals of the History of Computing for early 2022 on “Expert Systems and the Commercialization of Artificial Intelligence.” We have most of the issue already lined up with contributions from key figures in various commercialization efforts with expert systems, describing and analyzing their technology and business experiences. We are currently seeking one or two additional articles that address the commercialization of artificial intelligence (expert systems or otherwise) from the 1970s to the 1990s. If members of this list have work that they feel might be a good fit for this special issue, please email David C. Brock directly at dbrock(a)computerhistory.org +++++++++++++++ David C. Brock dcb(a)dcbrock.net 40 Russell Street, Greenfield, MA 01301 Mobile: 413-522-3578 Skype: dcbrock Twitter: @dcbrock Pronouns: he, him, his

1 0

Correctness and verification
by thomas.haigh＠gmail.com 06 Jul '20

06 Jul '20

Returning for part II of the answer, on actual bugs. There is a huge computer science literature relevant to Matt’s question, but the key words are “correctness,” “formal methods,” “specification language” and “verification” rather than “error” or “bug.” With the Pentium bug, IIRC some bogus value in a lookup table deep in the processor caused it to give wrong answers. That’s an example of a situation where a finished system doesn’t perform in line with requirements. But how are requirements expressed? Typically with a written specification that leaves many things ambiguous. Going back to the 1950s a lot of work in systems analysis was aimed at coming up with methods to get specifications right so that the systems built from them would do what was required. A problem in the final system might be a result of a mistake in specification or in implementation. The computer science answer to this was to express specifications completely and unambiguously in mathematical terms and then prove that the final software/hardware would always do what the specification said. Both tasks were enormously difficult. A lot of the history is told in MacKenzie, Donald. Mechanizing Proof. Cambridge, MA: MIT Press, 2001 which is an extremely good book full of very clear explanations of difficult topics. This history includes the intervention of a philosopher, J.H. Fetzer, who IIRC said that claiming to prove any correspondence between a mathematical specification and a material object is a category error. So I’m sure there are pointers there to follow up for more recent philosophical work on the topic. I gave some autobiographically grounded thoughts on some of this in a recent paper “Assembling a Prehistory for Formal Methods” which also points to some papers by Niklaus Wirth and Cliff Jones giving insider views on the history. http://www.tomandmaria.com/Tom/Writing/FormalMethodsHistoryPreprint.pdf My suggestion is that the formal methods movement was in large part an outgrowth of the original impetus and core community behind both the Algol effort and the 1968 Software Engineering Conference (which has less than generally suggested to do with what was offered under the banner of “Software Engineering” by the 1980s). That appeared in special issue on the history of formal methods, which includes other, more technical, items of possible interest: https://link.springer.com/journal/165/31/6. Editing the Turing Award website (particularly ongoing work to add video clips to profiles) has also reminded me that several awards were given for work in this area, and in particular that the “model checking” approach has had a huge impact on how chip designs are tested. So Matt might want to look at the following entries: https://amturing.acm.org/award_winners/hoare_4622167.cfm https://amturing.acm.org/award_winners/sifakis_1701095.cfm https://amturing.acm.org/award_winners/emerson_1671460.cfm https://amturing.acm.org/award_winners/clarke_1167964.cfm Best wishes, Tom From: Members <members-bounces(a)lists.sigcis.org> On Behalf Of Matthew Kirschenbaum Sent: Friday, July 3, 2020 12:55 PM To: members <members(a)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(a)umd.edu <mailto:mgk@umd.edu>

5 4

AI progress measuring
by Jonathan Coopersmith 06 Jul '20

06 Jul '20

Interesting piece that raises some neat questions ranging from comparison to upgrading and hype: Core progress in AI has stalled in some fields 1. Matthew Hutson Science 29 May 2020: Vol. 368, Issue 6494, pp. 927DOI: 10.1126/science.368.6494.927 Stay sane, keep washing those hands, and practice social solidarity as well as distancing, JC Jonathan Coopersmith Professor Department of History Texas A&M University College Station, TX 77843-4236 979.739.4708 (cell) 979.862.4314 (fax) To teach or not to teach: https://www.tact.org/post/to-teach-in-person-or-not-that-is-the-question Most recent oped: "Will Artemis fail in the halls of Congress?" https://www.thespacereview.com/article/3836/1 Apollo thoughts: https://today.tamu.edu/2019/07/19/would-apollo-11-have-happened-without-rus… *FAXED. The Rise and Fall of the Fax Machine* (Johns Hopkins University Press) is the co-recipient of the 2016 Business History Conference Hagley Prize for best book in business history.

1 0

Wed, 7/22: Video Conferencing – Silicon Valley’s 50-Year History
by Brian Berg 05 Jul '20

05 Jul '20

Hello, With all the online events happening these days that have replaced in-person events and meetings, video conferencing has gone mainstream with the general public. We are pleased to promote the upcoming Wed, July 22 webinar <https://californiaconsultants.org/event/webinar-video-conferencing-silicon-…> of the IEEE Silicon Valley Technical History Committee which will detail how Silicon Valley has advanced this technology over the last 50+ years. Committee Chair (Tom Coughlin) and Vice Chair (myself) are both CNSV Board members. CNSV member Ken Pyle is also a committee member and event videographer, and he originated this webinar and will moderate the panel of speakers. Brian Berg *Wed, July 22, 1:30-2:30pm PDT* *Webinar: Video Conferencing – Silicon Valley’s 50-Year History <https://californiaconsultants.org/event/webinar-video-conferencing-silicon-…>* [image: NY-VideoPhone.jpg] The COVID-19 pandemic looks like it will be the catalyst that turns video conferencing into an everyday communications tool for use by everyday people. However, this 50+ year overnight success story has roots dating back to the 19th century, as well as the 1964 World’s Fair with AT&T’s vision of a videophone that would be as simple to use as a telephone. To realize that vision, many different technologies would have to be invented, refined and cost-reduced, including video capture and associated screens, broadband infrastructure and what came to be known as the cloud, and the digitalization of audio and video. The compression algorithms and methodologies that were used to dramatically reduce the amount of audio and video data needed to be transmitted were an essential enabler, and they will be the focus of this event. Silicon Valley’s history in this realm goes back over 50 years, and companies that no longer exist that built the foundation for video conferencing include Compression Labs, C-Cube and Divicom. However, their inventions were foundational, and companies including 8×8 and Intel still exist and are active in support of video conferencing as we use it today. Join the IEEE Silicon Valley Technical History Committee as we look back at the history of how we arrived at today’s technology, including how hype and marketing often raced ahead of the technology and infrastructure. Our speakers will discuss the lessons they learned along the way, and will explain how the various building blocks slowly came together. We will also provide a picture of what the future holds for richer communication experiences, including virtual reality and improved security. About the speaker, Dave House <dave(a)davehouse.com?subject=Inquiry%20from%20IEEE-CNSV%20Website> of House Family Vineyards <https://www.housefamilyvineyards.com/Story/House-Family> Dave House joined Intel Corp.in 1974, and led the company’s microprocessor division from the 80386 through the Pentium II in 1985-2003. He also launched Intel’s still very successful Server Products Division, and managed the team that introduced the “Intel Inside” marketing program. Dave was also instrumental in Intel’s 1988 purchase of Digital Video Interactive (DVI) technology from David Sarnoff Research Center Laboratories. DVI brought multimedia initially to DOS-based PCs, and later became a fundamental building block for Intel’s ProShare video conferencing system. Dave went on to lead several Silicon Valley telecom and networking stalwarts such as Bay Networks, Nortel, and Brocade, and he is currently the proprietor of the highly acclaimed House Family Vineyards. About the speaker, Eric Dorsey <eric_dorsey(a)mac.com?subject=Inquiry%20from%20IEEE-CNSV%20Website> Eric Dorsey’s primary expertise is in creating consumer products in the audio, video, neural networks and mobile space. He is currently managing projects for the US government using AI and Machine Learning in the area of national security. Eric was Director of Engineering at San Jose-based Compression Laboratories, a pioneer in video compression for both video conferencing and television distribution networks. He was involved in the initial meetings of the MPEG standard committees, and went on to senior roles at notable set-top companies such as Thomson and San Jose-based TiVo. More recently, he worked on a project for preserving Dr. Stephen Hawking’s synthetic voice <https://www.npr.org/2018/03/27/597390626/an-engineers-quest-to-save-stephen…> . About the speaker, Bryan Martin <bmartin(a)8x8.com?subject=Inquiry%20from%20IEEE-CNSV%20Website> of 8x8, Inc. <https://www.8x8.com/> Bryan Martin is Chairman and CTO of 8×8, Inc. in Campbell. He led the company’s transition from hardware to its Unified Communications as a Service offering which integrates voice and video over IP in a single platform to enable cloud phone, video collaboration, team chat, contact center and analytics functionalities. Bryan’s early work in compression was at Santa Clara-based Integrated Information Technology (IIT) where he helped develop the Vision Processor chips that allowed JPEG image encoding and decoding at video rates, and which could also perform both MPEG and H.261 compression and decompression of audio and video data. San Jose-based Compression Labs used these chips as a replacement for discrete circuits in its systems. About the speaker, Ken Pyle <ken.pyle(a)viodi.com?subject=Inquiry%20from%20IEEE-CNSV%20Website> of Viodi, LLC <https://viodi.com/> Ken Pyle will moderate the above panel of speakers. Ken is a CNSV member <https://californiaconsultants.org/members/ken-pyle/> who has been a videographer of many past CNSV events. He began working in field service and product management roles in the cable television and video industries starting in the 1980s, including Catel and Comlux/C-Cor. As these companies were providers of uni- and bi-directional analog and digital video transmission systems, this led Ken into work with video-on-demand (VOD) providers. In 2002, he founded Viodi, a premier provider of information and assistance to independent communications service providers and their vendors. Besides creating well over 100 video interviews and “documonials” annually, Ken is managing editor of the Viodi View newsletter <https://viodi.com/> and producer of the ViodiTV YouTube channel <https://www.youtube.com/watch?v=Yugch_31fyA>.

1 0

the nature of computational error
by Matthew Kirschenbaum 05 Jul '20

05 Jul '20

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(a)umd.edu

9 9

Numerical errors
by thomas.haigh＠gmail.com 04 Jul '20

04 Jul '20

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(a)lists.sigcis.org> On Behalf Of Matthew Kirschenbaum Sent: Friday, July 3, 2020 12:55 PM To: members <members(a)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(a)umd.edu <mailto:mgk@umd.edu>

2 1

Re: [SIGCIS-Members] the nature of computational error
by Sam Kellogg 04 Jul '20

04 Jul '20

Hello Matt, all, What an exciting email thread! For those many of you who don't know me, my name is Sam Kellogg—I'd a PhD student in Media, Culture, and Communication at NYU and a long-time lurker on this list. My current dissertation research actually revolves around this very question of computational error, in a historical, philosophical, and linguistic sense—Matt, I think that you're absolutely right in your characterization of 'literal' mathematical error being a rather rare occurrence, though what precisely we mean by error is perhaps what most needs unpacking. After all, many of the 'error' messages we encounter seem to signify that things are still working as intended, at least on some level—the machine is still humming along! Anyways, I thoroughly agree this question needs a good deal more attention. I presented a paper on a specific class of error at SIGCIS in Milan last year. This was based on a series of contemporary empirical cases of errors I encountered that were functioning in overtly political ways in the context of the U.S. embargo on Cuba, but which were still appearing *as though* they had purely technical origins. Sanctions and political disjunctures, I argued, were being internalized within software systems as 'errors' (sometimes with accompanying bug reports and maintenance tickets!) with all kinds of bizarre outcomes. The fieldwork, undertaken a few years ago when travel between New York and Havana was a bit simpler, led me down a rabbit hole of questioning the role of error in the history of computation more broadly, and as well as in mathematics and philosophy, and I've been trying to think through these questions in view of some of the political consequences that we see downstream. I'd be happy to send you, and anyone else on this list, my slides and notes, with the proviso that the project has progressed quite a bit since then. Laurent, Chuck, Annette, Paul, Tom, and everyone else who has already responded (I receive the digest of this list so apologies if I've missed someone), all of these recommendations are exceedingly valuable. I am in the midst of moving house right now, but if there is interest I could put together a selection from my bibliography along with the materials already shared to distribute over the coming week. I myself have become particularly fascinated by Turing Award winner Richard Hamming's work on error (his early paper and accompanying patent for Error detecting and error correcting codes <https://ieeexplore.ieee.org/document/6772729> is a key touchpoint), who I don't think has been mentioned yet. The backstory of how he ended up working on error in the first place is a good one, and I'm working on writing up this history, likely as a dissertation chapter, right now. Hamming's notion of what we now refer to as Hamming Distance <https://en.wikipedia.org/wiki/Hamming_distance> is well worth reading up on—according to this schema, greater deviation from an intended message is rendered as greater 'distance' within a multidimensional space, a powerful transformation of the problem into spatialized terms. There's a great deal more to say here about how error is conceived of metaphorically and visually in order to transform it into something a little more workable or interpretable in different contexts, though for the moment I'll spare this list any further rambling. Matt, and anyone else actively pursuing this topic, please do reach out—I'd love to discuss further, hear more about parallel research, and in general welcome fellow travellers in the theory and history of error! Warm regards, Sam -- Sam P. Kellogg MCC, NYU <http://steinhardt.nyu.edu/mcc/> // PUBLIC CULTURE <https://read.dukeupress.edu/public-culture> // samkellogg.com

1 0