Boost logo

Boost :

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:
>>> Requesting comments on the code, and review for
>>> inclusion in the next release.
>> Hi,
>> the enum type could follow the one defined in
>> "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


Boost list run by bdawes at, gregod at, cpdaniel at, john at