[NumPy-Tickets] [NumPy] #1035: Fix up Nan handling for max/amax/argmax/fmac + min/sort equivalent

[NumPy Trac]

#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