Re: (now VERY long) Re: Tetrits and "stickiness"
Dan, P1788,
To avoid complexity in the discussion, I'm going to make just a few surgical
comments on what I think are the critical issues.
BTW, Dan thank you for such a heroic effort!
Dan Zuras Intervals wrote:
And if I can use <<== as a shorthand for \subset, we must
have both of:
{noPointsAtAll} <<== {inDomain} <<== {bothInAndOut}
{noPointsAtAll} <<== {outDomain} <<== {bothInAndOut}
for subintervals of a given interval. But inDomain & outDomain
have no relationship with one another in this sense.
No.
This is the problem with thinking of tetrits as subsets of the set {T,F},
i.e., it leads to just what you mention above.
Let me shift your attention away from this idea just for a moment, and to
think instead in terms of state transitions. Then, when tracking exceptions
through history of a lengthy computation, branch-and-bound requires:
noPointsAtAll <<== outDomain <<== bothInAndOut <<== inDomain.
In this case, "inDomain" etc. are states, and <<== are the allowable
direction of transitions. This is what we voted on in Motion 8. In the above
example, though, I have "upgraded" the concept from trits to include your
very nice idea of tetrits.
I agree it will be good to simplify and clarify Motion 8. This is why I'm
interested in your tetrits idea. But the core semantics of Motion 8 are
still relevant. Let's not throw the baby out with the bath water.
Let me characterize these states in the T/F notation again
(forgive me Nate)
No need to be forgiven.
I understand you are trying to give birth to new ideas!
So, what do we have? (Remember, outSticky is the only one
that's sticky.)
Wait a minute. I am re-reading this after a break & I just
realize that or'ing outSticky with THIS operation's outDomain
loses us some potentially useful information. Namely whether
or not THIS operation had a domain problem. So I am going to
redefine it as follows & redo all that follows. Its more work
for me that you will never see but that's what I get for
writing this on the fly. :-)
The net effect is that we will go from 6 possible states to
8 & the new states differentiate between current domain errors
& previous ones.
+------ '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)
...
So, I think maybe Baker is right. Perhaps we should keep all
3 bits around.
At the very minimum, if we proceed down this path it will require an extra
bit; since for history, branch-and-bound requires (at least):
outDomain <<== bothInAndOut <<== inDomain,
and this is (at least) a trits-worth of information (a tetrit if you add the
one extra state noPointsAtAll, as in the beginning of this e-mail).
In the mapping you describe above, however, there is only one bit of
historical information (outSticky). There's no way to provide all the
required information in that single bit!
Sincerely,
Nate