From: Guillaume Melquiond (guillaume.melquiond_at_[hidden])
Date: 2006-12-08 10:27:50
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
Boost interval<T> uses a representation as a pair of T values: the lower
and upper bounds of the connected set . 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
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 .
That is, once you said how to divide values of type T, you can divide
values of type interval<T>.
 For comparison, n2137 does not mandate a specific representation; an
implementation relying on a midpoint-radius one would still be compliant.
 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk