[ENH] hcrystalball forecaster adapter
#4040
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fkiraly
added
the
module:forecasting
aiwalter
suggested changes
Jan 3, 2023
Same rules for everyone, I would suggest. |
|
If you want to block this or downvote this, please specify, on which grounds. E.g., do you still think it is a code of conduct violation to remove someone else's estimator from |
|
Lazy consensus failed on this PR |
|
@aiwalter, that is not a productive statement - it amounts to you saying "I cause the lazy consensus to fail, and my reason is that the lazy consensus fails". I.e., you say you reject this "just because". I kindly ask you to reconsider your position on this PR and contribute productively to a discussion. |
|
no follow-up, and not a clear change request. Can be merged by standing policy. |
klam-data
pushed a commit
to CodeSmithDSMLProjects/sktime
that referenced
this pull request
Jan 18, 2023
This PR adds back @MichalChromcak's framework adapter to `hcrystalball`. Since its removal, internal discussions have clarified inclusion policy of estimators in `sktime`, see here: https://www.sktime.org/en/stable/get_involved/governance.html#algorithm-inclusion-guidelines The consolidated policy sees `sktime` as a library, to which any estimator can be contributed as long as minimal requirements on documentation are met. I.e., perceived duplication, performance, relevance, personal taste of core developers, are not criteria we have decided we want to use going forward to decide on whether an algorithm should be included. This PR moves the estimator into a new module `forecasting.adapters`, a location where potentially further adapters can be placed, say, to `gluonts`, `darts`, `pytorch-forecast` and so on (should someone implement those). `hcrystalball` is not added as soft dependency in `all_extras`, which is fine, as `sktime` now also has full capability for dependency isolation.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds back @MichalChromcak's framework adapter to
hcrystalball.Since its removal, internal discussions have clarified inclusion policy of estimators in
sktime, see here: https://www.sktime.org/en/stable/get_involved/governance.html#algorithm-inclusion-guidelinesThe consolidated policy sees
sktimeas a library, to which any estimator can be contributed as long as minimal requirements on documentation are met.I.e., perceived duplication, performance, relevance, personal taste of core developers, are not criteria we have decided we want to use going forward to decide on whether an algorithm should be included.
This PR moves the estimator into a new module
forecasting.adapters, a location where potentially further adapters can be placed, say, togluonts,darts,pytorch-forecastand so on (should someone implement those).hcrystalballis not added as soft dependency inall_extras, which is fine, assktimenow also has full capability for dependency isolation.