[std-interval] Interval comparison operators

Ron Avitzur avitzur at PacificT.com
Wed Apr 26 18:11:47 PDT 2006


Hello,

I use the equivalents to certainly, possibly, and interval<bool> in 
interval graphics code.  Given both the care that must be taken to 
think through the cases, and that interval methods will be novel to 
many programmers using the library, I would tend towards an API which 
preferred safety over convenience.

If a programmer constructs an STL container of intervals which uses 
operator< by default, it would be safer if that failed to compile (if 
it has the wrong signature and there is no automatic conversion to 
bool, for example), rather than if it compiled but sometimes failed 
at run-time because either operator< or the automatic conversion to 
bool threw an exception, which is not allowed to happen for 
comparisons used in standard containers.

Being able to write certainly(X < Y) makes for readable code. 
Allowing if(X < Y) to compile with some default meaning introduces 
potential for confusion and subtle run-time errors.

A tradeoff is that then examples such as this need to be written in a 
way that is less elegant.

At 6:06 PM +0200 4/26/06, Guillaume Melquiond wrote:
>         template< class T > sign_t det2(T a, T b, T c, T d) {
>           T u = a * d, v = b * c;
>           if (u < v) return negative;
>           if (u > v) return positive;
>           return zero;
>         }
>
>         sign_t good_det2(double a, double b, double c, double d) {
>           try { return det2< interval<double> >(a, b, c, d); }
>           catch(...) { return det2< exact >(a, b, c, d); }
>         }

An appropriate question here is, how often is it useful to have 
functions template <class T> f(....) were T can be either scalar or 
interval?

- Ron Avitzur


>#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.


More information about the Std-interval mailing list