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: 109d8a,c7637cfdf68e766 X-Google-Attributes: gid109d8a,public X-Google-Thread: f8362,c7637cfdf68e766 X-Google-Attributes: gidf8362,public X-Google-Thread: f43e6,c7637cfdf68e766 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,c7637cfdf68e766 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: floating point comparison Date: 1997/08/24 Message-ID: #1/1 X-Deja-AN: 268286355 Distribution: inet References: <5tk5he$7rq$1@news.fsu.edu> <5tnreu$9ac$1@news.fsu.edu> Organization: New York University Newsgroups: comp.lang.ada,sci.math.num-analysis,comp.software-eng,comp.theory,sci.math Date: 1997-08-24T00:00:00+00:00 List-Id: James Carr says << The difference is inevitable. It does exist. It has important consequences when interpreting the result of a calculation that is being used as a substitute for working with real numbers, a major reason computers exist. If you do not like the name, propose another -- but do not pretend that it does not happen. >> I think you should assume that I do understand how floating-point works, and I have written hundreds of thousands of lines of numerical Fortran code, carefully analyzed, much of which is still in use today, even though that was some thirty years ago! The point, which perhaps you just don't see, because I assume you also understand floating-point well, is that I think the term "error" for the discrepancies that occur when an arbitrary decimal number is converted to binary floating-point are not errors. An error is something wrong. There is nothing wrong here, you habve made the decision to represent a decimal value in binary form, and used a method that gives a very well defined result. If this is indeed an "error", then please don't use methods that are in error, represent the number some other way. If on the other hand, your analysis shows that the requirements of the calculation are met by the use of this conversion, then there is no error here! Similarly when we write a := b + c, the result in a is of course not the mathematical result of adding the two real numbers represented by b and c, but there is no "error". An error again is something wrong. If an addition like that is an error, i.e. causes your program to malfunction, then don't do the addition. If on the other hand, your analysis shows that it is appropriate to perform the computation a = b + c, where a is defined as the result required by IEEE854, then there is no error. Yes, it is useful to have a term to describe the difference between the IEEE result and the true real arithmetic result, but it is just a difference, and perhaps it would be better if this value had been called something like "rounding difference", i.e. something more neutral than error. The trouble with the term error, is that it feeds the impression, seen more than once in this thread, that floating-point is somehow unreliable and full of errors etc. Go back to the original subject line of this thread for a moment. Is it wrong to say if a = b then where we know exactly how a and b are represnted in terms of IEEE854, and we know the IEEE854 equality test that will be performed/ The answer is that it might be wrong or it might be right. it has a well defined meaning, and if that meaning is such that your program works, it is right, if that meaning is such that your program fails, then it is wrong. But --- we could make the same statement about any possible programming language statement we might write down. There is nothing inherently wrong, bad, erroneous, or anything else like that about floating-point. Now one caveat is that we often do NOT know how statements we write will map into IEEE854 operations unless we are operating in a well defined environment like SANE. As I have noted before, this is a definite gap in programming language design, and is specifically the topic that my thesis student Sam Figueroa is working on.