Re: [boost] Re: Interval Library and comparison operators

From: Herve Bronnimann (hbr_at_[hidden])
Date: 2002-09-05 15:57:05

On Thu, Sep 05, 2002 at 03:01:18PM -0400, David Bergman wrote:
> What is so sacred about '<='? The choice of ordering to be denoted by
> the '<' symbol is obviously up for debate. But no matter what the
> choice, should the '<=' not be regarded as syntactic sugar for '< ||
> =='?

I don't want to throw more fuel into the fire at this point :)
but indeed, I tend to consider this as a sticking point and one that is
mostly responsible for the discussion we've had so far. With this email,
I don't try to reach a consensus, but I hope my reply will
make you understand why *I* don't think `<=' should necessarily be
construed as `< || =='.

> I am obviously missing something fundamental here ;-)

I think it's just a matter of point of view. In designing the library,
we took (rather, I must admit, I put forward) the STL view that
EqualityComparable and LessThanComparable are two different concepts
that apply to different domains. And since we were designing
comparaisons of intervals, it seemed to me like we really wanted to
provide LessThanComparable.

This means to deal with <, and >, <= and >= would follow automatically.
So far, it does not say anything about ==.  This is why in the design of
the comparison policy, there are two function: less_than, and equal_to.
By giving the freedom to specify independently less_than, and equal_to
in the comparison policy, we explicitly did not link the two operators <
and == together, with the consequences you pointed out. I still think
it's consistent with the STL design, hence desirable.

Now, for a number type (or one that is supposed to replace/extend one,
as interval does), the requirement that  a<b || a==b || b<a  also
makes sense and implies a certain definition of ==, once you accept <.
We've already discussed about it, and I yet have to digest all the other
messages (esp. Joel's) about the alternate definition.

I just meant the above to say that, it is not obvious to me why ==
should be dragged into the discussion of <. If you take our view, all
the other operators follow only from <, and equivalence for the order <
is when neither a<b nor b<a. With certainly<, `equivalence' becomes
overlap and <= becomes possibly<=, which have a clearly-defined meaning.
The problem is that `equivalence' is not an equivalence relation. But it
has a clearly defined semantics nevertheless.

If we follow your model, we define both < and ==, and then <= follows as
syntactic sugar for '< || > =='. But then, some combinations of < and
== give really strange result for <=, which is why I think you are
arguing for certain semantics over others.

Anyway, I did not mean to advance new arguments, or push one viewpoint
before another. My aim was simply to explain why ``should the '<=' not be
regarded as syntactic sugar for '< || > =='? '' is not so sacred for
everyone as it is for you.

Best,
-- 
Herve'