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

Re: Revised Motion 26 decoration scheme



John Pryce wrote:
Note also that our text continues to include Nate's "bare object
arithmetic", whose importance for efficiency I accept.

I'm glad to hear that, but I note we don't agree on how bare decorations are
promoted to decorated intervals: Bare decorations should always be promoted
to Empty decorated intervals, not Entire.

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.

I note motion 27 doesn't yet address arithmetic on bare objects. But my
position is that bare decorations must promote to Empty, not Entire. This is
because: once an exception occurs, the most important thing is to propagate
the original cause or reason for the exception to the end of the lengthy
computation. In other words, we no longer care about "containing" subsequent
exceptions, since at that point all interval information is lost, anyways,
and to do so leads trivially to "con" in almost all cases (and this is
really uninformative).

Nate