Add sbi wrapper class

[akapet00]

Attempt to resolve the issue #44.

The class Inferencer is fully functional and can be tested via hh_sbi.py file in examples. It supports both multi-round inference and multi-input/output traces.

Even though the class is ready to use, the feature metric is not yet fully supported. This actual feature metric should be supported by resolving the issue #48.

All additional changes are more or less stylistic improvements. sbi is added in the requirements file and in the setup.py as the optional dependency.

[akapet00]

Marcel, thanks for great comments! We can discuss the issue #48 in greater details in near future. For now, I'll try to create this list of functions for feature extraction possible. I guess it would be okay if some of the functions from that list use eFEL if the start and end stimulation times are known a priori?

[mstimberg]

For now, I'll try to create this list of functions for feature extraction possible. I guess it would be okay if some of the functions from that list use eFEL if the start and end stimulation times are known a priori?

So just to avoid misunderstanding, I meant that the inferencer gets something like features=[fun1, fun2, fun3] as an input, with fun1, etc. being functions mapping traces → features, all independent of eFEL. So from the Inferencer side we would not offer any functions, all functions would be provided by the user. Concretely, the hh_sbi.py example would define a function similar to what is current Inferencer.extract_features (which would be removed from Inferencer) and pass it as an argument for features. In general, the provided functions could certainly be a wrapper around eFEL, but the Inferencer code should (at this stage) do not need to know that eFEL exists, that there is such a thing as a stimulation time, etc.

[akapet00]

In general, the provided functions could certainly be a wrapper around eFEL, but the Inferencer code should (at this stage) do not need to know that eFEL exists, that there is such a thing as a stimulation time, etc.

That's exactly what I was thinking. Anyway, thank you for the clarification!

[akapet00]

Last few commits deal with some minor docstrings issues. Also train method is renamed to infere. This was done to be able to refactor the initial train method to 3 additional methods. The reason behind this is stated here:

I think it would be good to divide this up a bit further, e.g. have one method to simulate from the priors (or from posteriors from a previous run in the multi-round approach), one method to train the network, and one method to build the posterior. There are several reasons for this: 1) it makes it possible to train a network and then use the trained network on different experimental data (e.g. different cells) 2) it can be useful for debugging/sanity checks (e.g. if half of the simulations from the prior distribution give completely senseless results, it probably makes sense to adapt the prior before starting to train a network and 3) sbi's train() and build_posterior() methods both take several arguments. For advanced users, it would be good if they could provide them (which would be a mess with the current Inferencer.train() method. Having said all that, I think your Inferencer.train() method is a good convenience method for the most common use case, so I'd keep it and just have it call out to the more fine-grained methods . This also solves #50.

Advanced users can use each of the methods init_inference, train and build_posterior separately to gain complete control over the inference. Utility method 'infere' achieves similar results but does not offer such a powerful control over sbi.

Also, functionality for generating fitted traces by using the inferred parameters is added.

The example is updated according to these changes.

[akapet00]

Great, thanks!