RE: [boost] Re: rationals initialization bug

From: Moore, Paul (paul.moore_at_[hidden])
Date: 2000-11-28 07:51:39

From: d.frey_at_[hidden] [mailto:d.frey_at_[hidden]]
> 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 :)

Um. Are you arguing for NOT having a conversion from double? If so, I could
easily agree with you.

> 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...

Well, it has the unpredictability of "what is the format?"... In my view,
rationals have the canonical string representation n/m, and that's what is
currently supported (admittedly not by a constructor, but by IO, and hence
by lexical_cast). What format (exactly!) would you want? Does it never
depend on the application?

In my view, constructors from strings (and IO representations, for that
matter) are fraught with danger, because representation is so highly
application-specific. In 99% of cases, the standard representations are
inappropriate, and people write their own parsers anyway.

Parsing strings into an internal representation is an entirely different
problem. We already have the regex library, and will soon have lexical_cast,
and possibly others as well. These can be used to build any number of string
parsers for reading rationals.

Paul.