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.
[mailto:boost-bounces_at_[hidden]] On Behalf Of Guillaume Melquiond
Sent: Tuesday, September 03, 2002 3:49 PM
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.
Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk