Interval arithmetic presents some unique challenges compared to
plain floating-point arithmetic in this regard.
On (Thu, 20 Nov 2008 11:43:47 +0100) Arnold Neumaier wrote,
in thread
Subject: Version 2.11, Proposal for interval standardization
In addition, it will specify the following about value-changing
optimizations:
Value-changing optimizations.
These should be handled similar to Section 10.4 of IEEE-754-2008.
Transformations are allowed if and only if they would be exact
in exact real arithmetic and provably lead to enclosures contained
in the enclosures obtained by using the original expression.
A (nonexhaustive) list of such allowed transformations should be
provided in an appendix to the standard.
Consider the fact that [-2,3] * [-2,3] = [-6,9]
whereas [-2,3]**2 = [0,9]
Is the language processor allowed to transform xx*xx into xx**2
or sqr(xx)? This would tighten the enclosure, hence would be
permitted by Arnold's description quoted above.
Presumably the reverse transformation would not be allowed, unless
the correlation (same xx) is observed and handled, as otherwise
the enclosure would widen.
Should the language processor be allowed, or encouraged, to go even
further and recognize
yy := xx; zz := xx*yy;
as being a product of correlated intervals?
Note that similar concerns arise when interval arguments to a function
are passed by value, compared to passed by reference. In by-value the
function must assume independence; in by-reference it could detect the
correlation. Should it act on it? Do we need guidelines?
The issue becomes critical when interval primitives are implemented
as library subroutines, in languages that permit passing structures
by value.
Comments?
Michel.
Sent: 2008-11-20 19:46:52 UTC