Open fkiraly opened 1 month ago
Listing different layers and sublayers that might help to draw a delineation:
sktime
BaseForecaster
etcpytorch
framework layer objects, e.g., a hypothetical BasePytorchNetwork
in sktime
pytorch
framework layer objects specific to forecasting, e.g., a hypothetical BasePytorchForecaster
in sktime
pytorch
networks or layers that are specific to forecasting models, but not full forecasting modelspytorch
networks or layers that are specific to time series models but shared by, say, forecasting and time series classification, see multimodal momentfm
transformer modl https://github.com/sktime/sktime/issues/6542 (FYI @julian-fong)pytorch
forecasting models, e.g., nbeats forecaster
Issue collecting design discussion related to the boundary between
sktime
andpytorch-forecasting
, with a particular focus on foundation models and weight management, also seesktime
issue https://github.com/sktime/sktime/issues/6177.In
sktime
we have recently started to introduce a dedicated layer forpytorch
based forecasting models, and also specifically around weight management for "foundation models" - pre-trained deep learning models, of transformer architecture, which are predominantlypytorch
based as well.This situation begs the natural question, whether some parts of this layer - and if yes, which precisely - would be better contained in
pytorch-forecasting
. For instance, one could argue that the natural boundaries ofpytorch-forecasting
are anything that has to do withtorch
objects and their direct interfaces, which would include the aforementioned foundation models.One could even argue that all
sktime
interfaces specific topytorch
based forecasters should be contained inpytorch-forecasting
, in the form of a 2nd party interface, along the lines of patterns discussed here: https://github.com/sktime/sktime/issues/6639, that is,sktime
estimators present and maintained inpytorch-forecasting
towards with thepytorch
-facing backend, only specific to forecasting. Although in a case where there are common backend concerns with, say, time series classification (FYI @fnhirwa), that might be cutting off too much.