From: David Bergman (davidb_at_[hidden])
Date: 2002-09-05 16:23:23
I hope the induced equivalence relation not being an equivalence
relation at all in your case do trigger some after-thought... That fact
is important enough to not only mention it in a subsentence. Any
equivalence you choose have to start by including one element in each
equivalence class, through reflexivity.
Numbers (according to most definitions) are linearly ordered, intervals
(and sets) are not, according to your "completely to the left of"
operation. It is as simple as that, there is no way to make that
structure be homeomorphic to a numerical system, while retaining the
useful properties of intervals. Again, STL does *not* mandate that
things are totally ordered, it is just that certain operations are not
viable if the structures are not totally (or linearly) ordered.
As I suggested in a recent post, I would want us to skip using these
operators at all and try to define what relations we have here.
I will look through Joel's diagrams and come with a formal suggestion
' David <= Genius '
[mailto:boost-bounces_at_[hidden]] On Behalf Of Herve Bronnimann
Sent: Thursday, September 05, 2002 4:57 PM
Subject: Re: [boost] Re: Interval Library and comparison operators
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
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.
-- Herve' _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk