Boost logo

Boost :

From: David Bergman (davidb_at_[hidden])
Date: 2002-09-06 11:12:17


But we will not find such a ordering (at least not a total one, which is
required by STLish use). Does this mean that we should give up the idea
of using intervals in (associative) containers, and in traversing

Please, agree with me ;-)

We could add a disclaimer that "this ordering is a pragmatic solution
and there is no aspiration on it being of any more relevance than others
as to the domain of intervals, but we could not find anyone better,
being total, sorry".


-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Sylvain Pion
Sent: Friday, September 06, 2002 12:01 PM
To: boost_at_[hidden]
Subject: Re: [boost] Interval Library and comparison operators

On Fri, Sep 06, 2002 at 11:18:44AM -0400, David Bergman wrote:
> I definitely vote for having the lexicographic ordering being the
> default one, for all us STLish developers. It should be noted, and
> understood, that the purpose of that ordering is to enforce a total
> ordering for STL and similar purposes, and is in no way a
> domain-specific statement about intervals for arithmetics.
> If developers want domain-relevant relations, he/she should define
> them (or Boost.IntervalArithmetic could provide some useful ones, as
> given by Joel's disection)

I disagree.
I think that the default, if there is one, should be useful for the
_primary_ usage of intervals. And IMHO, this primary usage is not going
to be 'using the STL stuff "blindly"' by "us all STLish developpers".

If someone has a need for intervals, it is motivated _first_ by some
"domain-relevant" stuff. Hence I think the default is related to that.
This is what is going to drive you to choose the correct

Do you use std::complex just to store a pair of floats ? No.

The discussion shows that operator< and std::less are stuck to each
other. And I think it is much more useful to have a default that works
well for the usage of operator< (related to the primary usage of
intervals), than for STL's default arguments in some containers.

So I am still on the position that there should either be no default
Comparison_policy, or that the default should be to throw an exception
for the overlap case (and usual total order for the rest of the domain).

Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at