[Haskell-cafe] Re: Repair to floating point enumerations?

[David Roundy]

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