On Thu, Oct 3, 2013 at 7:59 PM, Charles R Harris <[email protected]> wrote: > > <snip> > >> >> Please, no. It's another thing to remember and another way to shoot >> yourself in the foot and introduce casual bugs. >> >> FWIW, my vote is to raise an error or return a nan, which will likely >> eventually raise an error. If I have all nans, it's usually the case >> that something's off, and I'd like to know sooner rather than later. >> > > Here is what I have currently implemented. First, define an AllNanError > > class AllNanError(ValueError): > def __init__(self, msg, result): > ValueError.__init__(self, msg) > self.result = result > > For nanmax/nanmin/nanargmax/nanargmin this error is raised for all-nan axis > and the result is attached. The exception can then be caught and the result > examined. A ValueError is what amax, amin return for empty arrays. > > For nanmax/nanmin the result for an empty slice is nan. For > argnanmax/argnanmin the result of an empty slice is -1, which is easier to > read and remember than intp.min. A ValueError is what argmin, argmax > currently return for empty arrays. Note that both of these functions can > give wrong results if they contain some min/max values respectively. That is > an old bug and I haven't fixed it. > > The nanmean/nanvar/nanstd functions currently raise a warning for all-nan > slices and the result for such is nan. These could also be made to raise an > error. > > Thoughts?
Is this intended for 1.8 or master? -n _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
