[Numpy-discussion] Apropos ticked #913

[Charles R Harris]

On Wed, Mar 4, 2009 at 10:45 PM, David Cournapeau <
david at ar.media.kyoto-u.ac.jp> wrote:

> Robert Kern wrote:
> > On Wed, Mar 4, 2009 at 23:32, Charles R Harris
> > <charlesr.harris at gmail.com> wrote:
> >
> >
> >> One thing that still bothers me a bit is the return value of fmax/fmin
> when
> >> comparing two complex nan values. A complex number is a nan whenever the
> >> real or imaginary part is nan, and currently the functions return such a
> >> number but originally they returned a complex number with both parts set
> to
> >> nan. The current implemetation was a compromise that kept the code
> simple
> >> while never explicitly using a nan value, i.e., the nan came from one of
> the
> >> inputs. I avoided the explicit use of a nan value because the NAN macro
> was
> >> possibly unreliable at the time. I'm open to thoughts on what the
> behavior
> >> should be.
> >>
> >
> > Do we have examples from other implementations?
> >
>
> matlab max is similar to our fmax:
>
> max(1, nan) -> 1
> max(nan, nan) -> nan
>
> (matlab doc is not clear: they say they ignore nan, but then what's the
> point of nanmax ? I cannot see a different behavior between both
> functions in matlab)
>
> Then, for complex numbers, matlab does some unexpected things as well.
> First:
>
> a = 1 + nan*i -> print NaN + 1.000i
> b = nan + 1*i -> print NaN + NaNi
>
> And then:
>
> a = 1 + nan*i;
> max(a, a) -> Nan
> isreal(a) -> 0
> isreal(max(a, a)) -> 1
>

Heh, it's somehow comforting to know Matlab finds it a bit confusing too. I
suppose what bothers me is that fmax/fmin return the first argument when
both are nans. For reals, that is simply a nan, no problem, but for complex
numbers is seems a bit arbitrary. Maybe I'm being a bit obsessive here.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20090304/ec11733c/attachment.html>