Automatically increasing Step counter by default

[EwoutH]

This discussion is split of from

• model: Automatically increase steps counter #2223

Background

Currently, Mesa models require manual incrementing of the step counter. Only if a scheduler is used, is model.scheduler.steps updated automatically, model._steps isn't. Calling _advance_time() currently fulfills this function.

The proposal is to increase model._steps automatically with each time model.step() method is called.

Key Points to Consider

• Automatic incrementing could simplify model creation, especially for beginners.
• However, it might reduce flexibility for advanced users who need custom step behavior.
  • Therefore, should it be possible to disable or modify the automatic incrementing?
• How would this change affect existing models?
• Consider models with complex step logic or those using custom schedulers.

Examples

Current approaches:

class MyModel(Model):
    def step(self):
        self._steps += 1
        # Model logic here

or

class MyModel(Model):
    def step(self):
        self._advance_time()
        # Model logic here

Proposed approach:

By default, the step is increased by 1.

class MyModel(Model):
    def step(self):
        # Step counter automatically incremented
        # Model logic here

This can be disabled, by setting step to False.

class MyModel(Model):
    def step(self, step=False):
        # Step counter not increased
        # Model logic here

A potential implementation is available in #2223.

Questions for Discussion

• Is automatic step incrementing a necessary feature for Mesa?
• If implemented, should there be a way to opt-out or customize the behavior?
• How might this affect Mesa's educational value for teaching simulation concepts?

[quaquel]

Is automatic step incrementing a necessary feature for Mesa?

Yes, having a simple automatic counter for the number of times model.step has been called it useful.

If implemented, should there be a way to opt-out or customize the behavior?

This question is too broad. I would say that optional advanced time management is desirable (and available in the simulator classes).

How might this affect Mesa's educational value for teaching simulation concepts?

Time representation is critical in teaching simulation (and in many ABM courses not handled well IMO).

[EwoutH]

This question is too broad.

What about just having the opt-out, like step=False or maybe even passing a flag in the model init?

Then by default, it just increases. For teaching very clear. Don't have to mention that there are other options in Mesa. But you can disable it (and that will always be a conscious choice by the modeller).

[EwoutH]

I think this should be a very nice thing to have, by default. It should be disable-ble when users want to do it manually.

[quaquel]

Depends on implementation details of automatic counting and exactly what you want to achieve. In the simplest case, just do model.step -= 1. For more advanced cases, overwrite e.g., _wrapped_step. Similar to the discussion about time, I just don't see a use case for not incrementing step automatically which cannot be implemented in a way fully under the control of the user. That is, keep the default functionality of mesa simple and confined (allways increment step with 1 when model.step() is called). My suggestion would be to do the _wrapped_step as you came up with (clever trick by the way that solves the super/annotation discussion), but don't add the optional keyword argument. If, in the future, a clear use case for this functionality emerges, we can allways add it later.

[EwoutH]

model.step -= 1

Isn't just being able to pass step(step=False) (or step(increase=False)) way cleaner?

We can also make it a model initialisation variable, that you can optionally pass Model.__init__(increase_step=False), which by default is True.

clever trick by the way

Thanks, was took some tinkering to get is working while being user-overwritable. Appreciated!

[quaquel]

Isn't just being able to pass step(step=False) (or step(increase=False)) way cleaner?

For me, this is not so much about what is cleaner. I fail to see a usecase for the boolean in the first place. If there is one, it is easy for a user to get it working along the lines I suggested (or whatever is needed). If the use case is common enough, we can add this feature at some later stage.

[EwoutH]

I fail to see a usecase for the boolean in the first place.

1. Backwards compatibility. Currently we're not increasing the step counter on model.step. Let's allow our users to retain that behaviour. You don't know what kind of custom code they've build on top of it.
2. Flexibility. You can now increase the step counter in another place if you want to deviate from the convention.
3. Hackability. You know we use step for the datacollector, visualisation and stuff. You can now "misuse" that to let the datacollector of visualisation do other stuff.

Let me be clear: We are going to build the datacollector and stuff around the assumption of an increasing step counter. But it allows you to take control over when and how it's increased, if you want that.

[Corvince]

1. I think this point is strange, since we are breaking models either way. If you messed with _steps previously, you have to adapt anyway. As @quaquel already said you can simply call model.steps -= 1 to "revert" this change. Since we are already in hacky territory this is not too bad.
2. But we just want to count the number of times model.step is called. If you want to do something else, just use another variable
3. Thats always possible

I think we are severly overcomplicating this. I think we all agree that counting the number of times model.step is called is useful. Lets just do just that and leave everything else to other variables.

[DrEntropy]

Since PR2223 is closed, is this the best place to continue this discussion?

I really like the idea of moving away from schedulers or making them more optional. I have no strong preference toward advancing time at the beginning or the end of the Model.step() function. Either way this would have to be documented clearly. Why is requiring the user to call _advance_time() (or another tick type function as in netlogo) considered unappetizing? This would give the user full control of when time advances. (And also would require documentation of course.)

[rht]

self._advance_time() being renamed to self.tick() (if the name is too unwieldy for daily use) seems fine to me. It keeps the underlying implementation of the Model class simple without the monkey patching in #2223. And with the API being explicit, it is more customizable and composeable with other libraries, should user want to e.g. do ABM-RL stuff. On the other hand, with monkey patching the step, it is a modified as a private method that users aren't meant to modify.

[EwoutH]

We're having a call on this subject. Note that some of the discussion continues there:

• Call on time integration in Mesa (Tuesday 27 aug 14:30 CEST) #2247