MathGroup Archive 1994

[Date Index] [Thread Index] [Author Index]

Search the Archive

FWD: Pentium bug !! (THAT'S A PC...) (fwd)

  • To: mathgroup at christensen.cybernetics.net
  • Subject: [mg244] FWD: Pentium bug !! (THAT'S A PC...) (fwd)
  • From: BOSS at PMEL.NOAA.GOV
  • Date: Mon, 28 Nov 1994 10:50:43 -0700 (PDT)

From:	IN%"csc at coast.UCSD.EDU"  "Charles Coughran"    18-NOV-1994 08:30
To:	IN%"oceantech at ucsd.edu"
CC:	
Subj:	Pentium bug !! (THAT'S A PC...) (fwd)

FYI Pentium floating point division bug.

                                              -Charles Coughran
                                               ccoughran at ucsd.edu

---------- Forwarded message ----------

> >
> > Subject: Pentium Floating Point Bug     Date: 15 Nov 1994
> > Summary: Divisions might give incorrect results on Pentium
> > 
> >               Pentium Floating Point Division Bug
> > 
> > There has been a flurry of activity the last fews days on the
> > Internet news group, comp.sys.intel, that should interest MATLAB
> > users.  A serious design flaw has been discovered in the floating
> > point unit on Intel's Pentium chip.  Double precision divisions
> > involving operands with certain bit patterns can produce incorrect
> > results.
> > 
> > The most dramatic example seen so far can be extracted from a
> > posting last night by Tim Coe of Vitesse Semiconductor.  In MATLAB,
> > his example becomes
> > 
> >     x = 4195835
> >     y = 3145727
> >     z = x - (x/y)*y
> > 
> > With exact computation, z would be zero.  In fact, we get zero on
> > most machines, including those using Intel 286, 386 and 486 chips.
> > Even with roundoff error, z should not be much larger than eps*x,
> > which is about 9.3e-10.  But, on the Pentium,
> > 
> >     z = 256
> > 
> > The relative error, z/x, is about 2^(-14) or 6.1e-5.  The computed
> > quotient, x/y, is accurate to only 14 bits.
> > 
> > An article in last week's edition of Electronic Engineering Times
> > credits Prof. Thomas Nicely, a mathematics professor at Lynchburg
> > College in Virginia, with the first public announcement of the
> > Pentium division bug.  One of Nicely's examples involves
> > 
> >     p = 824633702441
> > 
> > With exact computation
> > 
> >     q = 1 - (1/p)*p
> > 
> > would be zero.  With floating point computation, q should be on
> > the order of eps.  On most machines, we find that
> > 
> >     q = eps/2 = 2^(-53) ~= 1.11e-16
> > 
> > But on the Pentium
> > 
> >     q = 2^(-28) ~= 3.72e-09
> > 
> > This is roughly single precision accuracy and is typical of the
> > most of the examples that had been posted before Coe's analysis.
> > 
> > The bit patterns of the operands involved in these examples 
> > are very special.  The denominator in Coe's example is
> > 
> >     y = 3*2^20 - 1
> > 
> > Nicely's research involves a theorem about sums of reciprocals
> > of prime numbers.  His example involves a prime of the form
> > 
> >     p = 3*2^38 - 18391
> > 
> > We're not sure yet how many operands cause the Pentium's floating
> > point division to fail, or even what operands produce the largest
> > relative error.  It is certainly true that failures are very rare.
> > But, as far as we are concerned, the real difficulty is having to
> > worry about this at all.  There are so many other things than can
> > go wrong with computer hardware, and software, that, at least, we
> > ought to be able to rely on the basic arithmetic.
> > 
> > The bug is definitely in the Pentium chip.  It occurs at all clock
> > rates.  The bug does not affect other arithmetic operations, or the
> > built-in transcendental functions.  Intel has recently made changes
> > to the on-chip Program Logic Array that fix the bug and is now
> > believed to be producing error free CPUs.  It remains to be seen
> > how long it will take for these to reach users.  
> > 
> > An unnamed Intel spokesman is quoted in the EE Times article as
> > saying "If customers are concerned, they can call and we'll replace
> > any of the parts that contain the bug."  But, at the MathWorks,
> > we have our own friends and contacts at Intel and we're unable
> > to confirm this policy.  We'll let you know when we hear anything
> > more definite.  In the meantime, the phone number for Customer
> > Service at Intel is 800-628-8686.
> > 
> >    -- Cleve Moler     moler at mathworks.com
> >    Chairman and Chief Scientist, The MathWorks, Inc.
> > 
> 


--
Steve


--------------------------------------------------------------------------------
 I am in the field on the Outer Banks of North Carolina until 27 November.
 From 28 Nov - 4 Dec I will be on the Dream Cruise in the Atlantic.
 After the cruise I will go to AGU, and finally to Pullman about 8 Dec.


 Steve Elgar                            FAX :      (919) 261-4432
 Army Research Pier                     ATT :      (919) 261-1706
 1261 Duck Road                         OMNET:     s.elgar
 Kitty Hawk, NC 27949                   internet:  elgar at eecs.wsu.edu 



Return-path: <list-relay at UCSD.EDU>
Received: from csg.pmel.noaa.gov by ALPHA.PMEL.NOAA.GOV (PMDF V4.2-15 #4803) id
 <01HJM9QGY7PS8Y5ECL at ALPHA.PMEL.NOAA.GOV>; Fri, 18 Nov 1994 08:29:59 PDT
Received: from DIRECTORY-DAEMON by CSG.PMEL.NOAA.GOV (PMDF V4.3-7 #4803) id
 <01HJM9Q3FDTC002Q79 at CSG.PMEL.NOAA.GOV>; Fri, 18 Nov 1994 08:29:41 PDT
Received: from ucsd.edu by CSG.PMEL.NOAA.GOV (PMDF V4.3-7 #4803) id
 <01HJM9PSJYDS002SYP at CSG.PMEL.NOAA.GOV>; Fri, 18 Nov 1994 08:29:27 PDT
Received: from coast by ucsd.edu; id IAA22081 sendmail 8.6.9/UCSD-2.2-sun via
 SMTP Fri, 18 Nov 1994 08:25:14 -0800 for <oceantech at ucsd>
Received: by coast (4.1/UCSDGENERIC.3) id AA14381 to oceantech at ucsd; Fri,
 18 Nov 94 08:29:34 PST
Date: Fri, 18 Nov 1994 08:29:33 -0800 (PST)
From: Charles Coughran <csc at coast.UCSD.EDU>
Subject: Pentium bug !! (THAT'S A PC...) (fwd)
To: oceantech at ucsd.edu
Message-id: <Pine.SUN.3.91.941118082641.14264B-100000 at coast>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
X-Sender: csc at coast





  • Prev by Date: Re: ListContourPlot for irregular sampling
  • Next by Date: MMA: EndOfFile-Character (1A) disturbes ReadList
  • Previous by thread: Problems with MeshRange in ListContourPlot3D: THE FIX
  • Next by thread: MMA: EndOfFile-Character (1A) disturbes ReadList