Re: Standard behavior for decorations...
Dan Zuras Intervals schrieb:
If we are to go down this path & separate the KISS
interval portion of our results from the not-so
simple decoration portion, then we will likely need
some standard rules to keep the latter from slowing
down or even invalidating the former.
Let me suggest some rules. Feel free to criticise
to taste. :-)
These are gleaned from my discussions with Vincent
appropriately adapted to George's suggestion.
(1) The interval portion of a result should (sorry,
shall) only depend on the interval portion of its
operands. To have decorations that affect the
numerical calculations would drive any hardware to
a halt real fast. So let's not allow that.
(2) The decoration part of a result may, however,
depend on either or both of the interval portions
of its operands or the decoration portions.
(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.
(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.
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).
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