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

[Henning Thielemann]

On Wed, 15 Oct 2008, David Roundy wrote:

> 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 had to use MatLab in the past and remembered problems with rounding 
errors. What you show indicates that they try to be more clever, though.
But they can't make floating point numbers precise rationals.



>> length(0:1/10:0.9999999999999999)

ans =

     11

>> length((0:1:9.999999999999999)/10)

ans =

     10


>> zeros(1,10/77*77)
Warning: Size vector should be a row vector with integer elements.

ans =

      0     0     0     0     0     0     0     0     0


I suspect that all algorithms that try to solve problems of floating point 
numbers will do something unexpected in certain circumstances. So, I think 
it is better they do it in a way that can be predicted easily. I feel much 
safer with enumeration of integers which are converted to floating point 
numbers than using a heuristics for floating point numbers.


Haskell or the underlying math library has also heuristics that I don't 
like.

Prelude> (-1)**2 :: Double
1.0
Prelude> (-1)**(2 + 1e-15 - 1e-15) :: Double
NaN

So I think, (**) should be limited to positive bases.