Standard behavior for decorations...

[Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>]

	Folks,

	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.

	(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.

	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.

	(2) Things like PossiblyUndefined which are not
	really properties of the interval at all but a
	property of the function to which that interval
	was applied.  So really there is nothing at all
	undefined about the interval [-2,-1] but some
	people want to know that when [-2,-1] is given
	to the sqrt() function it will raise the
	possiblyUndefined decoration.  Thus
	IsPossiblyUndefinedOnSqrt() would have to be a
	predicate specific to the sqrt() function.  But
	IsOrWasPossiblyUndefined(taggedInterval) can look
	at the possiblyUndefined decoration & be generic.

	BTW, sqrt([-2,-1]+decorations) should also raise
	the empty decoration.  In this way the c-set people
	(who want to see the empty) & the modal people (who
	may look on possiblyUndefined as their NaI in this
	case) can both be made happy.

	This may not be a complete list of our needed rules.
	If so, post some more.

	But if this is an acceptable set of rules we can
	start to argue about the decoration events we want
	to see.

	Maybe we can settle on a standard set of decorations
	as well.

	Then again, maybe not. :-)

	Let's see.

	Yours,

				Dan