[std-interval] interval(NaN)

[Dr John Pryce]

Guillaume

At 07:14 19/09/06, Guillaume Melquiond wrote:
>contrarily to
>quiet NaNs, signaling NaNs cannot be generated by any floating-point
>arithmetic operations. This is the same with an hypothetical
>Not-an-Interval, none of the arithmetic operations of the proposal would
>generate them, they can only appear at "entry-points". So there is not
>much point in propagating them across every arithmetic operation.

For a non-parallel computation I agree with what you say. But I 
stated the contrary argument in this passage:
At 22:14 16/09/06, Dr John Pryce wrote:
>I have argued for throwing an exception in such a case. But I accept 
>the force of the argument that this also is bad policy in the case 
>of large parallel computations. Assume we have made the constructor 
>work elementwise for arrays, and we have
>   x = interval<double>(xlo,xhi);
>where x,xlo,xhi are arrays of a million elements. If just one 
>element of x failed to be constructed because of a NaN in xlo or 
>xhi, we would like to continue working with the "good" 999999 while 
>STILL BEING ABLE to detect that the computation with the one bad 
>value produces garbage output.

Not my argument of course! Disagreement on this dilemma was I believe 
a cause of the long delay in getting exceptions into the Fortran 
standard (Baker, confirm?).

>And I
>don't want to have to define what would be the semantic of functions
>that return bool, bool_set, and float, when they encounter such an
>interval.

It is a good point. But a nettle that must be grasped if one agrees 
that parallel computation makes NaI's desirable. Siegfried Rump 
probably has views on this in the context of INTLAB.

>  In my opinion, the sensible solution is to have a behavior
>similar to sNaN: "trapping" when they are encountered, which translates
>to: throwing a C++ exception.
>
>Now, back to the main problem. Where should the invalid floating-point
>values be detected? I don't think every function should pay this (not
>necessarily negligible) cost for checking the values. In particular, we
>still need a way for the programmer to quickly create an interval when
>the values are known to be valid. This was the point of leaving
>interval(T,T) partly undefined.
>
>So I suggest having interval(T) throw an exception [1], leaving all the
>other functions undefined when encountering a non-finite floating-point
>number. This leaves one point of disagreement between us: you want the
>checking to be implicit to every functions (don't let any programming
>mistake go through), while I want the checking to be explicit and
>restricted to a few functions (don't pay for what you don't need). I
>suggest we wait for the opinions of the other mailing-list members on
>which checking policy should be chosen.

You put the point very clearly. It is like the distinction between 
your fast lower(), upper() and your always defined but slower inf(), 
sup() functions.

Three points along the coding spectrum are:

- Ann is implementing an interval elementary function. She wants 
speed, and from the structure of her algorithm she is able to prove a 
constructor will never be called with invalid arguments.

- Bob is writing interval code C that accepts user-supplied functions 
F. The code could be an algebraic or differential equation solver. C 
sometimes calls F in point mode, sometimes in interval mode. Bob 
cannot trust F at all. Can he isolate the places where F might cause 
invalid input to constructors? I do not know. Ned, Baker, your views?

- Cal is an inexperienced programmer writing the F for Bob's code. If 
I were Bob, I should want Cal to only access constructors that do 
"implicit" checking as you call it above (I think "internal" is a better word).

We want to cater for all these. Is it possible to make the standard 
offer fast constructors that are only available to "trusted 
programmers" implementing appropriate parts of the library, while 
making the rest of us use safe constructors?

Regards

John

>[1] I believe that, whenever somebody spoke about an exception-free
>library, it applied to the empty set and interval inputs outside the
>mathematical domains of the functions. So having an exception should
>still be consistent with this paradigm, shouldn't it?

I'm glad you said this - I was a little concerned that your standard 
meant the ban on exceptions to be total. I am in violent agreement 
and my impression is that the other ISL members are so too.

Dr John and Mrs Kate Pryce
142 Kingshill Rd
Swindon, Wiltshire SN1 4LW
UK
Tel (+44)1793-331062