Discussion on tetrits motion
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
----- Original Message -----
From: "Chenyi Hu" <chu@xxxxxxx>
To: <rbk@xxxxxxxxxxxx>; "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>
Cc: <stds-1788@xxxxxxxxxxxxxxxxx>
Sent: Friday, April 23, 2010 12:41 PM
Subject: Do I have a second? Re: Motion: Clarify decoration definition and
propagation.
Yes, I second Dan's motion.
Chenyi Hu
Ralph Baker Kearfott <rbk@xxxxxxxxxxxx> 4/23/2010 12:34 PM >>>
P-1788 members:
Do I have a second to this motion?
Baker
On 4/23/2010 09:16, Dan Zuras Intervals wrote:
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.
--
---------------------------------------------------------------
R. Baker Kearfott, rbk@xxxxxxxxxxxxx (337) 482-5346 (fax)
(337) 482-5270 (work) (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------