You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Instead of writing vectorized operations of property layer, users could write step() functions for individual cells, similar to how NetLogo handles its patches, or how Mesa-Geo currently manages its Cell class. In a way Cells act like agents with changing states, while they can't move.
However, it might be easier to write in certain cases, especially when it's difficult to vectorize model logic.
Describe the solution you'd like
Perhaps have something similar to how AgentSet activites agents through its do, shuffle_do and other methods, in CellCollection class to activate cells' step() and other functions. A difference could be that agents are indexed by unique_id, whereas cells are indexed by (x, y) or (row, col) indices. Both AgentSet and CellCollection already have a select() method with similar API:
Hence I think that a property layer can be viewed as a collection of its cells, i.e., a CellCollection. For example, AgentSet has an aggregation function:
There are set_cells, select_cells and modify_cells methods in property layer, although here cells do not link to the Cell class that is mainly agent containers with neighborhood definitions.
The text was updated successfully, but these errors were encountered:
This is already possible in the new style cell space by using a FixedAgent.
I would be hesitant to make a cell, which encapsulates connection and has a collection of agents, itself an agent or even agent-like. To me, this violates the separation of concerns.
What's the problem this feature will solve?
Instead of writing vectorized operations of property layer, users could write
step()
functions for individual cells, similar to how NetLogo handles its patches, or how Mesa-Geo currently manages its Cell class. In a way Cells act like agents with changing states, while they can't move.For example in our urban growth gis example, users can define how individual Cell should update itself: https://github.com/projectmesa/mesa-examples/blob/0c93dc50f2c9cbcaf1c98287c6beca85fa6c6233/gis/urban_growth/urban_growth/space.py#L49
This is much slower than vectorized operations on the entire property layer at once: https://github.com/projectmesa/mesa-examples/blob/0c93dc50f2c9cbcaf1c98287c6beca85fa6c6233/examples/conways_game_of_life_fast/model.py#L43-L47
However, it might be easier to write in certain cases, especially when it's difficult to vectorize model logic.
Describe the solution you'd like
Perhaps have something similar to how AgentSet activites agents through its
do
,shuffle_do
and other methods, in CellCollection class to activate cells'step()
and other functions. A difference could be that agents are indexed byunique_id
, whereas cells are indexed by (x, y) or (row, col) indices. Both AgentSet and CellCollection already have aselect()
method with similar API:mesa/mesa/agent.py
Lines 200 to 206 in 393f6a0
mesa/mesa/experimental/cell_space/cell_collection.py
Lines 113 to 117 in 393f6a0
Similarly for property layer:
mesa/mesa/experimental/cell_space/property_layer.py
Line 166 in 393f6a0
Hence I think that a property layer can be viewed as a collection of its cells, i.e., a CellCollection. For example, AgentSet has an aggregation function:
mesa/mesa/agent.py
Line 384 in 393f6a0
and similarly for property layer:
mesa/mesa/experimental/cell_space/property_layer.py
Line 186 in 393f6a0
There are
set_cells
,select_cells
andmodify_cells
methods in property layer, although herecells
do not link to theCell
class that is mainly agent containers with neighborhood definitions.The text was updated successfully, but these errors were encountered: