[ENH] EnbPI based forecaster

[benHeid]

Reference Issues/PRs

Towards #6446, uses the aws-fortuna based approach together with tsbootstrap bootstraps

What does this implement/fix? Explain your changes.

Interfaces the aws-fortuna EnbPI implementation

Does your contribution introduce a new dependency? If yes, which one?

Yes aws-fortuna as well as third party library to use them (Jax==0.28.1)

What should a reviewer concentrate their feedback on?

Did you add any tests for the change?

get_test_params

Any other comments?

PR checklist

For all contributions

• I've added myself to the list of contributors with any new badges I've earned :-)
  How to: add yourself to the all-contributors file in the sktime root directory (not the CONTRIBUTORS.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 plus code if you also fixed the bug in the PR).maintenance - CI, test framework, release.
  See here for full badge reference
• Optionally, for added estimators: I've added myself and possibly to the maintainers tag - do this if you want to become the owner or maintainer of an estimator you added.
  See here for further details on the algorithm maintainer role.
• The PR title starts with either [ENH], [MNT], [DOC], or [BUG]. [BUG] - bugfix, [MNT] - CI, test framework, [ENH] - adding or improving code, [DOC] - writing or improving documentation or docstrings.

For new estimators

• I've added the estimator to the API reference - in docs/source/api_reference/taskname.rst, follow the pattern.
• I've added one or more illustrative usage examples to the docstring, in a pydocstyle compliant Examples section.
• If the estimator relies on a soft dependency, I've set the python_dependencies tag and ensured
  dependency isolation, see the estimator dependencies guide.

[benHeid]

@fkiraly should be ready for review :)

[benHeid]

Before merging check the dependencies..

[benHeid]

For the EnbPI wrapper, we using just a single method of the EnbPI class in the aws-fortuna package. Unfortunately this package has a lot of soft dependencies, including JAX. Furthermore, currently, the package is not easily installable due to dependency conflicts: awslabs/fortuna#194

Thus, I wonder if we could copy paste the method conformal_intervals method from the EnbPI class of the aws-fortuna package and adapt it slightly (adaption would get rid off the checks that aren't required anymore since it is internal and replacement of jax.numpy by numpy directly. If copying and modifiying we need to include the original license and the notice statement. Not sure how we should do this: https://github.com/awslabs/fortuna?tab=Apache-2.0-1-ov-file#readme and https://github.com/awslabs/fortuna/blob/main/NOTICE

@fkiraly any ideas?

[fkiraly]

If it is a very small part only, it could go in a private submodule with a license file. We could also give the user the option to use fortuna if they manage to get it installed, via a hyperparameter, but that´s perhaps overkill.

[fkiraly]

Looks good, some minor things:

• for sktime estimators, the clone method (of the estimator) should be used, or configs will not be cloned.
• the docstring should describe better how the algorithm is applied
• I would move it to an enbpi module. compose is for pipelines or similar, it does have some "ensembles" in it but I think in some cases these are misnomers, in others I would not have put it there.

Non-blocking: some typos

[benHeid]

@fkiraly I addressed your changes and additionally also added a adapted version of the EnbPI implementation from aws-fortuna into the libs folder, together with the corresponding license and the NOTICE file that includes the copyright of aws-fortuna. I would appreciate a check if this is added correctly or if I should change the structure..

[fkiraly]

Regarding the library:

• I would make it private, since it is not intended for public consumption
• call it _aws_fortuna_enbpi or similar as it is not the entire library, just a method from it
• README should be markdown, md
• I would also suggest to add to the main README in libs. I would suggest to add a new section "snippets" or similar and explain that these are private
  • while you are at it, you could also fix the "distibution" type :-)

Also worth considering:

• instead, new folder _libs_private, libs_private, or similar?
• moving it into a folder close to the estimator, as it is the single dependency. Coupling-wise, might be better to use it directly from there?

What are your thoughts on handling private libraries?
Perhaps we should open an issue to discuss more widely with core devs, public and private libraries?

[benHeid]

I addressed your comments and created a new issue #6648

[fkiraly]

left over?

[benHeid]

Yes..

[benHeid]

@fkiraly Please wait before merging, I need to check if I introduced a Bug. I will ping you if everything is fine.

[benHeid]

@fkiraly bug should be fixed now.