Add prospensity

[KCGallagher]

Idea for a test: can we assert that propensity function is always negative, for a variety of random inputs? I'll handle it in solve_gillespie, but just in case

[codecov[bot]]

Codecov Report

Merging #97 (dc7d787) into main (8725efa) will not change coverage. The diff coverage is 100.00%.

@@            Coverage Diff             @@
##              main       #97    +/-   ##
==========================================
  Coverage   100.00%   100.00%            
==========================================
  Files           11        14     +3     
  Lines          394       521   +127     
==========================================
+ Hits           394       521   +127     

Impacted Files	Coverage Δ
seirmo/__init__.py	100.00% <100.00%> (ø)
seirmo/_stoch_model.py	100.00% <100.00%> (ø)
seirmo/_stochastic_output_collector.py	100.00% <100.00%> (ø)
seirmo/plots/__init__.py	100.00% <100.00%> (ø)
seirmo/plots/_plot_from_numpy.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 8725efa...dc7d787. Read the comment docs.

[KCGallagher]

Flake8 currently failing because: ./seirmo/plots/__init__.py:12:1: F401 '._plot_from_numpy.StochasticPlotter' imported but unused This will be fixed when Lizi merges in updated plotters which use this function

Code coverage is also below 100%, this is again from seirmo/plots/_plot_from_numpy.py which will be updated when Lizzi merges

[KCGallagher]

Merge plotter (#107) into this, and resolve issue #110 before pulling into main

Edit: This has now been completed

[rccreswell]

Thanks @KCGallagher for starting on the changes I won't pretend that I know why the docs started failing. But adding those blank lines does get us passing again.

[rccreswell]

Re https://github.com/SABS-R3-Epidemiology/seirmo/pull/97#event-5568941868, @KCGallagher did you see https://github.com/SABS-R3-Epidemiology/seirmo/pull/97#discussion_r741797586

[rccreswell]

Ok, your comments have appeared now. You raise a good point about rgb tuples. However, I still maintain that it's quite contrary to good python practice to have the behavior depend so much on list vs tuple, &c.

You could take a look at the matplotlib.colors.to_rgba_array function, somewhat inspired by the precedent of the c argument of the plt.scatter function.

Do these four formats cover all the ones you want to support for plotting a single line? It seems to handle them all fine, and when we do colors[0] in the plotting for loop, it gives us exactly what we need, with no discrimination between list, tuple, or anything else:

>>> matplotlib.colors.to_rgba_array('red')[0]
array([1., 0., 0., 1.])
>>> matplotlib.colors.to_rgba_array(('red',))[0]
array([1., 0., 0., 1.])
>>> matplotlib.colors.to_rgba_array((1,0,0))[0]
array([1., 0., 0., 1.])
>>> matplotlib.colors.to_rgba_array(((1,0,0),))[0]
array([1., 0., 0., 1.])

The same function will handle the data_width>1 case:

>>> colors=matplotlib.colors.to_rgba_array(('red', 'blue'))
>>> colors[0]
array([1., 0., 0., 1.])
>>> colors[1]
array([0., 0., 1., 1.])
>>> len(colors)
2

[KCGallagher]

I completely agree - I didn't like the code before but it seemed necessary to maintain functionality so glad I can achieve the same handling in a nicer way - this change has now been made!