<div dir="ltr"><div>Hi Jesse,</div><div><br></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 22, 2018 at 10:56 AM, Jesse Livezey <span dir="ltr"><<a href="mailto:jesse.livezey@gmail.com" target="_blank">jesse.livezey@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 dir="ltr"><div>Hi everyone,</div><div><br></div><div>I'm using cKDTrees for a project and noticed two potential ways to improve the code and have written one additional count method that might be useful to others.</div><div><br></div><div>I have written code and some tests for all three items and can contribute if there is interest.</div><div><br></div><div>1) Allowing an array of rs in cKDTree.query_ball_point(). I started a PR <a href="https://github.com/scipy/scipy/pull/8818" target="_blank">here</a>. In principle, this should speed up multiple queries with different rs, but see 2.</div><div><br></div><div>2) I noticed that for the cases when cKDTree.query_ball_point() returns large numbers of points (>100), it is faster to loop over queries in python. This is true both with and without my PR. This is largely because single point queries do not sort the return indices, but multi-point queries DO sort them (see details <a href="https://github.com/scipy/scipy/issues/8838" target="_blank">here</a>). Removing the sorted() leads to considerable speedups, but is not backwards compatible. However, the sorted behavior is not in the method description and is not even internally consistent, so maybe it could just be removed or made optional?<br></div></div></blockquote><div><br></div><div>I agree with Sturla's reply on the issue; adding a keyword that defaults to the current behavior and allows turning off sorting is probably the way to go.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div>3) I have written a cKDTree.count_ball_point() method that behaves like query_ball_point() but just returns the number of points rather than their indices. This is much faster than calling len(query_ball_point()).</div></div></blockquote><div><br></div><div>How much faster is it after adding the keyword for (2)?</div><div><br></div><div>Cheers,<br></div><div>Ralf</div><div><br></div></div></div></div></div>