Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Version 2.11, Proposal for interval standardization



Michel Hack schrieb:
Interesting discussion between Sylvain Pion and Arnold Neumaier about
expression evaluation and constant expressions (section 2.6 in V2.11).

Sylvain Pion a ©crit:
Arnold Neumaire schrieb:
The transformation (1/interval(3))*3   ->  interval(3) is covered since
in 2.6., only requirements on the results are specified, not on the
means how to obtain them.
Yes, but I was suggesting to remove section 2.6, by generalizing it with
what I just proposed, hence the example that shows that it applies to
constants as well, just like your current section 2.6.

Arnold himself forgot that section 2.6 only talks about REAL expressions
(and in fact CONSTANT real expressions), not INTERVAL expressions.

Yes, I had responded to what I thought is the theme and was taking interval to be some unary function, rather than looking at what was really written. So I also didn't see that the simplification should
have been -> interval(1). (Sometimes I am a bit tired.)


There is a reproducibility issue here however -- but I think that P1788
would be ill-advised to recommend, never mind mandate (under special mode
perhaps), reproducibility across implementations.  I touched on that in
my comments about the Kearfott/Pryce/Revol P1788 draft of 2008-09-29.

The 754-2008 standard has a section on reproducibility, and recommends a
mode of calculation where the "literal meaning" of the program text has
to be followed, primitive by primitive (among other things).  In the P1788
this would mean that (in 3-digit decimal, to simplify the example), the
program expression (NOT 2.6 text)
   (1/interval(3))*3
must yield [.999,1.01].

The question remains how many rearrangements should be permitted.  We all
agree that containment properties are crucial -- but is that all?

A compiler should not do any rearrangement, since few of them have a uniformly benefical effect. Expert users may be able to gain from
a good manual rearrangement, an effect which is marred when the compiler
undoes their intentions.

On the other hand, systems that have access to the syntax tree of an expression (such as all current systems for constraint programming and deterministic global optimization) may involve expert knowledge to transform a problem given as a problem involving real numbers only
into its best interval representation. Then rearrangement is part
of the solution algorithm.


Arnold Neumaier