Re: Motion 8 and sqrt
Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
wrote on 04/10/2009 06:55:50 PM:
> > Date: Sun, 04 Oct 2009 14:33:25 +0200
> > From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
> > To: Ian McIntosh <ianm@xxxxxxxxxx>
> > CC: STDS-1788@xxxxxxxxxxxxxxxxx
> > Subject: Re: Motion 8 and sqrt
> >
> > Ian McIntosh wrote:
> > >
> > > The way I'd suggest you propagate decorations for a unary
operation like
> > > sqrt is to set the result decorations field to the input
> decorations, then
> > > change the individual decorations as needed. For most
operations the
> > > result cannot be defined unless the input was, so if the
input
> > > deco:defined is -1 the result deco:defined needs to be too.
If the input
> > > deco:defined is 1 then the result deco:defined will be what
you show. If
> > > the input deco:defined is 0 (unknown) then I think the result
> deco:defined
> > > must also be unknown.
> > >
> > > If the input is undefined or might be undefined, then you
can't be sure
> > > that the result is bounded even if its value appears to
be. I think you
> > > can still be sure it's unbounded if one bound is -oo or
+oo.
> >
> > No. The infinity might have come from overflow. So one needs
to inspect
> > the corresponding decoration....
> >
> >
> > Arnold Neumaier
>
> It seems to me that the propagation rules & the defaults
> are related.
>
> Remember that the decorations of any given interval are
> meaningful only for the evaluation of that interval in
> the context of that function. So if a decoration
value
> is to propagate through a function it must be meaningful
> to that function as well as some previous function.
>
> Therefore, if unknown (0) is to propagate through some
> function, I assert that it cannot be the default value
> for interval constructors. For otherwise, how is
one
> ever to get a decoration value to anything OTHER than
> unknown?
>
>
> But, whether it is his intention or not, I think Arnold
> raises an interesting unrelated question. Namely:
Should
> we use a decoration to distinguish between an infinite
> endpoint arrived at through the evaluation of a pole
from
> an infinite endpoint arrived at through overflow?
>
> It is an interesting & tempting thought. Let
me use a
> simple example: For positive x large enough that x^2
> overflows to infinity in the precision being used to
> store interval values, shall we distinguish by means
> of a decoration the following:
>
> [5,x]^2 = {[25,+oo],isBounded} or
> [5,x]^2 = {[25,+oo],possiblyBounded}
>
> and
>
> {[5,+oo],isBounded}^2 = {[25,+oo],isBounded} or
> {[5,+oo],possiblyBounded}^2 = {[25,+oo],possiblyBounded}
or
> {[5,+oo],notBounded}^2 = {[25,+oo],notBounded} ?
>
> It would meet our performance goal of only the decoration
> being affected & not the interval portion. But
library
> writers would have to be careful not to use 'notBounded'
> as a test for infinity as an endpoint.
>
> A more stark example would be one in which there were
no
> infinities on the input & the input decoration had
no
> effect on the output decoration. For example: if
eps is a
> positive number small enough such that 1/eps^2 overflows
in
> the precision of discourse, then shall we do the following:
>
> 1/[eps,1]^2 = {[1,+oo],isBounded} or
> 1/[eps,1]^2 = {[1,+oo],possiblyBounded}
>
> and
>
> 1/[0,1]^2 = {[1,+oo],notBounded} ?
>
> As I said, this is a tempting thing to do.
>
> Still, there is an itch in the back of my head that says
> this will lead to a confusion that we don't want to
> introduce into a standard that will already be difficult
> to teach.
>
> But I am not the expert. Perhaps this solves problems
I
> am unaware of. I don't know.
>
> What say all of you?
>
>
> Dan
When I joined this group, I was a firm
believer that the arithmetic used to implement Intervals should be based
on IEEE 754, at least for any environment supporting it.
I still believe that, with one exception.
I've decided that 754 (and Control Data's 6600/7600 architecture
before that) used a simplification that was tolerable in normal floating
point usage but causes more problems for intervals. The simplification
was to merge two concepts into one. There should have been separate
representations for "overflow" versus "infinite". That
would have avoided several problems.
1. There is a conceptual difference
between "This value is infinite." versus "This value overflowed."
2. There is a difference between
0 x overflow, which should give 0, and 0 x infinity, which should give
NaN.
That matters more
in Intervals, where an upper bound of infinity is considered to be a huge
finite value, so 0 x an_infinity_upper_bound should give 0 but IEEE says
NaN.
If you fix that
in software you pay an execution performance price.
If you fix it in
hardware you pay a design price, a hardware and software implementation
price, and in many cases an execution performance price (dynamically switching
hardware modes).
Having an upper
bound of overflow would let you always use a normal multiply, and always
get the correct semantics at full speed.
3. The definition of the lower
and upper bounds is flawed in a way that matters little on paper but does
in programming.
If the upper bound
is finite, the comparison operation is <=, while if it is infinity it
is <.
People have no
trouble coping with that, but a compiler needs to know which comparison
it's supposed to generate - is it < or <= ?
If you don't know,
then the code gets bigger, slower and messier, and you pay an execution
performance price even if all your values are finite.
Having an upper
bound of overflow would let you always use <=, and always get the correct
semantics at full speed.
4. There is a difference between
"infinity and unbounded" meaning "infinity" versus
"infinity but not unbounded" meaning "some huge finite value"
when you are deciding how to decorate an interval,
or even just deciding
what it means.
When will my time machine be delivered?
- Ian Toronto
IBM Lab 8200 Warden D2-445 905-413-3411