[std-interval] Interval comparison operators

[George Corliss]

Friends,

My thoughts on this thread:

#1  In my own interval programming work, I don't think I have ever used
certainly/possibly operators or tri-valued logic, mostly because I have to
think too hard.  Instead, I use <double> tests on interval endpoints, e.g.,
lo(A) <= hi(B), and similar.  I must think carefully through all cases, but
boolean tests work as I am familiar.  I think I am not alone in that
practice.  I believe it leads to code that is more easily maintained by
people with only intermediate expertise.

#2  I do NOT favor making it as easy as possible for programmers to take
legacy code, change double to interval, and expect to get anything sensible.

If I ruled the world, I would have no interval to interval comparisons.  If
I did accept them, I'd use the CERTAINLY interpretation, that is
   X < Y is hi(X) < lo(Y)

I do not want the responsibility of ruling the world, and I am certainly
sympathetic to the argument that interval code should be as familiar as
possible to experienced programmers of <double>, suggesting the standard
should support interval to interval comparisons.

I also favor simplicity.  If this group argues about interpretations, what
is the plight of someone new to intervals.  Who would read the several pages
required to specify the semantics of several alternatives?

I am not sure what is the simplest solution, and I'll gladly follow further
discussions.  At the moment, I favor providing the CERTAINLY interpretation,
   X < Y is hi(X) < lo(Y), etc.,
although I am painfully aware that makes it easy to write code that violates
the Principle of Least Astonishment and can deliver results that a user
could interpret as violation of containment.

If we cannot accept
   1. No interval to interval comparisons
or
   2. Interpret comparisons as CERTAINLY,
my third choice is the interval<bool>.  When I first saw it, I was
horrified, but I've come to rather like the idea.  It has the advantage of
making boolean operators consistent with the cset interpretation for
numerical operators.  I like that design consistency.

Dr. George F. Corliss
Electrical and Computer Engineering
Marquette University
PO Box 1881 
1515 W. Wisconsin Ave.
Milwaukee WI 53201-1881 USA
414-288-6599; Fax: 288-5579; Dept. 288-6280
Office: Haggerty Engineering 296
George.Corliss at Marquette.edu