1^NaN and 1^Inf

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

1^NaN and 1^Inf

John W. Eaton-6
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


Reply | Threaded
Open this post in threaded view
|

Re: 1^NaN and 1^Inf

Paul Kienzle-2

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
[hidden email]

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
>