-
Notifications
You must be signed in to change notification settings - Fork 548
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] UMAP transform throws illegal memory access error when data_on_host=True #6216
Labels
Comments
btepera
added
? - Needs Triage
Need team to review and classify
bug
Something isn't working
labels
Jan 10, 2025
1 task
csadorf
added
2 - In Progress
Currenty a work in progress
and removed
? - Needs Triage
Need team to review and classify
labels
Jan 23, 2025
csadorf
added a commit
to csadorf/cuml
that referenced
this issue
Jan 24, 2025
csadorf
added a commit
to csadorf/cuml
that referenced
this issue
Jan 24, 2025
4 tasks
csadorf
added a commit
to csadorf/cuml
that referenced
this issue
Jan 24, 2025
csadorf
added a commit
to csadorf/cuml
that referenced
this issue
Jan 24, 2025
csadorf
added a commit
to csadorf/cuml
that referenced
this issue
Jan 24, 2025
csadorf
added
3 - Ready for Review
Ready for review by team
and removed
2 - In Progress
Currenty a work in progress
labels
Jan 24, 2025
rapids-bot bot
pushed a commit
that referenced
this issue
Jan 28, 2025
…#6259) Fixes #6216 by identifying whether the original input data is on host or device and conditionally builds the brute force index (required for a separate `transform()` call) for the correct matrix view. - [x] Identify and fix root cause - [x] Clean up implementation - [x] Implement unit test - [x] Document fix Closes #6216 Authors: - Simon Adorf (https://github.com/csadorf) - Dante Gama Dessavre (https://github.com/dantegd) Approvers: - William Hicks (https://github.com/wphicks) - Victor Lafargue (https://github.com/viclafargue) URL: #6259
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When running UMAP with batched nn descent, fit is supported today but not transform, which falls back to using brute force knn (#6215). If I run fit with
data_on_host
set to True, this causes the transform call to throw an illegal memory access error.Independent of having transform support batched nn descent (which I would imagine is a larger effort), we should handle this fallback appropriately in cases where data_on_host was True during the fit.
The text was updated successfully, but these errors were encountered: