From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 107079,c7637cfdf68e766
X-Google-Attributes: gid107079,public
X-Google-Thread: 103376,c7637cfdf68e766
X-Google-Attributes: gid103376,public
X-Google-Thread: f43e6,c7637cfdf68e766
X-Google-Attributes: gidf43e6,public
X-Google-Thread: 109d8a,c7637cfdf68e766
X-Google-Attributes: gid109d8a,public
X-Google-Thread: f8362,c7637cfdf68e766
X-Google-Attributes: gidf8362,public
From: christian.bau@isltd.insignia.comm (Christian Bau)
Subject: Re: floating point comparison
Date: 1997/08/21
Message-ID: 
 <christian.bau-2108971008120001@christian-mac.isltd.insignia.com>#1/1
X-Deja-AN: 268531367
Distribution: inet
Sender: news@isltd.insignia.com (Usenet News)
References: <dewar.871221105@merv> <5t5976$rle$1@ccioffe.ioffe.rssi.ru>
 <dewar.871925372@merv> <5tc7kl$a19$1@news.fsu.edu>
Organization: Insignia Solutions
Newsgroups: 
 comp.lang.ada,sci.math.num-analysis,comp.software-eng,comp.theory,sci.math
Date: 1997-08-21T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <5tc7kl$a19$1@news.fsu.edu>, jac@ibms48.scri.fsu.edu (Jim Carr)
wrote:

> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> >There are no *errors*, the discrepancies between IEEE arithmetic and
> >real arithmetic are not errors, they are simply differences that come from
> >two different arithmetic models.

As an example: Given a floating point number with an absolute value less
than 10^15, find an integer number that is close to it. 

Solution in C with IEEE arithmetic: 

double nearby_number (double x)
{
   x += 6.0 * 1024.0 * 1024.0 * 1024.0 * 1024.0 * 1024.0;
   x -= 6.0 * 1024.0 * 1024.0 * 1024.0 * 1024.0 * 1024.0;
   return x;
}

Adding 1.5 * 2^52 will produce a result that is rounded to an integer
number. I cant call this a rounding error (or "uncertainty") since it is
exactly the effect that I wanted to achieve. 

> 
>  It could be useful to adopt the terminology of experimental science 
>  here, and use "uncertainty" to denote the variance between the 
>  results of real arithmetic and floating point arithmetic done 
>  'correctly' in a particular model.  The two have much in common, 
>  since one propagates those uncertainties in a similar way, and 
>  since the confusion associated with calling them "errors" is 
>  equally strong.  And both are poorly known.  ;-) 

That term "uncertainty" makes things much much worse. The difference
between well designed floating point arithmetic and real arithmetic is in
no way uncertain. It is absolutely certain and predictable. 

For example, with IEEE arithmetic it is relatively easy to compute the
difference between a+b (using real arithmetic) and a+b (using IEEE
arithmetic) _exactly_. But you cant call something "uncertainty" that can
be computed exactly. 

>  It _is_ an error to treat those numbers as if they were real numbers. 

Absolutely right.

-- For email responses, please remove the last emm from my address. 
-- For spams, please send them to whereever.you.want@but.not.here