-
Notifications
You must be signed in to change notification settings - Fork 15
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
API: naming and functions #32
Comments
+100
… |
Given the past work, I think it should be doable to have something along the lines of:
My 2 issues with the current design is that we have to instantiate 6 objects to fit (estimator, model, monitor, algo, criterion, optimizer), and that we must use estimator to predict in the end, while it should remain hidden from the user (it's not obvious that it's modified by grad_search) Does it sound doable the way I propose, @QB3 @Klopfe ? this may help for refitting in #86 |
While we are discussing the API, it seems that instantiating |
what do you suggest?
… |
As we saw in #30 and with @ksehic, newcomer's life could be made easier.
I would like to discuss a few API changes:
sparse_ho.models.Lasso
which has as an attribute aceler.Lasso
Since
models.Lasso
sets the alpha, I would name this classLassoGradSearch
, orLassoGS
orLassoAuto
, or something else (in a similar way as insklearn.linear_model.LassoCV
)LassoGradSearch
,estimator
should be made private. It's only called for its solver, and I don't think the user should be aware of it.estimator
when creating LassoGradSearch. It should be created in the init (if possible with sklearn convention, oterwise on the first call tofit
). Conceptually, this makes the instanciation of the class easier.fit
and apredict
(so the user does not need to access itsestimator
), and passsklearn.utils.estimators_check.check_estimator
@agramfort @josephsalmon what do you think ?
The text was updated successfully, but these errors were encountered: