[std-interval] Interval comparison operators

[George Corliss]

Guillaume,

>> #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.
> 
> I agree, but only partly. Handling bounds directly makes it look
> simpler, but only as long as you are sure your intervals are not empty.
Absolutely, but I probably am checking for non-empty in my algorithms
anyway.

> For example, "A.lower() <= B.upper()" will be undefined if one of the
> intervals is empty, while "possibly(A <= B)" will return false. With
> possibly empty intervals, it becomes necessary to add new tests and this
> may decrease both performance and readability.
> 
> I suppose it's only a matter of habits though. People who are used to
> handling bounds directly will keep handling bounds directly, while
> people who are used to multi-valued logics will keep using them, and so
> on. So, in a sense, the question could become: into which habits do we
> want people who are new to interval arithmetic to get? Personally, I
> wouldn't mind students using possibly / certainly so that they have to
> think about what they really want to express rather than directly going
> to lower level manipulation of bounds :-).
Good point.

Any handling I can think of adds surprises, e.g.,
(X < Y) || (X == Y) || (X > Y)
is almost surely FALSE.

Add that to the list
    a - a != 0
    a^2 != a*a
    distributive law does not hold
of surprises awaiting the unwary.  These are unavoidable consequences of the
theory, but the longer is the list of surprises, the more challenging is
adoption.

I accept that we'll end up with interval to interval comparisons.  I urge a
simple alternative, (relatively) easy to understand, in some sense.

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