Open jaheba opened 2 years ago
Should predictors not allow being called without n
? (That is, should n
not have a default value?)
This line seems too complicated:
median_forecast = np.array([np.median(sample) for sample in forecast])
If forecast
is an array-like object, should one not be able to do something like
median_forecast = np.median(forecast, axis=1)
?
This line seems too complicated:
median_forecast = np.array([np.median(sample) for sample in forecast])
If
forecast
is an array-like object, should one not be able to do something likemedian_forecast = np.median(forecast, axis=1)
?
I wanted to use the same code for both examples. The axis-parameter doesn't work where you only have a single value per time-stamp, I think.
Another note: predict_many
may be the preferred way of implementing some of the predictors (e.g. NN-based ones that prefer to process multiple entries in one batch).
What is the idea here? Are you thinking of having a fall-back definition for predict
and predict_many
, each relying on the other one? So that if a predictor implements predict_many
it gets predict
for free, and vice versa.
Should predictors not allow being called without
n
? (That is, shouldn
not have a default value?)
Like 1
, or do you mean one defined by the predictor? I would find the latter unintuitive since different predictors would then yield different length by default.
Another note:
predict_many
may be the preferred way of implementing some of the predictors (e.g. NN-based ones that prefer to process multiple entries in one batch).What is the idea here? Are you thinking of having a fall-back definition for
predict
andpredict_many
, each relying on the other one? So that if a predictor implementspredict_many
it getspredict
for free, and vice versa.
Something like that. predict
and predict_many
would be low-level primitives that users don't interact with directly.
But something I find really annoying at the moment is when I want to predict a single time-series, I have to do something like:
forecast = list(predictor.predict([past_data]))[0]
instead of
forecast = predictor.predict(past_data)
With predict_one
and predict_many
(or however we would like to call them) we could define interfaces for both.
How they work internally is another question of course :)
I wanted to use the same code for both examples. The axis-parameter doesn't work where you only have a single value per time-stamp, I think.
Sure. One problem I see there, is that something like for sample in forecast
will iterate along the first dimension of the forecast
array, in case it's an actual np.array
. So that axis should be the "sample" axis; if there is no sample axis (because the forecast is not sample-based, for example if it’s a parametric distribution or a point-forecast), iterating over it will give misleading results. In conclusion, whoever gets the forecast
object back should in any case be aware of its shape and the meaning of the axes, in order to correctly operate on it.
Creating a predictor in GluonTS is relatively complicated. Let's make it simpler!
Proposal
Each predictor should implement the following interface:
The function takes some model-specific past_data attribute and a prediction-length
n
and is expected to returnn
Distribution
values.Distribution
is an array-like object, on which we can call invoke numpy functions such asnp.median(...)
.Let's take a look at a trivial example:
And a slightly more complex example returning samples:
TODO:
predict_many
for models that can predict multiple values at once