[boost] Re: Re: Re: rational with finite precision

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-12-14 14:30:55

Andras Erdei wrote:
> On Sun, 12 Dec 2004 18:10:58 -0700, Jonathan Turkanis
> <technews_at_[hidden]> 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

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

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