1.0 road map

[KristofferC]

This was my very first package and looking at this with a set of more experienced eyes there are quite a few changes I want to make to APIs etc. Some of those will be somewhat breaking but I think it is worth it.

• [ ] https://github.com/KristofferC/NearestNeighbors.jl/pull/167
• [ ] Rethink the skip function. Right now it only takes a single index but it isn't really documented and it is unclear if this is the best API.
• [ ] Remove DataFreeTree: I don't see any use of this in JuliaHub and I am not really satisfied with its implementation.
• [ ] Ensure all public API is documented, https://github.com/KristofferC/NearestNeighbors.jl/issues/147
• [x] Test benchmarks and have them run on CI
• [ ] Some public API for investigating the tree like bounding_box, isleaf etc?
• [ ] Consider multithreading
• [ ] Go through and triage open issues and PRs
• [ ] Remove the sorting kwargs, users can just sort themselves.
• [ ] Add knn! to be able to pass in a vector to be updated.
• [ ] Consider if "vectorized" functions of knn and inrange are needed or if user can just write the loop themselves if they want. Would remove the need for https://github.com/KristofferC/NearestNeighbors.jl/pull/167.
• [ ] Periodic versions of the trees?
• [ ] Better docs?

More to come

[KristofferC]

CC some people that I know use this package: @juliohm, @fredrikekre

[aplavin]

Wonder if there are any plans for adding multidimensional inrange search? Implementation is very short: https://github.com/JuliaAPlavin/FlexiJoins.jl/blob/00000000ca2fe5eace0b881caa8d2258ca6154ee/src/nearestneighbors.jl#L32-L52 https://github.com/KristofferC/NearestNeighbors.jl/pull/150

[aplavin]

Also, what about supporting arbitrary types, at least for BallTree? Stuff like strings or even custom objects can be useful with distance searches. https://github.com/JuliaAPlavin/FlexiJoins.jl/issues/8

[KristofferC]

Wonder if there are any plans for adding multidimensional inrange search?

Sounds like a good idea!

[KristofferC]

Also, what about supporting arbitrary types, at least for BallTree?

I don't think that should be too hard, we would "just" have to relax some assumptions of what types are used for the data etc.