Andy Little wrote:
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:00aa01c536c0$66dd7f60$6601a8c0@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.