Re: Motion 8 and sqrt

[Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>]

> 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