<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Availability of the NaN functionality in a method of ndarray<br>

<br>
The last point is key. &nbsp;The NaN behavior is central to analyzing real<br>
data containing unavoidable bad values, which is the bread and butter<br>
of a substantial fraction of the user base. &nbsp;In the languages they&#39;re<br>
switching from, handling NaNs is just part of doing business, and is<br>
an option of every relevant routine; there&#39;s no need for redundant<br>
sets of routines. &nbsp;In contrast, numpy appears to consider data<br>
analysis to be secondary, somehow, to pure math, and takes the NaN<br>
functionality out of routines like min() and std(). &nbsp;This means it&#39;s<br>
not possible to use many ndarray methods. &nbsp;If we&#39;re ready to handle a<br>
NaN by returning it, why not enable the more useful behavior of<br>
ignoring it, at user discretion?<br>
</blockquote></div><br>Maybe I missed this somewhere, but this seems like a better use for masked arrays, not NaN&#39;s.&nbsp; Masked arrays were specifically designed to add functions that work well with masked/invalid data points.&nbsp; Why reinvent the wheel here?<br>
<br>Ryan<br><br>-- <br>Ryan May<br>Graduate Research Assistant<br>School of Meteorology<br>University of Oklahoma<br>
</div>