A couple of previous posts (here and here) presented three Python-based alternatives for expressing process or agent-based behavior that takes place over (or blocks for) simulated time: generators, greenlets and tasklets. So which approach is best? There are (at least!) three factors to consider: Ease of use – ease-of-coding, expressiveness, maintainability. Eco-system factors – compatibility… (read more)
My last two posts (here and here) introduced three Python-based alternatives for expressing simulation process or agent-based behavior that takes place over (or blocks for) simulated time: Generators, a core feature of the Python language Greenlets, provided by the third-party greenlet Python extension package Tasklets, provided by two standalone Python distributions, Stackless Python and PyPy… (read more)
In my last post, I discussed Python’s built-in support for coroutines via generators. While we can use generators to implement simulation process code, the essentially stackless nature of generator functions limit their expressiveness and power. Once we venture beyond Python’s standard library, there are a couple of other options that facilitate completely stackful coroutines: greenlets… (read more)
As I mentioned here, coroutines provide a means to express processes occurring over simulated time in a pretty natural way. Python has one built-in mechanism, the generator, which enables coroutine-like functionality. Two other flavors of coroutine, greenlets and tasklets, are implemented by third-party packages; these will be discussed in a later post.
There are simulation tools that require you to define your model entirely in the form of a program, or source code – whether via an existing general purpose programming language or a special purpose simulation language. Other tools require you to define models totally through data: graphical, tabular, or some combination of the two. This… (read more)
I started my career in simulation building process-based models. That is, of course, a classic approach to simulation modeling, and it generally worked pretty well for the manufacturing applications that I was involved with. Fabrication and assembly work flows to often map very nicely to processes in a simulation model. Except when they don’t.
As I mentioned in my introductory post, I started down this road as a software engineer turned simulation practitioner, who thought he might be able to build a better – or at least different – mousetrap. Which naturally leads to the question: what am I trying to do differently? You might be tempted to translate… (read more)
