georust / rstar

R*-tree spatial index for the Rust ecosystem
https://docs.rs/rstar
Apache License 2.0
386 stars 67 forks source link

Support for non-const number of dimensions. #98

Closed lvella closed 1 year ago

lvella commented 2 years ago

Hello. I was investigating the use of rstar for my project, and for what I see in the Point trait, it won't be possible because I only know the number of dimensions at runtime. It would be nice to support a dynamic number of dimensions, set when the RTree is created.

lvella commented 2 years ago

Or even an "infinite" number of dimensions, where all the dimensions beyond the dynamically set dimension of a given Point assumes a default (zero?) value.

rmanoka commented 2 years ago

I am unsure of the theoretical feasibility of such a data-structure, but r-star knn algorithm gets very slow (slower than linear search) for high-dimensional data (ref), Could you explain your use-case further?

Our current impl. requires the dimension to be known apriori, and also to be a const. (because our trait Point requires Copy which also implies const. size). I'm also unsure if any other library supports this.

lvella commented 2 years ago

I have a set of monomials (e.g: { x²y, xz, yz², x³yz⁴}) and I want to quickly find the subset of monomials that divides some other given monomial (e.g: given monomial xyz, from that set, only xz divides it). Using this particular example, the problem is equivalent to having the set of points {(2,1,0), (1,0,1), (0,1,2), (3,1,4)} (each variable is a dimension, the exponents are the coordinates values), and finding what point has all coordinates less than or equal the given point (1,1,1).

The problem here is that the number of variables is unknown beforehand. And yes, it can get very big, so maybe r*-tree is not for me.

Stoeoef commented 1 year ago

I agree with @rmanoka on this one - the rtree is probably going to be too slow for this use case if the number of dimensions is too high.

Also, dropping Copy for point types would really hurt our maintenance for little gain.

Closing as this isn't likely to be implemented.