On Wed, Oct 15, 2008 at 11:25:57PM +0200, Henning Thielemann wrote:
David Roundy schrieb:
Why not look for a heuristic that gets the common cases right, rather than going with an elegant wrong solution? After all, these enumerations are most often used by people who neither care nor know how they're implemented, but who most likely would prefer if haskell worked as well as matlab, python, etc.
Although MatLab has a lot of bad heuristics, they fortunately didn't try to be too clever with respect to rounding errors. Floating point enumerations have the same problems in MatLab as in all other languages.
I presume you say this because you haven't tried qusing matlab? I don't know what their algorithm is, but matlab gives:
sprintf('%.20f\n', (0:0.1:0.3), 0.1*3, 0.1+0.1+0.1, 0.3)
ans = 0.00000000000000000000 0.10000000000000000555 0.19999999999999998335 0.29999999999999998890 0.30000000000000004441 0.30000000000000004441 0.29999999999999998890 from which you can clearly see that matlab does have special handling for its [0,0.1..0.3] syntax. For what it's worth, octave has the same behavior: octave:1> sprintf('%.20f\n', (0:0.1:0.3), 0.1*3, 0.1+0.1+0.1, 0.3) ans = 0.00000000000000000000 0.10000000000000000555 0.20000000000000001110 0.29999999999999998890 0.30000000000000004441 0.30000000000000004441 0.29999999999999998890 I don't know what they're doing, but obviously they're doing something clever to make this common case work. They presumably use different algorithms, since octave gives a different answer for the 0.2 than matlab does. Matlab's value here is actually less that 0.1 and it's also less than 2*0.1, which is a bit odd. Both agree that the final element in the sequence is 0.3. The point being that other languages *do* put care into how they define their sequences, and I see no reason why Haskell should be sloppier. David