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