Andras Erdei wrote:
On Sun, 12 Dec 2004 18:10:58 -0700, Jonathan Turkanis <technews@kangaroologic.com> wrote:
This sounds like an argument for a checked_rational type, not for automatic rounding.
actually adding a "rounded" flag (e.g. stored in the sign bit of the denominator) is trivial and does not increase the complexity of the rounding code
From my point of view, it defintely can't be the default because this would change the behavior of existing code. However, I'm open to adding a rounding
<snip discussion> I agree with many of your points, except the main one: that Boost.Rational with built-in intergal types is useless without rounding. One way to make the class more flexible would be to introduce a rounding policy as the second template parameter. Various rounding policies could include: - no rounding, and no notification that the result of an operation is inexact - no rounding, with an assert when the the result of an operation is inexact - no rounding, with an exception when the the result of an operation is inexact - round to the nearest representable value - round towards zero I think you are arguing that the second to the last is easy to compute, and should be the default. Right? policy or adopting some other solution which would allow users to chose the other behaviors. Please feel free to offer suggestions or contribute code. The only thing I'm against is changing the default behavior, unless there is wide agreement that the current version is broken.
Boost.Rational has been around for almost 5 years now, and I don't believe it's had this effect.
do you know anyone who has been using it with built-ins?
No, I've only been the maintainer for a short time.
(this problem surfaced the second day i started using it, and i have spent a lot of time looking for the bug in my code before checking the boost::rational implementation :O)
I'm sorry about that. I think we're agreed that the warning in the documentation should be more prominent.
br, andras
Jonathan