views:

574

answers:

7

I've been going through a Haskell tutorial recently and noticed this behaviour when trying some simple Haskell expressions in the interactive ghci shell:

Prelude> 1.1 + 1.1 == 2.2
True
Prelude> 1.1 + 1.1 + 1.1 == 3.3
False
Prelude> 1.1 + 1.1 + 1.1 > 3.3
True
Prelude> 1.1 + 1.1 + 1.1
3.3000000000000003

Does anybody know why that is?

+6  A: 

Looks like a typical floating point error issue.

See http://stackoverflow.com/questions/249467/what-is-a-simple-example-of-floating-point-rounding-error

micahtan
+5  A: 

Few floats can be expressed exactly using IEEE 754 representation, so they will always be a little off.

Ignacio Vazquez-Abrams
+7  A: 

Because floating-point numbers are not accurate (wikipedia)

YuppieNetworking
-1 Misleading, sorry. IEEE floating point numbers *are perfectly accurate*, you just have to watch out for rounding errors with decimal numbers. You have the same problems trying to represent fractions like 1/3 in decimal (0.3333 ...).
Seth
Agreed. The issue isn't one of accuracy, it's one of representation. Numbers that can be represented completely are completely accurate. Those that lie inbetween those numbers can only be approximated, and _that's_ the issue.
codekaizen
So what you two nitpickers are saying is, floating-point numbers are only inaccurate when they're inaccurate? Wow, nothing gets past you people. If `1.1 * 3 != 3.3` in your math system, that is *not* accurate.
Chuck
Sure it's accurate... what went wrong was the conversion into binary floating point. So it's accurate, repeatable and predictable, just somewhat surprising.
Andrew McGregor
@Chuck - There's always the Decimal type (implemented in python et. al.), which "works in the same way as the arithmetic that people learn at school" - http://docs.python.org/library/decimal.html. It's slower though since it's not implemented in hardware.
Seth
@Seth: I didn't learn at school that 1/3 is 0.3333333...3 where the number of 3s is finite and depends on the precision that has been set.
sepp2k
@sepp2k: Still not exactly an accuracy issue. Just a representation issue because memory is finite. Floating point arithmetic gives the right answer to the wrong problem :D
trinithis
+30  A: 

Because 1.1 and 3.3 are floating point numbers. Decimal fractions, such as .1 or .3, are not exactly representable in a binary floating point number. .1 means 1/10. To represent that in binary, where each fractional digit represents 1/2n (1/2, 1/4, 1/8, etc), you would need an infinite number of digits, 0.000110011... repeating infinitely.

This is exactly the same problem as representing, say, 1/3 in base 10. In base 10, you would need an infinite number of digits, .33333... forever, to represent 1/3 exactly. So working in base 10, you usually round, to something like .33. But if you add up three copies of that, you get .99, not 1.

For far more information on the topic, read What Every Computer Scientist Should Know About Floating Point Arithmentic.

For representing rational numbers more precisely in Haskell, you can always use the rational data type, Ratio; coupled with bignums (arbitrarily large integers, Integer in Haskell, as opposed to Int which are fixed size) as the type for numerator and denominator, you can represent arbitrarily precise rational numbers, but at a significantly slower speed than floating point numbers, which are implemented in hardware and optimized for speed.

Floating point numbers are an optimization, for scientific and numerical computation, that trade off precision for high speed, allowing you to perform a very large number of computations in a small time, as long as you are aware of rounding and how it affects your computations.

Brian Campbell
Thanks for pointing out the 'Ratio' data type!
Frerich Raabe
Just a quibble, but `Ratio` is a type constructor - `Rational` is a type, the type (alias) of `Ratio Integer`.
BMeph
+5  A: 

It has to do with the way IEEE floating point numbers work.

1.1 is represented as 1.1000000000000001 in floating point, 3.3 is represented as 3.2999999999999998.

So 1.1 + 1.1 + 1.1 is actually

1.1000000000000001 + 1.1000000000000001 + 1.1000000000000001 = 3.3000000000000003

Which, as you can see is actually larger than 3.2999999999999998.

The usual workaround is to either not evaluate equality, or to check if a number is within the target +/- a small epsilon (which defines the accuracy you need).

Ex: if both are true, then the sum is "equal" to 3.3 (within the allowed error).

1.1 + 1.1 + 1.1 < 3.3 + 1e9 
1.1 + 1.1 + 1.1 > 3.3 - 1e9
Seth
No, 1.1 is not represented as 1.1000000000000001. It is represented as 1.0001100110011001100110011001100110011001100110011010 (base 2), which when converted to decimal, rounds to 1.100000000000000001
Brian Campbell
Ahh, true enough.
Seth
+12  A: 

You can avoid floating-point errors in Haskell using rational types:

Prelude Data.Ratio> let a = (11 % 10) + (11 % 10) + (11 % 10)
Prelude Data.Ratio> a > (33 % 10)
False
Prelude Data.Ratio> fromRational a
3.3

Of course, you pay a performance penalty for the increased accuracy.

daf
You can even write `let a = 1.1 + 1.1 + 1.1 :: Rational`, with no worries about loss of precision (the literal `1.1` is actually an abbreviation for `fromRational (11%10)`).
Reid Barton
+1  A: 

In general, you shouldn't be comparing floats for equality (for the reasons outlined above). The only reason I can think of is if you want to say "has this value changed?" For example, "if (newscore /= oldscore)" then take some action. That is okay as long as you are not comparing the result of two separate computations to check whether they happen to be equal (because then even mathematically if they are, they might round otherwise).

mgiuca