GithubHelp home page GithubHelp logo

Comments (8)

quaquel avatar quaquel commented on May 25, 2024

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.

  1. For backward compatibility, self.schedule.agents_by_type[Trader] should still work.
  2. Removing from the scheduler in the current version "deactives" an agent but does not remove the agent from the model.
  3. 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.

rht avatar rht commented on May 25, 2024

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.

rht avatar rht commented on May 25, 2024

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.

quaquel avatar quaquel commented on May 25, 2024

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.

Corvince avatar Corvince commented on May 25, 2024

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.

quaquel avatar quaquel commented on May 25, 2024

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.

rht avatar rht commented on May 25, 2024

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.

quaquel avatar quaquel commented on May 25, 2024

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)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.