predict() and cross_validation() outputs inconsistency about mlforecast HOT 6 CLOSED

Hey @RashidBakirov, thanks for using mlforecast. If you don't specify static_features they're all interpreted as static, so setting static_features=None (the default) or static_features=['feat'] is the same. I believe the outputs are correct here, aren't they? In one of the cases feat is being intepreted as static and in the other case as dynamic.

from mlforecast.

Hi @jmoralez

According to the documentation of cross_validation, the final two cross_validation calls fcst.cross_validation(df,n_windows=1,h=1,static_features=[]) and fcst.cross_validation(df,n_windows=1,h=1) should have resulted in the same outcome, with feat being treated as dynamic, at least this is my interpretation. This was also an impression I got from my previous question on this #144 . However, it looks omitting static_features argument assigns feat to be static.

Perhaps the documentation should be made more explicit to avoid misunderstandings.

from mlforecast.

As I said in my previous answer, the default is to treat all features as static, so:

• static_features=None (the default) -> static = ['feat'], dynamic = []
• static_features=['feat'] -> static = ['feat'], dynamic = []
• static_features=[] -> static = [], dynamic = ['feat']

So it's expected for those two commands to differ, since in the first one feat is dynamic and in the second one feat is static. That's the same case with predict, so if you don't set static_features and then provide X_df you'll get an error. It'd be expensive to validate if the static features are actually static (constant) but we could add something to see if the first and last rows don't match and raise an error.

from mlforecast.

As I said in my previous answer, the default is to treat all features as static, so:

• static_features=None (the default) -> static = ['feat'], dynamic = []

I understand this now, but I do feel that the above is confusing, and at least could be explicitly mentioned in the documentation.

It'd be expensive to validate if the static features are actually static (constant) but we could add something to see if the first and last rows don't match and raise an error.

I would rather keep the current (replication of the last value) behaviour for static features even if they are not quite static, but their future values are not known.

Thanks for your help!

from mlforecast.

Would you like to modify the wording here a bit to make it clearer?

from mlforecast.

This issue has been automatically closed because it has been awaiting a response for too long. When you have time to to work with the maintainers to resolve this issue, please post a new comment and it will be re-opened. If the issue has been locked for editing by the time you return to it, please open a new issue and reference this one.

from mlforecast.