From octave-maintainers-request at bevo dot che dot wisc dot edu Tue Nov 19 13:53:47 2002
Subject: Re: 1^NaN and 1^Inf
From: Paul Kienzle <pkienzle at jazz dot ncnr dot nist dot gov>
To: octave-maintainers mailing list <octave-maintainers at bevo dot che dot wisc dot edu>
Date: Tue, 19 Nov 2002 14:53:44 -0500


I would argue for 1^NaN returning NaN since NaNs should propogate.

For 1^Inf I could go either way:

	lim_{y->\inf} (1^y) = 1

but 

	lim_{x->1^{+}} (x^\inf)  = \inf
	lim_{x->1^{-}} (x^\inf)  = 0

I would prefer it were consistent across platforms, but that is
not a great concern to me.

Paul Kienzle
pkienzle at users dot sf dot net

On Tue, Nov 19, 2002 at 01:06:41PM -0600, John W. Eaton wrote:
> In the last day or so, there has been a thread on the Matlab newsgroup
> about the values that Matlab returns for 1^NaN and 1^Inf.  In both
> cases, Matlab returns NaN, but Octave returns whatever the C library
> function pow (double x, double y) returns.  The GNU C library returns
> 1 for both cases.  On other systems, we may get other results.
> 
> An argument for the NaN results can be found in the paper "What Every
> Computer Scientist Should Know About Floating-Point Arithmetic" by
> David Goldberg, on page 218 at the end of the section "Ambiguity".
> PDF copies of this paper are available on the web, for example, I
> found one at
> 
>   http://www.nondot.org/sabre/os/files/Processors/WECSSKAFloatingPoint.pdf
> 
> but a quick search will turn up many more copies.
> 
> I submitted a bug report, but the maintainer of glibc, Ulrich Drepper,
> says that the current behavior is what the ISO C standard requires.
> 
> What do people think Octave should do for these expressions?
> 
> Thanks,
> 
> jwe
>