Threading of allknn

[rasmushenningsson]

allknn is a nice addition to the last release, in particular, it's convenient to exclude the points themselves from the result.

But what is the recommended way of threading allknn? For knn it's trivial to split the query in batches, but that's not possible for allknn.

[KristofferC]

Hm, I guess we can do the same as with the tree constructors and thread by default with an option to disable. What do you think?

[rasmushenningsson]

I can think of a couple of alternatives:

1. Your suggestion (thread allknn by default).
2. Add an optional parameter point_indices to allknn defaulting to 1:n_points that let's the user choose which subset of points in the tree to compute neighbors for. (Thus allowing the user do the batching.) The name allknn might be a bit misleading now. 🙂
3. Make it possible to exclude the point itself in a call to knn (by letting the user provide self_idx per-point (which then needs to be remapped if inner_tree.reordered is true).
4. Similar to 3 but, make it possible to pass an array of predicates for the skip parameter, so that it can be set differently per query point.

I guess alternative 1 might be best for most users?
But I personally like the other options better because they are more flexible.

[rasmushenningsson]

Coming back to this now after Christmas, my preferred solution would be number 2 above.
A better name than allknn might be internalknn, since we are referring to the points that are also stored in the tree.

I can make a pull request if you think you will be fine with this solution.

[rasmushenningsson]

Friendly bump. What do you think is the best path forward?