Re: Motion 8 and sqrt
Dan Zuras Intervals schrieb:
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?
Motion 8 declares the default as a no-0 decoration.
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}
I think that the decoration should specify boundaries for real intervals
(set of real numbers). With floating point intervals we have an
overestimated result [25,+oo) but the exact result is the bounded
interval [25,x^2]. So in my opinion the result should be {[25,+oo),
isBounded} to get best information...
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
--
o Marco Nehmeier, Lehrstuhl fuer Informatik II
/ \ Universitaet Wuerzburg, Am Hubland, D-97074 Wuerzburg
InfoII o Tel.: +49 931 / 31 88684
/ \ Uni E-Mail: nehmeier@xxxxxxxxxxxxxxxxxxxxxxxxxxx
o o Wuerzburg