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

Subject: Re: [boost] [rational] Over/underflow checked update ready for comments
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-09-05 23:40:59

Le 06/09/12 04:28, Dan Searles a écrit :
>>> 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.
Yes and not. Maybe from the point of view of the library, but this is a 
useful information from the user point of view.
> '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.
You are right. modulus for rational has not a clear sense.
> 'Saturate' sounds like it might be useful, but gets problematic
> quickly when there is under/overflow within the largest/smallest
> range limits.
Could you clarify?
> 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.
A user can be interested in overflow check without exceptions. The 
saturate policy should be a good replacement in context where exceptions 
are not allowed.

Anyway, you should replace the CamelCase use in the definition of this 
new enumeration. I think that basing your definition on the preceding 
one could be acceptable.
>
>> 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.
I was interested by the examples and test using the new facility. Could 
you commit them in the sandbox, please?
>>
>> 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.
>
How are you right, there is no break. I don't know which problem I was 
seeing.

Best,
Vicente