Le vendredi 08 décembre 2006 à 14:04 +0000, John Maddock a écrit :
Then there is the matter of representing intervals. With lower-upper bounds as in Boost.Interval, the representation is fine as long as the precision of the intervals is "small". For precisions of thousands of bits, a midpoint-radius representation is more efficient, as the radius can be stored in reduced form to improve performance and memory footprint.
Isn't the Boost.Interval interface agnostic of the underlying representation?
Boost interval<T> uses a representation as a pair of T values: the lower and upper bounds of the connected set [1]. Whatever the uncertainty on the real results, it is enclosed between these two bounds.
Of course one would probably have to specialise boost::interval<T> for each type T you want to work with :-( Unless someone has a generic implementation?
The implementation is generic; you just have to provide a mathematical kernel as a policy (what the documentation calls the "rounding policy") in order to describe how to perform operations on values of type T [2]. That is, once you said how to divide values of type T, you can divide values of type interval<T>. Best regards, Guillaume [1] For comparison, n2137 does not mandate a specific representation; an implementation relying on a midpoint-radius one would still be compliant. [2] n2137 does not need a policy, as it is not generic : its behavior is not defined for user-defined types, only for native floating-point types.