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 ...?