On Thu, 12 Jul 2007, Jon Fairbairn wrote:
> Henning Thielemann <[EMAIL PROTECTED]> writes:
>
> > On Thu, 12 Jul 2007, Jon Fairbairn wrote:
> >
> > > 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}
> >
> > Interesting approach.
>
> But flawed as I put it: the big part can't express big
> numbers! The big part needs to be either Rational (and the
> precision of that part limited during arithmetic) or
> BigFloat where
>
> > Data BigFloat = BF {mantissa:: Int, exponent:: Integer}
>
> (ie limited precision, but unbounded magnitude). If we were
> to use BigFloat the base would need to be a power of ten to
> get the desired results for things like Don's example)
People will be confused, that 'sin pi' won't lead to a result since the
correct result is zero and it will need forever to normalize that number.
They will be confused, that the result of 'sqrt 2 ^ 2' cannot be shown in
usual decimal notation, since the formatting algorithm cannot decide
between starting with 2.0000 and 1.9999. However 'round (sqrt 2 ^ 2)' will
work as expected.
In short, the Real number type will leed to all difficulties known from
computable reals.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
