Remove "model" from agentset initialization

[Corvince]

What's the problem this feature will solve?
I just noticed that AgentSet is still initialized with a ´modelinstance. I think this is unnecessary, since the only use case is retrievingmodel.random. I think I remember some discussion about random` by @quaquel regarding its use in agentset. But before we declare AgentSet fully stable for 3.0 we should probably revisit this issue. Without model AgentSet will be completely independent, simplifying testing et al.

[quaquel]

I think the way we handle this in the grid spaces is the way forward for now. Instead of passing model, there you need to pass random explicitly. The main drawback is that if you run multiple experiments without re-initializing the model class, you can't explicitly control random. In #2021, I played with other possible solutions but got a bit stuck (see e.g., this comment and then mainly point 3.).

[EwoutH]

Might be interesting how other scientific libraries approach this. Have you read SPEC 7? https://scientific-python.org/specs/spec-0007/

[rht]

I see access to model as a catch-all object where you can retrieve any globally accessible content (clock, steps, global average temperature, total money supply, etc). If you localize access to just the RNG, then:

1. More RAM on the mental model: User will have to remember that AgentSet only has access to the RNG instead of a less specific model, and another set of rules for other Mesa components
2. In case in the future you want AgentSet to access another global content (could be the system clock), you have to modify AgentSet's list of public attributes to include this object.

[Corvince]

Interesting viewpoint. I think there is some truth in that, but I am still in favor of keeping the API surface minimal. I don't understand your first point of user RAM. Users should not have to think about what agentset has access to and what not, because why would you want to access the model through agentset (as a user).

I agree that "model" is a catch-all object, but for that reason it shouldn't be exposed completely to every subcomponent. This only creates circular dependencies, which isn't a problem per se, but can lead to nasty bugs and surprising behavior.

Also I would immediately make random optional with the hope to deprecate it later and only be dependent on agents. So instead of adding more dependencies later I would strive to remove all dependencies, this moving in the opposite direction

[quaquel]

There are a few additional reasons to explicitly pass random.

1. Explicit is better than implicit. In this way, users know which rng is being used inside AgentSet. This point can be generalized: explicitly pass the rng wherever needed (so also in Agent, ContinouosSpace, etc.).
2. Explicitly passing the RNG gives the user more control over what is happening. In The handling of random numbers #1981 and Centralization of the seeded random number generator #2021, I have discussed some of this before, but for variance reduction, it can be very useful to explicitly control, e.g., which seed is used for the random activation of agents. At the moment, this is not easy to do and requires the user to understand the inner workings of various MESA classes.

In short, I am in favor of explicitly passing random to the AgentSet as an optional keyword argument. I would do the same in all other places where a class depends on the RNG. This can, for now, be in addition to passing model, where if random=None, the class falls back to using model.random.

[quaquel]

I just ran into another reason to make this change. I was experimenting with changing CellCollection.agents from returning an iterable to returning an AgentSet. While moving mesa-examples to grid spaces, I frequently missed agentset funtionality when doing operations on collections of neighboring agents. Because currently AgentSet requires model (just to have access to the central rng), I cannot easily test the performance impact of this simple change.

[quaquel]

closed via #2350