Re: Fw: Tetrits and "stickiness"
> Subject: Fw: Tetrits and "stickiness"
> To: stds-1788@xxxxxxxxxxxxxxxxx
> From: Ian McIntosh <ianm@xxxxxxxxxx>
> Date: Thu, 15 Apr 2010 10:21:36 -0400
>
>
>
>
> RBK> The implications of this will require some additional thought.
>
> Agreed.
Quod erat demonstrandum. :-)
>
> RBK> 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..
Ian brings up an excellent point here which has nagging
at me for some time. That is: Should selection functions
be an exception to the propagate the decorations of ALL
the operands to the result or just the selected operand?
After all, something like:
r = (abs(x) >= 1) ? sqrt(x^2 - 1) : sqrt(x^2 + 1);
has likely been constructed is such a way as to AVOID
going outside the domain of sqrt(). That is, the
unselected operand plays no part in the result in that
it was never meant to be evaluated in the first place.
For this reason I would support propagating only the
selected operand to the result, decorations & all.
>
> 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?
This one is slightly more subtle.
If z (or zz) ends up being [empty] I would propagate it,
warts & all.
But assuming yy is not a constant it will have its own
decorations that might explain why it got to be [0,0].
I see no need for an exception to the propagate both
operands' decorations in this case.
But I could see an argument that says propagate only
yy's decorations in this case.
Nah, then you'd have to make provision for [0,0]*[0,0].
I think propagating both is still best.
>
> RBK> 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?
>
> - Ian McIntosh IBM Canada Lab Compiler Back End Support
> and Development
OK, this last is a matter of opinion & convenience to
the user.
Ian is, in principle, correct that keeping only the non-
sticky part is sufficient in that the user can back
diagnose the problem by looking at each previous operation
in turn.
However, in practice, this may be intractably difficult.
Perhaps even more so as our machines tackle ever larger &
more complex questions. Some in real time as the rocket
is in flight.
A sticky diagnostic can often immediately point to the
problem or, at the very least, narrow it sufficiently to
find it immediately.
For example, whenever people came to me & said they had NaNs
all over their calculation, I would say, without thinking
about it & often without looking up, look for the divide by
zero. While there are many ways of getting a NaN in 754,
when they spread about indiscriminately the are almost
invariably the result of a divide by zero. (Divide by zeros
create infinities. Infinites get subtracted from each other
& NaNs appear. And NaNs breed like rats.) Those people
would go back, find the divide by zero almost immediately,
& my reputation as a wizard would be enhanced.
(Remember, use this power only for good. :-)
The moral of the story is that I think that if we 'stick'
the proper information around it will greatly ease the
diagnostic problem for our users.
Whether this should be done in Nate's fashion or another
is something we can decide in the fullness of time.
But I think we should HAVE sticky information.
Your opinion may vary,
Dan