RE: [boost] Interval Library and comparison operators

From: David Bergman (davidb_at_[hidden])
Date: 2002-09-05 18:49:00

Sylvain,

As had been said over and over again, there evidently is no "natural"
ordering complying both with STL algorithms and interval arithmetics,
since STL is primarily constructed for total orderings (I hope I will
get some reaction to this statement :-) ), while interval arithmetics
deal with partial orderings.

So you are right in your intuition that there might not be an ordering
that complies with both "fields".

/David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Sylvain Pion
Sent: Thursday, September 05, 2002 7:39 PM
To: boost_at_[hidden]
Subject: Re: [boost] Interval Library and comparison operators

On Thu, Sep 05, 2002 at 06:42:39PM -0400, David Bergman wrote:
> What about taking George's midpoint relation and extend it to a total 
> order?

It seems to me that comparing the midpoints of 2 intervals is not far
related from just comparing only the two lower bounds, right ? And if
you want a total order based on this one, I guess you naturally go to
lexicographic order.  So we are back to square one :)

Otherwise, midpoint has several problems : I don't really see the
connection to any reason why you would play with IA (the core of it
being the arithmetic operators).  midpoint gives you an approximation,
but the whole point of IA is to control roundoff errors, hence you use
that when you don't want any approximation, so... Moreover, it's harder
to compute than just comparing bounds (not that much a priori, but if
you look more closely, it may overflow and cause various problems,
etc...).

All what these discussions make me think is that there is no obvious
default that "fits the STL" and has a useful arithmetic meaning at the
same time.

If there is a default one, it should really be "the obvious one" for
everybody. But I don't see one going to reach a consensus.

And I'm not even sure there really needs to be one either.

Comparisons over the intervals have to be used carefully (and
intentionally) anyway, and the precise meaning is dictated by the
intended usage.

So another option is to not have any default Comparison policy, and
force the user to choose one.  That would be fine with me.

That said, I think that most useful orders (from the arithmetic point of
view) match the corresponding order over the underlying type T, when the
intervals do not overlap (e.g. x<y => x.upper() < y.lower()). 

[the inclusion order is special, though useful and used]

Since there is no really obvious value to return when the intervals
overlap, we might want to consider throwing an exception. At least
having this policy as default is going to force the user to explicitely
do something to take care of the problem :)

I may be partial on this one, since it's the choice of my own IA
implementation.

Concerning Joel's list of orders, I think it would probably be nice to
have them all available as policies.

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