Re: Tetrits and "stickiness"
Ian McIntosh wrote:
The implications of this will require some additional thought.
Agreed.
if an argument is not totally in the domain of part of the
expression, we need to say the argument is not wholly within the
domain of
the entire expression.
I think that's generally true, but there are some exceptions; for
example,
if you implement
d = c ? a : b;
by evaluating both a and b then using c to "select" one of them, only
the
selected one matters, just as if you evaluated it with a test and
conditional branch choosing whether to evaluate a or b..
Agreed!
Not to beat a dead horse (and slightly off-topic), but global flags could
mess this up if c somehow depends on exceptional information.
Another one to think about is
x = y * z;
where y is the singleton [0,0] and z has had a domain (or other)
error.
Should that be propagated to x? Should it depend on the kind of
error or
the value of z?
I think so. IMO, x should get the worst decoration of y, z and y * z.
Do we need both the sticky part and the non-sticky part?
I don't think so, if we handle it carefully. When somebody cares
where in
an expression a problem occurred, they should ask for it to be checked
after each step, and one part is enough. When they don't care about
the
details, only the sticky part matters. Generally the main question
is: Is
the result of the calculation is valid, or did some error occur?
Other opinions? Other experience?
I agree with you, Ian.
IMO, I think its best not to try and separate decoration information into
"most recent operation" vs. "rest of history". A few reasons why I'd suggest
this are:
-- divide-and-conqer algorithms require knowledge of the entire history
(not just the most recent operation) in order to function properly.
-- then we're talking about 4-bits for each attribute of a decoration:
2-bits for the "most recent" portion and 2-bits for the "rest of the
history" portion.
-- Motion 8 reminds us to consider that the new IEEE 754 "short"
datatype only has 10-bits of NaN payload. So this would be a worst-case
number of bits we potentially have to work with for a decoration mechanism.
-- a user might check only the "most recent operation" portion of a
decoration and erroneously conclude there is no exception when in fact the
history leading up to that operation in the "sticky" portion of the
deocoration might be exceptional.
-- we still need correct "sticky" propogation rules for the "rest of
history" portion of the decoration.
Nate