[ENH] re-interface API for `LTSF` algorithms about sktime HOT 6 CLOSED

I am working on adding an LTSF algorithm, so I'll fix the author tag.

I am closing the issue, as we have had a good discussion and have reached a conclusion to not change the API design.

from sktime.

Good observation!

I would go with the "implement a new one" plan.

Why: afaik, the current implementations are "reference implementations", taken from the cited repositories (which have not been released as packages on pypi).

So, they have - at least - an important place in comparisons, benchmarks, etc, for scientific purposes. Further, I'd imagine they are not fully interface identical with the neuralforecast ones (I have not checked though).

Regarding the name, I would add as an option, perhaps we don't necessarily want to switch them, but keep neuralforecast in the name, to give credit to neuralforecast / nixtla brand. So there's the original "academic" implementation which has been a reference for a while at least, and there's the nixtla implementation, which may or may not be improved, optimized, etc.

What do you think?

from sktime.

sure, I'll check how the original academic implemention and that of neuralforecast and sktime differs

from sktime.

hm, looks like nixtla did the same thing and copied the code? That's a curious situation then.

If it is a 1:1 copy - like in sktime - I see no reason to "outsource" it to nixtla?

Because accessing the same code behind an additional layer of interfaces makes it more brittle - which in the case of nixtla historically comes with substantial breakage risk (@yarnabrina probably has opinions on this, as the creator and maintainer of the statsforecast facing one).

Further, nixtla packages tend to take dependencies on all of pypi (exaggerating a little), while sktime minimizes dependencies. This would make the dependency requirements, for users of the same estimator, worse.

from sktime.

hm, looks like nixtla did the same thing and copied the code? That's a curious situation then.

yes, I was checking DLinear and it does look quite the same

Further, nixtla packages tend to take dependencies on all of pypi (exaggerating a little), while sktime minimizes dependencies. This would make the dependency requirements, for users of the same estimator, worse.

Yes, just observed the same thing, was working on nixtla on colab and it takes really long to install all the packages unlike sktime.

Because accessing the same code behind an additional layer of interfaces makes it more brittle - which in the case of nixtla historically comes with substantial breakage risk

I think this and the above reasons are strong enough to keep LTSF network implementations inside sktime

from sktime.

perhaps we should make the original authors aware that their algorithms exist in sktime and are indexed?

I am also noticing, they do not appear in the author tag, even though the code is copied. So, as an action, we should add the GitHub IDs of the original authors?

(this is my oversight, we added author/maintainer tags for estimators recently and we added them to 100s of estimators using default settings for the migration, based on file authors. Also see policy discussion in #5938 )

from sktime.