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

Re: Revised Motion 26 decoration scheme

Arnold Neumaier wrote:

On Wed, July 20, 2011 17:06, Nate Hayes wrote:

Arnold Neumaier wrote:

On Wed, July 20, 2011 16:43, Nate Hayes wrote:

Arnold Neumaier wrote:

For example, consider the real function
    f(x,y) = y + 1 / g(x)
and its interval extention over interval domain (X,Y) where both X
and
Y
are
nonempty. If we are computing with bare objects and g(X) is not
continuous,
then we have
    Y + 1 / def.

Promoting the bare decoration def to (Empty,def) gives:
    Y + 1 / (Empty,def)
        = Y + (1/Empty,inf(ein,def))
        = Y + (Empty,def)
        = (Y+Empty,inf(dac,def))
        = (Empty,def)
        = def
In other words, the exception "def" first occured in g(X) and this
decoration is promoted all the way to the end of the computation. So
the
user knows in this case the reason for failure.

On the other hand, promoting the bare decoration def to (Entire,def)
gives:
    Y + 1 / (Entire,def)
        = Y + (1/Entire,inf(con,def))
        = Y + (Entire,con)
        = (Y+Entire,inf(dac,con))
        = (Entire,con)
        = con
In this case, the exception "def" that occured in g(X) is lost by the
subsequent computations: the user has less knowledge why the failure
occurred.


If one has g(x)=sign(x) and X=[-1,1], the decorated evaluation would
give
con and not def, and indeed, f is not everywhere defined. This
property
must be preserved by the bare rules, since the use of the decoration
might
depend on this.

Moreover, having a different semantics for the decorated and the bare
case
(as proposed by you) would lead to confusion....



This is already a problem for Motion 26, since for g(x)=floor(x) and
X=[4,8]
the full decorated interval computation gives
    def
but when evaluated using bare objects (by Motion 26) it gives
    con


This is not a problem, since in both cases, the answer says something
correct about the function.


Only by coincidence, since the decoration provided is trivially correct
for
any computation.


No. The recipe given in Motion 26 always gives a correct result (namely
equal or less informative than the result of the decorated computation).



Whereas in your example, the bare answer makes a wrong statement about
the function.


It states the evalutation of f(X,Y) is not possible because one of the
sub-expressions was not continuous. This is an entirely correct statement
about the function.


But the ordinary meaning of the decoration def is that the function is
defined on the whole box, which is not the case in your computation. Thus
the user has to keep in mind two different semantics, depending on whether
the compiler did or did not optimize. This would be VERY confusing.


Arnold, be careful.

When you say things like "the ordinary meaning of the decoration", that is
something P1788 has yet to decide. Motion 27 of course gives some different
definitions and semantics: if you criticize those semantics by a competing
definition or point of view, then of course people will be confused.

We ALL will be confused.

I believe Motion 27 gives definitions and semantics that are internally
coherent and consistent; and I believe that promotion of bare decorations to
Empty are entirely correct and consistent with those definitions and
semantics.

The trouble arises when trying to "mix and match" points of view between
Motion 26 and Motion 27, as you are trying to do, IMHO.

So I don't find this line of argumentation persuasive or convincing.

Nate