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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit 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 X-Google-Thread: 107079,c7637cfdf68e766 X-Google-Attributes: gid107079,public X-Google-Thread: 109d8a,c7637cfdf68e766 X-Google-Attributes: gid109d8a,public From: Martin@nezumi.demon.co.uk (Martin Tom Brown) Subject: Re: floating point comparison Date: 1997/07/31 Message-ID: <870335897snz@nezumi.demon.co.uk>#1/1 X-Deja-AN: 260918729 Distribution: inet References: X-Mail2News-User: Martin@nezumi.demon.co.uk X-Mail2News-Path: nezumi.demon.co.uk Organization: Nezumi Reply-To: Martin@nezumi.demon.co.uk Newsgroups: comp.lang.ada,sci.math.num-analysis,comp.software-eng,comp.theory,sci.math Date: 1997-07-31T00:00:00+00:00 List-Id: In article mheaney@ni.net "Matthew Heaney" writes: > In article , dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > > > >As for when it makes sense to compare floating-point values for equality, > >that is a matter for the programmer to understand. Floating-point arithmetic > >on modern IEEE machines is not some kind of approximate hocus-pocus, it > >is a well defined arithmetic systenm, with well defined, well behaved > >results, in which equality has a perfectly reasonable meaning. > > OK, so if do this > > declare > m1, m2 : slope; > begin > if m1 = m2 then > > and I'm using IEEE floating point types (I'm on a SUN box), can I assume > that the lines are parallel? There are two obvious situations where you can get into trouble - #1 m1 equal to m2 but the lines are not parallel, and numerical cancellation gives fewer significant bits. You can try and control this loss of significance. #2 m1 not equal to m2 but the lines are actually parallel and the small difference is due to rounding errors. On some systems this may be unavoidable hence you have to accept numbers as equal if they differ by less than some limit. If "slope" is a single floating point number then you are in trouble when a line becomes parallel to one of the two axes (division by 0). As Robert has said IEEE is a well defined floating-point number system and so for any given calculation it is possible to determine bounds. How much thought you give to a problem depends on how much it matters - for example there is probably no need to worry if a plotter pen is a few microns out of position after drawing a 1m line. As a concrete and I think simpler example of the difference between algebraic identities and numerical IEEE FP approximations try evaluating the following in the explicit order shown : f1(x) = 1 + x + x^2 + ... + x^(N-1) + x^N f2(x) = x^N + x^(N-1) + x^(N-2) + ... + x + 1 f3(x) = (1 - x^(N+1))/(1-x) Barring typos I hope everyone agrees these are algebraic identities (at least for finite N) If you now try to evaluate each of them numerically for say N=10 and x = 10, 3, 2, 1, 1/2, 1/3, 1/10 you should see some differences. (There is a gotcha in this list) Common programmer errors often arise from exact decimal fractions which do not have a finite representation in the binary system. Regards, -- Martin Brown __ CIS: 71651,470 Scientific Software Consultancy /^,,)__/