You should perhaps be using a rational number datatype instead of floating point arithmetic.
It depends what calculations you're doing: if you need to use transcendental functions then you're stuck with floating point, and you'll have to decide how close two numbers need to be for you to consider them equal. n.b. you need to do this: no programming language can know whether false positives are more or less harmful than false negatives in your program.
In C#, (0.3m - 0.2m) == (0.2m - 0.1m). The latest version of the C++ spec allows for user-defined literals, so you could do something similar there (with caveats). But as far as I know, there's no modern language in widespread use that has decimal literals which default to base-ten representations.
I checked in Go (golang). Verbatim, it's false. But if I save at least one side of the equality to a variable, or cast at least one side to a float, it's true.
I have just tested it on a Windows Vista machine, it doesn't work in Internet Explorer, Opera and Safari. Putting each side of the equation into an alert box shows the difference.
IMHO, the right thing to do would be to forbid the usage of == for decimals values.
1.0 == 0.9 -> Throw err
1.0 > 0.9 -> true
In most case, you don't want to use == on double because it 's very dangerous... it's way better to use (0.3 - 0.3000001) < 0.001 or something similar. So, by forbidding the == on doubles, you force the programmer to use a safer way. In the same time, it's a clean hack around this decimal issue. As a bonus, a programmer who doesn't know binaries arithmetic might get curious on why == isn't implemented on double and read on it.
APL, J and K/Kona all get it "right" - their default floating point comparison is a "tolerant comparison", basically meaning that floating point numbers compare equal even if they are slightly apart (a few ulps, configurable). It does not extend to hashing (because tolerant equality does not actually have equivalence classes), but is nevertheless an extremely useful behaviour.
As many others have pointed out, this is not really a matter of language but of the data types used. In IEEE 754 floating point arithmetic, the two expressions are not equal.
You're looking for a different data type, and many choices would give you the desired equality: a decimal floating point representation, calculating with rational numbers and interval arithmetic come to mind (technically, IEEE floating point is a kind of interval arithmetic, but you have not much control over the size of the intervals used and comparison does not do what you might naively expect, i.e., checking whether the two intervals intersect).
I suppose you should look for a library like GMP or MPIR for whatever is your preferred language. Most computer algebra systems (e.g., Sage) will also provide with what you need in some way or another.
But the APL family (APL, J, K) does get this right despite using IEEE 754 floating point - it has comparison tolerance built in.
And you would probably look at what it does with disgust, given that it breaks transitivity of equality (that is, there are numbers such that a==b and b==c but a<>c). However, in practice it does work very well. You can still run into weird corners, but e.g.
(3*(a/3.0))==a
always holds true, unlike with C comparison semantics.
This seems to be a very sensible default way to handle the comparison, assuming the programmer already knows about the problems with floating point math. A programmer who does not know about that will probably trip up sooner or later no matter how the language implements comparison.
So personally I would not see it as "right" (or "wrong"), simply because it is a choice between many different methods with their own advantages and disadvantages. I view this not as a problem a language can (or has to) solve, but as one a programmer has to be aware of and has to solve depending on his particular application.
Any language which uses floating points to represent these values rather than fixed points.
C# and some versions of C use fixed-point representations for these values by default (or correct for floating point errors internally, as with C#), and return the correct answer of true, as .1 is equal to .1 in fixed-point representations.
EDIT: False is only the correct answer when using floating point representations, as the equation no longer boils down to .1 == .1, but something like .999 == 1.0001, etc.
In Haskell, decimal literals can be inferred as any Fractional type (including Rational, which is precise), but they default to Double if there is no context that dictates otherwise.
Above, we explicitly declare one of the literals as Rational, and the rest are inferred as having the same type (since the standard library does not allow you to do arithmetics or comparisons between discrepant types).
In binary, you can't represent any of 0.1, 0.2, nor 0.3 with "proper" fractions, as they are irrational in a radix-2 number system. Thus, when actually performing the operation (0.3 - 0.2) - (0.2 - 0.1), the result may actually be non-zero, although very small.
The best thing to do here would be to use an inline comparison function with a threshold:
Unfortunately, compounding floating point operations can drastically reduce calculation accuracy, leading to requiring a greater threshold value... Which is why I highly recommend reading the article titled "What Every Computer Scientist Should Know About Floating-Point Arithmetic" by David Goldberg (circa 1991, available at http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.ht...).
25 comments
[ 3.0 ms ] story [ 56.6 ms ] threadIn other words, floating point operations in binary computers can give unintuitive results; welcome to the bizarre world of programming. This may be a useful starting point for reading: http://stackoverflow.com/questions/1167691/ieee-floating-poi... , or perhaps this: http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.ht...
(Note that most programming languages have a prominent warning about this in the documentation.)
It depends what calculations you're doing: if you need to use transcendental functions then you're stuck with floating point, and you'll have to decide how close two numbers need to be for you to consider them equal. n.b. you need to do this: no programming language can know whether false positives are more or less harmful than false negatives in your program.
In C#, (0.3m - 0.2m) == (0.2m - 0.1m). The latest version of the C++ spec allows for user-defined literals, so you could do something similar there (with caveats). But as far as I know, there's no modern language in widespread use that has decimal literals which default to base-ten representations.
(1.2x2^-2) - (1.6x2^-3) = (1.6x2^-3) - (1.6x2^-4)
which is pretty clearly false. http://www.h-schmidt.net/FloatConverter/IEEE754.html has a pretty nice conversion tool, if you're curious.
You're looking for a different data type, and many choices would give you the desired equality: a decimal floating point representation, calculating with rational numbers and interval arithmetic come to mind (technically, IEEE floating point is a kind of interval arithmetic, but you have not much control over the size of the intervals used and comparison does not do what you might naively expect, i.e., checking whether the two intervals intersect).
I suppose you should look for a library like GMP or MPIR for whatever is your preferred language. Most computer algebra systems (e.g., Sage) will also provide with what you need in some way or another.
And you would probably look at what it does with disgust, given that it breaks transitivity of equality (that is, there are numbers such that a==b and b==c but a<>c). However, in practice it does work very well. You can still run into weird corners, but e.g.
always holds true, unlike with C comparison semantics.So personally I would not see it as "right" (or "wrong"), simply because it is a choice between many different methods with their own advantages and disadvantages. I view this not as a problem a language can (or has to) solve, but as one a programmer has to be aware of and has to solve depending on his particular application.
C# and some versions of C use fixed-point representations for these values by default (or correct for floating point errors internally, as with C#), and return the correct answer of true, as .1 is equal to .1 in fixed-point representations.
EDIT: False is only the correct answer when using floating point representations, as the equation no longer boils down to .1 == .1, but something like .999 == 1.0001, etc.
I suspect it is due to the fact that those number have an infinite binary expansion...
Fortran (the oldest still in use):
Lisp (the second oldest still in use): Cobol (the third oldest still in use):The best thing to do here would be to use an inline comparison function with a threshold:
Unfortunately, compounding floating point operations can drastically reduce calculation accuracy, leading to requiring a greater threshold value... Which is why I highly recommend reading the article titled "What Every Computer Scientist Should Know About Floating-Point Arithmetic" by David Goldberg (circa 1991, available at http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.ht...).