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

Re: A motion for property tracking via decorations



> From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
> To: "P-1788" <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: A motion for property tracking via decorations
> Date: Fri, 20 May 2011 12:48:11 -0500
> 
> 
> Dear P1788,
> 
> I submit the attached PDF entitled "Property Tracking with Decorations" as a 
> new motion.
> 
> Sincerely,
> 
> Nate Hayes

	Nate,

	Some observations about your new motion:

	On page 2, 2.2 Decorations, the list of examples includes
	the entry:

		S(sqrt,[0,4]) = D3.

	This suggests to me that earlier on page 1, Definition 1,
	the continuous you are describing is C0 continuous.  Were
	it C1 continuous or anything higher the answer to sqrt([0,4])
	would be D2 (defined but NOT continuous).  In that case we
	would have:

		S(sqrt,[0,4]) = D2, &
		S(sqrt,[1,4]) = D3.
	
	Maybe some mention of this could be made.

	Page 2, definition 3, only applies to functions for which
	one of their operands being empty is OUTSIDE their domain.
	Off the top of my head, if we have a function
	max([0,3],[1,2]) = [1,3], we're going to want
	max([0,3],empty) = [0,3] & the decoration to be either D3
	or the decoration of the non-empty operand.

	I can see you are laying the groundwork for a FTDIA with
	this definition.  I hope this does not cause a problem.

	In particular, on page 3, under 3 Rationale, in the list
	of tracked decoration facts, the second entry CAN happen
	for the reasons stated above.  Unless you change
	definition 3 to account for it.

	Your 3rd entry: decoration = D3, result = Empty, At least
	one independent variable was nonempty and at least one
	independent variable was empty; the expression is certainly
	defined and continuous.

	This suggests that there are 2 different things we are
	calling empty here.  There is the interval part thing with
	the value empty.  And there is the decoration thing with
	another value that means empty.  The former is the thing
	that means the interval in question is empty & should be
	the only thing that answers to isEmpty().  The latter
	thing is a property that (mostly) tracks the existence of
	empty intervals in the evaluation chain & has a meaning
	more like isOrWasEmpty().  Do I have that right?  Do we
	need another nomenclature for the latter empty to avoid
	confusion in the future?

	A later entry on the same list: decoration = D2, result =
	Empty, At least one independent variable was nonempty and
	at least one independent variable was empty; the expression
	is certainly defined.

	This one confuses me a bit.  Perhaps it is in the nature
	of tracking things versus decorations that have meaning
	for the function being evaluated.  For if I saw an example
	of f(operands) = {empty,D2} I might be tempted to conclude
	that f is defined for this set of operands & the defined
	answer is empty.  But I THINK what you mean by this is
	that in the course of evaluating f(operands) some PREVIOUS
	function returned an empty (for whatever reason) but it
	was a sort of 'benign' empty that did not raise the threat
	level beyond D2.  Do I have that correct?

	The same can be said of the decoration = D1, result =
	empty entry where the empty in question was even MORE
	benign.

	Perhaps these things are (or must be) true.  But it
	confuses me.

	The last entry invokes a confusion of a different sort:
	decoration = D0, result = Nonempty, All independent
	variables were nonempty and the expression is certainly
	undefined.

	So we have a function for which the cross product of the
	operands is a non-empty interval which is ENTIRELY outside
	the domain of the function.  And YET that function manages
	to return a nonempty result.  What sort of mad function is
	that?

	There are two philosophies about decorations that have been
	bandied about in our discussions.  Let's call the first
	approach the TRACKING form.  That is, that decorations are
	there to record the actual sequence of exceptional events
	that happened on this particular tree of evaluations for
	this particular set of operands.  Then there is the STATIC
	form.  That is, that decorations are a statement about the
	evaluation of this function which is informed by but not
	necessarily constrained by the decorations of its operands.

	When I first suggested the notion of decorations lo these
	many months ago, I had the tracking form in mind.  And
	everything I have mentioned so far about your document
	suggests this is your philosophy too.

	But the first paragraph that follows your list on page 4
	suggests the static form to me:

		As is the case with FTIA, Computer Algebra Systems
		(CAS) can often be employed to perform expression
		rearrangement in order to find less pessimistic
		enclosures of an expression. For property tracking,
		finding less pessimistic enclosures may likewise
		cause a conservative tracking decoration (D1) of
		an expression to change to an exact decoration (D0,
		D2, or D3).

	The fact that a function might take inputs which are no
	worse that D1 & change them in either direction (D0, D2,
	or D3) suggests that the decoration is a property of THIS
	function & not (necessarily) of any previous.  Do I have
	that right?

	If so, which philosophy is it to be?  Tracking or static?

	BTW, although I favored the tracking philosophy in the
	beginning, some arguments people have made in the meantime
	suggest to me that the static philosophy might serve us
	better.  Both are sufficient for an FTDIA to be proved.
	But the tracking approach is not necessary.  And it is
	confusing in some cases.  So I am beginning to lean towards
	a static interpretation.  The library writer can still pass
	operand decorations through her function when they are still
	informative about that result.  (Your intersection example
	later down on page 4 is a good example of passing meaningful
	decorations through a function.)  But she is free to discard
	them when it is not, so long as operands that are ordered by
	subset have decorations that are ordered as well.

	Just a thought.

	On page 5, your comment about boundedness suggests a static
	approach.  I think that is the correct thing to do in this
	case.

	And your conclusion is practically a statement of that which
	is needed for FTDIA.  It is not (necessarily) tracking but
	maintains the inclusion property.  Exactly right.

	Well, that's my quick list.

	Hope it helps more than hinders...


				Dan


	P.S. - on reading this before I hit send I realized that
	you have no decoration for 'ill'.  Do we need one?  And
	where does it go in the ordering?