Hi ! In the Haskell 98 Library Report it says: "The functions numerator and denominator extract the components of a ratio; these are in reduced form with a positive denominator". However, when I try to use these functions on WinHugs, I get results like: numerator 1.3 = 5452595 denominator 1.3 = 4194304 This strikes me as strange, as what I was expecting was: numerator 1.3 = 13 denominator 1.3 = 10 What's particularly strange is that Hugs' answers aren't even of the form ( 13n, 10n ), and 5452595/4194304 is not equal to 1.3 in real life ( though it apparently is in Hugs ! ). I'd appreciate any comments you may have on this, as it kind of looks like a bug to me ( or am I just being dumb ! ). Thanks for your help with this. Sincerely, Iain McNaughton. -- Iain McNaughton
On Tuesday 07 August 2001 04:45, Iain McNaughton wrote:
However, when I try to use these functions on WinHugs, I get results like: numerator 1.3 = 5452595 denominator 1.3 = 4194304
This strikes me as strange, as what I was expecting was: numerator 1.3 = 13 denominator 1.3 = 10
It's not Hugs's library that's having problems here, it's the way Hugs handles the literal 1.3. I recall this being mentioned in the past, but it still doesn't seem to be listed among the bugs on the web site or the discrepancies in the manual. Section 6.4.1 of the Haskell 98 report says, "a floating literal stands for an application of fromRational to a value of type Rational" where the latter value plainly needs to be, as you expect, 13 :% 10. What Hugs is doing is immediately converting every floating literal to a binary floating point number in machine form. Since 1.3 is not exactly representable in binary, an approximation is stored which has the above ugly appearance if you inspect it as a rational number.
participants (2)
-
Iain McNaughton -
Scott Turner