Re: motion 15
> From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
> To: "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>
> Cc: <stds-1788@xxxxxxxxxxxxxxxxx>,
> "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>
> Date: Mon, 10 May 2010 14:18:57 -0500
>
> Dan Zuras Intervals wrote:
> >>
> >> -- As was shown, the single sticky bit in Motion 15 is not
> >> enough to
> >> reliably propagate exceptional information through all
> >> computations... at
> >> least one additional sticky bit of history would be required.
> >
> > On the contrary, the sticky bit in motion 15 IS sufficient
> > to remember the history of the computation WRT this
> > decoration. One need only look at the formula to see that.
>
> Dan, P1788,
>
> Facts are stubborn things.
They are, aren't they.
>
> To refresh everyone's memory why the single sticky bit in Motion 15 bit is
> not sufficient to rember the history of exceptional information of a
> computation, I attach the original discussion and example on why.
>
> Sincerley,
>
> Nate
>
Nate criticises Motion 15 from a discussion I posted
BEFORE Motion 15 was made while we were all still
working out the details.
As has been the case throughout, that discussion is NOT
what Motion 15 is about. Motion 15 is about means for
defining decorations & rules for their propagation.
The meaning of those decorations is to be a subject of
future motions. No doubt to be preceeded by discussions
of their own.
The only assumption that Motion 15 makes about those
decorations is that they name properties that are
generally intended to be true for the mostly defined,
mostly continuous, mostly bounded functions that are
the business of intervals work.
Under that assumption, the only thing that needs to be
tracked in a sticky is the failure of some evaluation to
be normal in this sense. Thus the bits defined in Motion
15 accomplish their task both for branch & bound methods
& diagnostics.
But Motion 15 speaks for itself.
I include it below for that purpose. Together with the
cover letter that outlined its intended purpose.
It is short. And as clear as I could make it.
Judge for yourself.
Dan
To: stds-1788@xxxxxxxxxxxxxxxxx
Cc: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
From: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
Subject: Motion: Clarify decoration definition and propagation.
Date: Fri, 23 Apr 2010 07:16:01 -0700
Folks,
I move that we adopt the following as our definition
of decorations.
The purpose of this motion is to clarify the definition
of decorations and define rules for their propagation.
The meaning of the decorations themselves is not part
of this motion and should be the subject of some future
motion.
However this motion assumes that the names of those
decorations correspond to properties that are usually
expected to be true. For example, 'bounded' rather than
'unbounded'. Thus, it is the failure of a property to
be true that is considered unusual and worthy of being
tracked with that property's sticky.
Dan
------------------------------------------------------
To each interval there shall be a set of decorations that
corresponds to that interval and carries information about
how that interval was computed. Each decoration within
that set shall carry 3 bits of information named
'thingy'True, 'thingy'False, and 'thingy'Sticky.
(Note to editor: John, 'thingy' is where you can put some
italic form placeholder to stand in for the property being
discussed. This is like <i> formatOf </i> in 754. Perhaps
<i> propertyOf </i> or <i> decorationOf </i>. Its up to
you.)
Together with the predicate is'thingy' we define for all
monadic interval functions f(xx):
'thingy'True = {there exists x in xx such that
is'thingy'(f,x) is True}
'thingy'False = {there exists x in xx such that
is'thingy'(f,x) is False}
'thingy'Sticky =
'thingy'False(xx) \or 'thingy'Sticky(xx)
We define for all dyadic interval functions f(xx,yy):
'thingy'True = {there exists x in xx and y in yy
such that is'thingy'(f,x,y) is True}
'thingy'False = {there exists x in xx and y in yy
such that is'thingy'(f,x,y) is False}
'thingy'Sticky =
'thingy'False(xx) \or 'thingy'Sticky(xx) \or
'thingy'False(yy) \or 'thingy'Sticky(yy)
There shall also exist predicates 'thingy'True(xx),
'thingy'False(xx), and 'thingy'Sticky(xx) and the
extraction function
get'thingy'(xx) = ('thingy'True(xx),'thingy'False(xx),
'thingy'Sticky(xx)).
The initial (or default) value of 'thingy'True(xx), and
'thingy'False(xx) upon creation of a new xx shall be determined
by the nature of 'thingy' (in a future motion). The initial
value of 'thingy'Sticky(xx) shall be False.