I’ve been puzzled about the difference between and meaning of step and time. I want to report one or the other in certain contexts, so I thought I’d dig deeper than just noticing that step is always one greater than time (in every application I’ve checked). I found the following in the list archive. Here’s what I think I understand now:

The number of steps is not the number of steppables that have been called, or the number of times that some agent’s step() function has been called. The step is incremented only once per time at which any agent is scheduled to run. So if you schedule one or more agents to run at times 0, 1, 2, 3, 4, etc., step will be incremented once for each time, and step will always be one more than time in this case.

Where time and step pull apart would be if you started scheduling agents in a pattern other than at each time = 0, 1, 2, …. For example, if agents were scheduled at times 0, 2, 4, 6, etc., but not at odd-numbered times, then time would be 2X step. Or if agents were scheduled at 0, 0.5, 1, 1.5, 2, 2.5, etc., then step would be 2X time. There are obviously other possibilities e.g. agents could be scheduled at the previous time plus a random number, and the relationship would be random but monotonic.

Subject: Re: Change in scheduling changes behavior of time vs. step?

From: Sean Luke <[log in to unmask]>

Reply-To: MASON Multiagent Simulation Toolkit <[log in to unmask]>

Date: Thu, 6 Sep 2007 21:29:42 -0400

On Sep 6, 2007, at 6:20 PM, Maciej M. Latek wrote:

> Please excuse me my ignorance, but I feel confused about definitions

> of time and step. If we obtain double time = schedule.time() and long

> step = schedule.getSteps(), there needs not to be any strict relation

> between those two (apart some positive correlation): with 10 agents

> scheduled to be activated at some randomized moments coming from

> U[0,1], querying for steps just before termination will return 10,

> while time might have not progressed much at all.

Correct. But Bruno was right, something had changed, and incorrectly

so.

Here's how it's *supposed* to work. Each iteration of the Schedule,

it does the following:

0. Identify the lowest timestamp scheduled in the Schedule.

1. Pull out all Steppables registered that timestamp.

2. Sort those Steppables as follows:

- Steppables registered with a lower ordering go first

- Ties are broken either at random, or in order that the Steppables

were originally submitted to the Schedule.

3. Move the time forward to reflect the timestamp.

4. Step each Steppable in turn

5. Throw the Steppables away

6. Increment the step counter

Thus clearly the timestamp rate of change can be totally different,

and indeed nonlinear, from the step counter. But many people

schedule things to repeat exactly per timestep, so the timestamps

appear to reflect exactly the number of steps (well, they appear to

be one off).

Sean