On Sun, 12 Dec 2004 17:53:08 +0000 (UTC), Mickey Moore <mgmoore@austin.rr.com> wrote:
This is true for *any* operations on the built-in types. If you over/under- flow, the results are meaningless.
no, it is more like 1.0/3.0 giving -0.1415 because 1/3 cannot be represented exactly as a floating point value (or 1/3 giving -20; imho not what a user expect)
You didn't state what platform you were running on, but I figure it's likely that shorts are 16 bits.
yes, i have chosen (a 16 bit) short to make the example small
Therefore both the numerator and denominator of the result are out of range (greater than 32768), so there is no possible way that rational<short> can represent this number. What can you expect it to do in such case?
return the (unique) best approximation, in this case 3197/1540, or (an easier way out) to state in the docs that boost::rational<> only works with unlimited precision types
In general, you can never use finite precision and expect accurate results
no, but imho i can expect reasonable results (the rationale for using boost::rational instead of the built-in floating point types would be to get slower, but useable results even when floats return garbage)
If someone wants the best approximation rather than the exact answer, they would probably just be using floating point. rational is used when people want an exact answer, not just an approximation.
if i understand you correctly, what you say is that rational<> will never be instantiated with finite precision integers anyway (no exact answer then), so there is no reason not to change the docs afaik rationals (and interval arithmetic and numerous other workarounds) are used in applications where floating point arithmetic gives you unusable results (CAD, electronic circuit design and so on), because finite rational arithmetic has much nicer properties than finite floating-point
I think it would be more useful to add a mechanism (probably optional) for reporting when such overflows ocurred (or some equivalent to floating point NANs and INFs, perhaps).
i do not think overflow is the correct term in this case: the result (2.076...) is well inside the range of representable values [you do not say that 1.0/3.0 overflows (or underflows), so you also cannot say it about the example i have given] br, andras