Remove freq argument in SeasonalNaivePredictor

[lostella]

Description of changes: So far, freq was a mandatory argument in constructing SeasonalNaivePredictor. However, its role is not really clear this way: what is it used for? Can the predictor only treat data sampled at frequency freq? No, the frequency information is only used to infer the seasonality in case not directly provided.

This PR fixes this by removing freq altogether: now season_length is required.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Please tag this pr with at least one of these labels to make our release process faster: BREAKING, new feature, bug fix, other change, dev setup

[jaheba]

Not sure this would be nicer.

maybe.or_(season_length, freq).expect("You must provide one of `freq` or `season_length`")

[jaheba]

What is the use of freq, if season_length is passed?

[lostella]

it's ignored (season_length takes precendence); another option is that not both can be specified

[lostella]

Not sure this would be nicer.

not sure, I find the explicit assertion clearer

[melopeo]

I would keep the option of both parameters to be given, with season_length taking precedence.

[jaheba]

I think I actually like removing freq as a parameter and require setting season_length (why is it not called seasonality?).

That way things become much more explicit.

[melopeo]

Maybe I am wrong, but with this modification this model would be the only one that explicitly requires the parameter season_length, and I am not sure this is something we want. I agree that giving priority to season_length is something nice, but in many cases one computes seasonal_naive just as a reference without giving so much thought about the seasonality. For instance, in our metrics we use calculate_seasonal_error and I am not sure to what degree this would then also require an explicit value for season_length.

[lostella]

but with this modification this model would be the only one that explicitly requires the parameter season_length

I think that’s fine. The only thing common to all models really is that they have a fixed prediction length; in general, I think it’s fine that models each have their own set of options, related to how they work internally.

This model has a very simple logic, entirely determined by season_length: specifying this directly has no ambiguity. Adding indirection to translate freq only hides a little bit what the model will end up doing, with no added flexibility.

Then there are the choices for the default seasonality for hourly and daily data, which are completely arbitrary and end up tying together the behavior of different models or components for no reason.

In summary, I tend to agree that if you want to use the naive seasonal method, you should bring your own seasonality parameter. We do provide some heuristics to get that from frequency, and one is free to use them, but should do that explicitly.

[lostella]

Removed freq altogether, making season_length mandatory.

[lostella]

I think naive2 could be simplified in a similar way, see

gluonts/src/gluonts/ext/naive_2/_predictor.py

Lines 61 to 80 in 3ccb6d3

	freq: Optional[str] = None,
	season_length: Optional[int] = None,
	) -> np.ndarray:
	"""
	Make seasonality adjusted time series prediction.
	If specified, `season_length` takes precedence.
	As described here:
	https://www.m4.unic.ac.cy/wp-content/uploads/2018/03/M4-Competitors-Guide.pdf
	Code based on:
	https://github.com/Mcompetitions/M4-methods/blob/master/Benchmarks%20and%20Evaluation.R
	"""
	assert freq is not None or season_length is not None, (
	"Either the frequency or season length of the time series "
	"has to be specified. "
	)
	season_length = (
	season_length if season_length is not None else get_seasonality(freq)
	)

[jaheba]

@lostella Do you want to adjust naive2 in a separate PR?