-
Notifications
You must be signed in to change notification settings - Fork 17
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
Model's _fit should accept Dataset also, not just BatchVectorizer #70
Comments
Did you mean |
Exactly! The owls are not what they seem. Corrected! |
First, Given that we go forward and implement this enhancement we will have to change some of the core architecture: making method "legal" to use makes it so that we have to 1) add a cube information to the fit 2) check that the fit is not overlapping with previous actions 3) train model in a separate thread and save/load it afterwards... See where it's going? the nice and simple method grows into something that duplicates existing functionality and puts it into the "models" class that we already wanted to "separate" from the training action. |
I think you are moving the goalposts. We do not provide guarantees on Also, training a model without Cubes + Experiment overhead is exactly why one would consider using the method (e.g. for very dirty prototyping or perhaps for cases not covered by Cubes + Experiment yet). |
Ok, but it doesn't mean that we shouldn't think about how to make the method better 🙂 |
Seems more natural for a model to fit on Dataset.
Maybe better to use
Union[artm.BatchVectorizer, topicnet.cooking_machine.Dataset]
instead of justartm.BatchVectorizer
(Union — for compatibility)?The text was updated successfully, but these errors were encountered: