From: Andras Erdei (aerdei_at_[hidden])
Date: 2004-12-12 19:51:20
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
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
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
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
br,
andras