[Feature] add encoder support for torch datasets

[jakubchlapek]

Is your feature request related to a current problem? Please describe.
Building on the issue #3006, as it relates to documentation

Describe proposed solution
add support for our datasets to support encoders.

[tRosenflanz]

Does it make sense to add the support for encoders to the datasets directly (essentially add methods that construct the SequentialEncoder and call it on the dataset covariates during the init) and/or add a flag to fit_from_dataset to inherit the encoders from the model with the default behavior being old behavior of ignoring them? As a user the latter seems fairly intuitive but I wonder if there are some Dataset use cases that will be an issue.

[daidahao]

Hi everyone, I don't think add_encoders support for TorchTrainingDataset under the current API design is appropriate. Currently,

• Setting add_encoders for TorchForecastingModel creates SequentialEncoder as self.encoders.
• Under the hood of fit() and predict() of TorchForecastingModel, self.encoders (SequentialEncoder) is used to generate past/future covariates from timestamps of series (see ForecastingModel.generate_*_encodings()).

With the proposed add_encoders support:

• If the user-defined dataset is ShiftedTorchTrainingDataset or SequentialTorchInferenceDataset or their subclasses, creating past/future covariates from series is possible because all those classes have series attributes.
• However, the proposed change breaks down when the user-defined dataset is a generic TorchTrainingDataset because the series attribute is not guaranteed.

All in all, I think the current TorchTrainingDataset is intended to be as generic as possible and even to support non-timestamped data. Instead of setting add_encoders, users can create their own SequentialEncoder to encode timestamps in TorchTrainingDataset.

That said, I am in favour of @tRosenflanz proposal in #3006 and to raise a warning/error when add_encoders is set but fit_from_dataset() is called.

[jakubchlapek]

Hey @daidahao, thanks for the input :) For the reasons you've said I originally mentioned in #3006 that we should hold off on implementing any changes to the logic. You are correct that the TorchTrainingDataset was designed to be as generic as possible, and be provided by the user fully prepared. Ideally any of the encoder transformations should be done by the user beforehand, so fit_from_dataset() would ingest a ready dataset, however this is something we wanted to explore as the TorchTrainingDataset was written a while ago and it'd be good to check if there is any space for improvements, hence this issue and initial adding it to the backlog. Let me know if this makes sense, maybe @dennisbader has any additional thoughts?