lmcinnes / lmcinnes/pynndescent
Question about simple RP-Tree experiment in document
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 970
- Forks
- 107
- PR merge metrics
- No merged PRs in 30d
Description
In the document How PyNNDescent works, I have a question in Random projection trees for initialization.
In the third paragraph of Random projection trees for initialization, it says that only one tree is used to initialize the graph and then proceeded with nn-descent for simple testing.
Let’s got back to our example data we built the graph for in the last section. This time we’ll use just one random projection tree to initialize things, and then proceed with nearest neighbor descent as before.
In my opinion, I don't think nn-descent will work normally in this case.
Because all neighbor's neighbors in node V can only exist within the same leaf block - the k-nearest neighbors of V are already decided, and there is nothing to update with nn-descent.
In other words, if I use only one random projection tree, the node will get stuck in it's leaf block when nn expansioning.
However, the result shows that nn-descent worked well even though only one random projection tree was used.
I wonder if I misunderstood the concept of random projection tree, or if you used more than two trees to test it in the document.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Random projection trees for initialization section in the How PyNNDescent works document and compare its example with the surrounding nearest neighbor descent explanation. Verify the behavior described for a single random projection tree, then clarify the documentation so the initialization and subsequent neighbor expansion are unambiguous.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- machine-learning
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100