[std-interval] Out-of-domain behavior

[R. Baker Kearfott]

Gilllaume,

Thank you for the clear analysis.  I concur.

Baker

At 02:46 PM 10/9/2006 +0200, Guillaume Melquiond wrote:
>Le dimanche 08 octobre 2006 à 08:55 -0700, Steve Clamage a écrit :
>
>> I'm sorry, I didn't mean to introduce any confusion by talking about a 
>> hypothetical "iNaN".
>> 
>> There is no real number corresponding to sqrt(-1), but if sqrt returns, 
>> it must return some value.
>> 
>> I only wanted to distinguish the case of returning a result when there 
>> is no answer, from throwing an exception instead of returning.
>
>[ This mail is meant to state anew, what the problem is precisely, so
>that we don't get sidetracked too much. ]
>
>The NaI was only discussed as a way to return something when one of the
>inputs has no interpretation as an interval, for example a NaN
>floating-point value. This is just an implementation detail due to some
>functions/constructors having floating-point arguments. Let's focus on
>interval arithmetic; the important point is: With interval functions,
>there _always_ is an interval answer. This is a consequence of the
>mathematical model we chose in the proposal: intervals are sets and
>functions are set extensions. Example: sqrt([-1,2]) returns a superset
>of [0,sqrt(2)] while sqrt([-1,-1]) returns the empty set.
>
>Unfortunately, when solving equations (differential or not), this
>resulting set does not contain enough information. You also want to know
>if some values of the input interval were out of the domain of the real
>function. This information should not replace the previous interval, it
>has to be an _extra_ information. This is why neither an exception nor a
>NaI are good solutions, as you will lose the "set" part of the answer.
>Moreover, the out-of-domain information has to propagate till the end of
>the computations: it has not much sense locally, it is only useful when
>looking at the global computation.
>
>So, if we want to use the most interesting interval algorithms, we
>should systematically use something like a pair<interval, bool> instead
>of just an interval, both at input and at output of interval functions.
>This is neither usable nor efficient.
>
>So the two solutions we are left with are:
>
>1. Using an explicit parameter:
>
>interval my_function(interval x, interval y, bool &f)
>{ return divide(sqrt(x, f), 1. + sqrt(asin(x) + y, f), f); }
>
>2. Using an implicit (global) parameter:
>
>interval my_function(interval x, interval y)
>{ return sqrt(x) / (1. + sqrt(asin(x) + y)); }
>
>The first solution has a clean semantic and it is vendor-friendly, as
>there is no side effect. The second solution is user-friendly, as it is
>more readable, less error-prone (have you noticed the mistake in the
>first version of my_function?), and probably more efficient. I don't
>think any of these two solutions is clearly superior, and unfortunately
>I don't have anything better to suggest.
>
>Best regards,
>
>Guillaume
>
>_______________________________________________
>Std-interval mailing list
>Std-interval at compgeom.poly.edu
>http://compgeom.poly.edu/mailman/listinfo/std-interval
>
>

---------------------------------------------------------------
R. Baker Kearfott,    rbk at louisiana.edu   (337) 482-5346 (fax)
(337) 482-5270 (work)                     (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------