Re: [boost] Re: [rational] Announcing new maintainer--call fo rfeaturerequests

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-04-02 04:51:47

Andy Little wrote:
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> news:00aa01c536c0$66dd7f60$6601a8c0_at_pdimov...
>> Jonathan Turkanis wrote:
>>> No, I was claiming that in some cases a developer might know the
>>> range of all possible inputs, and be able to reason that no overflow
>>> could occur.
>>
>> You do understand that the range of the inputs has almost nothing to
>> do with overflow, right?
>
> There is a safe range of values for each operation.
> eg for an implementation of rational addition  where Rationalx  = Nx/
> Dx and operator + is implemented as :
>
> (N1 * D2 + N2 * D1 ) "/ "(D1 * D2)
>
> Assuming the same maximaum allowable value for each of N1, D1, N2, D2
> max value of ( N1 * D2 + N2 * D1) occurs when
> N1 == D1 == D2 == N2,
> max value of (D1 *D2) when D1 == D2,
>
>  therefore max allowable value of all these is:
>
> sqrt(double(std::numeric_limits<int_type>::max()/2)) .
>
> For a  16bit int this leaves you with a safe range of +-127 in this
> case.Of course after 'normalisation' referred to in the
> boost::rational docs, the result of the addition itself  may or may
> not be out of range.

True, but if your computations do not consist of a single addition, you'll 
see you "conservative" range shrinking down rapidly to [1, 1] for the 
denominator. ;-)

The real answer is that rational addition is rational-overflow-safe (as 
opposed to ordinary integer-overflow-safe) if Di == Dj (or the equivalent 
where all D's divide some Di). That is, when I could have used integer 
arithmetic instead of rational.

This is perhaps an important use case. However it is completely unaffected 
by rounding (which never occurs in this scenario.) Hence, rational can be 
improved to support another use case (floating point replacement) without 
affecting its current users.