PRNG determinism

[jmason42]

We need all implementations to be deterministic. With any sort of compiled approach (JIT, Cython) this is challenging.

It's particularly tricky to support determinism with the single-step approach (as opposed to evaluating to some time point) with compilation since jumping in and out of compiled code while maintaining a PRNG state is difficult or impossible. I'm inclined to suggest that the step-based procedure should be handled via a class or generator function, while the run-until procedure should be handled by a separate function entirely, with the expectation that the two will not lead to the exact same results.

[prismofeverything]

After doing some more tests with numba I was getting results where the jit compiled code was taking longer than the uncompiled code (10s vs 25s for the same simulation). I will make a new issue for it, but for now I am leaning to keeping this uncompiled, both for this reason and to avoid nondeterminism with RNG.

[jmason42]

That's troubling. If you have a working example, I can poke around. It's possible that it was only compiling the already fast parts.

[prismofeverything]

Yeah I actually removed the numba parts, but it should be easy enough to put back in to test. I also had a few problems with compilation, for instance the list comprehension threw some kind of "This error should not happen" deep in the numba code, but works with map? Kind of funny. Now that I think about it I should have written all this down, but I was moving fast and just stripped it out instead with the intention that I would try it again later.

[jmason42]

A separate resource for Numba friction points would be tremendously helpful. There's not a lot out there.