RE: [boost] Re: rationals initialization bug

From: Moore, Paul (paul.moore_at_[hidden])
Date: 2000-11-28 04:58:30

From: Lutz Kettner [mailto:kettner_at_[hidden]]
> I wonder if there is a misconception on my side. For me the 
> "algorithm" of converting a float/double to a rational is simple
> and easy, and it is exact except for overflow errors in num/denom. 
> The rounding and approximation errors happen always when converting
> towards doubles/floats. The rounding error in:
> 
>   rational<..> rat = 0.1;
> 
> happens when 0.1 gets scanned and converted to double, not when
> the double gets converted to a rational.

I may be overcomplicating the issues, but in my view, someone who writes

    rational<int> rat = 0.1;

wants rat to have numerator 1 and denominator 10. Yes, this is not the exact
value of the double which is being passed as an argument to the rational
constructor, but that isn't the programmer's fault. (For a more obvious
example, suppose that the 0.1 came from an input stream, as end user
input...)

I agree that we're in the area of "do what I mean, don't do what I actually
said", but that's the point - floating point is hard, and rationals are
"nicer" in some sense. Exposing floating point representation issues to
naive users of rationals is, IMHO, not helpful.

To make my position explicit, I believe that

    rational<int> r1 = 0.1;
    rational<int> r2(1,10);

should result in r1 == r2. If it does not, then I don't believe that an
implicit conversion from double is appropriate - although maybe a function
(which makes the issue explicit, say simplest_rational()) to do the job is
appropriate.

I will test the algorithms I have seen and find out if they make this
equality happen. If any of them do, then no problem. Otherwise, I won't
implement a constructor from double. If anyone wants to try to persuade me
that I should change my position, by all means do so. But I *don't* want the
rational class to expose the complexities of floating point representations
to the user (I already have an issue with the problems caused by the use of
limited-range integers, but don't start me on that one again :-)

Paul.