So, if I understand you correctly,
[-2,3] * [-2,3] should not be optimized to [-2,3]**2
but
A * A should be optimized to A**2.
I think this makes good sense. In the former case, the compiler has no
way to know that the first and second instance of [-2,3] refer to the
same quantity, whereas, in the latter case, the programmer has asserted
that they do by choosing the one variable name.
Scott
Christian Keil wrote:
I
think we should be very cautious with such transformations. Currently
writing an interval library or some rigorous algorithm is quite
difficult because of compilers being too smart. Finding out what really
happens often involves going to assembler level and finally decorating
the code with "volatile"s (telling a C/C++ compiler to not assume
anything about the variable, thereby precluding all optimizations
involving it) and searching for expressions that the (current version
of the) compiler does not optimize away.
In my opinion, one of the worst things that can happen to an IA
implementation is that a "correct" program produces invalid enclosures
because of transformations done by the compiler.
The question of independence is of course very important here. [-2,3] *
[-2,3] should not be optimized to [-2,3]**2 unless there is a clear
dependence. Maybe this can be done at the level of variables.
Cheers,
Christian
Michel Hack wrote:
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
|