From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-04-02 04:51:47
Andy Little wrote:
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
>> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk