[FEAT] StatsForecast AutoETS forecasting model

[AzulGarza]

Description

This PR includes a new model for the forecast module. AutoETS selects the best model amongst the exponential smoothing family. Here's a reference for the model. Since StatsForecast is already included in the dependencies, it wasn't necessary to include it.

Here's a working example

And its comparison against the theta method,

• Summary of the change / bug fix.
• Link # issue, if applicable.
• Screenshot of the feature or the bug before/after fix, if applicable.
• Relevant motivation and context.
• List any dependencies that are required for this change.

How has this been tested?

• Please describe the tests that you ran to verify your changes.
• Provide instructions so we can reproduce.
• Please also list any relevant details for your test configuration.

• Make sure affected commands still run in terminal
• Ensure the SDK still works
• Check any related reports

Checklist:

• Update our Hugo documentation following these guidelines.
• Update our tests following these guidelines.
• Make sure you are following our CONTRIBUTING guidelines.
• If a feature was added make sure to add it to the corresponding scripts file.

Others

• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.

[martinb-ai]

@FedericoGarza Will this change in the future when we do not use "B" freq for time series?

Does StatsForecast do an auto-check if it doesn't happen to be "B"?

[AzulGarza]

Hey @martinb-bb!

I think it would be better if there were an extra parameter in the models named freq, so that the user can include the frequency of their data.

As far as I know, it is difficult for pandas to infer the frequency "B" because there are missing values in the data (weekends).

Should I include the freq parameter in this PR?

[martinb-ai]

Hey @FedericoGarza, Just thinking aloud right now..

I would rather not add another kwarg for the time being, since we have so many. Some users are new to this field, and assuming they know frequency right out the gate can be overwhelming.

Instead, the goal is to make the menu robust under the hood. Our current code checks for B right off the bat, and if that fails, then tries to use pandas to assume freq. If that fails as well, we then resort to index of the Dataframe.

found in helpers.py

try:
    ticker_series = TimeSeries.from_dataframe(**filler_kwargs)
except ValueError:
    # remove business days to allow base lib to assume freq
    filler_kwargs.pop("freq")
    ticker_series = TimeSeries.from_dataframe(**filler_kwargs)
except AttributeError:
    # Uses index if no date column
    console.print(
        "[red]Warning: no date found, assuming items evenly spaced.[/red]\n"
    )
    filler_kwargs.pop("time_col")
    ticker_series = TimeSeries.from_dataframe(**filler_kwargs)

Something like this would be ideal. If we include your library with the Darts wrapper, we can then do the same logic and it should work identically to the other models we have. Else, you can add some sort of custom logic in front of the StatsForecast(df=ticker_series, models=[model_ets], freq="B") before you pass in the time series?

In the future, we may revisit the concept on frequency when we start including extraordinary datasets and/or have have feature requests - in which that will require a decent refactor.

Only some thoughts... feel free to comment on any other ideas!

[AzulGarza]

hey @martinb-bb! Thanks for sharing your thoughts. I agree with you, asking users for freq would be overwhelming.

I've changed the preprocessing step to use helpers.get_series before using StatsForecast,

https://github.com/OpenBB-finance/OpenBBTerminal/blob/ba75a1f80f9fb8d8c0ef18af0494b06d564a9d56/openbb_terminal/forecast/autoets_model.py#L75-L79

This ensures that the same logic is applied to the frequency between all models.🙌

[martinb-ai]

@FedericoGarza Is a progress bar like the other models possible? It allows the user to know whats happening under the hood and not that the terminal is frozen.

[AzulGarza]

@FedericoGarza Is a progress bar like the other models possible? It allows the user to know whats happening under the hood and not that the terminal is frozen.

Hey @martinb-bb, I've included verbose=True in 5d1ea53. The verbose argument is only available as of v1.1.3 version of StatsForecast. Should I freeze that requirement in poetry.lock? Since darts installs the most recent version, perhaps it is unnecessary.

[martinb-ai]

Hey @martinb-bb, I've included verbose=True in 5d1ea53. The verbose argument is only available as of v1.1.3 version of StatsForecast. Should I freeze that requirement in poetry.lock? Since darts installs the most recent version, perhaps it is unnecessary.

This is great!
Works nicely to give users some understanding on what is going on.

I would say yes, poetry should update the statsforecast to the latest, regardless what darts installs. If you set a requirement in the poetry under the -e prediction tag, that would be easiest.

For ref, we install darts into the conda env and then update the remaining libs through poetry. This will help us in the future when you would like to add in new features to your lib and include them into the terminal.

When you update poetry, I will test on my end to make sure it will play nicely with the other operating systems 😄
Nice work!

[AzulGarza]

Hey @martinb-bb, I've included verbose=True in 5d1ea53. The verbose argument is only available as of v1.1.3 version of StatsForecast. Should I freeze that requirement in poetry.lock? Since darts installs the most recent version, perhaps it is unnecessary.

This is great! Works nicely to give users some understanding on what is going on.

I would say yes, poetry should update the statsforecast to the latest, regardless what darts installs. If you set a requirement in the poetry under the -e prediction tag, that would be easiest.

For ref, we install darts into the conda env and then update the remaining libs through poetry. This will help us in the future when you would like to add in new features to your lib and include them into the terminal.

When you update poetry, I will test on my end to make sure it will play nicely with the other operating systems 😄 Nice work!

Thank you @martinb-bb! I've included statsforecast==1.1.3 in the conda-3-9-env-full.yaml file instead of in poetry to simplify changes. What do you think? :)

[martinb-ai]

@FedericoGarza This is looking just about ready to merge from my end! We are currently doing a review of the forecast menu and adding in some UX improvements.

Could you please add a check for dataset size within your model.py to ensure users are running with at least 100 points? This is to prevent them from getting wonky results and expecting some valuable insights when using very small datasets. We have just merged a PR that added this in for Expo and theta as well : #3133

This is useful when they use the API.

@DidierRLopes anything else from a UX perspective that you see that could use a quick modification before we proceed to merge?

[DidierRLopes]

@FedericoGarza This is looking just about ready to merge from my end! We are currently doing a review of the forecast menu and adding in some UX improvements.

Could you please add a check for dataset size within your model.py to ensure users are running with at least 100 points? This is to prevent them from getting wonky results and expecting some valuable insights when using very small datasets. We have just merged a PR that added this in for Expo and theta as well : #3133

This is useful when they use the API.

@DidierRLopes anything else from a UX perspective that you see that could use a quick modification before we proceed to merge?

Nothing from my end, I created a PR with the UX improvements.

Let's merge this one first, and then I can rectify whatever else is needed. But this is looking great 😊