RE: [boost] Re: Formal Review for Interval Library beginning

From: Guillaume Melquiond (gmelquio_at_[hidden])
Date: 2002-09-03 03:46:11

On Mon, 2 Sep 2002, David Bergman wrote:

> 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
> intervals...

To use intervals for dates is something I never considered, so please
excuse me if I miss the point. In my opinion, a date is just a number
(maybe in a strange base). So you can use the library with it (even if I
don't see the interest to use such a complex library on such a simple
datatype).

And it's not because the library allow you to compute the sinus of an
interval that you are forced to compute it. Moreover, if you actually try
to compute the sinus of your date interval, you may get the constant
answer [-1:1] (just to say that, depending on the type, the library may
not even try to compute the sinus).

> 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.

Wrong :-). First, there are some viable partial orders on complex (there
even are some viable total orders); but unfortunately, none of them is
compatible with interval arithmetic. And secondly, "comparing the
magnitudes" is not an order, since it is not antisymmetric. It is a total
pre-order (not sure it is the correct word in english).

> I think we might want partially ordered numbers (although most
> definitions of numbers imply some kind of total ordering) to be used in
> these intervals.

As I said before, an interval is not just a pair of ordered numbers; it is
meant to represent all the numbers between the two bounds. So after giving
it some thoughts, I agree that it is not necessary at all for the order to
be total, seeing that it is compatible with all the operations the user
intend to use.

The order could even be a partial pre-order if you don't intend to use
predicates like "certainly equal". But it's another problem.

> 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.

What will "discreteness" provide? It looks to me like these two traits
are not orthogonal at all; they are antagonistic. Indeed, if you
manipulate intervals on a discret type and are interested in iterators and
traversal, then the analytical functions will not be of any use. And vice
versa.

The two corresponding types are totally different; the only common point
being that the underlying datatype is an ordered pair. So yes this
underlying datatype could be in its own library . But it is not the
purpose of the Interval Arithmetic Library to provide it.

It's the reason why I was mentioning the Range Library. It is especially
meant (if I clearly remember) to deal with discret types, traversal and
iterators.

This library was really meant to provide mathematical functions over
intervals, in the same way that std::complex offers mathematical functions
over something not really different from std::pair. (please, I don't want
this last sentence of mine to be the start of a long thread, it is not
meant to be an insult to anyone)

Guillaume