[ENH] Add new FunctionParamFitter parameter estimator
#5630
Conversation
To make it more consistent with the new `FunctionParamFitter` class
fkiraly
left a comment
There was a problem hiding this comment.
The code is great and I would approve it once docs are complete. Example in the docstring is also very nice and clear. Let's also separate out the base class refactor, this is a very good spot but separate topic and likely to lead to longer discussion
Docs:
- should be added to API reference,
docs/source/api_reference - docstring is incomplete, params are missing
Suggestions for improvement, non-blocking:
- in the example, you could also use
get_fitted_paramsto look at theselected_forecaster, and carry out the combination with theMultiplexForecasterto have a form of custom tuning! - let's not have too many estimators in one file, especially the
composemodules have gotten bloated in the past. I would suggest, turn it into a folder with private files and export at thecomposemodule level, similar toforecasting.compose.
…py` and `_pipeline.py` modules
|
@fkiraly Thanks for all the feedback! I belive all points have been addressed. I will open this PR for a full review now :) |
|
For reference, see the rendered docs here: https://sktime--5630.org.readthedocs.build/en/5630/api_reference/auto_generated/sktime.param_est.compose.FunctionParamFitter.html |
fkiraly
left a comment
There was a problem hiding this comment.
Yes, changes have been addressed. Thanks!
|
One non-blocking comment, I am slightly wondering about the case of multiple fitted parameters, but none of the ways in which one could generalize makes me happy, so I would suggest to leave the signature as is. |
hmm what about something like this: class MultiParamFitter(BaseParamFitter):
def __init__(self, fitters: dict[str, Callable]):
self.fitters = fitters
def _fit(self, X):
for param, fitter in self.fitters.items():
param = param.rstrip("_") + "_"
setattr(self, param, self.func(X))
return selfIf passing kwargs to the functions is a requirement, I think the cleanest solution is to require users to use something like functools.partial. For instance: MultiParamFitter({"my_param": partial(my_fitter, a="foo", b="bar")}) |
|
yes, thought of that - do not like it since the user has to pass an iterable, which is confusing in the single fitter case. Other option is returning The optimal solution would have intuitive syntax in the simple cases, and consistent syntax in the more complicated ones. |
…ter` inheritance of that method (#5633) Relates to discussions had on #5630 #### What does this implement/fix? Explain your changes. See #5630 (comment)
Reference Issues/PRs
Fixes #4818
What does this implement/fix? Explain your changes.
Does your contribution introduce a new dependency? If yes, which one?
No.
What should a reviewer concentrate their feedback on?
Note that this implementation was heavily inspired by the existing FunctionTransformer implementation.
Did you add any tests for the change?
Doctests only
PR checklist
For all contributions
How to: add yourself to the all-contributors file in the
sktimeroot directory (not theCONTRIBUTORS.md). Common badges:code- fixing a bug, or adding code logic.doc- writing or improving documentation or docstrings.bug- reporting or diagnosing a bug (get this pluscodeif you also fixed the bug in the PR).maintenance- CI, test framework, release.See here for full badge reference
See here for further details on the algorithm maintainer role.
For new estimators
docs/source/api_reference/taskname.rst, follow the pattern.Examplessection.python_dependenciestag and ensureddependency isolation, see the estimator dependencies guide.