Can we solve and close the problem of the meaning of decimal pointed leterals? To my | People wrote about toRational (0.9) == 9%10 = False | ... | Probably, the source of a `bug' is a language agreement that the | input is in decimal representation (`0.9') and its meaning is a | floating approximation in _binary_ representation. | For example, 1%5 yields a finite mantissa in decimal representation | and an infinite (periodic) mantissa for the binary representation of | toBinary(1%5) = 1B % 1001B. (a typo: this should be 101B) | Therefore applying toRational to any finite float approximation | (Double, or other) of 1%5 does not return 1%5. Lennart Augustsson <lennart@mail.augustsson.net> writes
What are you talking about? Input in decimal representation is stored as a Rational number. There is absolutely no loss of precision.
and in his next letter citates the Report:
"The floating point literal f is equivalent to fromRational (n Ratio.% d), where fromRational is a method in class Fractional and Ratio.% constructs a rational from two integers, as defined in the Ratio library. The integers n and d are chosen so that n/d = f."
By saying "input is in decimal representation (`0.9')" I meant that a number `0.9' is written by a programmer keeping in mind a decimal representation. Further, according to the citation, 0.9 --> fromRational (9%10), 0.2 --> fromRational (1%5) are stored as the values of type Fractional a => a. (1) What is this `a' for our example of toRational (fromRational (0.9)) == 9%10 ? (2) Why Haskell does not report an ambiguity error? For `a' may be Rational, Double, Float - just anything of Fractional. If we take Lennart's assertion
Input in decimal representation is stored as a Rational number. There is absolutely no loss of precision.
then it should be `a' = Rational. Then, in particular, toRational (0.d) == d%10 = True for any decimal literal d and * any other behavior is a bug. * Is this really so? Now, Hugs-98-Feb-2000, probably, decides that `a' = Double. Because it returns False for 0.9. And in this case these values are _not_ stored as the rational numbers, but convert to Double, with the precision loss caused, as I wrote initially, by truncating of the division result, like 1001B % 1010B. Who could explain, please, whether I understand correct the whole question, and answer to the questions (1), (2) ? And is `False' is a bug? Thanks in advance for the comments. ----------------- Serge Mechveliani mechvel@botik.ru