Re: Motion 52 -- Time to revive the "Expression" subgroup?

[Richard Fateman <fateman@xxxxxxxxxxxx>]

There are lots of potential interactions between compiler-generated code and
implementations of interval arithmetic,and potential for error even without
intervals. With a few notable exceptions, the people who implement
compilers tend to have a simplistic understanding of arithmetic.

"optimizing" x-x to zero isn't one
even if x is a number... x-x is, I think, NaN  if x is a NaN.

There are also bugs to be identified when compilers ignore the fact
that rounding modes affect the meaning of expressions, and take out
what appear to be common subexpressions.

Implementing interval arithmetic as a collection of calls to closed 
subroutines
which take full note of, and reset as necessary, all floating point flags,
traps, etc.   seems to me to be almost inevitable.

RJF


 On 11/19/2013 3:59 PM, Vincent Lefevre wrote:
> On 2013-11-05 07:10:33 -0800, Richard Fateman wrote:
> > On 11/4/2013 5:44 PM, Jean-Pierre Merlet wrote:
> > > I think that by default the compiler should take the expression
> > > "as it" and provides simplification only on demand.
> The compiler should follow the semantics of the language.
> Allowed optimizations with depend on that.
>
> > I think we cannot depend on a language implementation ignoring
> > optimization settings etc.  Thus some systems will 'optimize'
> > x-x to 0.   So we cannot advocate writing x-x, at least if the answer
> > matters!
> Systems don't blindly "optimize" x-x to 0 (unless x is necessarily
> a number). An interval isn't a number. 0 isn't an interval.
> Optimizing x-x to 0 when x is an interval is an error.
>
> Note: If in some language, x represents a number but the evaluation
> is done with interval arithmetic, then compiler could be allowed to
> optimize x-x to 0, but that's out of the scope of P1788, because the
> optimization (or simplification) is done before interval arithmetic
> comes into play.