gwyn@BRL.ARPA (03/31/87)
I don't think at this stage X3J11 would really take my idea about banishing floating == very seriously. It may very well be something that "lint" should catch, though.
manis@ubc-cs.UUCP (03/31/87)
In article <6529@brl-adm.ARPA> gwyn@BRL.ARPA (VLD/VMB) writes: >I don't think at this stage X3J11 would really take my idea about >banishing floating == very seriously. It may very well be something >that "lint" should catch, though. Back in prehistory (about 1970) I used a Fortran compiler on a Univac 1108 running the Exec 2 operating system. This compiler would generate a warning when you compared floating point numbers for equality (or non-equality). I would go further than asking lint to catch it. This is a classic instance of something the compiler knows and can easily tell you. A non-fatal warning (which can be suppressed) is all that's really necessary. Something like "Warning: floating point equality tests are rarely correct" would do quite nicely. A compiler which generates this warning is only trivially non-compliant. A "flequal(a, b, fuzz)" function is a perfect candidate for a library routine (or even an inline expansion).
martin@entropy.ms.washington.edu (Don Martin) (04/09/87)
There are several occasions where an exact test of equality is needed for floating point numbers. One is for missing value codes in statistical systems. I have also senn a few numerical algorithms that are designed to converge for all bits in a number. I admit that usually when you see float == float that it is a beginners error but there are some legit uses for this construct. Various numerical analysts have complained about APL which calls float1 == float2 if abs( float1 -float2 ) is less than "fuzz". Don Martin martin@entropy