Re: Tetrits and "stickiness"
Dan Zuras Intervals wrote:
From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
To: "P1788" <stds-1788@xxxxxxxxxxxxxxxxx>, "Michel Hack"
<hack@xxxxxxxxxxxxxx> Subject: Re: Tetrits and "stickiness"
Date: Thu, 15 Apr 2010 16:12:07 -0500
Michel Hack wrote:
. . .
If the sticky bits represent the same information as the detailed
bits for a single operation, then yes, it would be sufficient to
implement the sticky bits, and have the program clear the sticky
bits before every operation. I was under the impression however
that the detailed bits proposed by Dan Zuras carried more
information than can be handled as a sticky bit.
Ok. That makes sense.
My understanding is they do represent the same information, i.e.,
that an "octrit" is comprised of two "tetrits," each tetrit
representing the same information except one is sticky and the other
is not. So I was liking the idea of "tetrit" but scratching my head
wondering why we need "octrits".
Nate
. . .
No, actually. What I had in mind was collecting only the
exceptional or notable information in a third bit. Thus,
'octit' for 8 states. (Or is it octigit? It can't be
octrit as it is a contraction of 'octal digit'. It could
be octagit. :-)
Ok... "octagit"
But this presumes that the decoration is named for some
unexceptional property. 'domain' for 'in the domain'.
'continuous' like most function we use in intervals.
Or 'bounded' as in 'still finite'. Then it presumes that
the information we wish to retain as sticky is the other
or exceptional property. 'domainFalse' or 'domainOut'
for 'we strayed from the proper definition of this function'.
'continuousFalse' or even 'discontinuous' for the obvious
if hard to define property. And, 'boundedFalse' or even
'unbounded' for either overflow or an actual singularity.
Strictly speaking, I understood that "octagit" as you mentioned in your
posts only have 3-bits. I've been clumsy in my responses, I think. So let me
try and be more specific:
The problem with "octagit" is that one bit of sticky information for history
is not good enough. In Motion 8 parlance we need at _least_ one trits worth
of information:
-- "isDefined"
-- "notDefined"
-- "possiblyDefined."
What you are proposing, if I understand correctly, is only a binary sticky
bit for the history of domain violations:
-- "isDefined"
-- "notDefined."
This is why in my response to Ian, I said that a minimum of 4-bits is
required to do what you are suggesting: 2-bits for the "most recent
operation" and 2-bits for "history."
However, then we have the same information in each portion of 2-bits, the
only difference being that one portion is sticky and the other is not.
So my overall feeling is this whole part of the discussion is a step
backwards, since we are essentially using more bits to propagate less
information.
As one retains no diagnostic value by 'sticking' the
states we expect, it should be sufficient to retain only
those things are are unusual, exceptional, or otherwise
worthy of note to the diagnostician.
This is why Nate's approach may have merit. If we can
fit everything we need to know about an operation into
4 states then 2 bits suffice.
I really believe this can be done, i.e., we can take your original "tetrits"
mapping, modify the definitions slightly, and fit everything into 4 states.
Notice that your original tetrit maps to subsets of {T, F}, so it produces
the permutations {T}, {F}, {T,F}, and {}.
Now, this is almost exactly the same as a trit in Motion 8:
-- {T} iff "isDefined"
-- {F} iff "notDefined"
-- {T,F} iff "possiblyDefined."
In fact, this was the original motivation/inspiration for the tetrits
mapping.
The main difference is the tetrits mapping introduces a fourth state, {},
which has no counterpart in the trit model. I don't know for sure that this
new state is useful or necessary, but I'm convinced (so far) it doesn't hurt
anything. Plus, I think the use of existentially-qualified predicates to map
intervals to bits is elegant and precise. So these are the reasons I'm
warming up to "tetrits" over trits.
HOWEVER:
The biggest problem with tetrits, unlike trits, is they have no natural
ordering that allows us to propagate exceptional information through a
lengthy computation in a reliable manner.
At least the way they were originally defined. With a small adjustment, its
possible to give tetrits the ordering:
Rank Tetrit Description
3 {1,1} Everywhere defined
2 {1,0} Somewhere defined, somewhere not defined
1 {0,1} Somewhere not defined
0 {0,0} Nowhere defined, nowhere undefined, i.e., {empty}
Notice that I subtitute "T" and "F" for the binary digits "1" and "0",
respectively. Also notice these two binary digits are the binary
representation of the Rank number for each tetrit.
Now that each tetrit has a Rank relative to every other tetrit, we can
propagate tetrits just like trits: the new tetrit is the infimum
(bitwise-AND) of two input tetrits.
Let's agree on whether the tetrits contain the
information we want to see on THIS operation for the
moment.
I think they do. They're really just like a trit, but with one extra state.
After we agree on that, we will have a better handle on
what needs to be kept & what can be discarded.
Just a suggestion...
A good suggestion.
Nate