-
Notifications
You must be signed in to change notification settings - Fork 14
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
review expectations of incremental training in various objects - was UMAP incremental training doesn't work #189
Comments
The object wasn't designed to support incremental training from what I can see. Where did the expectation that it does come from? |
Like all other iterative process we have. it is even in the learn material. I'll leave that open as this is the only one that doesn't do it in our toolset as far as I know, or at least we have some that do and some that don't which is far from a good idea - this comes from a user that was unprompted and following our interface design expected that to be the case... |
Apologies, closed by mistake. Apart from the MLP, which iterative processes did you have in mind? KMeans doesn't support this: incremental fitting has to be done by hand. NMF only kind of does, to the extent that its complete state can be represented in a couple of buffers. As far as I can see, MLP is the odd one out here. Looking at the code, I'm not even sure what incremental fitting would entail for UMAP. There are a series of convergent processes, and the iteration count only pertains to the last of these (optimising the layout), once the embedding has already been learnt (for which we use library code). So fit can't be incremental. If you call transform, it is using the learned embedding (but not changing it?) on a whole new input dataset, assumed to be high dimensional, applying the embedding and then optimising the layout. Making the layout optimisation incremental would entail some other method that took a low dimensional input and updated that with So, my view is that this not a bug, but a feature request that I'm not sure is actually possible (or at least simple) with the code we have. |
thanks for the explanation. We should definitely make it clearer in the doc if this feature request is not possible. But (s)kmeans support(s) it. There is even a tab showing how it works :) so with MLP there is something of an (wrong) assuption that it should happen in everything iterative, which is obviously wrong, so when I'm rested post holidays I'll review iterative assumptions and expectations. I'm changing the ticket name now and will assigned to me (and maybe @gerard so we can discuss that) thanks again for your patience |
this patch illustrates how 100x 1 iteration (actually 1000x neither, I tested) is not getting anything beyond the first result, compare to the first result of 100 iteration in one go.
I reckon there is a state that gets lost or not passed between iterations?
The text was updated successfully, but these errors were encountered: