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