New connection rule for Poisson-distributed number of synapses between neuron pairs

[ackurth]

In my work, I found it practical to adapt the pairwise_bernoulli connection method to a pairwise_poisson method, where the number of synapses between pre- and post-synaptic neurons is drawn from a Poisson distribution.

The choice of the Poisson distribution is not arbitrary.
Imagine you have the average number of synapses p between two neurons of specific populations.
Oftentimes, these specific populations have distinct targeting patters: same inhibitory neurons target preferentially basal, other distal dendrites etc.
Assume that the process on which a synapses is established has overall length L and that this L is similar for all neurons in the target populations
Since the overall number of synapses between two neurons of pre- and postsynaptic populations is known (p), on a small piece of the target process with length ```x````, the probability of the synapses being established on that piece is p*x.
Here of course we assume that the connection probability is identical everywhere on the target process.
To first order, this approximation seems fine.
You can probably already see where I am going: The synapses are thus a Poisson process on the line, the number of synapses is Poisson distributed.

This has two additional advantages:
First, the heterogeneity in the network is bigger in comparison the the standard Erdos-Renyi graphs generated by the pairwise_bernoulli connection method.
Indeed, in this case variance relative to the mean (i.e. the Fano Factor) is N_1*N_2*p*(1-p) / (N_1 * N_2 * p) = (1-p) <= 1with equality iff p = 1.
Here, N_1, N_2 are the number of neurons in the pre- and post-synaptic populations.
For the Poisson based rule the Fano Factor equals 1.

Additionally, especially when working with spatial networks it frequently occurs that the average number of synapses between to populations (then interpreted as connection probability) on short distances exceeds 1.
This leads to errors when using pairwise_bernoulli, but is not a problem for the pairwise_poissson.

Anyway, in the current PR such a connection scheme is implemented.
If you deem this sufficiently interesting to potentially merge it into master I will add the documentation.

[heplesser]

Hello @ackurth! Thank you for this contribution, which seems useful. I have only had a first look at the code, so here a few initial observations:

• Please make sure the formatting is in order.
• I don't like the lam parameter name, and yes, the one true design flaw in Python is lambda as a keyword, but even lambda would not be good. Can you find a name that is neurobiologically meaningful?
• As far as I could see, while you give a very nice justification for the new rule in the PR here, there is no documentation or example for the new rule. Could you add that?

[jessica-mitchell]

@ackurth I second the need for documentation; there should be a section added in the doc/htmldoc/synapses/connection_management.rst at the very least

[ackurth]

@heplesser
I changed the variable name from lam to pairwise_avg_num_conns.
It's a bit wordy but I think the most precise. Unless one wants to exchange average with expected.

I also corrected the formatting now. I have to say the new (to me) workflow for this is quite nice.

@heplesser @jessica-mitchell
Sure, documentation must be added.
This is what I was aiming at with the last sentence of the message of the PR.
I now added some documentation in the doc/htmldoc/synapses/connection_management.rst as well as in the doc/htmldoc/networks/spatially_structured_networks.rst (latter I think is in order since the new connection rule is also nice and works for spatial networks).
Anyway, I did find that the description of why the connection rule is nice did not really fit in the doc/htmldoc/synapses/connection_management.rst.
Is there another place where I should write it down? Do we want this to be part of the documentation anyway?

[jessica-mitchell]

@ackurth I see what you mean, but I can't think of another document that would suit such a description. In this case, I would suggest adding a note or subsection in connection_management. @heplesser do you have any other suggestions?

[nicolossus]

@ackurth Thanks! Overall this looks good to me. I only have some minor nitpicks, see inline comments.

@heplesser @jessica-mitchell This PR got me thinking that it would be nice to have a minimalistic example where the differences (including the different parametrizations) between all connection rules are shown. I think this can be handled in a separate PR. If you agree, I can create an issue to remind us.

[heplesser]

Hi @ackurth I have a few more suggestions, please see inline.

[ackurth]

I addressed this in 995f22d .

[heplesser]

@ackurth Thanks for the changes, this looks good to me now!