Have the schedulers use the model's randomizer

[lmzintgraf]

Regarding this TODO in the documentation:

TODO: Have the schedulers use the model's randomizer, to keep random number seeds consistent and allow for replication.

How about letting the model have a random state (using numpy) which the scheduler can then call? I.e.,

• in the model init: self.random_state = numpy.random.RandomState(seed)
• in the schedule step: self.model.random_state.shuffle(self.agents)
• alternatively, in the schedule init: self.random_state = self.model.random_state (which I assume will make a copy; not important for reproducibility but it might be nicer to use the model's random state directly)

Some things I ran into while trying this:

• It would now be required for new models to call the super().__init__() method (see Example models should call super in init #248 ) to make sure that models have a random state. Alternatively, we could put a check in the scheduler if the model has a random state, and if not, create a local one. The problem is that then the seed can't be specified, or, if it can be passed to the scheduler, it will only have effect if the model doesn't have a random state, which seems weird.
• When testing this, test_time.py will crash:
  • First error is because super().__init__() is not called (see above), and the scheduler cannot call self.model.random_state
  • Another error occurs when mesa.time.random.shuffle is called in the test. It will either complain that the import isn't there (I removed it, import random in time.py is not necessary anymore), or the following happens:
  • test_random_activation_step_shuffles and test_shuffle_shuffles_agents crash. I guess it's because the way random calls are made changed (it's not mesa.time.random.shuffle, but via np.random). Not sure how to fix this.

[djmitche]

The Model base class already seeds the global Python random number generator. I think it can also seed the global Numpy random number generator with the same seed, and I'm making a PR to do so. Then all uses of random values can just consult those global generators, avoiding the need to pass around random state instances.

[lmzintgraf]

I think it might be safer to use random state instances, instead of setting the global seed. If someone uses the mesa framework and sets global random seeds in their own implementation, they will unknowingly influence the random generators in the mesa implementation, which might lead to unwanted behaviour. In addition, setting the global seed might not be thread-safe, and it could very well be that somebody works with multiple threads with mesa.

I can make a PR with the proposed changes. (Same thing goes for the space module, where also the global random generator was used.)

[djmitche]

Random numbers will never be deterministic in a multi-threaded environment (since the order of requests for random numbers is then based on thread scheduling). I don't think double-seeding the global random seeds would be problematic, either - it's redundant and not the Mesa best practice, but it would work.

This PR doesn't preclude a Mesa user using their own state instances (and seeding those instances if they want repeatable results).

I'm going by the Zen of Python's "simple is better than complex" -- in this case, the complex option involves threading two RandomState instances (one for python, one for numpy) through models, agents, servers, etc., without hurting compatibility.

[lmzintgraf]

Agreed - seeding both the Python and Numpy random generator is sufficient then, and indeed simpler than passing around random state instances.

[jackiekazil]

If I followed this convo correctly, this is resolved yes?
(I just wanted to make sure there wasn't anything open before closing.)

[lmzintgraf]

Yes, I think so.

[jackiekazil]

YAY!