Grex Hardware Conference

View Responses

Grex Hardware Item 91: Round-off error
Entered by gull on Fri Jul 21 02:19:16 UTC 1995:

Want to see an interesting example of round-off error?  Load up QBASIC
and enter the following program:

10 x = .1
20 FOR y = 1 TO 40
30 PRINT x,
40 x = x + .1
50 NEXT y

When you run the program, you'll get something like this:

.1              .2              .3              .4              .5
.6              .7              .8000001        .9000001        1
1.1             1.2             1.3             1.4             1.5
1.6             1.7             1.8             1.9             2
2.1             2.2             2.3             2.4             2.5
2.6             2.7             2.799999        2.899999        2.999999
3.099999        3.199999        3.299999        3.399999        3.499999
3.599999        3.699999        3.799999        3.899998        3.999998

What you're seeing is round-off error, a result of the fact that 0.1 is a
repeating decimal in binary.  Truncating this repeating decimal creates a
small error that builds up as the program continues.  You can get similar
results on a Commodore 64 or (I think) an Apple ][-series machine.

10 responses total.

#1 of 10 by gregc on Fri Jul 21 04:01:06 1995:

Yes, interesting. But this probably belongs in the software conference,
not the hardware conference.

#2 of 10 by gull on Fri Jul 21 21:15:39 1995:

Perhaps...it's kind of both, becuase it's partially a result of how the
software does math, and partially because of the limitations of the hardware.

#3 of 10 by ajax on Sat Jul 22 08:01:12 1995:

One of my faves is Windows calculator: 2.01 - 2 = 0!  That raised some 
eyebrows after the Pentium fiasco...and it definitely strains people's
normal acceptance of floating point inaccuracy with computers.

Wired had a one-pager on the "inherent" inaccuracy of floating point calcs
by computers...I put it in quotes because I think they overlooked that
software can be written to compute things as accurately as you want, or
compute and output fractions for that matter.  But one factoid I thought
was interesting was it said Crays are less precise than the standard Intel-
and Motorola-based machines...they had some quote about how Cray customers
were more concerned with getting answers fast than getting answers right!

#4 of 10 by mju on Sat Jul 22 08:50:44 1995:

(That must be in the Win3.1 calculator.  The Win95 calculator says
2.01 - 2 = 0.01.)

#5 of 10 by scott on Sat Jul 22 12:36:47 1995:

They did fix it.  It was something like 2 years after the bug was discovered
that it became known to the public (I know - still very unknown to most users)

I don't think a fix was ever released, except in the form of Win95...
"Yes, I think we'll get rid of that wart on your hand by replacing your whole
arm with a plastic one that will never get warts again"    :)

#6 of 10 by ajax on Sat Jul 22 16:09:32 1995:

  "Of course to use it, we'll have to replace your brain with one
that has more memory.  And that heart can't possibly pump enough
blood to this new arm...we'll upgrade that too.  Oh, and we found
a couple fractures on this new plastic hand, but we're readying an
upgrade for that too!"

#7 of 10 by gregc on Sat Jul 22 22:44:02 1995:

Sounds like that new tv show: _BionicMan95_.

#8 of 10 by scg on Sun Jul 23 02:07:19 1995:

We've found a bug in our betas in elbow 95, such that it won't run with our
current beta of arm 95.  To fix the bug in elbow 95, we're replacing arm 95
with a new version that's compatable with the buggy elbow.

(For those not familiar with the scenario I'm referring to, Microsoft is
shipping a new version of the Windows 95 beta with the Office 95 beta, because
Office 95 won't run under the "final beta release" of Windows 95)

How are these bugs different from the Pentium bug?  If the Pentium bug was
only a pentium bug, and I'm getting these errors on my 486, they must be
somehow different, and yet they appear to be doing the same thing.

#9 of 10 by gull on Sun Jul 23 02:55:09 1995:

The Pentium bug was the result of a bad lookup table for the FDIV
instruction, causing divisions using certain numbers to give wrong
answers.  It was a bug in the hardware; the chip was intended to be able
to do that division properly.
        The round-off errors being discussed here are caused by
*limitations* of the chip and/or sloppy programming, not by actual bugs in
the chip.  There's a fundamental differece between what a chip isn't
*supposed* to be able to do and what it *should* do, but can't. :-)

#10 of 10 by ajax on Mon Jul 31 18:39:24 1995:

  Re 8, as an example, if you were doing a math problem
using decimal notation, and someone asked you to divide
one by three, you'd wind up with 0.33333333333333333333
with a lot of threes after it...without using fractions
or a "repeating 3" symbol, you have to draw the line at
some point as to how accurate you're going to be.  With
a computer, it's the same basic issue, except that they
use binary notation.  Unless it's programmed to do math
using fractions, you expect round-off errors.  Pentiums
had non-expected, non-round-off errors, as gull said.

Response not possible - You must register and login before posting.