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

Re: motion 15

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





Dan Zuras Intervals wrote:

Subject: Re: Discussion on tetrits motion



From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
To: "P1788" <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: Discussion on tetrits motion
Date: Fri, 23 Apr 2010 15:59:16 -0500

Dan, et. al.

In your 4/17 post, for all 3-bits you included the explicit tables:



No, Nate.

Those tables were part of a discussion that
only applied to the 'domain' decoration as
I understood it at the time.

In the motion just made, you will notice
that there are no such tables.  The reason
for this is that they will not apply to all
decorations.

And, as this motions says nothing about any
particular decoration, I would like to make
discussion of particular decorations the
subject of some future motion.

As I said in the cover letter.


   Dan


Dan,

I'm trying to make sense of your e-mail:

   -- Of course there are no tables in the motion, but the definitions
that generated the 4/17 tables are the same as the definitions in the
motion. Below I include both for a "side by side" comparison... the tables
are a consequence of these definitions.

   -- I believe we need to explicitly discuss advantages or
disadvantages of the proposed definitions with regard to particular
decorations that we probably will adopt, i.e., having or not having a
particular decoration should not be the issue, but how suitable the
motion enables or inhibits the goals of various decorations would be.

Sincerely,

Nate



Dan Zuras Intervals wrote(4/23/2010):

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)





Dan Zuras Intervals wrote (4/17/2010):

+------ 'inDomain' = {There exists x in xx & y in yy such

                    that (x,y) is in the domain of g(x,y)}
+---- 'outDomain' = {There exists x in xx & y in yy such

                  that (x,y) is NOT in the domain of g()}
+-- 'outSticky' = outDomain(xx) \or outdomain(yy) \or

                outSticky(xx) \or outSticky(yy)

v v v Meaning
- - - -------
F F F No points, never was, [empty] & always has been.

F F T No points, also [empty], one operand was [empty] while
the other one was outDomain or outSticky.  Looks like
this state can only be reached by a dyadic function.
I'm glad I decided to check that.

F T F Completely outside the domain of this function but no
previous function had that problem.  Returns [empty].

F T T Completely outside the domain of g(), also [empty],
also was outside the domain of some previous function.

T F F Completely inside the domain of g() & as well as inside
the domain of all previous functions.  This is the
good state we all like to see.

T F T Completely inside the domain of g() but some previous
function was not so lucky.  This is also a good state
of sorts.  A domain error once happened but it hasn't
bothered g().  This may or may not be of interest to
the user but it looks like something that is good to
know.

T T F Both inside & outside the domain of g() but no previous
function suffered a domain error.  Any problems are g's
fault alone.  This state & the next are states you
likely start with in branch & bound methods.

T T T We have points both inside & outside the domain of g()
& had problems in the past.  This is the other state
you start with on branch & bound.



On 4/23/2010 15:59, Nate Hayes wrote:

Dan, et. al.

In your 4/17 post, for all 3-bits you included the explicit tables:

op1 x op2 --> possible results
--- --- ----------------
FFF x FFF --> FFF
FFF x FFT --> FFT
FFF x FTF --> FFT
FFF x FTT --> FFT
FFF x TFF --> FFT
FFF x TFT --> FFT
FFF x TTF --> FFT
FFF x TTT --> FFT

FFT x FFT --> FFT
FFT x FTF --> FFT
FFT x FTT --> FFT
FFT x TFF --> FFT
FFT x TFT --> FFT
FFT x TTF --> FFT
FFT x TTT --> FFT

FTF x FTF --> FFT
FTF x FTT --> FFT
FTF x TFF --> FFT
FTF x TFT --> FFT
FTF x TTF --> FFT
FTF x TTT --> FFT

FTT x FTT --> FFT
FTT x TFF --> FFT
FTT x TFT --> FFT
FTT x TTF --> FFT
FTT x TTT --> FFT

TFF x TFF --> FTF, TFF, TTF
TFF x TFT --> FTT, TFT, TTT
TFF x TTF --> FTT, TFT, TTT
TFF x TTT --> FTT, TFT, TTT

TFT x TFT --> FTT, TFT, TTT
TFT x TTF --> FTT, TFT, TTT
TFT x TTT --> FTT, TFT, TTT

TTF x TTF --> FTT, TFT, TTT
TTF x TTT --> FTT, TFT, TTT

TTT x TTT --> FTT, TFT, TTT


Now, if we examine what's happening only with the domainOut and domainIn
bits, i.e., the first 2 of the 3 bits (sans the "sticky" bit), we get:

op1 x op2 --> possible results
--- --- ----------------
FF* x FF* --> FF*
FF* x FT* --> FF*
FF* x TF* --> FF*
FF* x TT* --> FF*

FT* x FT* --> FF*
FT* x TF* --> FF*
FT* x TT* --> FF*
FT* x TT* --> FF*

TF* x TF* --> FT*, TF*, TT*
TF* x TT* --> FT*, TF*, TT*

TT* x TT* --> FT*, TF*, TT*


In most cases, these are exactly the same results provided by the Level 2
priority mapping of tetrtis in my position paper. For example:

sqrt(([-3,-2],(T,F,*))) + ([1,2],(T,F,*))
= ({empty},(F,T,*)) + ([1,2],(T,F,*))
= ({empty},(F,F,*))

The reason is because sqrt([-3,-2]) is {empty}, even though the decoration
is (F,T). As an operand of the addition operation, however, the tetrit of
{empty} is (F,F); and this is the infimum (by priority mapping) of all
operand tetrits.

In other cases, they are quite different, i.e., the proposed mapping is:

sqrt(([-3,1],(T,F,*))) + ([1,2],(T,F,*))
= ([0,1],(T,T,*)) + ([1,2],(T,F,*))
= ([1,3],(T,F,*))

By itself, the decoration (domainIn=T,domainOut=F) is quite misleading for
the interval result [1,3]. With priority mapping, the decoration would be
(domainIn=T,domainOut=T).

I understand this is why you are trying to make up the difference with the
third bit, i.e., the proposed mapping actually results in (T,F,T).

But how is a user supposed to know just by looking at the bits (T,F,T) if
somewhere in the history of computation an operand was evaluated entirely
vs. partially outside its natural domain?

The proposed mapping appears to be counting on the fact that any function
evaluated entirely outside its natrual domain will produce {empty}, and
that
this is good enough to start a chain-reaction of (F,F,T) tetrits
propagating
through the result all the way to the end.

However, {empty} can be absorbed by a union operation, in which case the
tetrit can change back to (T,F,T) state. In this case, the fact that a
serious domain violation ocurred is lost. With priority mapping the
decoration (F,F) would propagate all the way to the end.

THis is why I had suggested that if it really is necessary to divide
decorations into "most recent operation" vs. "history", that we should have 
at least 4 bits. Otherwise its possible to propagate all the neccessary
history in only 2 bits.

Nate