Re: [boost] Re: rational with finite precision

From: Andras Erdei (aerdei_at_[hidden])
Date: 2004-12-12 14:16:49

On Sun, 12 Dec 2004 17:53:08 +0000 (UTC), Mickey Moore <mgmoore_at_[hidden]> 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