<br><br><div class="gmail_quote">On Mon, Jul 15, 2013 at 8:34 AM, Sebastian Berg <span dir="ltr"><<a href="mailto:sebastian@sipsolutions.net" target="_blank">sebastian@sipsolutions.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, 2013-07-15 at 07:52 -0600, Charles R Harris wrote:<br>
><br>
><br>
> On Sun, Jul 14, 2013 at 3:35 PM, Charles R Harris<br>
> <<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br>
><br>
<br>
</div><snip><br>
<div class="im"><br>
><br>
>                 For nansum, I would expect 0 even in the case of all<br>
>                 nans.  The point<br>
>                 of these functions is to simply ignore nans, correct?<br>
>                  So I would aim<br>
>                 for this behaviour:  nanfunc(x) behaves the same as<br>
>                 func(x[~isnan(x)])<br>
><br>
><br>
>         Agreed, although that changes current behavior. What about the<br>
>         other cases?<br>
><br>
><br>
><br>
> Looks like there isn't much interest in the topic, so I'll just go<br>
> ahead with the following choices:<br>
><br>
> Non-NaN case<br>
><br>
> 1) Empty array -> ValueError<br>
><br>
> The current behavior with stats is an accident, i.e., the nan arises<br>
> from 0/0. I like to think that in this case the result is any number,<br>
> rather than not a number, so *the* value is simply not defined. So in<br>
> this case raise a ValueError for empty array.<br>
><br>
</div>To be honest, I don't mind the current behaviour much sum([]) = 0,<br>
len([]) = 0, so it is in a way well defined. At least I am not sure if I<br>
would prefer always an error. I am a bit worried that just changing it<br>
might break code out there, such as plotting code where it makes<br>
perfectly sense to plot a NaN (i.e. nothing), but if that is the case it<br>
would probably be visible fast.<br></blockquote><div><br>I'm talking about mean, var, and std as statistics, sum isn't part of that. If there is agreement that nansum of empty arrays/columns should be zero I will do that. Note the sums of empty arrays may or may not be empty.<br>
<br>In [1]: ones((0, 3)).sum(axis=0)<br>Out[1]: array([ 0.,  0.,  0.])<br><br>In [2]: ones((3, 0)).sum(axis=0)<br>Out[2]: array([], dtype=float64)<br><br>Which, sort of, makes sense.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
> 2) ddof >= n -> ValueError<br>
><br>
> If the number of elements, n, is not zero and ddof >= n, raise a<br>
> ValueError for the ddof value.<br>
><br>
</div>Makes sense to me, especially for ddof > n. Just returning nan in all<br>
cases for backward compatibility would be fine with me too.<br>
<div class="im"><br>
> Nan case<br>
><br>
> 1) Empty array -> Value Error<br>
> 2) Empty slice -> NaN<br>
> 3) For slice ddof >= n -> Nan<br>
><br>
</div>Personally I would somewhat prefer if 1) and 2) would at least default<br>
to the same thing. But I don't use the nanfuncs anyway. I was wondering<br>
about adding the option for the user to pick what the fill is (and i.e.<br>
if it is None (maybe default) -> ValueError). We could also allow this<br>
for normal reductions without an identity, but I am not sure if it is<br>
useful there.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br>Chuck <br></div><br></div>