[boost] [rational] Over/underflow checked update ready for comments

Subject: [boost] [rational] Over/underflow checked update ready for comments
From: Dan Searles (dansearles_at_[hidden])
Date: 2012-09-05 22:28:27

>> For those interested in the rational number class, see:
>> https://svn.boost.org/svn/boost/sandbox/rational
>>
>> Requesting comments on the code, and review for
>> inclusion in the next release.
>>
>>
>
>Hi,
>
>the enum type could follow the one defined in
>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html

>"When an overflow does occur, the desirable behavior depends on the
>application, so programmers may specify the overflow mode with a value
>of type |enum class overflow|. The possible values are:
>
>|impossible|
>    Programmer analysis of the program has determined that overflow
>    cannot occur. Uses of this mode should be accompanied by an argument
>    supporting the conclusion.
>|undefined|
>    Programmers are willing to accept undefined behavior in the event of
>    an overflow.
>|modulus|
>    The assigned value is the dynamic value mod the range of the
>    variable. This mode makes sense only with unsigned numbers. It is
>    useful for angular measures.
>|saturate|
>    If the dynamic value exceeds the range of the variable, assign the
>    nearest representable value.
>|exception|
>    If the dynamic value exceeds the range of the variable, throw an
>    exception of type |std::overflow_error|.

'impossible' and 'undefined' are effectively the same thing, and
equivalent to the 'no check' currently implemented. 'modulus' makes
more sense for the fixed point class that it's being described for
than rational numbers. I'm not sure a useful definition can even be
made for rationals. 'Saturate' sounds like it might be useful, but gets problematic
quickly when there is under/overflow within the largest/smallest
range limits. The point is that if a result of a calculation is not
exactly representable, you will get an exception to notify you. And of
course 'exception' is in the new implementation for just that purpose.

>
>BTW, I have no access to the link for the examples and the test.

I have not changed those files. The existing examples and test
are still valid for the original non-checked case. For the checked
case, I have tests which run for hours. The tests for rational
instantiated with signed char is exhaustive (there are only so
many normalized values. Pairing up each value with every
other value on the binary operators doesn't result in much more
that 2**32 combinations). For short/int/long long, sets of interesting
values are created, and each value is paired up with every other
value in the set. I can provide the test drivers if anyone is
interested.

>
>Could you update the History section?

The history section is missing about 6 earlier updates. It also has the problem
that it's written in the 1st person by the original author. It might be best
to leave that section alone, and just update the main doc body and the
revision history of the header file (already done).

>
>In order to avoid breaking the existing interface, you could define a
>class basic_rational that has the new template and define the current
>rational using this basic_rational.
>
>template <typename Integer, overflow Ov> class basic_rational;
>
>template <typename Integer> class rational :
>basic_rational<Integer,overflow::undefined> {...}

The new implementation doesn't break the existing interface of
the original rational class/header.

>
>Best,
>Vicente

Thanks

>
>P.S A link to a standard proposal
>* http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3363.html.

There are some interesting things in there to consider... My current
goal, however, is to add over/underflow checking to the original implementation,
rather than add new capabilities beyond that. 

Comments?