[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 1^NaN and 1^Inf
From: |
Paul Kienzle |
Subject: |
Re: 1^NaN and 1^Inf |
Date: |
Tue, 19 Nov 2002 14:53:44 -0500 |
User-agent: |
Mutt/1.2.5.1i |
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
address@hidden
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
>
- 1^NaN and 1^Inf, John W. Eaton, 2002/11/19
- Re: 1^NaN and 1^Inf,
Paul Kienzle <=