[NumPy-Tickets] [NumPy] #1035: Fix up Nan handling for max/amax/argmax/fmac + min/sort equivalent
NumPy Trac
numpy-tickets@scipy....
Sun Jul 18 16:13:30 CDT 2010
#1035: Fix up Nan handling for max/amax/argmax/fmac + min/sort equivalent
------------------------+---------------------------------------------------
Reporter: cdavid | Owner: cdavid
Type: defect | Status: accepted
Priority: high | Milestone: 1.5.0
Component: numpy.core | Version:
Keywords: |
------------------------+---------------------------------------------------
Changes (by pv):
* component: Official binaries => numpy.core
* milestone: 1.4.1 => 1.5.0
Comment:
Let's try to nevertheless address the comparison-related issues for 1.5.0.
The argmin and argmax behavior should be harmonized by r8509, they now
propagate nans. The previous behavior was actually undefined (cf. #1429),
not non-propagating, so I think we can just change it as any code relying
on the previous behavior is invalid.
***
The last question is what should be done with complex nans. I think they
should be defined as
- (z, nan), (nan, z), (nan, nan), where `z` is any fp value, are all
equivalent representations of "cnan", as far as comparisons, sort order,
etc are concerned.
- The ordering between (z, nan), (nan, z), (nan, nan) is undefined. This
means e.g. that maximum([cnan_1, cnan_2]) can return either cnan_1 or
cnan_2 if both are some cnans.
I didn't check if `sort` handles cnans this way, but the other parts
should be in place.
I changed the comparison operations to treat cnans according to the above
way in r8508, since I don't think it makes sense for us to have
{{{
>>> np.complex64(complex(1,np.nan)) < np.complex64(complex(2,0))
True
}}}
This change also fixes a bug where maximum/minimum were not propagating
complex nans properly.
--
Ticket URL: <http://projects.scipy.org/numpy/ticket/1035#comment:6>
NumPy <http://projects.scipy.org/numpy>
My example project
More information about the NumPy-Tickets
mailing list