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
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk