-
Notifications
You must be signed in to change notification settings - Fork 16
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
Instacrash when fittransform
-ing in fluid.umap~
#277
Comments
I've managed to reproduce the bug, and got the stacktrace to a segfault in |
I don't know if something was changed with this in the update(s) since this, but this is much more prone to crashing now. Between this issue and #278 it seemed like having not only the same number of dimensions as At the moment I'm coding something based around small-ish datasets (~10-20 entries) and it's basically a dice roll every time I do it whether Max crashes or not based on this bug.
Max version 8.6.2 |
Ok, narrowed it down. Max will crash if you have a For some reason if your
|
actually this is a duplicate of #278 and there is now a fix. |
fix proposed at #279 |
I remember this being an issue a while back but it being fixed (hence the
fluid.umap~: Number of Neighbours is larger than dataset
error message now when trying tofittransform
something that has fewer dimensions than@numneighbours
) but there appears to have been an oversight when coding it as it gives a nice instacrash whenfittransform
-ing a dataset with the same amount of dimensions as@numneighbours
.patch.zip
I imagine this means that a
>
needs to get changed to a>=
when running the size check.Also including three crash reports, two of which point to a gnarly UMAP error but the third one is different (no flucoma mention at all), so including it in case it's indicative of something else happening at the same time.
crash reports.zip
The text was updated successfully, but these errors were encountered: