Floating point non-exactness

[Doug Matlock]

In article <11160 at alice.UUCP>, ark at alice.UUCP (Andrew Koenig) writes:
> For example, IEEE guarantees that if I read the decimal representation
> of a number that can be represented exactly in floating point,
> that's what I'll get, period.  It also guarantees exact results
> for primitive operations including addition, subtraction, multiplication,
> division, and square root.

What if these primitive operators generates a result that cannot be
represented exactly in IEEE floating point notation?  Many simple rational
(or irrational, since you've included square root) numbers are not
exactly expressesed in decimal notation.  

> As a simple example,
> 
> 	double d;
> 	for (d = 0; d < 1e10; d++) {
> 		/* stuff */
> 	}
> 
> under IEEE floating point can be counted on to execute precisely 1e10
> (ten billion) times.

The obvious pitfall here is exceeding the precision of floating point.
For 8-byte double, I think the turning point is somewhere around 1e15.
If I take a floating point number greater than 1e15 (or so) and add 1
to it, I will get the same number back.  (This is generally lots of fun
when running computer simulations. ;-) )

-- 
Doug.

"If you want Peace, work for Justice."