-
Notifications
You must be signed in to change notification settings - Fork 275
Refactor learning module #1873
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
Refactor learning module #1873
Conversation
fa62fd9 to
3912c93
Compare
…classifier and Knn; fix AAC
|
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
8316006 to
e43cbad
Compare
e43cbad to
771b41b
Compare
Codecov Report
@@ Coverage Diff @@
## master #1873 +/- ##
==========================================
- Coverage 91.44% 88.43% -3.01%
==========================================
Files 141 141
Lines 13450 13570 +120
==========================================
- Hits 12298 11999 -299
- Misses 1152 1571 +419
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 26 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So much cleaner and interpretable, thank you so much!!
Two remarks:
- the optimizers (e.g. BaseGradientDescent) are currently in the files where they're used (e.g. in frechet_mean): since the logic of optimization is now abstracted, would it make sense to have a separate folder, in the spirit of what you did for the numerics folders?
- pymanopt provides optimizers: could we make our abstraction of optimizers compatible with theirs, so that we can use their optimizers on demand?
These two remarks are not necessarily for this PR, we can talk about them in another one, if they make sense.
Thanks again!!
|
@ninamiolane, the optimizers are still particular for the cases we they're defined (that's why I keep them there). The goal is the medium term would be to see if we can get a common abstraction and then move them to e.g. Having a seamlessly integration with |
This PR refactors
learningin order to make an estimator consistently usespace(instead ofspaceand/ormetric).1
Additionally, some estimators or optimizers were "promoted" to their own class. In particular:
in
FrechetMeanoptimizers:
BaseGradientDescent,GradientDescent,BatchGradientDescent, andAdaptiveGradientDescentalgorithms:
FrechetMean,CircleMean,ElasticMean,LinearMeanin
GeodesicRegression:RiemannianGradientDescentin
ExponentialBarycenterGradientDescentNotice these classes are not created from scratch, but from already-existing code.
Regarding the optimizers, the main goal is to make it easier to control hyperparameters (following what has been done in
geomstats.numerics.optimizers), as well as to try to find common abstractions we may be missing out (for now there's nothing very obvious, but is nice to see adaptations of gradient descent appearing "everywhere" -> maybe later we can merge them).Regarding the estimators, it makes it easier to identity what's the algorithm we are actually using. Notice the API is not impacted, as e.g. to use
CircleMean, it suffices to pass a circle toFrechetMean.I've added the method
setto set parameters of e.g. an optimizer used within an estimator. This serves two purposes:__init__method by not allowing such parameters to be defined from thereGeodesicRegressionusingmethod="extrinsic", requires different parameters than usingmethod="intrinsic".setverifies if the parameter we are trying to set actually exists, so it can prevent bugs.I've made
setreturnselfsuch that the following snippet of code is valid (this is very common in OOP, but not seem very often in python -> let me know how natural it feels to you):2
I've added a note with "required metric methods" to the docstrings of most of the estimators, such that we can understand the minimum we need to define in order to run them.
3
In
TangentPCAandToTangentPCAI use the notion of_geometryin order to also be able to use thespaceto compute theexp: if a space is equipped,geometry=space.metric, otherwisegeometry=space, followed bygeometry.metric.A lot of other little things where updated, but mostly for consistency among estimators.
There's still work that needs to be done in this part, especially related with inheritance.
EDIT: tests are successful now!
closes #715