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

Feedback on the API #20

Open
dfalbel opened this issue Mar 14, 2022 · 1 comment
Open

Feedback on the API #20

dfalbel opened this issue Mar 14, 2022 · 1 comment

Comments

@dfalbel
Copy link
Member

dfalbel commented Mar 14, 2022

I wrote a draft vignette on what I think would be a reasonable API for tft and would like to get some feedback on it.
Ideally I'd love to have the same API as modeltime, but I am not sure how to fit it into its workflow because of a few critical differences:

  1. TFT handles differently each kind of predictors (static variables, known and unknown time varying variables) and data prep must be very different for each one.
  2. It can be used to forecast multivariate time series as well as multiple time series.
  3. It also produces multi-horizon forecasts - couldn't find how to do it with modeltime.
  4. Allow producing prediction intervals.

The write-up can be found here: https://mlverse.github.io/tft/articles/Getting-started.html

@cregouby, @mdancho84, @topepo would love know your opinion on it. Let me know if you have time for a quick look.

@cregouby
Copy link
Collaborator

cregouby commented Mar 16, 2022

👍🏽 for the horizon = 5 parameter, as current total_time_step is completely ugly.
👍🏽 for the tsibble in, tsibble out, as such

  • long format for multi-horizon forecast becomes an evidence,
  • "key" and "index" are well documented and straightforward for timeseries practitioner
  • avoid the use of new_role="time" and new_role="static_input"

So it is fine for me globally.
I'm still not comfortable with the "known" name for the last new_role, even if it comes from the paper, as no one can remember it without referring to a doc. But I can't find a better name... So this just adds a challenge for documentation clarity.
And we have to manage the split of tsibble keys into former new_role="id" and new_role="static_input" that is not covered here. We could document first key will endorse the id role maybe...

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

No branches or pull requests

2 participants