Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: DirectedInf



> Date: Sat, 09 Oct 2010 15:33:33 +0200
> From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> CC: stds-1788@xxxxxxxxxxxxxxxxx
> Subject: Re: DirectedInf
> 
> Dan Zuras Intervals wrote:
> >> . . .
> 
> > 	In 7.3 I'm less sure that you can claim that oo-oo
> > 	should be zero.  But if you can, I'm OK with it.  Shouldn't
> > 	oo-oo be -oo for a lower bound & +oo for an upper?  How
> > 	can anything else contain the result?
> 
> The point is that inf is a bound, not a number. This allows
> exceptional behavior without violation containment.

	This is kind of my point as well.

	Infinity is not so much a value that was arrived at
	(say exactly, as in analogy to your 'exact zero') as
	it is the limit of something that has no limit or
	whose limit is beyond our ability to represent
	(inexactly, as with overflow in analogy to your
	inexact zero from underflow).

	In more conventional terms, this the result of the
	limit of f(x) as x approaches something & f(x)
	continues to grow without bound.

	So let's take one of these NaN cases.  The simplest
	one is oo/oo.  The only meaningful way this can be
	interpreted is the JOINT limit of an f() & g() indexed
	by the same index variable.  That is the limit of
	f(x)/g(x) as x approaches something in the case where
	both f(x) & g(x) individually grow without limit.

	But we don't know HOW these functions are growing.

	And we want to contain the ratio f(x)/g(x).

	So isn't the only containing result the one where
	the limit of f(x)/g(x) is -oo for a lower bound
	(thus containing any actual result on the down side)
	& +oo for an upper bound (containing it on the up
	side)?

	Similarly for 0*oo, oo-oo, 0/0, & all the other cases
	that result in NaN in 754?

	If it is your intention to have a intervalLowerBound
	rounding mode & an intervalUpperBound rounding mode,
	this would fall out nicely.

	There may be some things you can do with the signs.

	Say lowerBound(+0*+oo) = +0 & upperBound(+0*+oo) = +oo.
	Or lowerBound(+oo/+oo) = +0 & upperBound(+oo/+oo) = +oo.

	But you will have to be scrupulously careful how you
	take care of the signs to still guarantee containment.

> 
> > 
> > 	Come to think of it, in the last case shouldn't 0*oo be
> > 	-oo for a lower bound & +oo for an upper?
> 
> I'll check in due time; I can't remember my old arguments ave need
> redo everything.
> 
> 
> > 	7.4 & 7.5 0/0 = 0 rather than NaN, the same as the others.
> > 	Once again, -oo for lower & +oo for upper?  But if you know
> > 	its right, OK.  We should never run into NaN/0 but if we
> > 	do I cannot see anything other than NaN being correct.
> 
> We do, for Empty/0, but there the result is ok.

	Ah, yes.  If Empty uses NaNs.  Which is, I guess, where
	we're going at level 3.

>
> . . .
>
> > 	Really, if this is all you have in mind for a new rounding
> > 	mode (or a pair of them) all this is fine.
> 
> It is such things - variations of what it already there now.
> 
> 
> > 	It is the new NaNs I balked at.  Not the new rounding modes.
> 
> I believe that everything will work out well in some way or another,
> and will find out how.
> 
> But I need time to ponder the options and how things best work together.
> 
> 
> Arnold Neumaier

	If this is it, all of this is pretty tame & I was
	out of line to claim otherwise.  I thought you
	had somethinig entirely different in mind.

	I apologise for that.


				Dan