Bringing Point Processes into GluonTS

[canerturkmen]

Hello everyone. 🎉

Here you may find the branch I'm working on to include capability for working with temporal point processes in GluonTS. It has a few days of extra work left to complete the sampler, and potentially throw in a tutorial, but the design as I see it is in place.

So integrating ideas from TPP to GluonTS meant a bit of work, and extending some of the core facilities the library provides.

The main difficulty is that TPP realizations are "ragged" tensors, i.e., observations occur in a fixed length interval in the real line and have "variable length." This is why the Tensor objects passed around are ragged, and common arguments such as prediction_length and context_length are void. I tried, to the best of my ability, to conform to the GluonTS API while allowing TPP-type data structures. This meant extending some of GluonTS's common interfaces.

Specifically,

• A new Forecast object is there, which allows for forecasts to be available as ragged tensors.
• The DataLoader interfaces are extended to include logic on stacking ragged tensors. Particularly, this means extending the BatchBuffer object, and we now have a VariableLengthBatchBuffer.
• A new transform, the continuous-time analogue of InstanceSplitter, had to go in there. ContinuousTimeInstanceSplitter (extending FlatMapTransform) samples sub-intervals of the real line and produces ragged tensors which include the point observations. This introduces a dependency on a ContinuousTimePointSampler object, which we also define an interface for.
• Extending GluonPredictor, The PointProcessGluonPredictor is again aware of point process-style data structures and yields PointProcessSampleForecasts.
• Finally, of course, we have estimator and network objects that diverge from the GluonTS API sparingly.

Some Other Issues

• Hybridization, unfortunately at this stage, is not an option. This is mainly driven by the fact that our implementation depends on the LSTMCell facility rather than LSTM (the latter cannot work with ragged sequences), and has to be unrolled explicitly---with the length of unrolling known ahead of time.
• The univariate Hawkes process will wait a little since the operator was released as part of MXNet 1.5.0, which we don't seem to allow at the moment. The current model is the RMTPP.
• I did not try extra hard at this point for "representability," though it would be great if you could point out what's missing on that front.

The Plan & Some Questions

My plan is as follows. I'll cut the contribution up into several PRs, splitting core components and the model itself. I'm hoping this will make the review process easier. At this point however, I have a few questions.

• First, of course, this is an RFC on the current design and plan. Any comments are very very welcome.
• I am not very clear on what namespace to organize these components under. Should I...
  • organize the model components (Estimator, Predictor, Networks) in gluonts.model.tpp or gluonts.tpp? The main issue here is that we will have multiple TPP models that share, e.g., the Predictor object; and that TPP model API differs slightly from other model APIs (e.g., no prediction_length but prediction_interval_length, etc.).
  • include the Transform, Forecast, BatchBuffer, and DataLoader objects with their parents in gluonts.dataset and gluonts.transform? Or maybe gluonts.tpp.common?

Looking forward to the discussion. Thanks a lot!

[ehsanmok]

What's the status of this feature now?

[canerturkmen]

Hi Ehsan, thanks for your message. Unfortunately, it's still WIP.

[AaronSpieler]

We had some discussion regarding the same issue for seq2seq models recently, and if I'm not mistaken the last consensus was that we need to split that module up because it's encompasses too many things, but no final conclusion was reached as to how exactly.

Something like gluonts.model.tpp_common could also be a solution, otherwise It's hard to make better suggestions without the concrete code.

[canerturkmen]

Hey thanks for reading through this @AaronSpieler ! I agree with splitting it up. On second thought, some parts are more coupled than others. The forecast object, for example doesn't make sense out of the TPP context, while the transforms and loader logic "might."