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
It would be strange to name a function readFloat if its type is RealFrac a => ReadS a. I think the function should be named readFrac. For compatibility, one could put the following into the prelude: readFloat :: RealFloat a => ReadS a readFloat = readFrac And one could mark readFloat as depricated and maybe remove it in some future version of Haskell. Ciao, Wolfgang
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
Hi Haskellers,
"Max" == Max Kirillov <max630@mail.ru> writes:
Max> So why one might need it? I've never used Rational, but, if Max> asked, I would say that they are for exact representation of Max> numbers (some symbolic calcs). that's true. I'm using rationals intensively since a couple of years for this purpose and I'd like that they remain as exact as they are. Max> On the other side, 'real' dotted Max> numbers always represent some real values with finite Max> accuracy. I'm not sure if that always is the case, but there is the danger of confusion and this should be enough reason to be careful. Max> That's look like a bad idea to me to call Rational Max> numbers 'real' and type (print) them as a decimal fraction (*). Especially converting rationals to a string and back should always be the identity. It would be better to print rationals in the form numerator % denominator and read them in the same form. Surely, it's good to have flexibility in a programming language; but at critical points --and conversions between floating points (even if represented as strings) and rationals are such a point-- a programming language should demand explicit conversion. Cheers -- Christoph
participants (3)
-
Ch. A. Herrmann -
Max Kirillov -
Wolfgang Jeltsch