<html><head>



</head>
<body style="padding-bottom:40px">
    <div><p dir="auto" style="margin-top:0;margin-bottom:0;">Would it make sense to just make the output type large enough to hold the cumulative sum of the weights?</p><p dir="auto" style="margin-top:0;margin-bottom:0;"><br></p><p dir="auto" class="com.lge.email.signature" style="margin-top:0;margin-bottom:0;">    - Joseph Fox-Rabinovitz</p></div>


<div><p dir="auto" style="margin-top:0;margin-bottom:0;">------ Original message------</p><p dir="auto" style="margin-top:0;margin-bottom:0;"><b>From: </b>Jaime Fernández del Río<jaime.frio@gmail.com></jaime.frio@gmail.com></p><p dir="auto" style="margin-top:0;margin-bottom:0;"><b>Date: </b>Sat, Mar 26, 2016 16:16</p><p dir="auto" style="margin-top:0;margin-bottom:0;"><b>To: </b>Discussion of Numerical Python;</p><p dir="auto" style="margin-top:0;margin-bottom:0;"><b>Subject:</b>[Numpy-discussion] Make <a href="http://np.bi">np.bi</a>ncount output same dtype as weights</p><div dir="ltr">Hi all,<div><br></div><div>I have just submitted a PR (<a href="https://github.com/numpy/numpy/pull/7464">#7464</a>) that fixes an enhancement request (<a href="https://github.com/numpy/numpy/issues/6854">#6854</a>), making <font face="monospace, monospace"><a href="http://np.bi">np.bi</a>ncount</font> return an array of the same type as the <font face="monospace, monospace">weights</font> parameter.  This is an important deviation from current behavior, which always casts <font face="monospace, monospace">weights</font> to <font face="monospace, monospace">double</font>, and always returns a <font face="monospace, monospace">double</font> array, so I would like to hear what others think about the worthiness of this.  Main discussion points:</div><div><ul><li><font face="monospace, monospace"><a href="http://np.bi">np.bi</a>ncount</font> now works with complex weights (yay!), I guess this should be a pretty uncontroversial enhancement.</li><li>The return is of the same type as <font face="monospace, monospace">weights</font>, which means that small integers are very likely to overflow.  This is exactly what #6854 requested, but perhaps we should promote the output for integers to a <font face="monospace, monospace">long</font>, as we do in <font face="monospace, monospace"><a href="http://np.su">np.su</a>m</font>?</li><li>Boolean arrays stay boolean, and OR, rather than sum, the weights. Is this what one would want? If we decide that integer promotion is the way to go, perhaps booleans should go in the same pack?</li><li>This new implementation currently supports all of the reasonable native types, but has no fallback for user defined types.  I guess we should attempt to cast the array to double as before if no native loop can be found? It would be good to have a way of testing this though, any thoughts on how to go about this?</li><li>Does a behavior change like this require some deprecation period? What would that look like?</li><li>I have also added broadcasting of weights to the full size of list, so that one can do e.g. <font face="monospace, monospace"><a href="http://np.bi">np.bi</a>ncount([1, 2, 3], weights=2j)</font> without having to tile the single weight to the size of the bins list.<br></li></ul><div>Any other thoughts are very welcome as well!</div><div><br></div><div>Jaime</div><div><br></div>-- <br><div class="gmail_signature">(__/)<br>( O.o)<br>( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.</div></div></div></div></body></html>