Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!sun-barr!newstop!texsun!letni!void!ozdaltx!doug
From: doug@ozdaltx.UUCP (Doug Matlock)
Newsgroups: comp.lang.c
Subject: Re: Floating point non-exactness
Message-ID: <6855@ozdaltx.UUCP>
Date: 13 Aug 90 16:58:27 GMT
References: <622@.tetrauk.UUCP> <5467@quanta.eng.ohio-state.edu> <11160@alice.UUCP>
Organization: AIDS INFO EXCG/OZ BBS - Dallas, TX
Lines: 32

In article <11160@alice.UUCP>, ark@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."