Re: Tetrits and "stickiness"
> Subject: Re: Tetrits and "stickiness"
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Date: Mon, 26 Apr 2010 14:32:57 +0100
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Dan Z, Ian McI, P1788
>
> Sorry to be so behind on this.
>
> On 15 Apr 2010, at 16:53, Dan Zuras Intervals wrote:
> >> 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.
>
> I agree on both counts. The point I want to make is:
> (1) IMO the relevant functions should be defined at Level 1,
> hence these issues should be decided at Level 1.
>
> The context we are discussing is (I believe)
> (2) the definition of point-functions, from which interval
> functions are produced as interval extensions, so that
> the FTIA can be used.
>
> Take Ian's second point first. An illustration is the function
> f(x) = (x>=0) * sqrt(x)
> where (following the convention of C-style languages) I treat
> >= as a mathematical function on R x R that returns 0 or 1.
> Q: f(-1) evaluates as (0)*(undefined). Mathematically, is this
> 0, or undefined? I strongly go for undefined. What do others think?
Well, also in the C convention, there is a lot of
implicit conversion going on here. In particular,
f(-1) would evaluate to double(0)*sqrt(double(-1))
= (0.0)*(NaN) = NaN under 754.
I believe this should evaluate to [0.0,0.0]*[empty]
= [empty] as an interval problem.
Although, I can see arguments both ways.
>
> Ian's first point requires that we agree (which we haven't
> considered till now, nor does the Vienna proposal, I think)
> a definition of the
> c ? a : b
> function, which I shall call "branch" when using standard function
> notation.
>
> For this purpose, in its simplest form, branch() has the signature
> branch : B x R x R, where B is the booleans {0,1},
> R is the reals,
> and x is cartesian product. (More generally, replace R by an
> arbitrary type.) It is a total function on B x R x R, with
> the definition
> branch(c,a,b) = a if c==1, b if c==0.
>
> Applied to Dan's example
> r = (abs(x) >= 1) ? sqrt(x^2 - 1) : sqrt(x^2 + 1)
> this does what he advocates, e.g., if x is 0 this gives r=1, even
> though sqrt(x^2 - 1) is undefined.
>
> By extension, the decorations of the selected branch should be used.
> I agree with Ian and Dan here.
>
> John
As selection functions are being used more & more
these days to avoid branches in deep pipes, the
more our selection function behaves like it were
part of a branch, the better, IMHO.
I guess that's another argument for only the
selected decorations passing through.
Dan