[boost] Re: Re: [rational] Announcing new maintainer -- callforfeaturerequests

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-03-31 14:38:38

Peter Dimov wrote:
> Jonathan Turkanis wrote:
>> Peter, could you elaborate on why rounding is the only legitimate
>> behaviour when using rational with a limited precision type?
>
> Nice phrasing ;-)

This was my interpretation of "do the right thing".  ;-)

> but I'll try.
>
> Since rounding is a subset of unspecified, it can only be worse if it
> carries an unacceptable overhead when overflow does not occur. I
> don't think that this is the case here.
>
> Asserting on overflow is misguided, because asserts should be used to
> catch logic errors, and rationals rarely participate in program
> logic; the source of the computation usually comes from user input.
>
> Exception on overflow is only better than rounding if no result is
> better than an approximate result, that is, when the answer has to be
> correct no matter what. This requirement is better served by
> rational<unlimited> which does deliver a correct answer. I don't see
> how rational<limited>+exception-on-overflow is better.

It seems to me that in some cases developers will be able to reason that based
on the numerators and denominators of the instances of rationals they explicitly
construct and the type and number of operations they need to perform, no
overflow will occur if they use, say, rational<int>. In some cases, they will
reason incorrectly; this is the type of logic error which might be usefully
signaled using assertions.

I believe Andras was arguing that this type of reasoning can almost never
succeed in realistic situations; I'm not convinced of this yet.

If I change the implementation to implement rounding, but leave the
specification the same, I'm not sure I'm helping anyone. To the developer who
needs exact representations and has reasoned incorrectly that rational<int> is
sufficient, a close approximation may be no better than a wildly wrong result.
In fact, the wildly wrong result may make the logic error apparent earlier.
Also, a developer who doesn't need exact representations can't rely on unspecifi
ed behavior.

If, on the other hand, I change the specification to include rounding, I may be
excluding future optimized implementations of the arithmetic operations which
don't automatically yield a rounded result in cases of overflow. Maybe it's
clear no significant improvements are possible along these lines, but I'd like
to consider it carefully first.

Jonathan