Andras Erdei wrote:
Mickey Moore wrote:
... 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
This is essentially what the docs currently state: "The rational number class is designed for use in conjunction with an unlimited precision integer class." It would be easy to prevent rational from being instantiated with built-in integral types, but this would just make the library less useful. Perhaps the disclaimer should be featured more prominently.
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
It sounds like you are describing a numeric type which could coexist with boost::rational. Perhaps you should implement it and post it. Jonathan