feat: get rid off output and input conversion for user

[Gerhardsa0]

Is your feature request related to a problem?

Right now the user needs to set Input and Output conversion, but its always the same type of conversion.

Desired solution

Create one conversion, which the user sees.

Possible alternatives (optional)

No response

Screenshots (optional)

No response

Additional Context (optional)

No response

[lars-reimann]

Is this different from #656?

[Gerhardsa0]

Is this different from #656?

@Marsmaennchen221 and I were thinking about removing Output and Input Conversion and generalizing it, to a Conversion.
The problem with that is, that for Time Series, I like that I have two separate interfaces for defining parameters, like window_size, forecast_horizon and prediction_name.

[lars-reimann]

I'm wondering whether the output conversion is really needed. We should already know from the dataset we get as input what the desired shape of the output is.

Likewise for the input conversions, there's a strong overlap to datasets, as we discussed:

• InputConversionTable needs no extra arguments.
• InputConversionImage needs the image size, which is already in the dataset.
• InputConversionTimeSeries needs the window size and forecast horizon. We could also move these to the dataset.

Edit 1: The input conversion can be helpful, though, to indicate the input type of fit and the input and output type of predict. We could keep these completely empty and just use them to set the type parameters of the model correctly.

Edit 2: We also get this information when we fit, however, based on the given dataset. Since fit returns a new NN instance, it could specify its type parameters then. For the unfitted model, we can just leave the type parameters on Any. This means, we'd need a common superclass Dataset for all datasets, with at least two type parameters (input and output type).

@Marsmaennchen221 @Gerhardsa0 @sibre28

[Marsmaennchen221]

Edit 2: We also get this information when we fit, however, based on the given dataset. Since fit returns a new NN instance, it could specify its type parameters then. For the unfitted model, we can just leave the type parameters on Any. This means, we'd need a common superclass Dataset for all datasets, with at least two type parameters (input and output type).

If we do this, what is the point of having a __init__ anyway? At least for Image NNs, the image size is needed to build the internal PyTorch model, which we do so far in the __init__ method. If we move this to the fit method, I don't see any real point of having an unfitted model, as the only thing we can do with it is to fit the model.

@lars-reimann

[lars-reimann]

• We could compose several (untrained) NNs into an ensemble or data processing pipeline, which can then be trained.
• We define the layers of the model in __init__. This is consistent with the classical models, where we define hyperparameters in __init__ and differentiate between unfitted and fitted models.
• Hyperparameter optimization #264 can still be integrated into __init__, where we could specify several architectures to try.

At least for Image NNs, the image size is needed to build the internal PyTorch model, which we do so far in the __init__ method.

Does this already initialize the weights of the model? If so, it would be considerably more efficient to do this in fit, since we must otherwise create a clone of these to prevent mutation.