search

adamamer20 / mesa-frames

Extension of mesa for performance and scalability
https://adamamer20.github.io/mesa-frames/api
MIT License
6 stars 1 forks source link

Refactoring mesa.space #6

Open adamamer20 opened 5 months ago

rht commented 6 days ago

Can't wait for this feature. This is the only blocker to me implementing mesa-frames version of Sugarscape constant growback. It boils down to implementing the move within the space: https://github.com/projectmesa/mesa-examples/blob/668eb974ffdaaf2d20ca9a5fd7ba828f1b043426/examples/sugarscape_cg/sugarscape_cg/agents.py#L40-L61. Only eat and die part of the step can be DF-vectorized as of now.

adamamer20 commented 6 days ago

Can't wait for this feature. This is the only blocker to me implementing mesa-frames version of Sugarscape constant growback. It boils down to implementing the move within the space: https://github.com/projectmesa/mesa-examples/blob/668eb974ffdaaf2d20ca9a5fd7ba828f1b043426/examples/sugarscape_cg/sugarscape_cg/agents.py#L40-L61. Only eat and die part of the step can be DF-vectorized as of now.

Let me ensure I understood correctly the issue. The available spaces are the neighborhood spaces which are not occupied. The problem is that in the traditional Sugarscape model, since the step is sequential for agents, there is a race condition. If parallelized, we could have two agents that select the same space at the same time. What if we were to run an iteration across all agents, select randomly one of the agents which have a duplicate neighborhood, and then run the choice algorithm again on the agents with duplicates that are not selected? This approach is not as efficient as parallelizing everything at once, but it shouldn't require many iterations to resolve conflicts.

rht commented 5 days ago

Yeah, that (update the position in parallel, then do tie-breaking) is the method used in the FLAME 2 implementation of Sugarscape instantaneous growback (i.e. simpler version of constant growback, where the sugar grows to max value in the next step right after being consumed; constant growback has a growing rate), in figure 6. Here is their code.

adamamer20 commented 5 days ago

I see, that's very interesting that it's so recent! Do you think tie-breaking should be left to the user or handled by the library? Depending on the model, it can be either very simple or very complex to handle tie-breaking, similar to the challenge of vectorizing user-defined functions. Perhaps it would be better to include a section in the documentation on how to deal with race conditions?

rht commented 5 days ago

I think the basic version move_to_empty and move_to_empty_neighborhood should be handled by the library. They can be a starting point for users who want to implement more complex move logic. The former is used by the Schelling model. But the Boltzmann wealth model and Wolf sheep simply use moving to anywhere within the neighborhood.