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
Hi, You should have a look on this paper: https://hal.archives-ouvertes.fr/hal-01340384/document https://hal.archives-ouvertes.fr/hal-01340384 I believe it could meet your interest. Cheers! Le Fri, 3 Jul 2020 13:54:44 -0400, Matthew Kirschenbaum <mkirschenbaum@gmail.com> a écrit :
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
-- Laurent Bloch - https://www.laurentbloch.net - lb@laurentbloch.org Si vous trouvez que l'éducation coûte cher, essayez l'ignorance ! (A. Lincoln)
Matthew, the ‘famous’ error before the Pentium bug was the “Inverse Log of 2.02” error in the original HP35 handheld calculator. We wound up replacing a lot of firmware as a result. The bug is described well down in this article http://www.hpcc.org/calculators/wmjarts.html For my talk at the ACM History of Personal Computing January 1986, here is the video https://www.computerhistory.org/collections/catalog/102695114 In it at minute 51:00, Tom Osborne, the key creator of HP’s 9100 and HP 35 describes the issue surrounding this “Inverse log of 2.02” error. This is the only description I’ve ever heard Chuck House www.innovascapesinstitute.com www.anywhereanytime.io/covid19 http://innovascapes.blogspot.com 805-570-6706 From: Members <members-bounces@lists.sigcis.org> on behalf of Matthew Kirschenbaum <mkirschenbaum@gmail.com> Date: Friday, July 3, 2020 at 10:55 AM 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 _______________________________________________ This email is relayed from members at sigcis.org, the email discussion list of SHOT SIGCIS. Opinions expressed here are those of the member posting and are not reviewed, edited, or endorsed by SIGCIS. The list archives are at http://lists.sigcis.org/pipermail/members-sigcis.org/ and you can change your subscription options at http://lists.sigcis.org/listinfo.cgi/members-sigcis.org
Hi Matt, This article might be useful to you, from the special issue of *Computational Culture *on Rhetoric and Computation that Jim Brown and I co-edited: Matthew Bellinger. “The Rhetoric of Error in Digital Media.” *Computational Culture* 5 (15th January 2016). http://computationalculture.net/the-rhetoric-of-error-in-digital-media-2/. Good luck! Annette On Fri, Jul 3, 2020 at 2:37 PM Chuck House <housec1839@gmail.com> wrote:
Matthew, the ‘famous’ error before the Pentium bug was the “Inverse Log of 2.02” error in the original HP35 handheld calculator. We wound up replacing a lot of firmware as a result.
The bug is described well down in this article http://www.hpcc.org/calculators/wmjarts.html
For my talk at the ACM History of Personal Computing January 1986, here is the video https://www.computerhistory.org/collections/catalog/102695114
In it at minute 51:00, Tom Osborne, the key creator of HP’s 9100 and HP 35 describes the issue surrounding this “Inverse log of 2.02” error. This is the only description I’ve ever heard
Chuck House
www.innovascapesinstitute.com
www.anywhereanytime.io/covid19
[image: signature_656552628]
http://innovascapes.blogspot.com
805-570-6706
*From: *Members <members-bounces@lists.sigcis.org> on behalf of Matthew Kirschenbaum <mkirschenbaum@gmail.com> *Date: *Friday, July 3, 2020 at 10:55 AM *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
_______________________________________________ This email is relayed from members at sigcis.org, the email discussion list of SHOT SIGCIS. Opinions expressed here are those of the member posting and are not reviewed, edited, or endorsed by SIGCIS. The list archives are at http://lists.sigcis.org/pipermail/members-sigcis.org/ and you can change your subscription options at http://lists.sigcis.org/listinfo.cgi/members-sigcis.org _______________________________________________ This email is relayed from members at sigcis.org, the email discussion list of SHOT SIGCIS. Opinions expressed here are those of the member posting and are not reviewed, edited, or endorsed by SIGCIS. The list archives are at http://lists.sigcis.org/pipermail/members-sigcis.org/ and you can change your subscription options at http://lists.sigcis.org/listinfo.cgi/members-sigcis.org
Rounding error is ubiquitous and unavoidable in digital computers, but with high precision computing (64-bit, 128-bit) it’s so small as to be negligible. However, in cases where the same computation is performed many thousands or millions of times, it can still accumulate to a point that it’s significant. MacKenzie, D. (1993). Negotiating Arithmetic, Constructing Proof: The Sociology of Mathematics and Information Technology. Social Studies of Science, 23(1), 37-65. Also see the short examples of this in my book A Vast Machine: Computer Models, Climate Data, and the Politics of Global Warming (MIT Press, 2010), pages 177-178. Best, Paul On Jul 3, 2020, at 10:54, Matthew Kirschenbaum <mkirschenbaum@gmail.com<mailto:mkirschenbaum@gmail.com>> wrote: 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> _______________________________________________ This email is relayed from members at sigcis.org<http://sigcis.org>, the email discussion list of SHOT SIGCIS. Opinions expressed here are those of the member posting and are not reviewed, edited, or endorsed by SIGCIS. The list archives are at http://lists.sigcis.org/pipermail/members-sigcis.org/ and you can change your subscription options at http://lists.sigcis.org/listinfo.cgi/members-sigcis.org ________________________ Paul N. Edwards<https://profiles.stanford.edu/paul-edwards> Director, Program on Science, Technology & Society<http://sts.stanford.edu> William J. Perry Fellow in International Security and Senior Research Scholar Center for International Security and Cooperation<http://cisac.fsi.stanford.edu/> Co-Director, Stanford Existential Risks Initiative<https://cisac.fsi.stanford.edu/stanford-existential-risks-initiative> Stanford University Professor of Information<http://www.si.umich.edu/> and History<http://www.lsa.umich.edu/history/> (Emeritus) University of Michigan
Although physicists often use rules of thumb, the precision of calculation became an important point in John von Neumann's policy against the analogue computer. The precision of individual calculations on analog machines is lower than on digital machines. But the final results of integrating a differential equation were the same on analog machines as on digital ones, as comparisons in the 1950s showed, see my paper The Computing Boom in the US Aeronautical Industry, 1945–1965, in: ICON – The Journal of the International Committee for the History of Technology, volume 24, 2019, pp. 127–149. Best, Richard On 03.07.2020 22:18, Paul N. Edwards wrote:
Rounding error is ubiquitous and unavoidable in digital computers, but with high precision computing (64-bit, 128-bit) it’s so small as to be negligible.
However, in cases where the same computation is performed many thousands or millions of times, it can still accumulate to a point that it’s significant.
MacKenzie, D. (1993). Negotiating Arithmetic, Constructing Proof: The Sociology of Mathematics and Information Technology. Social Studies of Science, 23(1), 37-65.
Also see the short examples of this in my book A Vast Machine: Computer Models, Climate Data, and the Politics of Global Warming (MIT Press, 2010), pages 177-178.
Best,
Paul
On Jul 3, 2020, at 10:54, Matthew Kirschenbaum <mkirschenbaum@gmail.com<mailto:mkirschenbaum@gmail.com>> wrote:
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> _______________________________________________ This email is relayed from members at sigcis.org<http://sigcis.org>, the email discussion list of SHOT SIGCIS. Opinions expressed here are those of the member posting and are not reviewed, edited, or endorsed by SIGCIS. The list archives are at http://lists.sigcis.org/pipermail/members-sigcis.org/ and you can change your subscription options at http://lists.sigcis.org/listinfo.cgi/members-sigcis.org
________________________ Paul N. Edwards<https://profiles.stanford.edu/paul-edwards>
Director, Program on Science, Technology & Society<http://sts.stanford.edu> William J. Perry Fellow in International Security and Senior Research Scholar Center for International Security and Cooperation<http://cisac.fsi.stanford.edu/> Co-Director, Stanford Existential Risks Initiative<https://cisac.fsi.stanford.edu/stanford-existential-risks-initiative> Stanford University
Professor of Information<http://www.si.umich.edu/> and History<http://www.lsa.umich.edu/history/> (Emeritus) University of Michigan
_______________________________________________ This email is relayed from members at sigcis.org, the email discussion list of SHOT SIGCIS. Opinions expressed here are those of the member posting and are not reviewed, edited, or endorsed by SIGCIS. The list archives are at http://lists.sigcis.org/pipermail/members-sigcis.org/ and you can change your subscription options at http://lists.sigcis.org/listinfo.cgi/members-sigcis.org
-- ******************************************** Prof. Dr. Richard Vahrenkamp Logistik Consulting Berlin Phone 0177- 628 3325 E-Mail: Vahrenkamp2016@gmx.de Web: www.vahrenkamp.org Trendelenburgstr. 16 14057 Berlin *********************************************
If you are interested in the human side of the discussion of error, I'd suggest taking a look at chapter 4 of Otte and Mlynarczyk's 2010 book on Basic Writing <https://wac.colostate.edu/books/referenceguides/basicwriting/> and Stuart Moultrhop's essay "Error 1337" in the collection edited by Mark Nunes entitled "Error: Glitch, Noise, and Jam in New Media <https://books.google.com/books?id=tvGoAwAAQBAJ&newbks=1&newbks_redir=0&dq=nunes+error&source=gbs_navlinks_s>" (Bloomsbury, 2010). For a 19th c. perspective, you might want to take a look at Kuno Fischer's chapter on "The Origin of Error" in his History of Modern Philosophy <https://books.google.com/books?id=JmANAAAAIAAJ&pg=PA360&dq=error+and+philosophy&hl=en&newbks=1&newbks_redir=0&sa=X&ved=2ahUKEwjL7LDXjLTqAhVLg3IEHRNiAwsQ6AEwAHoECAAQAg#v=snippet&q=error%20&f=false> (1854–77; the link is to an 1887 English translation). All best, Johannah On Sat, Jul 4, 2020 at 10:04 AM Richard Vahrenkamp <vahrenkamp2@gmx.de> wrote:
Although physicists often use rules of thumb, the precision of calculation became an important point in John von Neumann's policy against the analogue computer. The precision of individual calculations on analog machines is lower than on digital machines. But the final results of integrating a differential equation were the same on analog machines as on digital ones, as comparisons in the 1950s showed, see my paper The Computing Boom in the US Aeronautical Industry, 1945–1965, in: ICON – The Journal of the International Committee for the History of Technology, volume 24, 2019, pp. 127–149.
Best, Richard
On 03.07.2020 22:18, Paul N. Edwards wrote:
Rounding error is ubiquitous and unavoidable in digital computers, but with high precision computing (64-bit, 128-bit) it’s so small as to be negligible.
However, in cases where the same computation is performed many thousands or millions of times, it can still accumulate to a point that it’s significant.
MacKenzie, D. (1993). Negotiating Arithmetic, Constructing Proof: The Sociology of Mathematics and Information Technology. Social Studies of Science, 23(1), 37-65.
Also see the short examples of this in my book A Vast Machine: Computer Models, Climate Data, and the Politics of Global Warming (MIT Press, 2010), pages 177-178.
Best,
Paul
On Jul 3, 2020, at 10:54, Matthew Kirschenbaum <mkirschenbaum@gmail.com<mailto:mkirschenbaum@gmail.com> <mkirschenbaum@gmail.com>> wrote:
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 Marylandmgk@umd.edu<mailto:mgk@umd.edu> <mgk@umd.edu> _______________________________________________ This email is relayed from members at sigcis.org<http://sigcis.org> <http://sigcis.org>, the email discussion list of SHOT SIGCIS. Opinions expressed here are those of the member posting and are not reviewed, edited, or endorsed by SIGCIS. The list archives are at http://lists.sigcis.org/pipermail/members-sigcis.org/ and you can change your subscription options at http://lists.sigcis.org/listinfo.cgi/members-sigcis.org
________________________ Paul N. Edwards<https://profiles.stanford.edu/paul-edwards> <https://profiles.stanford.edu/paul-edwards>
Director, Program on Science, Technology & Society<http://sts.stanford.edu> <http://sts.stanford.edu> William J. Perry Fellow in International Security and Senior Research Scholar Center for International Security and Cooperation<http://cisac.fsi.stanford.edu/> <http://cisac.fsi.stanford.edu/> Co-Director, Stanford Existential Risks Initiative<https://cisac.fsi.stanford.edu/stanford-existential-risks-initiative> <https://cisac.fsi.stanford.edu/stanford-existential-risks-initiative> Stanford University
Professor of Information<http://www.si.umich.edu/> <http://www.si.umich.edu/> and History<http://www.lsa.umich.edu/history/> <http://www.lsa.umich.edu/history/> (Emeritus) University of Michigan
_______________________________________________ This email is relayed from members at sigcis.org, the email discussion list of SHOT SIGCIS. Opinions expressed here are those of the member posting and are not reviewed, edited, or endorsed by SIGCIS. The list archives are at http://lists.sigcis.org/pipermail/members-sigcis.org/ and you can change your subscription options at http://lists.sigcis.org/listinfo.cgi/members-sigcis.org
-- ******************************************** Prof. Dr. Richard Vahrenkamp Logistik Consulting Berlin Phone 0177- 628 3325 E-Mail: Vahrenkamp2016@gmx.de Web: www.vahrenkamp.org Trendelenburgstr. 16 14057 Berlin
*********************************************
_______________________________________________ This email is relayed from members at sigcis.org, the email discussion list of SHOT SIGCIS. Opinions expressed here are those of the member posting and are not reviewed, edited, or endorsed by SIGCIS. The list archives are at http://lists.sigcis.org/pipermail/members-sigcis.org/ and you can change your subscription options at http://lists.sigcis.org/listinfo.cgi/members-sigcis.org
-- johannahrodgers@gmail.com www.johannahrodgers.net
I'd like to thank everyone on the list who has responded so generously to my query, both here and back channel. Tom's posts are, as always, marvels. There's a lot for me to work with here. List members might enjoy going back to Ellen Ullman's 2002 novel *The Bug*, which is a dark but loving recreation early programmer culture from someone who was there. Here's a snippet to enjoy, just as a small thank you: On Sat, Jul 4, 2020 at 1:27 PM Johannah Rodgers <johannah.rodgers@gmail.com> wrote:
If you are interested in the human side of the discussion of error, I'd suggest taking a look at chapter 4 of Otte and Mlynarczyk's 2010 book on Basic Writing <https://wac.colostate.edu/books/referenceguides/basicwriting/> and Stuart Moultrhop's essay "Error 1337" in the collection edited by Mark Nunes entitled "Error: Glitch, Noise, and Jam in New Media <https://books.google.com/books?id=tvGoAwAAQBAJ&newbks=1&newbks_redir=0&dq=nunes+error&source=gbs_navlinks_s>" (Bloomsbury, 2010). For a 19th c. perspective, you might want to take a look at Kuno Fischer's chapter on "The Origin of Error" in his History of Modern Philosophy <https://books.google.com/books?id=JmANAAAAIAAJ&pg=PA360&dq=error+and+philosophy&hl=en&newbks=1&newbks_redir=0&sa=X&ved=2ahUKEwjL7LDXjLTqAhVLg3IEHRNiAwsQ6AEwAHoECAAQAg#v=snippet&q=error%20&f=false> (1854–77; the link is to an 1887 English translation).
All best,
Johannah
On Sat, Jul 4, 2020 at 10:04 AM Richard Vahrenkamp <vahrenkamp2@gmx.de> wrote:
Although physicists often use rules of thumb, the precision of calculation became an important point in John von Neumann's policy against the analogue computer. The precision of individual calculations on analog machines is lower than on digital machines. But the final results of integrating a differential equation were the same on analog machines as on digital ones, as comparisons in the 1950s showed, see my paper The Computing Boom in the US Aeronautical Industry, 1945–1965, in: ICON – The Journal of the International Committee for the History of Technology, volume 24, 2019, pp. 127–149.
Best, Richard
On 03.07.2020 22:18, Paul N. Edwards wrote:
Rounding error is ubiquitous and unavoidable in digital computers, but with high precision computing (64-bit, 128-bit) it’s so small as to be negligible.
However, in cases where the same computation is performed many thousands or millions of times, it can still accumulate to a point that it’s significant.
MacKenzie, D. (1993). Negotiating Arithmetic, Constructing Proof: The Sociology of Mathematics and Information Technology. Social Studies of Science, 23(1), 37-65.
Also see the short examples of this in my book A Vast Machine: Computer Models, Climate Data, and the Politics of Global Warming (MIT Press, 2010), pages 177-178.
Best,
Paul
On Jul 3, 2020, at 10:54, Matthew Kirschenbaum <mkirschenbaum@gmail.com<mailto:mkirschenbaum@gmail.com> <mkirschenbaum@gmail.com>> wrote:
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 Marylandmgk@umd.edu<mailto:mgk@umd.edu> <mgk@umd.edu> _______________________________________________ This email is relayed from members at sigcis.org<http://sigcis.org> <http://sigcis.org>, the email discussion list of SHOT SIGCIS. Opinions expressed here are those of the member posting and are not reviewed, edited, or endorsed by SIGCIS. The list archives are at http://lists.sigcis.org/pipermail/members-sigcis.org/ and you can change your subscription options at http://lists.sigcis.org/listinfo.cgi/members-sigcis.org
________________________ Paul N. Edwards<https://profiles.stanford.edu/paul-edwards> <https://profiles.stanford.edu/paul-edwards>
Director, Program on Science, Technology & Society<http://sts.stanford.edu> <http://sts.stanford.edu> William J. Perry Fellow in International Security and Senior Research Scholar Center for International Security and Cooperation<http://cisac.fsi.stanford.edu/> <http://cisac.fsi.stanford.edu/> Co-Director, Stanford Existential Risks Initiative<https://cisac.fsi.stanford.edu/stanford-existential-risks-initiative> <https://cisac.fsi.stanford.edu/stanford-existential-risks-initiative> Stanford University
Professor of Information<http://www.si.umich.edu/> <http://www.si.umich.edu/> and History<http://www.lsa.umich.edu/history/> <http://www.lsa.umich.edu/history/> (Emeritus) University of Michigan
_______________________________________________ This email is relayed from members at sigcis.org, the email discussion list of SHOT SIGCIS. Opinions expressed here are those of the member posting and are not reviewed, edited, or endorsed by SIGCIS. The list archives are at http://lists.sigcis.org/pipermail/members-sigcis.org/ and you can change your subscription options at http://lists.sigcis.org/listinfo.cgi/members-sigcis.org
-- ******************************************** Prof. Dr. Richard Vahrenkamp Logistik Consulting Berlin Phone 0177- 628 3325 E-Mail: Vahrenkamp2016@gmx.de Web: www.vahrenkamp.orgTrendelenburgstr. 16 14057 Berlin <https://www.google.com/maps/search/Trendelenburgstr.+16%0D%0A14057+Berlin?entry=gmail&source=g>
*********************************************
_______________________________________________ This email is relayed from members at sigcis.org, the email discussion list of SHOT SIGCIS. Opinions expressed here are those of the member posting and are not reviewed, edited, or endorsed by SIGCIS. The list archives are at http://lists.sigcis.org/pipermail/members-sigcis.org/ and you can change your subscription options at http://lists.sigcis.org/listinfo.cgi/members-sigcis.org
-- johannahrodgers@gmail.com www.johannahrodgers.net
-- Matthew Kirschenbaum Professor of English and Digital Studies Director, Graduate Certificate in Digital Studies Printer's Devil, BookLab University of Maryland mgk@umd.edu
Hello, I would reiterate Paul Edwards suggestion and add that depending on what kind of error and what kind of analysis you are looking for etc. it might be worth checking out Donald MacKenzie's book expanding on the subject of the mentioned essay Mechanizing Proof: Computing, Risk, and Trust. MIT Press, 2001. My vague sense is that errors like the Pentium Error are not actually that rare? Flaws or suboptimal arrangements of hardwired code are noticed and work arounds developped now and then in various iterations of popular chip design, they are usually just much more obscure technical problems. Looking at the Wikipedia page for the Pentium error I see reference to at least one other Pentium chip error that had been discovered: https://en.wikipedia.org/wiki/Pentium_FDIV_bug https://en.wikipedia.org/wiki/Pentium_F00F_bug Depending on what you mean by error one of the deadlier errors known in computing may actually be bad interface design. There was a brand of automatic morphine pumps which in at least a few cases was misprogrammed to deliver a lethal dose to patients. If I understand correctly other morphine pumps never saw this human error committed, suggesting that poor interface design/human factors engineering is responsible. I learned about this case from a popular introduction to human factors engineering Kim Vincente The Human Factor, Alfred A. Knopf, 2003. Pages 142-150 for an account of the morphine pump. Human factors engineering also plays a role in aviation disasters, nuclear disasters and so on. More recent accounts might relate these more to computing practice and discuss the morphine pump case more definitively, I am afraid I have limited familiarity with the literature. In terms of obscure debtates about error in the earlier history of computing, one that I have come across that might be of interest although perhaps not is the concern among some earlier pioneers that in fixed point errors led almost inevitably to the results being the wrong order of magnitude and so clearly wrong, whereas with floating point, the order of magnitude being accumulated separate from the rest of the result errors could creep in to the signficant figures without affecting the magnitude leading to difficult to detect errors. I am not clear that this fear was well founded or widespread, but I know of at least two researchers who talk about it (I don't know of any source that summarizes discussion of the worry it is just somehting I noticed in my primary source reading and never really followed up). Mathematical physicist Martin Schwarzchild explains briefly the worry in an interview (page 20 of the pdf seen here https://conservancy.umn.edu/handle/11299/107629 ) with regards to working on the IAS machine. Herb Grosch mentions in his memoir his opposition to floating point in the 1940s and 50s, but never quite explains his opposition I am pretty sure it is motivated by what Schwarzchild articulated (here is an instance on page 120 where he alludes to his misgivings http://www.columbia.edu/cu/computinghistory/computer.html#[-120-] but there are only 13 instances of floating point in the book so you quickly find instances by searching for that if you are interested). Sorry to give such on worked out thought/case. -- Yours Truly, Allan Olley, PhD http://individual.utoronto.ca/fofound/ On Fri, 3 Jul 2020, Paul N. Edwards wrote:
Rounding error is ubiquitous and unavoidable in digital computers, but with high precision computing (64-bit, 128-bit) it’s so small as to be negligible. However, in cases where the same computation is performed many thousands or millions of times, it can still accumulate to a point that it’s significant.
MacKenzie, D. (1993). Negotiating Arithmetic, Constructing Proof: The Sociology of Mathematics and Information Technology. Social Studies of Science, 23(1), 37-65.
Also see the short examples of this in my book A Vast Machine: Computer Models, Climate Data, and the Politics of Global Warming (MIT Press, 2010), pages 177-178.
Best,
Paul
On Jul 3, 2020, at 10:54, Matthew Kirschenbaum <mkirschenbaum@gmail.com> wrote:
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 _______________________________________________ This email is relayed from members at sigcis.org, the email discussion list of SHOT SIGCIS. Opinions expressed here are those of the member posting and are not reviewed, edited, or endorsed by SIGCIS. The list archives are at http://lists.sigcis.org/pipermail/members-sigcis.org/ and you can change your subscription options at http://lists.sigcis.org/listinfo.cgi/members-sigcis.org
________________________ Paul N. Edwards
Director, Program on Science, Technology & Society William J. Perry Fellow in International Security and Senior Research Scholar Center for International Security and Cooperation Co-Director, Stanford Existential Risks Initiative Stanford University
Professor of Information and History (Emeritus) University of Michigan
Hi all, Just copying the email I sent to Matthew a few days ago to contribute to the scholarship on this subject. "....a copy of my recent book (*High-Tech Trash: Glitch, Noise, and Aesthetic Failure <https://www.luminosoa.org/site/books/10.1525/luminos.83/>, *University of California Press, 2019) which addresses themes of error, accident, and failure in computational systems, albeit primarily from the perspective of aesthetics." The book can also be downloaded for free, through open access here: *High-Tech Trash: Glitch, Noise, and Aesthetic Failure <https://www.luminosoa.org/site/books/10.1525/luminos.83/>* Best, Carolyn L. Kane, Author of *High-Tech Trash: Glitch, Noise, and Aesthetic Failure <https://www.luminosoa.org/site/books/10.1525/luminos.83/>* (University of California Press, 2019) *Chromatic Algorithms: Synthetic Color, Computer Art, and Aesthetics after Code <http://www.amazon.com/Chromatic-Algorithms-Carolyn-L-Kane/dp/022600273X/ref=sr_1_3?s=books&ie=UTF8&qid=1387478152&sr=1-3>* (University of Chicago Press, 2014) https://www.ryerson.ca/kane/ Associate Professor, School of Professional Communication Faculty of Communication and Design Ryerson University 80 Gould Street Toronto, Ontario Canada M5B 2K3 Carolyn L. Kane, Author of *High-Tech Trash: Glitch, Noise, and Aesthetic Failure <https://www.luminosoa.org/site/books/10.1525/luminos.83/>* (University of California Press, 2019) *Chromatic Algorithms: Synthetic Color, Computer Art, and Aesthetics after Code <http://www.amazon.com/Chromatic-Algorithms-Carolyn-L-Kane/dp/022600273X/ref=sr_1_3?s=books&ie=UTF8&qid=1387478152&sr=1-3>* (University of Chicago Press, 2014) https://www.ryerson.ca/kane/ Associate Professor, School of Professional Communication Faculty of Communication and Design Ryerson University 80 Gould Street Toronto, Ontario Canada M5B 2K3 On Fri, Jul 3, 2020 at 1:55 PM Matthew Kirschenbaum <mkirschenbaum@gmail.com> wrote:
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 _______________________________________________ This email is relayed from members at sigcis.org, the email discussion list of SHOT SIGCIS. Opinions expressed here are those of the member posting and are not reviewed, edited, or endorsed by SIGCIS. The list archives are at http://lists.sigcis.org/pipermail/members-sigcis.org/ and you can change your subscription options at http://lists.sigcis.org/listinfo.cgi/members-sigcis.org
participants (9)
-
Allan Olley -
Annette Vee -
Carolyn Kane -
Chuck House -
Johannah Rodgers -
Laurent Bloch -
Matthew Kirschenbaum -
Paul N. Edwards -
Richard Vahrenkamp