You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently running a simulation with a seed produces a deterministic output. Running the same code but inserting simulation events that do nothing will produce a different deterministic output. I was expecting the output from the two simulations to be the same.
It turns out that because the queue is implemented in terms of a heap it is not stable (in terms of sorting order). For example, if events A, B and C are scheduled to run at time t they may be executed in the order BCA. If an empty event E is also scheduled at t then that order may change to CAEB, essentially CAB.
This was unexpected behaviour, as I didn't expect asking for an event that does nothing to be called to change the output of the simulation.
The solution to this is to add a counter that records the number of events scheduled and assign each event a unique counter. The event counter would be used in the heap comparison to ensure events added first would be called first.
However, I'm not sure if this is a bug that needs fixing, or if it is just something worth documenting.
The text was updated successfully, but these errors were encountered:
Currently running a simulation with a seed produces a deterministic output. Running the same code but inserting simulation events that do nothing will produce a different deterministic output. I was expecting the output from the two simulations to be the same.
It turns out that because the queue is implemented in terms of a heap it is not stable (in terms of sorting order). For example, if events A, B and C are scheduled to run at time t they may be executed in the order BCA. If an empty event E is also scheduled at t then that order may change to CAEB, essentially CAB.
This was unexpected behaviour, as I didn't expect asking for an event that does nothing to be called to change the output of the simulation.
The solution to this is to add a counter that records the number of events scheduled and assign each event a unique counter. The event counter would be used in the heap comparison to ensure events added first would be called first.
However, I'm not sure if this is a bug that needs fixing, or if it is just something worth documenting.
The text was updated successfully, but these errors were encountered: