From: Herve Bronnimann (hbr_at_[hidden])
Date: 2002-09-10 10:45:12
On Mon, Sep 09, 2002 at 11:09:52PM -0400, David Bergman wrote:
> I got the impression that you have fixed your library to one-dimensional
> continuums (in C++ defined by float, double and long double).
Yes and no. We DO fix the library for one-dimensional continua. It's a
design choice, because I don't think we could have handled other
dimensions (literally and figuratively). But in C++ they are not
defined only by float, double and long double. You can create your own
class that represents real numbers. People do that all the time. As
Guillaume said, boost::rational, mpfr_t, bigfloat packages, and even
fixed-point floating point types (some are being discussed right now,
although not sure if that discussion is leaning towards numerics).
> There is nothing wrong with that, by the way. A purely "mathematical"
> (read "operating on a linear continuum") interval is good in itself. I
> just do not want us to cheat ourselves by thinking that the interval
> abstraction could be used for other elements. And, I do not mean "being
> able to instantiate without compiler objections". I mean real use.
Good. I didn't want to cheat anyone either, but obviously we could have
done a better job pointing this out in the documentation.
> No problem, by inserting it into "boost::numeric" the nature of the
> abstraction will be further defined, as well.
Good point. Yet still unresolved by the way. So far boost::math, or
boost::numeric, or simply boost::?
rational is only in boost, whereas quaternion is in boost::math, and
ublas and mtl in boost::numeric. I'm not sure about boost or
boost::math, but by association, boost::numeric would have been my last
choice. This is not to say, BTW, that boost::interval shouldn't operate
well with ublas, for instance.
> To reiterate what I meant with my two categories of template
> specializations (or instantiations): (1) conceptual specialization, is
> where we get some new concept, inheriting properties from the template
> and (2) implementation specialization, is where we get the same concept,
> but with other implementation-defined characteristics.
Thanks for clarifying. I get it now.
> I argue that
> "interval<float>" and "interval<double>" are category-2 variants.
In a way, yes, because they have the same conceptual semantics, provide
the same member functions and the likes, the only
thing that varies is the base number type.
> A lot of Boosters complain and warn other developers to not be overly
> abstract, so the pragmatic choice you made, with heavy focus on rounding
> policies is probably the right one.
Thanks. One concern with boost::interval was to make something that
works, and solves real problems that bother real people. The abstract
beauty of the construction came in second. This is also why we're not
too incline to abstract for the sake of abstracting and would rather
delagate further extensions (like half open ranges or interval lists) to
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk