2008/10/2 Robert Kern <[EMAIL PROTECTED]>: >> My only gripe is that they have the same NaN-handling as amin and >> friends, which I consider to be broken. > > No, these follow well-defined C99 semantics of the fmin() and fmax() > functions in libm. If exactly one of the arguments is a NaN, the > non-NaN argument is returned. This is *not* the current behavior of > amin() et al., which just do naive comparisons.
Let me rephrase: I'm not convinced that these C99 semantics provide an optimal user experience. It worries me greatly that NaN's pop up in operations and then disappear again. It is entirely possible for a script to run without failure and spew out garbage without the user ever knowing. >> Others also mentioned that >> this should be changed, and I think David C wrote a patch for it (but >> I am not informed as to the speed implications). >> >> If I had to choose, this would be my preferred output: >> >> In [5]: fmax(a,b) >> Out[5]: array([ NaN, NaN, NaN, 1.]) > > Chuck proposes letting minimum() and maximum() have that behavior. That would be a good start, which would be complemented by educating the user via some appropriate mechanism (I still don't know if one exists; there is no NumPy Paperclip TM that states "You have decided to commit scientific suicide. Would you like me to cut your wrists?"). That's meant only half-tongue-in-cheekedly :) Thanks for your comments, Cheers Stéfan _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
