readFloat
Max Kirillov
max630@mail.ru
Fri, 31 May 2002 23:45:26 +0700
So why one might need it? I've never used Rational, but, if
asked, I would say that they are for exact representation
of numbers (some symbolic calcs). On the other side, 'real'
dotted numbers always represent some real values with finite
accuracy. That's look like a bad idea to me to call Rational
numbers 'real' and type (print) them as a decimal fraction (*).
Further, one would like to treat Rational as not just a
decimal fraction, but, for example, decimal fraction with a
period -- 0.12(3).
I think that (readFloat :: ReadS Rational) must not be in
Reported libs. I anybody wants, let him declare
> instance RealFloat Rational,
taking all the responsibility.
Muth better would be provide (maybe where is) a function
> realToFrac :: RealFloat a, RealFrac b => a -> a -> b,
> realToFrac x err = ...
which would provide the shortest fractional approximation to
a given 'real' number.
Max.
(*) Some school teachers like children to write solution
of (4*x-3=0) as 0.75. I highly disagree with it.
3/4 is 3/4, but "0.75" is 0.75+-0.005 :)
On Tuesday, 2002-05-28, 18:57, CEST Simon Peyton-Jones wrote:
> Folks
>
> I'm back to tidying up the Haskell Report.
>
> In the Numeric library, there is the useful function
>
> readFloat :: RealFloat a => ReadS a
>
> But you can't use it for reading rationals, because Rational
> isn't in RealFloat!
>
> This is a Royal Pain, and entirely unnecessary. In fact,
> readFloat uses only operations from the RealFrac class,
> so it could equally well have type
>
> readFloat :: RealFrac a => ReadS a
>
> I'm strongly inclined to make this change. It breaks no
> programs, and it fixes a real bug i.e. there is no way to
> read a "103" as a Rational.
>
> Simon