[Haskell-cafe] Re: Double -> CDouble, realToFrac doesn't work
Robert Dockins
robdockins at fastmail.fm
Fri Nov 5 08:38:41 EST 2004
My guess is because irrationals can't be represented on a discrete
computer (unless you consider a computaion, the limit of which is the
irrational number in question). A single irrational might not just be
arbitrarily long, but it may have an _infinite_ length representation!
What you have described is arbitrary (not infinite) precision floating
point.
What IEEE has done is shoehorned in some values that aren't really
numbers into their representation (NaN certainly; one could make a
convincing argument that +Inf and -Inf aren't numbers). Perhaps it
would make more sense to add constructors to the Rational type to
represent these additional "values", ie, make Rational look like
(edited from section 12.1 of the Report)
data (Integral a) => Ratio a = a! :% a! |
Nan | PosInf | NegInf
deriving(Eq)
type Rational = Ratio Integer
This has the effect that pattern matching :% when the value is NaN etc.
gives an error instead of doing bizarre things (by succeeding against
non numeric values). This is an advantage or a disadvantage depending
on your viewpoint.
Unfortunately, that isn't how its defined in the Report, so it may not
be an option.
MR K P SCHUPKE wrote:
>>I would be very careful of adding non-rationals to the Rational type.
>
>
> Why is there no Irrational class. This would make more sense for
> Floats and Doubles than the fraction based Rational class. We could
> also add an implementation of infinite precision irrationals using
> a
> pair of Integers for exponent and mantissa.
>
> Keean.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
More information about the Glasgow-haskell-users
mailing list