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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
