RE: [boost] Formal Review for Interval Library beginning

From: Guillaume Melquiond (gmelquio_at_[hidden])
Date: 2002-09-03 14:48:34

On Tue, 3 Sep 2002, David Bergman wrote:

> Guillaume wrote:
> 
> > You are right, there is two interpretation of <=. And it was also one
> of the conflicting?
> > point during the design phase of the library.
> 
> > First, you can say that [a,b] <= [c,d] is true iff it is true for each
> pair of elements.
> 
> > But you can also say that [a,b] <= [c,d] is the same as !([a,b] >
> [c,d]). And unfortunately,  > this interpretation is not equivalent to
> the previous one.
> 
> My comment: no, you can not say that (partial order)

I strongly disagree! How can a function that returns a bool and doesn't
throw an exception be a partial function? The order defined by the
compare_certainly policy (or by compare_possibly) is a total order; each
pair of interval can be ordered by this relation.

So it is NOT a partial order. It really is a TOTAL order. So the second
interpretation is a valid one. Consequently, I hope you agree that I don't
have to answer your following concerns. :-)

> > So we had to choose an interpretation. And we finally choosed the
> second one. The reason is: > an user who is not attentive enough may
> transform "if !(a <= b)" in "if (a > b)". If it was > the first
> interpretation, the program would suddenly be incorrect. It can even be
> more
> > dangerous if you are using an algorithm that was not written by
> yourself: how can you be
> > sure the programmer didn't do this mistake, and this error never
> appeared before because
> > nobody was using intervals with it.
> 
> My comments to Guillaume's comment:
> 
> You chose the wrong one ;-)
> 
> Here we have that implicit strictness and totality of orderings lurking
> again...
> 
> Note that intervals, by the definition given in your library and in
> Interval Arithmetics are *partial orderings* w.r.t. "compare_certainly",
> no matter what numeric homeomorphically embedded basis we use.
> 
> The user should be forced to realize that he has left total orderings
> and went into the land of partial orderings, where the "if !(a <= b)"
> and "if (a > b)" equivalence does not hold. Such shortcuts are *only*
> allowed in total orderings, else we would end up with the rather
> unpleasant "(a <= b) != (a < b || a == b)", which is the case here...
> 
> Also, the implicit "equivalence as incomparability" is only a vivid
> alternative when sorting vectors, IMEHO.
> 
> I would love to see this library (1) extend its reach a bit, to make use
> of those "nifty meta-programming constructs" C++ provides us with, i.e.,
> be a bit more flexible w.r.t types and (2) handle the ordering of
> intervals in a more logically sound manner. Till then my vote would be
> to reject the library.
> 
> /David

Regards,

Guillaume