From: David Bergman (davidb_at_[hidden])
Date: 2002-09-02 14:54:43
You are absolutely right in me thinking that this was a bit more generic
Your tone was not hard at all, directness is always welcome.
But, one might want to have arithmetics without the analytical
properties. I.e., one might have "numbers" such as "date", where simple
arithmetic could be highly useful but analytical operations, for
example, have no place. So, if we could bisect this abstraction in some
way to be able to do operations on non-analytical intervals, such as
date intervals, which I consider a prime application area for these
And, the opening for partially ordered numbers still hold. Note that the
complex numbers is not a good example of a partially ordered set, since,
if you use the standard real "less-than" order on it, you actually get a
total order on a subset of the set. In fact, there is no viable (partial
or not) ordering on the complex number, except comparing the magnitudes.
I think we might want partially ordered numbers (although most
definitions of numbers imply some kind of total ordering) to be used in
Also, I happen to be abstract enough to not clearly distinguish "range"
and "interval". There seem to be two discriminators, that might be
implemented as traits: (1) discreteness and (2)analytical properties.
[mailto:boost-bounces_at_[hidden]] On Behalf Of Guillaume Melquiond
Sent: Monday, September 02, 2002 3:11 PM
Subject: RE: [boost] Re: Formal Review for Interval Library beginning
On Mon, 2 Sep 2002, David Bergman wrote:
> In fact, paragraph 3 of the Comparisons section seems to give an
> (implicit) opening for partially ordered types, since the whole "for
> all" argument would not be needed, were the type totally ordered; one
> would only need to compare the end points.
> I agree that there would be usage of this interval abstraction without
> all the arithmetic operations.
> One question: should we have iterators over an interval? I know it
> sound a bit Pythonish, but it would be nice to traverse (at least
> discrete) intervals.
> And, if "numbers" imply types with the given arithmetic operations
> defined, then one should definitely split the headers into "interval"
> and "interval_arithemtics", so we could use (partially) ordered types
> for interval operations such as comparison, slicing and traversal.
If I clearly understand you, you don't need the arithmetic part of the
library. But please remember that the name Interval Library is an
abbreviation of Interval Arithmetic Library. Its purpose is
What you propose is a complete change in the interface and the meaning
of the library. It was meant to provide an usable and efficient way of
replacing numbers by intervals in arithmetical operations.
If you only need "interval operations such as comparison, slicing and
traversal", then you should take a look at the proposal of Richard
Peters who has been working on "a library for representing ranges".
Please excuse me if you find my tone of voice uncalled-for. I just
wanted to say that you may be misunderstanding the original purpose of
Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk