interesting - as a starting point, may I kindly ask you to write some speculative code for both use cases? I don't think I've fully grokked them yet.

Rolling update: filtering timepoints after adding the new data:

from sktime.split import temporal_train_test_split


  if hasattr(forecaster, "_y"):
      if forecaster._y is not None:
          _, forecaster._y = temporal_train_test_split(
              y=forecaster._y, test_size=self.nr_timepoints
          )

  if hasattr(forecaster, "_X"):
      if forecaster._X is not None:
          _, forecaster._X = temporal_train_test_split(
              y=forecaster._X, test_size=self.nr_timepoints
          )

Model validation: Deleting data capability

if hasattr(forecaster, "_y"):
    del forecaster._y
if hasattr(forecaster, "_X"):
    del forecaster._X

But for above asked capabilities somehow the internal data update needs to propagate to all elements in the pipeline as data can be stored multiple times via (shadow) copy.

Hm, could you kindly add more text on why you are doing this and what the workflow tries to achieve?

To keep memory low as for some forecasters the internal data can become large as in hierarchical/panel/global forecasting cases. On our end we keep the data for fitting separately stored and only want to keep data relevant for prediction in the internal data of the forecaster.

The above comment is for the rolling update part. For the model validation the reason is already mentioned I think clearly in the initial description. Let me know if there is a specific point you would like me to elaborate more.

Ahhh, I see. For deleting - or, more precisely, not remembering - the _X, _y data, there is a config fields that turns it off:

• related discussion, How to reset the history of a TS model without to change the model's parameters #5545, @corradomio has also requested related featuers
• config option &corradomio [ENH] config to turn off data memory in forecasters #5676, it is called remember_data (a boolean) and can be turned off via set_config

It comes close. Not remembering seems to me only relevant to set before a model is first fitted and not covering the case after fitting when updating the model. It seems to me the old data is in that case still kept and there is no clean option to delete data after data is stored internally on the model.

Thanks for replying! Can you explain what you would wish instead? The config can be set after construction, before the model is fitted.

Two things would be nice:

• Public Method to delete the internal data from a forecaster and for example in the case of a ForecastingPipeline also all for all steps.
• Have a config option that defines how much internal data to keep. So how many timepoints to keep per timeseries stored in the internal data. There is often no need to keep all data, which now happens after multiple update calls. Not for training or prediction.

Maybe this deserves a separate issue, but this would solve a problem I'm having with _StatsModelsAdapter forecasters where calling set_config(remember_data=False) doesn't allow prediction since _predict uses some metadata items of self._y. Ideally, I would be able to delete all data not needed.

Yes, I forgot to add here that set_config(remember_data=False) is meant to solve this at least temporarily.

We should probably decouple all forecasters from the remembered data in _y, _X, this would allow a cleaner move to not remembering it at all.

@hudsonhoch, I agree that a separate issue would be great for the _StatsModelsAdapter. We should be able to fix the problem by adding lines in _fit that check for presence of _X, _y, and if not present, write them.

Created issue #7405.

We should probably decouple all forecasters from the remembered data in _y, _X, this would allow a cleaner move to not remembering it at all.

I'm not exactly sure what this means, but what is the idea behind saving _y and _X rather than only the data needed for post-_fit methods? FWIW I frequently hit memory issues so I've resorted to writing wrapper classes to get rid of bloat.

@hudsonhoch, interesting - could you share the wrapper classes, and how you fixed the _StatsModelsAdapter? Perhaps in a draft PR?

I would be very curious - maybe we can use this to reduce the memory footprint.

I suspect my wrapper classes wouldn't be much use in the module as they are hacky and break things: They just add a remove_data method, which clears most all of the data without any care of the repercussions downstream.

The reason for my earlier question on _y and _X is because I think it makes more sense for _fit to be responsible for saving only necessary data for downstream use. For example, _StatsModelsAdapter._predict only needs the following pieces of information: _y.index[0], len(_y), and _y.name.

They just add a remove_data method, which clears most all of the data without any care of the repercussions downstream.

What I would like to understand, when do you use this?

For example, _StatsModelsAdapter._predict only needs the following pieces of information: _y.index[0], len(_y), and _y.name.

I see! These are actually data either saved in metadata fields, or they can be remembered in _fit. That is what I meant, we just remember in _fit what we need, and do not access via _y in _predict. That should be an easy modification to the adapter.

• _y.index[0] is not stored outside _y, but we can remember it!
• _y.name is inferred by the input checks and stored as part of _y_metadata, namely the "feature_names" field. It should als obe written to self.feature_names_in_. The _y_metadata dictionary is created even if remember_data=False.
• len(_y) is not stored outside _y but could be remembered. We could also add it to _y_metadata, although this would require some changes to the datatypes metadata inference by adding a new field. Perhaps it is better to remember case-by-case, since lengths can be different in the panel case.

Might I suggest two actions?

1. issue and/or PR for uncoupling _StatsModelsAdapter from _X, _y
2. new issue on uncoupling every forecaster from _X, _y. We could check this with a diagnostic test, seeing what happens if remember_data=False.

I use my wrappers like the following:

forecaster.fit(y, X=fit_X)
p = forecaster.predict(fh=fh, X=predict_X)
forecaster.remove_data()

where remove_data deletes everything I don't need later. I'm forecasting hourly data with >50 groups of ~5 forecasters. >250 hourly forecasters quickly eats up my memory so I only keep the bare necessities for debugging purposes.

Might I suggest two actions?

1. issue and/or PR for uncoupling _StatsModelsAdapter from _X, _y
2. new issue on uncoupling every forecaster from _X, _y. We could check this with a diagnostic test, seeing what happens if remember_data=False.

1. I'll submit a PR to fix [BUG] Unable to use _StatsModelsAdapter.predict if config remember_data=False #7405
2. I can create an issue for this.

I see. So you do not use update?

1 and 2 would be appreciated!

I would then comment on the memory footprint - perhaps we should by default not make forecasters remember _X, _y, but this will take some serious change cycles.

I see. So you do not use update?

I don't, but maybe that's because I don't understand the use case. For my specific application, I just re-instantiate forecasters and fit with new data.