feat: Implement random activation by type #1162

rht · 2022-02-20T12:07:37Z

This is the least controversial way of putting in random activation by
type into the library, by simply using RandomActivationByBreed found in
sugarscape_cg and wolf_sheep (I have checked that the schedule.py in
both examples are identical).

Some differences:

replace the term "breed" by a more general "type"
add Mypy typings

If people want to get logging specific to one agent type, they can
either

loop through all agents, and filter by their type
loop through model.scheduler.agents_by_type[type_class]

We don't support agents that change their type, because in Python, you
can't have an object that changes its intrinsic type over its lifetime.

There could perhaps be a RandomActivationByAttribute, that groups
agents by their attributes, which may change throughout the course of a
simulation.

rht · 2022-02-20T12:09:30Z

@EwoutH check this PR out. It's much less controversial than #1142, and so require fewer points to be discussed for a consensus.

codecov · 2022-02-20T12:12:19Z

Codecov Report

Merging #1162 (61f8539) into main (d346c48) will increase coverage by 0.07%.
The diff coverage is 93.33%.

❗ Current head 61f8539 differs from pull request most recent head 9e60191. Consider uploading reports for the commit 9e60191 to get more accurate results

@@            Coverage Diff             @@
##             main    #1162      +/-   ##
==========================================
+ Coverage   89.28%   89.36%   +0.07%     
==========================================
  Files          19       19              
  Lines        1269     1297      +28     
  Branches      259      264       +5     
==========================================
+ Hits         1133     1159      +26     
  Misses        100      100              
- Partials       36       38       +2

Impacted Files	Coverage Δ
mesa/time.py	`94.73% <93.33%> (-0.79%)`	⬇️

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 d346c48...9e60191. Read the comment docs.

EwoutH · 2022-02-20T12:59:34Z

From an architecture perspective I agree this is the right course of action and a nice first step to full multiple agent types support.

Haven't looked closely at the exact implementation, I can do that tomorrow if you want (however I think I'm not going to find much).

EwoutH

Thanks for the PR, I added two comments, one about custom step orders and a documentation nitpick.

EwoutH · 2022-02-22T08:29:15Z

mesa/time.py

+        agent_class: Type[Agent] = type(agent)
+        del self.agents_by_type[agent_class][agent.unique_id]
+
+    def step(self, by_type: bool = True) -> None:


Can we add something like an optional order input that allows to input the order in which the agent types are executed? Maybe that input could be either the string "reversed" to loop through reversed(self.agents_by_type) or a custom list with agent types.

I suggested a code snipped below.

That's a good idea. Also good to compare with the API of NetLogo, MASON, and Agents.jl.

Agents.jl has 2 params: shuffle_types, shuffle_agents: https://github.com/JuliaDynamics/Agents.jl/blob/5d1182dc7dd80001492c27333898c50462bdb20e/src/submodules/schedulers.jl#L92-L99.

NetLogo' leaves the order up to the user's implementation with ask [breed]: https://github.com/NetLogo/models/blob/2bfb84e92b367f312e397338e27a4c85889f13a0/Sample%20Models/Biology/Wolf%20Sheep%20Predation.nlogo#L57-L75.

Maybe we can allow three strings for order: regular (default), reverse and shuffle, and a list of agent types.

Can't find a wolf-sheep model for MASON. It is also N/A in https://juliadynamics.github.io/Agents.jl/stable/comparison/.

EwoutH · 2022-02-22T08:29:19Z

mesa/time.py

+        if by_type:
+            for agent_class in self.agents_by_type:
+                self.step_type(agent_class)
+            self.steps += 1
+            self.time += 1
+        else:
+            super().step()


Suggested change

if by_type:

for agent_class in self.agents_by_type:

self.step_type(agent_class)

self.steps += 1

self.time += 1

else:

super().step()

if by_type:

if order == "regular"

for agent_class in self.agents_by_type:

self.step_type(agent_class)

if order == "reverse"

for agent_class in reversed(self.agents_by_type):

self.step_type(agent_class)

else:

for agent_class in order:

self.step_type(agent_class)

self.steps += 1

self.time += 1

else:

super().step()

mesa/time.py

rht · 2022-02-22T11:25:34Z

2 points that need consensus:

First, the by_type boolean is not necessary, and complicates the API without much benefit. If the user wants the regular RandomActivation, they can simply use RandomActivation.

Second, the step order of each type. I can't think of a use case when a modeler wants to do the reverse of the original insertion order of the agent types during the model initialization. I think a more general solution is to have an argument called agent_type_sequence, with a type of Optional[Sequence[Type[Agent]]]. The modeler can specify any order they want.

EwoutH · 2022-02-22T11:39:45Z

First, the by_type boolean is not necessary, and complicates the API without much benefit. If the user wants the regular RandomActivation, they can simply use RandomActivation.

Agreed, lets drop the by_type boolean.

Second, the step order of each type. I can't think of a use case when a modeler wants to do the reverse of the original insertion order of the agent types during the model initialization. I think a more general solution is to have an argument called agent_type_sequence, with a type of Optional[Sequence[Type[Agent]]]. The modeler can specify any order they want.

A custom order like Optional[Sequence[Type[Agent]]] is indeed the most important. You can of course implement reversing or shuffling the order yourself, but it might be nice to just very quickly be able experiment and iterate with it. But maybe it complicated the API too much.

rht · 2022-02-23T01:47:51Z

Shuffling may be in demand, but I'm not sure about the reverse order.

rht · 2022-02-24T00:38:15Z

I forgot to say that I removed the unnecessary by_type arg, and added shuffle_types and shuffle_agents. At least, featurewise, it is the same as Agents.jl. I'm tempted to say that adding custom types order argument can be deferred to a separate PR. We can always iterate on this activation before the next release.

rht · 2022-02-24T07:50:23Z

Bump. @tpike3 thoughts so far? I think this is ready to merge. Once you ack, I will squash and merge. After that, I will port my implementation of Sugarscape with trading ({G1}, {M, T}) and make a PR for it.

tpike3 · 2022-02-24T11:07:33Z

Dang, I am way behind... @rht and @EwoutH this is awesome. This is the implementation I am most familiar with so am ready to merge and I agree the terms (e.g type vs breed and shuffle) are the preferred.

We can always iterate on this activation before the next release.

To @rht's point thinking future customizations in new PRs before the next release ... I will concur and support two additional features in later PRs

I concur on the ability for a customized type order. To me the ability to customize is critical as growing simulation in different ways is often more insightful than the actual results
If I am reading it right since I did not get a chance to play around with the code but don't want to hold up progress, we should have the option to run all agents in a random order regardless of type.. in some models it will matter and is supporting evidence to Lorenz's seminal work on Deterministic Nonperiodic Flow.

rht · 2022-02-24T11:17:48Z

we should have the option to run all agents in a random order regardless of type

You can do this with:

if fully_random:
    self.schedule = RandomActivation(self)
else:
    self.scheduler = RandomActivationByType(self)

And so we can keep the API minimal.

tpike3 · 2022-02-26T12:09:16Z

we should have the option to run all agents in a random order regardless of type

You can do this with:
if fully_random:
    self.schedule = RandomActivation(self)
else:
    self.scheduler = RandomActivationByType(self)
And so we can keep the API minimal.

@rht That is perfect! I didn't even think of that...so obvious I looked right over it. Squash and merge at your discretion

This is the least controversial way of putting in random activation by type into the library, by simply using RandomActivationByBreed found in sugarscape_cg and wolf_sheep (I have checked that the schedule.py in both examples are identical). Some differences: - replace the term "breed" by a more general "type" - add Mypy typings If people want to get logging specific to one agent type, they can either - loop through all agents, and filter by their type - loop through model.scheduler.agents_by_type[type_class] We don't support agents that change their type, because in Python, you can't have an object that changes its intrinsic type over its lifetime. There could perhaps be a `RandomActivationByAttribute`, that groups agents by their attributes, which may change throughout the course of a simulation.

rht · 2022-02-26T12:37:43Z

Yay! Can't wait for the sugarscape variations being in the repo (at least the ones that doesn't require Multi-level Mesa).

Tracks agents in the model with a defaultdict. This PR adds a new `agents` dictionary to the Mesa `Model` class, enabling native support for handling multiple agent types within models. This way all modules can know which agents and agents type are in the model at any given time, by calling `model.agents`. NetLogo has had agent types, called [`breeds`](https://ccl.northwestern.edu/netlogo/docs/dict/breed.html), built-in from the start. It works perfectly in all NetLogo components, because it's a first class citizen and all components need to be designed to consider different breeds. In Mesa, agent types are an afterthought at best. Almost nothing is currently designed with multiple agent types in mind. That has caused several issues and limitations over the years, including: - projectmesa#348 - projectmesa#1142 - projectmesa#1162 Especially in scheduling, space and datacollection, lack of a native, consistent construct for agent types severely limits the possibilities. With the discussion about patches and "empty" this discussion done again. You might want empty to refer to all agents or only a subset of types or single type. That's currently cumbersome to implement. Basically, by always having dictionary available of which agents of which types are in the model, you can always trust on a consistent construct to iterate over agents and agent types. - The `Model` class now uses a `defaultdict` to store agents, ensuring a set is automatically created for each new agent type. - The `Agent` class has been updated to leverage this feature, simplifying the registration process when an agent is created. - The `remove` method in the `Agent` class now uses `discard`, providing a safer way to remove agents from the model.

Tracks agents in the model with a defaultdict. This PR adds a new `agents` dictionary to the Mesa `Model` class, enabling native support for handling multiple agent types within models. This way all modules can know which agents and agents type are in the model at any given time, by calling `model.agents`. NetLogo has had agent types, called [`breeds`](https://ccl.northwestern.edu/netlogo/docs/dict/breed.html), built-in from the start. It works perfectly in all NetLogo components, because it's a first class citizen and all components need to be designed to consider different breeds. In Mesa, agent types are an afterthought at best. Almost nothing is currently designed with multiple agent types in mind. That has caused several issues and limitations over the years, including: - #348 - #1142 - #1162 Especially in scheduling, space and datacollection, lack of a native, consistent construct for agent types severely limits the possibilities. With the discussion about patches and "empty" this discussion done again. You might want empty to refer to all agents or only a subset of types or single type. That's currently cumbersome to implement. Basically, by always having dictionary available of which agents of which types are in the model, you can always trust on a consistent construct to iterate over agents and agent types. - The `Model` class now uses a `defaultdict` to store agents, ensuring a set is automatically created for each new agent type. - The `Agent` class has been updated to leverage this feature, simplifying the registration process when an agent is created. - The `remove` method in the `Agent` class now uses `discard`, providing a safer way to remove agents from the model.

rht force-pushed the main branch from ed37b7d to bbb190b Compare February 20, 2022 12:11

rht force-pushed the main branch from 3a148f9 to 5d4d255 Compare February 20, 2022 12:20

EwoutH reviewed Feb 22, 2022

View reviewed changes

rht commented Feb 22, 2022

View reviewed changes

mesa/time.py Outdated Show resolved Hide resolved

rht force-pushed the main branch from 5d4d255 to 34a03f6 Compare February 22, 2022 11:32

rht force-pushed the main branch from f425cea to 61f8539 Compare February 23, 2022 05:19

tpike3 added this to the Quartzsite (next release) milestone Feb 23, 2022

rht mentioned this pull request Feb 24, 2022

Add RandomActivationByBreed from Sugarscape example to available schedulers in time.py #900

Closed

rht force-pushed the main branch from 61f8539 to 9e60191 Compare February 26, 2022 12:36

rht merged commit b622d1d into projectmesa:main Feb 26, 2022

rht mentioned this pull request Feb 26, 2022

RandomActivationByType: Allow custom execution order for the agent types #1175

Closed

tpike3 mentioned this pull request Mar 20, 2022

PoC: Multiple-agent types scheduling and datacollection #1142

Closed

9 tasks

EwoutH mentioned this pull request Nov 30, 2023

Native support for multiple agent types #1894

Merged

feat: Implement random activation by type #1162

feat: Implement random activation by type #1162

Uh oh!

Conversation

rht commented Feb 20, 2022

Uh oh!

rht commented Feb 20, 2022

Uh oh!

codecov bot commented Feb 20, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

EwoutH commented Feb 20, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

EwoutH left a comment

Choose a reason for hiding this comment

Uh oh!

EwoutH Feb 22, 2022

Choose a reason for hiding this comment

Uh oh!

rht Feb 22, 2022

Choose a reason for hiding this comment

Uh oh!

rht Feb 22, 2022

Choose a reason for hiding this comment

Uh oh!

rht Feb 22, 2022

Choose a reason for hiding this comment

Uh oh!

EwoutH Feb 22, 2022

Choose a reason for hiding this comment

Uh oh!

rht Feb 22, 2022

Choose a reason for hiding this comment

Uh oh!

EwoutH Feb 22, 2022

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

rht commented Feb 22, 2022

Uh oh!

EwoutH commented Feb 22, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rht commented Feb 23, 2022

Uh oh!

rht commented Feb 24, 2022

Uh oh!

rht commented Feb 24, 2022

Uh oh!

tpike3 commented Feb 24, 2022

Uh oh!

rht commented Feb 24, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tpike3 commented Feb 26, 2022

Uh oh!

rht commented Feb 26, 2022

Uh oh!

Uh oh!

codecov bot commented Feb 20, 2022 •

edited

Loading

EwoutH commented Feb 20, 2022 •

edited

Loading

EwoutH commented Feb 22, 2022 •

edited

Loading

rht commented Feb 24, 2022 •

edited

Loading