RE: [boost] Formal Review for Interval Library beginning

From: David Bergman (davidb_at_[hidden])
Date: 2002-09-03 15:13:58

Guillame, the relation, viewed as a function (from A x A to Bool) is
certainly not partial. Where did I claim that. I said that the resulting
*ordering* was partial. And you say here that it is not? I am totally
confused... What is [3, 5] < [4, 6]? And what is [4, 6] < [3, 5]? If
both are false then the ordering is partial.

/David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Guillaume Melquiond
Sent: Tuesday, September 03, 2002 3:49 PM
To: boost_at_[hidden]
Subject: RE: [boost] Formal Review for Interval Library beginning

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

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost