darts icon indicating copy to clipboard operation
darts copied to clipboard

[FEAT] RIN for covariates

Open turbotimon opened this issue 9 months ago • 7 comments

Is your feature request related to a current problem? Please describe.

Currently, the RIN (RevIn) is only done for the target series (n_targets). However, it would also be beneficial to past and future covariates in most cases (e.g. if they are leading indicators). An exception are maybe temporal or positional features (e.g. day/month/year) as added by add_encoders / datetime_attribute_timeseries()

Describe proposed solution

To give the user the most choice, I propose allowing the following for the use_reversible_instance_norm attribute:

  • A single Bool e.g. True: Target(s) only. As it is now (ensuring backwards compatibility)
  • A tuple of Bools e.g. (True, True, False) which is interpreted as (target, past, future) therefore apply RIN for target(s) and past covariates, but not future covariats in the example.
  • Optionally, allowing also tuple of Boosl in the tuple e.g. (True, (True, False), False) which gives even more fine control over which component will be normalized. The example would mean:
    • True for all targets
    • True for the first past covariate and False for the second (Tuple length must match number of components)
    • False for all future covariates

Describe potential alternatives

The logic could also be added as use_reversible_instance_norm kwargs proposed in https://github.com/unit8co/darts/issues/2748

use_reversible_instance_norm = {
   "series" = True # Enable for all series components 
   "past_covariates" =  (True, True, False) # Enable for the first two, but not the third. Tuple length must match number of components
   "future_covariats" = False # Disable for all past cov
}

Additional context

None

turbotimon avatar Apr 03 '25 17:04 turbotimon

Hi @turbotimon and thanks for this feature request. This will be a very useful feature.

I like the idea about giving the user control over which components to apply the RevIN. Regarding the implementation, I would suggest doing it similar to how you can define component-specific lags with our RegressionModel (e.g specifying the component names from the first series).

What do you think?

Also we could implement #2748 at the same time. The use_reversible_instance_norm could then accept all kwargs of RevIN (assuming that your proposed logic is implemented in the RevIN constructor as well).

dennisbader avatar Apr 04 '25 07:04 dennisbader

Yes, agree with specifying the component name would probably better more robust (less error-prone).

use_reversible_instance_norm = True # Only for targts(s) (as it is currently

# OR

use_reversible_instance_norm = {
   "series" = True # Enable for all series components 
   "past_covariates" =  {
       "comp_name": True,
   } # Enable for the component named "comp_name". All others are False by default
   "future_covariats" = False # Explicit disable for all past cov. False would be the default if not explicit specified for all (series, past, future)
}

turbotimon avatar Apr 04 '25 07:04 turbotimon

I could imagine something like this:

use_reversible_instance_norm = {
   "series": True  # Enable for all series components 
   "past_covariates": ["comp1", "compx"],  # enable only for the given component names. All others are False by default
   "future_covariates": False  # Explicitly disable for all past cov (default)
}

Let me know what you think.

dennisbader avatar Apr 04 '25 07:04 dennisbader

Yes, makes more sense with a list

turbotimon avatar Apr 04 '25 12:04 turbotimon

Hi! Interested in this too, but can't this behavior achieved just by scalers? I thought of a RIN as something that keeps outputs aligned with input scale and that's it, but for features other than targets there's literally no outputs...?

FourierMourier avatar Apr 17 '25 20:04 FourierMourier

No, it cannot. RIN is effectively a sample-wise scaler - it sets the lookback period of each input to mean 0, variance 1 for each train and inference sample, then inverts this scaling for the predictions. That's not equivalent to scaling the entire series.

eschibli avatar Apr 17 '25 21:04 eschibli

Possibly, something similar could/should be done on the output side of the model (see #2743).

felixdivo avatar Apr 23 '25 07:04 felixdivo