Re: rationals initialization bug

From: d.frey_at_[hidden]
Date: 2000-11-28 07:09:27

--- In boost_at_[hidden], "Moore, Paul" <paul.moore_at_u...> wrote:
> From: d.frey_at_g... [mailto:d.frey_at_g...]
> > Sounds like work, right? :) But we will have no operator>>, no
> > lexical_cast, nada - if there is no such beast as a floating point
> > parser.
> 
> Yes, but we already have such a beast:
>     double d;
>     std::cin >> d;
> 
> However, because of representation inaccuracies, it does not produce
an
> *exact* representation of the input (eg, in the case of input 0.1).
Hence,
> to produce a rational, we have two options: one, to reimplement the
parser
> avoiding the inaccuracies (which I have no intention of doing), or
two, to
> create rationals from doubles, "undoing" the inaccuracy of parsing.
> 
> Put that way, option (2) sounds unreasonable. Maybe it is. (It's
effectively
> attempting to invert a lossy conversion). But if so, then I will not
> implement a conversion from double to rational.

If you are using a rational<T> with a type T with 100 digits, option
(2) will not work. I'm working in the financial sector and it's not a
good idea to round or convert too much here :) Therefore, the string
method would have a big advantage: It needn't decide for either
'exact' or 'do what I mean'. When I don't allow initialization from a
double, the problem vanishes. The only way of initializing a rational
with a value other than an integer is to use a string and that's
non-ambiguous. Also, writing a parser for a class with an internal
decimal representation may be easier than you might think - it's IMHO
far easier than writing a parser for a binary represented value.

Also, the lack of a rational( double )-ctor will always remind the
user that conversion from double to rational is not as easy as he
might think. Also, it shows that some overhead is involved. (OK, true
for string conversion too - anyway, it's more obvious in that case :)

> rational class. The only question is whether one of these functions
is
> suitable for use as the default way of converting a double to a
rational. In
> my view, suitability boils down to "do what I mean". If the result
of
> rational<int> r = d surprises the user, then it has failed its
purpose, and
> should be handled via functional notation (where the function
documentation
> can include all the caveats).

The problem is that such functions may not be predictable (in the
sense of intuitively predictable by the programmer when using it). The
string approach yields no such suprises AFAIK...

Regards, Daniel