Add interface for MultiSeriesProblem

[MichaelClerx]

Does anyone have a good real-world example of a likelihood defined on multiple time series?

I'd like to delay this as long as possible, to avoid the scenario where we add extra difficulties that stay with us throughout the project and then never get used in real problems

[mirams]

Even a synthetic voltage+calcium traces would be interesting (Christini's gang have showed how fitting this too is helpful for getting cell-specific conductances - as you might expect).

[MichaelClerx]

That could be a good use case I suppose. Do you remember if they do whole trace fitting on that?

[mirams]

They showed it at the Oxford meeting back in Sept, but I can't remember whether it was from whole trace or biomarkers. But whole trace would be a good thing to code up anyway.

[sanmitraghosh]

For the benchmarking and extending this library outside Electrophysiology, this is a must have feature

[ben18785]

I agree this is essential. Could we have two settings on such an interface? (Later, three, if we can figure out a way to make hierarchical models not too onerous to introduce.)

• Heterogeneous coefficients, where you get one estimated set -- or posterior samples -- per time series.
• Homogeneous coefficients, where all the data is used to estimate a single 'overall' set.

[MichaelClerx]

What would the ErrorMeasure and LogLikelihood methods look like for multi-series problems?

[MichaelClerx]

And should we stop using the term dimension to indicate the size of the parameter space, if we're going to have a lot of different dimensions (number of series, number of samples, etc.)? Suggestions?

[sanmitraghosh]

There would be two dimensions 1) \Theta dimension 2) Visible State X dimensions . I think you can use 'dimension' for parameters and a separate entity 'states' for the state variables. I am sure we don't need anything more than that.

The noise/likelihood model is a multivariate normal distribution. where the mean vector is made up of the states and the covariance \Sigma=\sigma^2 \mathbb{I}, where \mathbb{I} is the identity matrix of size 'states' x 'states'. You can see equation 4 and 5 in this paper for a very nice explanation

[mirams]

I think for an optimisation/inference package, using dimension to indicate the dimension of the search space (i.e. number of parameters that is being inferred) is OK. But no harm in making it clearer and consistent in the tutorials etc.

[MichaelClerx]

Just a note to make clear that this is an interface for problems that provide 1 set of times, but a multi-dimensional set of values

[MichaelClerx]

@sanmitraghosh put a nice example online in PR #275 that I'm currently updating for tests, style issues, etc.

It introduces stateDim for the dimension of the state, but I'm thinking about changing this to outputs since we're interested in the number of visible outputs, which are not necessarily states. Any thoughts?

[MichaelClerx]

Another option would be to change everything to use terms like n_parameters (or n_params), and n_outputs. I don't like always assuming n is a count, but might be a more extensible naming scheme?

[martinjrobins]

I think the n_ naming scheme for numbers of things is good. I'm happy with n_outputs

[sanmitraghosh]

I am happy with n_outputs

[MichaelClerx]

What about n_params then? Big change but easy to do...

[sanmitraghosh]

Ya n_params is a big change, I think its better to avoid really big changes. Anyways these are internal/developer parameters, so I guess we could name it whichever way we find suitable.

[MichaelClerx]

Related question: Should we rename SingleSeriesProblem and MultiSeriesProblem to SingleOutputProblem and MultiOutputProblem ?

[sanmitraghosh]

Series --- best