Re: Standard behavior for decorations...
> Date: Sat, 05 Sep 2009 18:15:41 +0200
> From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> CC: stds-1788@xxxxxxxxxxxxxxxxx
> Subject: Re: Standard behavior for decorations...
>
> Dan Zuras Intervals schrieb:
> >
> > . . .
> >
> > Let me suggest some rules. Feel free to criticise
> > to taste. :-)
> >
> > . . .
> >
> > (3) A decoration is an event <x> which happened
> > during the calculation of this result or during the
> > calculation of some previous result that led up to
> > this result. Thus the event is more properly called
> > <x>Happened. A decoration may be tested or set but
> > it may never be cleared. After all, you cannot make
> > <x> unhappen at some later date.
>
> But this can be only locally. There must be a way to throw
> away a decoration when the variable is reused for a new
> function evaluation. Otherwise if an empty decoration was
> present once, all future evaluations would give empty.
> Thus the clearing process must be better specified.
Just so. Events, once they happen, hang around forever.
The event is emptyHappened or IsOrWasEmpty. It does not
mean that the interval is currently empty. Merely that
there was an empty involved in the computation of this
interval.
One can still determine if this interval is currently
empty as I mentioned below. But emptyHappened should
not be lost lest the user need that information in the
validation of some later result.
However, your point is well taken & one could reset
any or all decorations using an interval constructor.
One could construct a new interval with the dimensions
of the old one & any set of decorations one desires.
But I think that should be frowned on as a practice.
>
>
> > (4) The standard definition for a decoration event is,
> > therefore, <x> is the inclusive OR of the <x> events
> > of its operands together with any <x> event that
> > happened during the computation of this result.
> >
> > You can fill in your favorite values for <x> now.
> > We could have <x> be: Empty, PossiblyUndefined,
> > PossiblyDiscontinuous, Unbounded, UserNaI0, UserNaI1,
> > whatever.
>
> On the whole, I like these decoration rules.
>
> If the decoration is one byte (or two, should more than
> 8 properties be needed) in which the bits are individual
> properties, this should be a good format.
Agreed but not important at this time.
>
> Would it be cheap to arrange that users specify which bits
> will be set, and would there be a speed advantage in asking
> for fewer in some program? If not, there should just be two
> modes:
> -- No decorations and no monitoring of properties (default), and
> -- all properties monitored in the decoration (no matter
> what is actually tested in the program).
In my discussions with Vincent he repeatedly admonished
me for trying to decide this very thing & I ultimately
came to believe he was right.
We should let the decorations be an abstraction for the
moment. Let the number of them vary as we argue their
merits. And let the final form & ordering of them be
considered unimportant for the moment.
Indeed, if they are accessed through test & set functions,
they're final form could be forever irrelevant to the
purposes of our standard & we can leave that up to the
implementers to decide what is best for them.
As for modes: part of the motivation for having decorations
is to avoid behavior changing global state like modes.
IMHO, we can leave all the properties of decorations
(storage formats & handling of the bits) intact formally
& let optimizing compilers figure out that some or all
decorations are not used in this program & can be safely
eliminated without harming the correctness of the code.
All the more reason to leave the exact format of
decorations up to the implementers.
>
>
> > There may be a problem if you need to know if <x>
> > is currently true about the current interval.
> > This seems to fall into two classes.
> >
> > (1) Things like empty which may be discoverable
> > by looking at the interval portion of a result.
> > Thus IsEmpty(taggedInterval) is a function that
> > looks at the interval portion of taggedInterval.
> > IsOrWasEmpty(taggedInterval) is a function that
> > looks at the empty decoration.
>
> This would give two ways to test for empty, which should be
> enforced to be equivalent whenever decorations are actually
> computed.
>
>
> Arnold Neumaier
No. This gives one way to test for empty, IsEmpty().
And another way to test if there has ever been an
empty involved in the computation of this result,
IsOrWasEmpty().
Two different functions for two different purposes.
That is the intention anyway.
Yours,
Dan
P.S. - There is another event I had on my list with
Vincent. You could call it wideEvaluation or perhaps
looseEvaluation. The event is that some function
evaluated its result in some manner that resulted in
an interval that was wider than it might have been.
Thus, sin() could be written efficiently if it returns
looseEvaluation when it needs to rather than taking
the extra time to compute things down to the last bit.
Also, a non-singleton interval in some lower precision
could set looseEvaluation when it gets promoted to a
higher precision. Either way the user knows that this
result is wider (or less precise) than it might have
been. This also has the effect that the various
'accuracy modes' mentioned in the Vienna document are
not needed. A function is free to choose its accuracy
(on the fly, even) so long as it reports any
looseEvaluation events.