From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-04-04 16:10:24
Peter Dimov wrote:
> 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.
You can always use integer arithmetic instead. ;-)
> 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.
I basically agree except for the question of whether specifying rounding
behavior could lock in an inefficient implementation.
Jonathan