Skip to content
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

Add Model objects to forecasting #1558

Merged
merged 20 commits into from
Mar 24, 2022

Conversation

canerturkmen
Copy link
Contributor

Issue #, if available:

Earlier PR: #1538

Description of changes:

This PR adds model classes to autogluon.forecasting, porting over previous work and significantly refactoring:

  • adding an AbstractForecastingModel, partially inheriting from core's AbstractModel to modularize the code and remove code dupes. Most of the remaining code dupe is in the model_trial module, however these had to be re-implemented because of the "supervised model" signature (X, y) among other reasons.
  • Moving GluonTS specific functionality to AbstractGluonTSModel.
  • Fixing model serialization, HPO functionality, etc.
  • Adding tests for models
  • Improving style, adding docstrings, etc.

Coverage report:

Name                                                                      Stmts   Miss  Cover
---------------------------------------------------------------------------------------------
src/autogluon/forecasting/__init__.py                                         7      2    71%
src/autogluon/forecasting/models/__init__.py                                  2      0   100%
src/autogluon/forecasting/models/abstract/__init__.py                         2      0   100%
src/autogluon/forecasting/models/abstract/abstract_forecasting_model.py      95      8    92%
src/autogluon/forecasting/models/abstract/model_trial.py                     46     11    76%
src/autogluon/forecasting/models/gluonts/__init__.py                          2      0   100%
src/autogluon/forecasting/models/gluonts/abstract_gluonts.py                117      5    96%
src/autogluon/forecasting/models/gluonts/callback.py                         23      3    87%
src/autogluon/forecasting/models/gluonts/models.py                           26      2    92%
src/autogluon/forecasting/utils/__init__.py                                   0      0   100%
src/autogluon/forecasting/utils/metric_utils.py                              12      0   100%
src/autogluon/forecasting/utils/warning_filters.py                           19      0   100%
src/autogluon/forecasting/version.py                                          1      0   100%
---------------------------------------------------------------------------------------------
TOTAL                                                                       352     31    91%

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@canerturkmen
Copy link
Contributor Author

canerturkmen commented Feb 23, 2022

Copy link
Contributor

@Innixma Innixma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for creating the PR! I will plan to do a full review hopefully next week after v0.4.0 releases.

@szha
Copy link

szha commented Mar 2, 2022

Job PR-1558-3 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-1558/3/index.html

Copy link

@dcmaddix dcmaddix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Caner! It looks good - we can always merge this in first and then add support for mean after. Great job on the thorough tests too.

Copy link
Contributor

@Innixma Innixma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks very good overall!

@canerturkmen
Copy link
Contributor Author

Hello @Innixma @dcmaddix !

In the second revision of the PR, we've

  • taken care of the earlier comments (adding todos in some places)
  • partially taken care of the redundant gluonts model code by having a GenericGluonTSModel
  • enabled ProphetModel through GluonTS --- a big feature imho for small effort
  • added placeholders for how we will handle metadata in the library. Here, a metadata is a dictionary that maps feature types to columns in the data frame. Right now, metadata is supplied to models at construction time and model objects "own" their metadata. That said, there is still a fast follow item to this PR on how we consistently handle static features (in the data frame format without being redundant).

@canerturkmen
Copy link
Contributor Author

cc @huibinshen

@canerturkmen
Copy link
Contributor Author

@Innixma I can't tell why CI wasn't triggered.

@Innixma
Copy link
Contributor

Innixma commented Mar 23, 2022

@canerturkmen Looked like a transient CI error, I retriggered CI, hopefully it passes.

@szha
Copy link

szha commented Mar 23, 2022

Job PR-1558-7 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-1558/7/index.html

Copy link
Contributor

@Innixma Innixma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Awesome contribution. A few minor things can be refined in future PRs once we align on how this integrates with Trainer, Learner, and Predictor.

The class object of the GluonTS estimator to be used.
"""

def __init__(self, gluonts_estimator_class: Type[GluonTSEstimator], **kwargs):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should gluonts_estimator_class instead be a hyperparameter? How would the user specify a particular GluonTS model to train alongside others via Predictor?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see the need for this and will consider it in a future PR. Thanks!

)


# TODO: AutoGluon Tabular will be removed from GluonTS to avoid circular dependencies
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another option is that GluonTS can continue to depend on AutoGluon as an optional and lazily imported dependency that we explicitly don't use / import in AutoGluon Forecasting.

Meaning we would have AutoTabularModel implemented separately in both AG and GluonTS.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another (temporary) hack may be if GluonTS just depends on autogluon.tabular sub-package instead of the full autogluon.
Long term though, the AutoTabularModel should probably be moved back into just AG as it's not a core part of GluonTS.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GluonTS does not have autogluon as a core dependency, but only as an optional requirement for users who want to use AG Tabular; so I think we are safe in the near future.

@Innixma Innixma merged commit 339e8f2 into autogluon:master Mar 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants