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

Re: Past uses of NaN?



> Date: Mon, 08 Nov 2010 10:18:28 -0500
> To: stds-1788                    <stds-1788@xxxxxxxxxxxxxxxxx>
> From: Michel Hack                          <hack@xxxxxxxxxxxxxx>
> Subject: Re: Past uses of NaN?
> 
> Replying to Nick MacLaren, Nate Hayes wrote:
> > In your paper I see you did suggest min and max should be required
> > to percolate NaNs and raise exceptions, just like any other numeric
> > (arithmetic) operation.
> 
> At one point IEEE 754R had both min/max and minnum/maxnum, with only
> the former propagating NaNs.  I don't remember what discussion led
> to abandoning the distinction and using minnum/maxnum semantics but
> dropping "num" from the names.
> 
> Michel.
> ---Sent: 2010-11-08 15:23:53 UTC

	Michel is correct.

	The history of it is that there were initially two groups of
	min/max functions: those that returned a NaN when compared
	to other numbers named minnan, maxnan, minabsnan, & maxabsnan;
	& those that returned the number rather than the nan named
	minnum, maxnum, minabsnum, & maxabsnum.

	People that supported the NaN preserving group argued that
	these functions should behave as any other dyadic function
	& return a NaN when a NaN appeared on input.  NaN perserving
	functions was considered one of the sacred principles upon
	which 754 stood.

	People that supported the number preserving group argued that,
	of the two arguments, the number was the only one that COULD
	be compared for size & should be returned on that basis.
	Practically, the path that returned the NaN did something
	bogus & so the other path contained the only valid result.
	Therefore, much like our 1788 arguments involving intervals
	that extend beyond a function's domain, only the valid
	results have any meaning.

	These two camps were irreconcilable.  And the situation
	stood with both groups of functions for some years.

	But over time we came to realize that NaN preserving was not
	so absolute as you might think.  It is universal among the
	basic +, -, *, / functions but exceptions turned up as we
	went through the special cases among the transcendental
	functions in section 9.2.

	All of the following are true: hypot(+/-inf,NaN) = +inf,
	compound(NaN,0) = pown(NaN,0) = pow(NaN,0) = pow(1,NaN) = 1,

	(However, powr(x,NaN) = powr(NaN,y) = NaN due to the fact
	that powr is based on exp(y*ln(x)).)

	Also, in section 9.3, sumSquare & sumAbs return +inf if
	there are both infinite & NaN elements to be summed.

	The rationale for these exceptions is that some functions
	in some portion of their domain are independent of one or
	more of their operands.  Thus, for example, hypot(x,+/-inf)
	is independent of x.  When this is the case, such a function
	may be written so as not to even READ the other operand as
	it is not needed to know the result.

	Then it was realized that functions like min & max are
	really special selection functions.  That is, they are
	special cases of f(x,y) = if (condition) then x else y.
	Or, to use C notation, f(x,y) = (condition)?x:y;.  Selection
	functions routinely pay no attention to NaN preservation
	when the NaN appears on the path NOT selected.  For good &
	obvious reasons: the condition likely tested for some
	property to determine whether or not a given path was safe
	to use in a calculation & the NaN would have come up in the
	'not safe' case.

	Finally, it was pointed out that one of these functions,
	maxabs, is used universally to pick a pivot element in
	matrix operations.  In this case it is much to be
	preferred to pivot on the number rather than the NaN.
	The former minimizes the nasty effects of the NaN while
	the latter fills the matrix with NaNs & obscures the
	location of the original problem.

	And, by this time, everyone was tired of having two classes
	of these functions.

	So eventually it was moved & passed that we eliminate the
	NaN preserving class.  Then later we dropped the 'num' from
	the names as the distinction no longer had any meaning.

	That's the history of how the min/max functions came to
	be number preserving.

	It was a judgement call.  I think it was a good one.  But
	you may differ in that opinion.

	That's up to YOUR judgement.


				Dan