Andras Erdei wrote:
On Sun, 12 Dec 2004 13:47:54 -0700, "Jonathan Turkanis" <technews@kangaroologic.com> 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