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

RE: Motion 42 (not 41): Decoration system, revised text



John Pryce wrote:
> From: John Pryce [mailto:j.d.pryce@xxxxxxxxxx]
> Sent: Sunday, December 23, 2012 1:21 PM
> To: nh@xxxxxxxxxxxxxxxxx
> Subject: Re: Motion 42 (not 41): Decoration system, revised text
> 
> Nate
> 
> On 23 Dec 2012, at 14:15, Nathan T. Hayes wrote:
> > The idea to decorate intersection with max(dx,dy) and convexHull with
> > min(dx,dy) doesn't make any sense to me. Where does this idea come from,
and
> > why would someone want to do this?
> Oh dear, I thought this is your formula. I must have misread something,
please put me
> right. Apologies.

Hmm. No, these definitely aren't my formulas. Not sure where you got that
impression.

Attached is an e-mail I sent a few days ago with my formulas. They are the
same formulas I posted on the main reflector at the beginning of the
discussion period for Motion 42.

Anyhow, the trouble is: the decoration system in Motion 42 is not compatible
with my formulas since the motion does not define an ein decoration, nor
does the motion define the necessary containment order where EIN is a subset
of all tracking decorations (a summary of this is also in the attached
e-mail). This underscores my point that to the extent decorated set
operations are not to be prohibited by the P1788 standard, Motion 42 is not
the right decoration system.

Nate


 
--- Begin Message ---
Also FYI:

If dx and dy are the decoration operands of a set operation, then decoration
of the intersection operation is defined as min(dx,dy). For example:

	dx	dy	intersection
	ein	ein	EIN
	ein	dac	DAC
	dac	def	DEF
	dac	ndf	NDF
	ein	ndf	NDF

But union is defined as the "tightest" tracking decoration that contains
both dx and dy. For example:

	dx	dy	union
	ein	ein	EIN
	ein	dac	DAC
	dac	def	DEF
	dac	ndf	GAP
	ein	ndf	NDF

Nate

> -----Original Message-----
> From: Nathan T. Hayes [mailto:nh@xxxxxxxxxxxxxxxxx]
> Sent: Thursday, December 20, 2012 6:09 AM
> To: 'John Pryce'
> Subject: RE: Flavor-independent meaning of decorations
> 
> Hi John,
> 
> I leave the wordsmithing to you and won't suggest exact wording at this
point.
> However, I will provide a summary of the decoration system that will
appear in the
> document I'm preparing for the modal group:
> 
> The universe of all (f,X) pairs is partitioned into five disjoint sets of
static decorations:
> 
> 	p_ein(f,X)	The restriction of f to X is defined and continuous
on empty input
> 	p_dac(f,X)	The restriction of f to X is defined and continuous
and not
> p_ein(f,X)
> 	p_def(f,X)	The restriction of f to X is defined and not
p_dac(f,X)
> 	p_gap(f,X)	The restriction of f to X is nonempty and not
p_def(f,X)
> 	p_ndf(f,X)	The restriction of f to X is empty and not
p_gap(f,X)
> 
> The five static decorations (lowercase) are linearly ordered
> 
> 	ein > dac > def > gap > ndf
> 
> Each (f,X) is an element of exactly one static decoration, and the static
decoration
> represents what is mathematically true at Level 1 about the restriction of
f to X.
> 
> When each real operator in the syntax tree of function f is replaced by
interval
> operations, as when the syntax tree of f is defined in code, the
decorations of each
> operation are propagated using the linear order and the "min rule" we are
all familiar
> with. The result of evaluating f over the input box X in this manner is a
tracking
> decoration (uppercase) which has the following meaning:
> 
> 	Tracking
> 	Decoration
> 	For (f,X)		The mathematically true result for (f,X)
> 	EIN		=>	ein
> 	DAC		=>	ein or dac
> 	DEF		=>	ein or dac or def
> 	GAP		=>	ein or dac or def or gap or ndf
> 	NDF		=>	ein or ndf
> 
> It is therefore the tracking decorations (uppercase) and not the static
decorations
> (lowercase) which form the containment order:
> 
> 	EIN \subseteq DAC \subseteq DEF \subseteq GAP \supseteq NDF
\supseteq EIN
> 
> such that EIN is a subset of all tracking decorations.
> 
> For bare intervals, the natural interval extension f(X) is the tightest
interval hull of the
> image of f on X, and an interval extension F(X) is defined such that
> 	f(X) \subseteq F(X)
> By similar analogy, static decoration of an (f,X) pair is like the
"natural interval
> extension" and the tracking decoration is like the "interval extension" in
the sense that
> the tracking decoration always implies (contains) the mathematically true
result.
> 
> Nate
> 
> 
> 
> > -----Original Message-----
> > From: John Pryce [mailto:j.d.pryce@xxxxxxxxxx]
> > Sent: Wednesday, December 19, 2012 7:39 AM
> > To: Nate Hayes
> > Subject: Flavor-independent meaning of decorations
> >
> > Nate
> >
> > I am moving the "Decorations overview" text, currently at the start of
the set-based
> > flavor, into Chapter 1, aiming to make it flavor-independent. The second
paragraph
> > says (emphasized)
> >
> > > A decoration primarily describes a property, not of the interval it is
attached to,
> but
> > of the function defined by some code, that produced the interval by
evaluating over
> > some input box.
> >
> > I suspect that from your viewpoint this is not correct because you view
it more as
> > describing a property of computational history. Would you like to
suggest neutral
> > wording that applies equally to both flavors?
> >
> > John

--- End Message ---