Comments (8)
I am not familiar with the inner details of Sugarscape. So, I don't fully understand what is happening. Both the code you linked to and the shown code take a set of agents and shuffle them. Neither calls another method.
The key difference is that the current code takes the agents from the scheduler, while the new code takes the agents from the model.
- For backward compatibility,
self.schedule.agents_by_type[Trader]
should still work. - Removing from the scheduler in the current version "deactives" an agent but does not remove the agent from the model.
- It seems you are now trying to mix new and old functionality. But new functionality insists on the use of
agent.remove()
. So, I don't think this is a bug but actually desired behavior. We probably should do more to communicate this clearly.
from mesa.
model.get_agents_of_type()
is a public API, and users wouldn't expect that it can only be used when schedulers are not present and agent.remove()
. This is somewhat non-local, that you have to be aware of this gotcha, even if there is a clear documentation for it.
I'd say, agents_by_type
needs to be renamed _agents_by_type
, at least until the no-scheduler version of the code has become the standard way of doing activation.
from mesa.
The other alternative that I didn't say, but would make sense given the trade off, is to sacrifice the feature of having multiple schedulers by doing agent.remove()
in the scheduler's remove
method. get_agents_of_type
/agents_by_type
usage is much more common than having multiple schedulers, and should be preferred.
from mesa.
model.get_agents_of_type() is a public API, and users wouldn't expect that it can only be used when schedulers are not present and agent.remove().
I am not sure whether I agree with this. I think conceptually it is fine to say agent.remove
removes the agent from the model, while scheduler.remove
removes the agent from the scheduler but not from the model.
from mesa.
I am also not sure what exactly the problem is here, but from the title I don't see how this wouldn't be expected behavior. Why should agents be removed from model.agents if they are removed from schedule and grid? This just represents passive agents, so there is even a use case for this behavior. Think of a board game where playing pieces are taken of the board, but might reappear later.
The inverse could be expected: Removing an agent from model.agents should also remove it from the scheduler and the grid. So in the example above, taken completely out of the game. And I think thats also the intention of using weakrefs.
from mesa.
Exactly. The reason for using weakrefs in AgentSet was to make it easy to remove agents from everywhere by just calling agent.remove
. Clearly this vision is not yet fully realized because we don't use agentset or weakrefs yet in the spaces.
And, of course, we are discovering various performance drawbacks of weakrefs, which we then try to work around to maintain performance.
from mesa.
Once again,
The users would expect the 2 methods to give the same outcome, but will be tripped by the new requirement of agent.remove().
Please see it from the user perspective. It may be obvious to Mesa developers because you implemented the feature and the cause of the examples tests failing had been debugged during #1942. But the user who using the new method get_agents_of_type
wouldn't necessarily know the inner working and the nuances.
from mesa.
I agree with you on this point which is why we need to carefully check the documentation to make clear what the behavior is of these different forms of removing agents.
from mesa.
Related Issues (20)
- Make experimental cell spaces work with PropertyGrid HOT 1
- Make connections in experiment cell spaces named
- Question/request HOT 4
- Broken Links in Mesa Documentation
- Continuous space not visualizing (boid flockers model) HOT 1
- Use a Sparse data structure for (Multi)Grid
- Batch_Run begins, performs no iterations, no errors, writes empty .csv file. Help? HOT 1
- Inconsistency in get_neighbors Method Parameters for NetworkGrid in Mesa 2.2.4 HOT 1
- agent_portrayal isn't changing color of agent in Jupyter visualization HOT 1
- move_agent_to_one_of is deterministic when pos has multiple closest choices and selection="closest"
- Build docs for experimental modules (including cell space)
- Fix error in failing flocking benchmark
- Issue with data collection of PropertyLayer objects HOT 6
- batch_run stalls, no progress
- JupyterViz: Visualize new Cell Space
- JupyterViz: Visualize PropertyLayers
- Enhance Visualization Tutorial and use of new visualizations with Mesa Examples
- Move from Colab to jupyterlite for tutorials HOT 1
- Make Seminal Model Page
- huggingface hub integration HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mesa.