question of decimal pointed literals
Fri, 20 Apr 2001 16:12:03 +0400
Can we solve and close the problem of the meaning of decimal pointed
| 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 <email@example.com> writes
> What are you talking about? Input in decimal representation is
> stored as a Rational number. There is absolutely no loss of
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.