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

From: David Bergman (davidb_at_[hidden])
Date: 2002-09-03 06:13:43

Guillame,

We both know that there are numerous possible (partial or total) (strict
or non-strict) orderings on the complex numbers. You see, I am a math
guy too ;-)

When I said "viable" I meant "that could be interesting and/or
applicable for an interval application". So, we do agree there. What I
meant with it not being a good example is that there indeed are partial
orderings that could be potential alternatives for an (arithmetic)
interval application (do not ask me to mention one, cause then I would
have to think ;-)

And do not be too strict on the strictness property ;-) Of course the
relation <m, where a <m b iff |a| < |b| is an ordering on the complex
numbers; it is obviously antisymmetric.
Whether the "every day use" of the word "comparing" is intended to
denote the strict order or the preorder is up to debate. Do not get
hooked up on that; I can use exact terminology if you want, but would
then assume the same stringence from you, which would clutter the dialog
with unecessary formal adornments. So, please let us keep this dialog on
a higher level than that.

IMEHO, there are potential arithmetic interval applications dealing with
dates; even if dates are (usually) represented as numbers does not mean
they are numbers, i.e., one does not want all the "numerical" operations
on them. But, we still might want to do (some) arithmetics (thus falling
in the "Arithmetic Interval") on them. There would probably not be a
definition of sinus on david::date (or guillaume::date)...

One question, is your arithmetic interval library intended to be used
for anything else but "float" or "double"? If not, I think it could be
made into such an abstraction, without changing the "arithmetic"
property too much.

I hope you did not get offended by me seeing more applications of this
library than pure double or float. I got a bit excited by a real (pun
intended) interval library, and my mind flied away on applications where
intervals, and certain arithmetic operations on them, could be useful.

Regards,

David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Guillaume Melquiond
Sent: Tuesday, September 03, 2002 4:46 AM
To: boost_at_[hidden]
Subject: RE: [boost] Re: Formal Review for Interval Library beginning

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

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost