Experiment with using Pyro instead of Stan?

[nbarlowATI]

I think this has been discussed a couple of times before, but I couldn't find an issue for it.

Since it seems that a reasonable fraction of our installation/compatibility problems are related to Stan/pystan/gcc, is it worth trying a different probabilistic programming language for our model? Would we encounter fewer little problems with something like Pyro?
Could be a useful and fun learning exercise anyway to try to reimplement our team and player models in a different language.

[jack89roberts]

With the problems since the backwards-incompatible pystan version bump it's probably worth prioritising this now:

• Replace bpl team model with bpl-next
• Re-write player model in numpyro
• Check results and execution times are comparable
• Remove all pystan dependences (including in pyproject.toml etc.)

I've made a branch feature/313-pyro but haven't started any of the above yet. Will try to have a look at bpl-next before the hack session on Friday.

[jack89roberts]

Started having a play with it. 2 things I've noticed about bpl-next:

• Need to recreate ability to get predictions for new teams without match results (made an issue in the bpl-next repo)
• Prediction hangs if trying to run multithreaded, I think because Jax (which bpl-next uses and possibly numpyro too) is multithreaded itself so there's some conflict with multiprocessing.

[callummole]

This is implemented in #377