[boost] Re: Re: rational with finite precision

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-12-12 20:10:58

Andras Erdei wrote:
> On Sun, 12 Dec 2004 13:47:54 -0700, "Jonathan Turkanis"
> <technews_at_[hidden]> wrote:
>
>>> "When used with a limited precision integer type, the rational class
>>> suffers from many of the precision issues which cause difficulty
>>> with floating point types. While it is likely that precision issues
>>> will not affect simple uses of the rational class, users should be
>>> aware that such
>>> issues exist."
>
> maybe i'm not describing the problem clearly (or misunderstand
> something):
>
> every other finite precision type rounds or truncates
> the result, while rational<> returns unrelated garbage
> when it is not exactly representable

Depending on your requirements, the rounded or truncated results could be
considered "unrelated garbage."

> it is important that we are not talking about overflow
> (results out of the representable range), but "sideflow",
> when the result falls between two representable numbers

I understand the distinction you are making. But I don't yet see why it's
necessarily worse than overflow.

> to make sure this doesn't happen, you have to emulate the
> behaviour of rational<> (check during runtime whether the
> intermediate dens and nums are relative prime etc); this
> checking has the same complexity as actually doing the
> arithmetic = to use the class you have to reimplement it

This sounds like an argument for a checked_rational type, not for automatic
rounding.

> to me this spells: boost::rational in it's current form cannot
> be used with any finite precision type, built-in or UDT, ever,
> for any purpose, and people trying to use it might get scared
> away from boost itself

Boost.Rational has been around for almost 5 years now, and I don't believe it's
had this effect.

> br,
> andras

Jonathan