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: 109d8a,c7637cfdf68e766 X-Google-Attributes: gid109d8a,public X-Google-Thread: 107079,c7637cfdf68e766 X-Google-Attributes: gid107079,public X-Google-Thread: 103376,c7637cfdf68e766 X-Google-Attributes: gid103376,public X-Google-Thread: f8362,c7637cfdf68e766 X-Google-Attributes: gidf8362,public X-Google-Thread: f43e6,c7637cfdf68e766 X-Google-Attributes: gidf43e6,public From: jac@ibms48.scri.fsu.edu (Jim Carr) Subject: Re: floating point comparison Date: 1997/08/21 Message-ID: <5theo8$qg7$1@news.fsu.edu>#1/1 X-Deja-AN: 265699010 Distribution: inet References: <5tc7kl$a19$1@news.fsu.edu> Organization: Supercomputer Computations Research Institute 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: 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. christian.bau@isltd.insignia.comm (Christian Bau) writes: > >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. That is an interesting choice since you are not guaranteed to be able to represent 15 decimal digits in a float data type in C. Casting up to double to use your routine below will not change that. And don't tell me I pick nits; plenty of C programmers will cast a float to a double to call the intrinsic double routine to get a square root without narry a thought about 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. The uncertainty is in the representation of the original real value, say 1/10 or pi (or pi*10^14 in your case), as a float (or a double). jac@ibms48.scri.fsu.edu (Jim Carr) wrote: | | 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. So is the process of measurement with a device with less precision than necessary to make the measurement. For example, in your case there is no uncertainty in the integer part of a 14 digit real in a double precision IEEE representation that has been properly rounded, but there is an uncertainty if it was stored as a float. >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. The uncertainty is that more than one value of a and b will give the same a+b result on the IEEE side. -- James A. Carr | Commercial e-mail is _NOT_ http://www.scri.fsu.edu/~jac/ | desired to this or any address Supercomputer Computations Res. Inst. | that resolves to my account Florida State, Tallahassee FL 32306 | for any reason at any time.