Dr John Pryce
j.d.pryce at ntlworld.com
Tue Sep 19 15:43:07 PDT 2006
At 07:14 19/09/06, Guillaume Melquiond wrote:
>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?).
>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
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 , 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(),
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?
> 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
More information about the Std-interval