Re: A decorations question
Nate & P1788
On 3 Mar 2010, at 01:00, Nate Hayes wrote:
>> So it seems to me that in ALMOST ALL situations, we shouldn't flag
>> the result of an operation as "definitely unbounded".
>>
>> Even if xx holds Entire,
>> yy = tan(xx)
>> should in most cases be "possibly bounded".
>>
>> Or am I taking a wrongheaded view of what Bounded "means"? What
>> "meaning" is appropriate here?
>
> I think it is a good question to ask. But IMO these examples put focus on
> the wrong culprit. What you are noticing in the first example is the scurge
> of interval dependence.
Yes. But whatever is the "culprit", the issue of whether to use "definitely bounded" or "possibly bounded" remains.
> Simple interval arithmetic does not recognize the interval dependence caused
> by multiple occurences of the variable ww in the expression sin(ww)+cos(ww),
> so this causes the pessimistic result [0,2] instead of [1,2/sqrt(2)].
>
> Now, the arithmetic operation 1/[0,2], by itself, is unbounded, whereas
> 1/[1,2/sqrt(2)] is not.
>
> If IEEE 1788 only dictates how computers must process individual interval
> operations, then it seems to me the result must be 1/[0,2], which is
> unbounded.
>
> THe bounded result 1/[1,2/sqrt(2)] comes from a more sophisticated interval
> analysis to overcome the interval dependence. This requires some minimal
> amount of symbolic syntax analysis of the entire interval expression. For
> example, I expect a Computer Algebra System to provide this answer, but not
> a simple interval processor.
I agree with that. But should the simple interval processor label 1/[0,2] as definitely unbounded? It sounds as though you think Yes.
> But another aspect of this example is much, much more interesting to me: the
> fact that 1/[0,2] has the attribute "possiblyDefined" because 0 is an
> element of [0,2] and 1/0 is undefined.
Yes, another very interesting point. I just wanted to deal with one at a time! Thanks for raising this.
> Most serious interval software does not rely on simple forward evaluation of
> interval operations, since interval dependence causes pessimistic result
> that are for all practical purposes useless.
>
> At the very least, an interval analysis method like bisection will be used
> to defeat pessimism and find narrow bounds to solutions. In this example,
> 1/(sin(ww)+cos(ww)) over the interval [0,PI/2] is "possiblyDefined".
>
> Branch-and-bound algorithms should accept an "isDefined" result, reject a
> "notDefined" result, and continue to bisect a "possiblyDefined" result. In
> this case, [0,PI/2] can be bisected into [0,PI/4] and [PI/4,PI/2].
>
> Now the expression 1/(sin(ww)+cos(ww)) evaluated over these two smaller
> domains "isDefined."
I believe you have no doubt that "possiblyDefined" is the correct result here; you are just pointing out how a particular application algorithm should handle this information.
> This is an example why I wonder sometimes if the "Bounded" attribute is
> really relevant.
Me too. I see that Ian McIntosh and Dan Zuras have made some good points on these issues already, see Ian's of 6 Oct 2009.
A feature of Bounded, noted there, is that for all the *other* attributes, if xx, yy are decorated intervals the non-decoration part of
xx op yy
is purely a function of the interval parts of xx and yy. But this is not true for Bounded. E.g. if the interval parts of both are [3,+oo] then the truth of
xx containedIn yy
can't be determined without looking at the Bounded attribute. Oh, BTW, doesn't this force us to adopt 3-valued logic for relational operators ...?
JohnP