Simple question on floating-point errors

Quote:

> When you perform arithmetic operations on numbers of type float, small

> errors creep in to the calculation. I have found that tests of strict

> equality frequently fail, e.g. I am told that 0.10000 is not in fact

> equal to 0.10000. This is not something I have come across in other

> languages. My question is: what is the quick and ready solution to the

> problem? Some type conversion? Any help would be much appreciated.

This question comes up periodically, and almost invariably prompts the

same series of responses, some of which, alas, are misleading.

Because FP representations do not include all real (or rational)

numbers, it is true that a given FP quantity is usually intended to be

an approximation to some ideal real quantity. However, respondants to

your question are often too pessimistic about what one can say about

this approximation. For architectures of any wide-spread importance

these days, FP arithmetic is deterministic [Note 1], and for many of

those---notably IEEE-compliant FP (as on IBM PCs, e.g.)---rather well-

behaved. As long as you know what arithmetic engine your software is

intended for (or you are willing to support multiple versions), it

seems to me that you may as well count on a particular behavior, if it

yields significant advantages in performance (or whatever) to do so.

For example, in IEEE arithmetic, if the quotient of two integers is a

representable IEEE number (in some format), and if those integers are

themselves representable in that format, then the quotient will be

exact. As another example, if two positive IEEE FP numbers are within

a factor of two of each other, their difference will be exact.

As for your particular question (on equality), the answer depends on

your application. If you are using a particular FP value as an input

sentinel (to mark the end of some input data) and it is a

representable quantity, then naive use of the equality test should

work. Likewise, if you have a formula such as

something / (x - 1.5)

then (under IEEE arithmetic) the code

if (x == 1.5)

return /* the value at singular point x==1.5 */;

else

return something / (x - 1.5)

will not divide by 0 (although come to think of it, there are ways a poor

compiler could{*filter*}this up).

Others have posted locutions that sometimes work in other cases, but

none works universally. In particular, the routine translation of

"real" equality into some "fuzzy" equality, such as

x = y ----> abs(x-y) < EPSILON * abs(x)

is not a great idea.

NOTES:

1. On some architectures (some Honeywell models spring to mind) FP

arithmetic is actually non-deterministic as implemented by their

compilers and OS. The FP registers contain bits that are not included

when a quantity is stored to memory, as happens in response to context

switch resulting from an interrupt. As a result, the value of a

subexpression or temporary may change in the last significant bits

unpredictably. I can count the number of times I've used such

architectures on the fingers of one elbow.

P. Hilfinger