Are transition objects relevant for linalg/quad/others?

[pnkraemer]

The statespace subpackage implements transition objects: e.g. of the type

y -> N(g(y), S)

and all sorts of message-passing/inference/etc. on these objects (e.g. GP updates, which are the same as Kalman filtering updates, and so on).
There are variations of these forward and backward messages (the naming is abstract, but we found this to be easiest to formalise it this way), e.g. square-root implementations which propagate Cholesky factors, etc.

Now my question:

Since these are such basic operations, is this functionality relevant for other parts of ProbNum? E.g. for the belief updates in linalg? Sorry, I am not very familiar with how the probabilistic linear solver works, but I would believe that Gaussian belief updates use those equations. I remember that @marvinpfoertner pointed out that he wanted to build an inference module which, as far as I understand, would be very similar to this stuff.

If so, we can factor the interface (and non-SDE implementations) out of statespace, and move the rest of the SDE stuff e.g. into the random process module. What do you guys think? If there is no need for the modules besides filtering/ODEs, it might make most sense to leave it where it is.

Now discuss! ;)

[JonathanWenger]

Very much agree with separating the inference functionality from the SDE and random process part.

[marvinpfoertner]

I there are two points here:

First of all, I think that the type of inference procedures that should go into an inference module are conceptually much more general than Gauss-Markov type Transitions. Hence, I would implement inference procedures/model objects such as LinearGaussianModel (name to be debated) with all performance optimizations (square-root implementation, etc.) in an inference module and reuse these procedures in the Transitions.

Secondly, I agree that the Transitions should go into the randprocs package, preferably into a gauss_markov subpackage.

[pnkraemer]

Okay, so it seems there is interest. Though I am not entirely sure what you guys mean by "inference" (isnt everything we're doing here some sort of inference?).
I'll assume for the rest of this ramble you mean propagating and conditioning in e.g. linear Gaussian models.

New structure

I guess then essentially the content of what is currently statespace/discrete_transition.py would become its own package:

probnum/
    inference/  # Contains what is currently in discrete_transition.py under a suitable interface
    randprocs/
        markov/  # contains, among other things, the Transition interface, a DiscreteTransition that wraps what is now in inference/ into its old functionality

Current functionality (to be moved?!)

I think the functionality of the Transition objects can be transferred pretty directly. It probably mostly needs a bit of renaming.
What it can currently do is the following.

Suppose a linear, gaussian model Y -> N(AY, B). At its core, Transition objects can do four things:

1. Propagate a sample y ~ p(Y) through this transition, i.e. compute N(Ay, B).
2. Propagate a random variable Y through this transition (i.e. if Y ~ N(m, C), compute N(Am, ACAt + B)) (if possible)
3. Condition Y on (let Z ~ N(AY, B)) on Z=z (for a realisation/data point z)
4. Compute a smoothing step (which involves 3., but with a full distribution as z)

These are currently {forward/backward}_{realization/rv}. I think this is the functionality that one would expect from something in the more general module. Again, please correct me here if you meant something else.

Naming

How set are you guys (at least MP) on the inference name? I am not sure about it, I guess there are pros and cons:

• PRO: one could also build a submodule inference.approximate which could contain approximate message passing in non-linear models (which yield things like the extended and unscented Kalman filter further down the line)
• CON: Very general/generic (which shows by the fact that I am still not entirely sure what you envision there).

Would you plan on implementing all sorts of other things there in the future (e.g. some sampling schemes or whatever?!)? If not, let's maybe pick something else. Alternatives could be

• models
• conditional(s) (this is just conditional probabilities, no?)
• likelihoods
• Something more exotic like message_passing or so (We chose the language of message passing for the transitions for their generality; not so sure how much this should show in the package name...)

Other minor comments

separating the inference functionality from the SDE and random process part

This cannot be separated entirely, but some basic things can be moved out of the statespace models (which will be extended by, among others, the SDE parts). I guess this is what you meant, but better safe than sorry :)