Re: tetrits motion: I claim "valid" is not a decoration field
John Pryce wrote:
Nate, P1788
On 24 Apr 2010, at 20:11, Nate Hayes wrote:
I did frame a discussion of this motion as it applies to the "domain"
attribute in my post yesterday. It is still relevant.
I fear such an analysis demonstrates the proposed propagation
mechanism would be a setback for P1788; it deviates too far from the
semantics we agreed on in Motion 8. For example, Motion 8
specifically identifies the purpose of decorations is to help
disambiguate between X \union {empty} = X and X \union NaI =
NaI,
where "NaI" is really some bare decoration. But the definitions being
proposed in the current motion implicitly "undo" this disambiguation,
leaving us, to some extent, back where we originally started about a
year ago.
Thank you pointing this out. I have been (over-?) loudly advocating
that (1) the interval part of a result should depend only on
the interval part of the inputs, not of the decoration.
This is still true (see below).
While failing to remind myself (and everyone) that
(2) "valid" is a special case.
With Motion 8 semantics, we don't need to think of it this way; so on the
one hand, your loud advocation that the interval part of any result depends
only on the interval parts of the input remains valid (this is a good thing,
in my view), and on the other hand, we still achieve the desired NaI
semantics (this is also a good thing, in my view). See below...
(a) It's a Boolean property: "possiblyValid" isn't used, or in the
tetrit scheme xx can't be partly valid and partly not. (b) If xx is
invalid it has become a "black hole". It is simply impossible to
attribute any features to it, except the fact of being invalid.
Right.
But keep in mind Motion 8 specifically defines:
-- bare intervals
-- decorated intervals
-- bare decorations
What you mention above is essentially the function of what a bare decoration
is supposed to be. In other words, a bare decoration is a bare interval or a
decorated interval that for some reason has lost its interval portion. So
all that is left to survive is the bare decoration. As a bare decoration
propagates through a computation, it is the "black hole" that you speak of.
Well not quite. There has to be a "convert to bare interval"
function, and I think we agreed when applied to invalid xx it returns
Empty.
At one point we did, but this had many flaws and problems; such a conversion
would be like a light beam escaping from the "balck hole," which is never
supposed to happen...
So during discussion at the time, we amended clause 2.3 of Motion 8 to avoid
conversion (or promotion) of a bare decoration to either a decorated
interval or a bare interval, since there is no reliable way to do this that
makes any sense.
So here's a case where the result of an operation is determined
*entirely* by the decoration part of the (invalid) input
Sort of. This happens only when a bare decoration appears as input to any
operation. The bare decoration is a "black hole" and gobbles up everything
in its path: bare intervals and decorated intervals alike. The result is
always a bare decoration.
-- the reverse of (1).
Notice that by clause 2.3 of Motion 8 any operation involving a bare
decoration is a bare decoration, so it does not violate (1).
Nate: you invented this scheme (see above) because
(3) "valid" gives a *more efficient* way to implement NaI,
right? But it seems to me the correct conceptual way to view "valid"
is that
(4) "valid" is not a field in the decoration,
but a value of the interval-part.
Or you can just think of it as a bare decoration.
This allows us to not make any exceptions to (1).
*Conceptually*, mind you. As *implemented* it is indeed a field in
the decoration, to achieve (3).
If we adopt (4), this in effect revives NaI as (a possible value of)
a Level 2 datum -- in an efficient form at Level 3. It relieves us
from needing to reconcile the behaviour of "valid" with that of other
decoration properties.
I've always thought it should be possible for a vendor or implementor to
encode bare decorations as [NaN,NaN], [x,NaN], [NaN,x], or something like
that. In so many words, this bare decoration then functions as "not valid,"
i.e., "NaI," as you describe but without violating the principle of (1).
This is ideal for any interval computation that needs only the bare interval
OR the bare decoration but never both at the same time (as is the case in
branch-and-bound); since it does not require the overhead of decorated
intervals.
Actually, the effect is that NaI then exists for decorated intervals,
but not for bare ones. That seems very sensible.
I agree: operations on bare intervals have no NaI semantics if the
appropriate forgetful operators are used. Only when decorated intervals
and/or bare decorations enter the picture (or when some invalid operation on
bare intervals using the appropriate forgetful operators) do NaI semantics
"kick in," so to speak.
Nate
I believe a priority mapping, as outlined in my position paper, is
required to overcome this difficulty and integrate the very nice
idea of tetrits into a reliable exception handling mechanism
consistent with Motion 8 semantics. Although I have made a position
paper available, there has not been any discussion about it in the
short time before the current motion.
I'm a little skeptical that we really need to partition decorations
into "most recent operation" vs. "history,"
I also, but I need to study the discussion more deeply.
Regards
John