[std-interval] Interval comparison operators

[first.i.last at comcast.net]

 -------------- Original message ----------------------
From: Guillaume Melquiond <guillaume.melquiond at ens-lyon.fr>
>  Now we are interested in what the opinions of
> other interval developers are. Should the user be allowed to
> compare intervals in C++? And if so, what should the semantic
> of these comparisons be?

The attached file contains our detailed response to the issue of comparison of intervals.  Readers interested in specifics without explanation or rationale should not read it.

George Corliss wrote:

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

This is an effective endorsement of the KISS principle.  We agree that comparison operations need to be as simple, clear, and readable as possible.  We believe that expresion templates or any other specialized technique, e.g., exceptions, that is not widely used in other comparison contexts will retard the widespread use of intervals.

Devil's Advocate question: how much of your habitual resistance to the use of higher level comparisons is due to the non-portability of the various implementations?  AFAICT tests of the bounds are the only reliable cross-platform conventions, so they may be the only reasonable habits at present.

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

This is a properly cautionary warnng, but with respect to comparison operators, we disagree.  The warning applies to retaining point-wise algorithms instead of adopting interval algorithms.  We do not believe it applies to primitive operations.  Rather, primitive interval operations should be as similar as possible to built-in floating point operations.

Ron Avitzur wrote:

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

The readability issue is important.  I suspect that to a typical C++ user "if ( certainly( X < Y ) )..." looks more like a syntax error than it does readable code.  Since "if ( certainly_lt(X, Y ) )..." is approximately as readable even to a person without knowledge of the specialized expression templates that affect only intervals, it is absolutely more readable than the former.

The issue of default meaning is even more important.  The default meaning of the comparison operators has to be so simple that it is hard to get it wrong.  And it has to work everywhere, including within the STL.

Guillaume Melquiond wrote:

> Ron Avitzur a écrit :
> > 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?

> Not that often, I would say. Yet, whenever you are using
> intervals to control roundoff errors on a scalar type, it makes
> sense to use the same syntax for both the code using the
> scalar type and the code using the interval type. An exception
> is then thrown when two computed values are too close for
> being comparable due to roundoff errors.

In order to promote compatibility with the STL we suggest the avoidance of exceptions in favor of a handler function such as Interval::indistinct() modeled on _matherr() which would be called whenever an indistinct comparison was detected.  We have used this successfully, but found the principal value concept (detailed in the attached document) to be a simpler and thus superior solution.

>>>>>>

> 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 :-).

The question of the desirable habits for new users is absolutely fundamental.  The answer to that question forms the criteria that should be used to evaluate the entire interval proposal, particularly interval comparisons.  My company has spent a great deal of effort attempting to make it easy for C++ users to incorporate intervals into their programs, but our results are will not be ready for release for some months yet.

It may be worth soliciting an opinion from the author of the Frink programming language.  He added support for interval arithmetic in the form of triplex numbers a year or so ago.  His implementation is perfectly straightforward and lacks many of the features of other interval arithmetic implementations.  But due to the simplicity of his implementation he may be able to offer useful insiight into the issue of making intervals easy to use safely.

Lee Winter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-tar
Size: 5469 bytes
Desc: not available
Url : http://compgeom.poly.edu/pipermail/std-interval/attachments/20060528/cd7ed932/attachment.tar