more Re: [std-interval] pros and cons of csets

[R. Baker Kearfott]

Guillaume,

At 10:01 PM 6/5/2006 +0200, Guillaume Melquiond wrote:
>Le lundi 05 juin 2006 à 14:43 -0500, R. Baker Kearfott a écrit :
>
>> Picking up on your "digression," I don't see how multiplying four positive
>> intervals and getting an interval containing negative numbers as 
>> a result is related to cset arithmetic.  Isn't this related to
>> the definition of interval multiplication, which, for finite intervals,
>> is the same as the old-fashioned definition of multiplication
>> of intervals?  That is, isn't this a quality of implementation issue?
>> (Lower bounds that are positive but rounded down should be rounded
>> down to exactly zero, and a result that is exactly zero shouldn't 
>> be rounded down. Isn't that what IEEE-754 does?)  Otherwise, are
>> you thinking of an example with infinite end points that I missed?
>
>Yes, an infinite end-point is involved. But this is unfortunately easy
>to obtain because of rounding. For example,
>
>interval<double>
>  a(1.3e-200, 5), b(2.7e-150, 8), c(0.8, 4.2e100), d(17, 7.3e250),
>  e = (a * b) * (c * d);
>
>The lower bound of a * b is rounded to zero and the upper bound of c * d
>is rounded to infinity in double precision floating-point arithmetic. As
>a consequence, their product e will contain negative values. Indeed the
>cset of 0*inf contains -inf; hence e is forced to include the whole
>extended real line. Without rounding (e.g. with rational bounds),
>interval e would have contained only positive and finite values. With
>rounding and without cset, interval e would have been [0,+inf).
>

Thank you.  That clarifies it.  

Let me think about this some more and also allow (possibly) others to
respond.  I'm thinking there are possibly other cases where not including
the -\infty will result in a set that does not contain points that
are expected.

>By reverting the bounds, it is possible to distinguish between
>overflowed infinities and real infinities (I think there is a paper by
>Hickey on this subject) and hence prevent this issue. But interval
>computations will get a bit expensive because of this trick.
>

That is true.  Also, certainly, we'd like the interval arithmetic to
be reasonably fast.  However, regardless of exactly how the extended
interval arithmetic is defined in the standard, it should be possible
to make it clear to users, in a simple explanation, what particular
results will be.  If cset arithmetic is used, hopefully there aren't
too many cases in which what classically has been called "overflows"
and "underflows" occur :-)

Best regards,

Baker
 

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