> Richard A. O'Keefe (ok at cs.otago.ac.nz) wrote:
> "Jarvis, Robert P. (Bob) (Contingent)" <bob.jarvis at timken.com> wrote:
> 	The best practice I'm aware of for handling equality
> 	calculations with Floats is avoid them completely.
> 
> I do wish that more people would read "What Every Computer Scientist
> Should Know About Floating-Point Arithmetic".

Thank you!  Great paper.  Google found several references, including

	http://docs.sun.com/source/806-3568/ncg_goldberg.html

> Floating-point equality tests are in fact perfectly well behaved
> (in the absence of NaN, sigh).  More than that, when the operands
> and result are integers in the range -(2**53 - 1) .. +(2**53-1)
> held as IEEE 754 double precision numbers, addition, subtraction,
> multiplication, remainder() -- hence also division via
> rint((x - remainder(x,y))/y) -- and comparison are EXACT.

Agreed.  Integers that do not exceed the precision of the floating point
format chosen will behave as expected.  I think that where people get into
trouble is that they expect this intuitive behavior to extend to all
possible values.  Furthermore, people use floating point numbers precisely
because they can use them for non-integer calculations.  In fact many
languages enforce this by translating non-integer constants into
floating-point values and doing quiet conversions so that calculations
produce floating-point numbers if there is any floating-point number in the
calculation.

> There are plenty of examples where floating-point equality is exactly
> the right thing to do.  Any blanket ban on floating point equality is
> too strict.

If the developer has a clear understanding of their algorithm and a clear
understanding of the limitations and problems of working with floating point
values you are correct that equality comparisons can be used safely.  Years
of seeing people have the same problems repeatedly, though, leads me to
believe that "do not make equality comparisons of floating point values" is
a useful rule of thumb that can

	A) help people avoid problems, and
	B) nudge them towards learning *why* this is a useful rule of thumb.

> 	Do not under any circumstances use floating point numbers in
> 	financial calculations.  Floats are imprecise, often only
> 	approximate, and utterly inappropriate for any calculation where
> 	all the fiddly little decimal places really count.
> 	
> Except decimal floats.  Addition, subtraction, and multiplication of
> in-range numbers stated in decimal with in-range results are *exact*.
> We *really* want the new IEEE standard, don't we?

While it certainly sounds like an improvement, I think this is more of a
band-aid than a fix.  As soon as you exceed the precision of a floating
point number, be it binary or decimal, you have the situation where a
comparison like

	f = f + 1.0

answers 'true', at which point the auditors and lawyers will want to have a
word.  My choice, if I was given one, would be to get rid of floating point
entirely and replace it with some form of unlimited-precision scaled
decimal.

Bob Jarvis
Compuware @ Timken

-----------------------------------------
**********************************************************************
PLEASE NOTE: The above email address has recently changed from a previous
naming standard -- if this does not match your records, please update them
to use this new name in future email addressed to this individual.    This
message and any attachments are intended for the   individual or entity
named above. If you are not the intended  recipient, please do not forward,
copy, print, use or disclose this   communication to others; also please
notify the sender by   replying to this message, and then delete it from
your system.     The Timken Company
**********************************************************************