<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 7, 2017 at 11:29 AM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi All,<br><br></div>The current NumPy implementation of the truncated zipf distribution has several drawbacks.<br><br><ul><li>Extremely poor performance when the parameter `a` is near 1. For instance, when `a = 1.000001` a simple change in the implementation speeds things up by a factor of 1,657. When the parameter is closer to 1, the algorithm effectively hangs.</li><li>Because the distribution is truncated, say to integers in the range of int64, the parameter could be allowed to take all values > 0, even though the untruncated series diverges. There is some indication that such values of `a` can be useful in modeling  because of the heavy distribution in the tail.</li></ul><p>Because fixing these problems will change the output stream, I suggest implementing a truncated zeta distribution, which is an alternative name for the same distribution, and deprecating the the zipf distribution. Furthermore, rather than truncate at the value of C long, which varies, truncate at max(int64), or some possibly smaller value, say 2**44, which allows all integers up to that value to be realized with approximately correct probabilities when using double precision for the intermediate computations. <br></p><p>Thoughts?</p><p></p></div></blockquote><div><br></div><div>It is time that the 'random' API is extended to include some means of selecting a version of the random number generation algorithm.  This has come up in discussions on github (e.g. <a href="https://github.com/numpy/numpy/pull/5158#issuecomment-58185802">https://github.com/numpy/numpy/pull/5158#issuecomment-58185802</a>).  Then instead of deprecating the existing 'zipf`' function, the user has the option of selecting which version of the code to use.  Current users that are satisfied with the existing 'zipf' implementation are not affected.  But I'm not against deprecating 'zipf' if the code is bad enough that the best long-term option is removing it.<br></div><div><br></div><div>Something like this will be needed if there is interest in merging a pull request that I just submitted (<a href="https://github.com/numpy/numpy/pull/9834">https://github.com/numpy/numpy/pull/9834</a>) that fixes (and improves the performance of) the generation of hypergeometric variates when the number of samples drawn is small.</div><div><br></div><div>Warren</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><p>Chubk<br></p></div></blockquote><div><br></div><div>I think Chuck just got a new hip-hop name. :)</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br></div>
<br>______________________________<wbr>_________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/numpy-<wbr>discussion</a><br>
<br></blockquote></div><br></div></div>