octave-maintainers
[Top][All Lists]
Advanced

[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
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]