Re: [boost] Interval Library and comparison operators

From: Sylvain Pion (pion_at_[hidden])
Date: 2002-09-05 18:39:07

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