[Haskell-cafe] Re: Defaulting to Rational [was: Number overflow]

[Jon Fairbairn]

dons at cse.unsw.edu.au (Donald Bruce Stewart) writes:

> [...] there's been a long discussion in #haskell about the
> problems of defaulting to floating point, and should Rational, or
> something similar be used instead, given that Doubles and Float are
> broken for a lot of basic things (like Eq and Ord), much as we default
> to Integer already.
> 
> The issues raised regarding Rational was that you can unexpectedly
> build up large precision, and performance in general, of course.
> It was unknown whether there were suitable replacement types.
> Rational also can't be used with Floating functionsl, like sqrt, which
> would bring back Double defaulting.
> 
> But shouldn't this really work in Haskell, and if you want imprecision
> you must ask for Double explicitly:
> 
>     Prelude> 1.1 + 2.2 - 3.3
>     4.440892098500626e-16
> 
>     Prelude> 1.1 + 2.2 - 3.3 :: Rational
>     0%1

I'd say we do want something like that. I vaguely remember
that Double wasn't called Real because Haskell could, in
principle have an "exact Real" type.

Now, a proper exact real type is doubtless very inefficient,
but wouldn't it be possible to define something that had a
fairly efficient head, and a lazy tail? So you'd have, say

> data Real = R {big::(Ratio !Int !Int), small:: More_Precision}

for some exact real representation More_Precision such that
R a b represents the number (a+b) (It might be better to use
something shorter than Int for the Ratio so that it takes
less space).  For any rational arithmetic that fits in the
big part, the small part would be zero (and therefore
small!).

This would give exact answers for the sort of arithmetic you
list above, but could still be an instance of Floating etc.

-- 
Jón Fairbairn                                 Jon.Fairbairn at cl.cam.ac.uk