<br><br><div class="gmail_quote">On Wed, Nov 21, 2012 at 7:45 PM,  <span dir="ltr"><<a href="mailto:josef.pktd@gmail.com" target="_blank">josef.pktd@gmail.com</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 Wed, Nov 21, 2012 at 9:22 PM, Olivier Delalleau <<a href="mailto:shish@keba.be">shish@keba.be</a>> wrote:<br>
</div><div class="im">> Current behavior looks sensible to me. I personally would prefer no warning<br>
> but I think it makes sense to have one as it can be helpful to detect issues<br>
> faster.<br>
<br>
</div>I agree that nan should be the correct answer.<br>
(I gave up trying to define a default for 0/0 in scipy.stats ttests.)<br>
<br>
some funnier cases<br>
<br>
>>> np.var([1], ddof=1)<br>
0.0<br></blockquote><div><br>This one is a nan in development.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>>> np.var([1], ddof=5)<br>
-0<br>
>>> np.var([1,2], ddof=5)<br>
-0.16666666666666666<br>
>>> np.std([1,2], ddof=5)<br>
nan<br>
<br></blockquote><div><br>These still do this. Also<br><br>In [10]: var([], ddof=1)<br>Out[10]: -0<br><br>Which suggests that the nan is pretty much an accidental byproduct of division by zero. I think it might make sense to have a definite policy for these corner cases.<br>
<br><snip><br><br>Chuck <br></div><br></div>