[std-interval] Revised document available

[George Corliss]

Guillaume,

Very helpful response.  Thank you.

>> If that makes sense, would it also make sense to specify that
>> implementations on IEEE machines take advantage of IEEE support?  For
>> example, one might say, "On machines that support infinities, ... On other
>> machines, ... is implementation-defined."  That would be a MUCH stronger
>> specification of portability without imposing additional requirements in
>> practice.
> 
> Note that this is already the case for inf(). For other functions, it
> would depend on what you put behind your "..." dots.
I am not studying every line of the proposal for instances such as this, but
I hope you are, and that you are satisfied with what you see.

> Note also that the
> current wording impose the use of infinities for arithmetic functions if
> the implementation supports them, as they are the only way to enclose
> some theoretical interval results.
Correct.  That should be clear:  Implementations on IEEE machines are
required to use IEEE features :-)

> So the question becomes: should we
> impose implementations to document the results they return when they
> would have to return an interval containing an infinite bound? I'm not
> sure it is worth it, as I don't see how such a documentation would help
> developers.
I favor the clearest warnings I can convince you to accept.  For example,
suppose x = [1, max_real]; y = x^2.  If the implementation supports
infinity, we are safe with [1, +oo] (really meaning the mathematical
semi-open [1, +oo)).  If we have no infinity, what are our choices?
   1. LIE with something like [1, max_real]
   2. Raise an exception, which no one likes
   3. Some other special bit pattern
   4. Tag to indicate overflow, but we still need to return a value

I believe the most common implementation decision (with no infinities) is to
choose to lie, #1.  I have written a couple packages myself that did that.
I am willing to accept that as an engineering design choice, but with ANY
possible violation of containment, I prefer the strongest, clearest possible
warnings.  I'd like a run-time warning, although that is nearly equivalent
to unpopular exceptions.  AT LEAST mandate a strong warning in the
documentation that an overflow can introduce a containment failure.

We are in violent agreement on most of the proposal.  At points like this, I
think I am a bit more focused on the guarantee of containment, and you are a
bit more focused on speed.

I certainly agree that speed is important.  In fact, I suggest somewhere,
perhaps in the first half of p. 3, you include a reminder to the effect that
EVERYTHING in this standard will perform MUCH better is there is built-in
hardware support for intervals [credit two anonymous referees of one of my
recent papers for reminding us].

I know you agree that containment is important.

Hence, many of these points of discussion are about where on the
speed-safety spectrum we want to be.  Whatever compromises we settle on, we
should clearly document so developers know where they are.

Dr. George Corliss
Electrical and Computer Engineering
Marquette University
P.O. Box 1881
1515 W. Wisconsin Ave.
Milwaukee, WI 53201-1881
George.Corliss at Marquette.edu
414-288-6599 (office); 288-4400 (GasDay);
    288-6280 (Dept.); 288-5579 (fax)
Office: Haggerty Engineering 296
Www.eng.mu.edu/corlissg