Re: [boost] Interval Library and comparison operators

From: Sylvain Pion (pion_at_[hidden])
Date: 2002-09-05 20:27:23

On Thu, Sep 05, 2002 at 08:41:46PM -0400, David Bergman wrote:
> I would like to have total ordering just to be able to put intervals in STL
> collections, though...

You definitely will be able to do so, with a functor provided by yourself.

The only question is if we should provide a sensible default.
So if there is one, which one should it be ?

If there is a chosen default functor and you can use it, it basically means
that you don't care which particular (total) order of the elements is used in
the sorted container, because otherwise we fall back on the discussion about
the default operator<, where there is no sane default.  If the order provided
by the Comparison policy is fine, the default std::less is probably going to be
fine as well, so there's no need to provide anything more.

So it would be for applications that don't care about the actual order in the
container.  It means it would just use the set/map as a dictionnary, like a
hash table for example, just to test if an element is there or not, i.e. where
the traversal order of the container does not matter to the application.

BUT, (that's what David Abrahams already noted, if I understood him correctly)
the should be a high similarity between std::set<interval<double> > and
std::set<double>.
They should behave roughly the same, at least when the intervals don't overlap.

Now could you give a real application where you would use a std::set<double>
as a dictionnary (i.e. you don't care about the order in the container, think
of it as a hash table and you want to test if a double is there) ?

It seems not obvious for me to find one.  The only one I see if for removing
duplicate points with same coordinates in a list of points read from a file.
( Note that for this application, I don't see what would be the relevance of
  an interval version. )
But if your doubles are computed values with roundoff errors, then the hash
table already mean much less, because equality over computed doubles is
senseless in general.

So, to me, it doesn't seem that common a need to warrant the existence of a
default functor provided by the interval library.

-- 
Sylvain