💾 Archived View for siiky.srht.site › petri_nets › log001.gmi captured on 2024-02-05 at 09:41:53. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-09-28)
-=-=-=-=-=-=-
siiky
2022/05/16
2022/07/23
en
I started studying Petri nets a few weeks ago, reading the Statebox monograph, and just finished today reading Ch. 2, the formalization of Petri nets and useful definitions.
At first I didn't understand the point of having places (seemingly analogous to "states" in more common automata theories) and transitions (analogous to arrows in more common automata theories) as disjunctive sets of nodes of a graph -- other than the obvious advantage of it being easier to specify several inputs/outputs of a transition. Plus, there's no current "state" (the mentioned places), very different from other more common automata theories! Not only that, but what they call a "state" is the number of tokens in each place -- what?
Once I saw Fig. 2.8 and 2.9, however, it clicked: a transition is enabled (can fire, "execute") if its input tokens can be satisfied by all its input places. So what's currently a valid "step" in the system is determined by the number of tokens in each place, just like the "current state" of other automata determines the valid next transitions. And, several transitions may execute simultaneously (as long as their executions don't prevent each other)!
Yesterday and today were good days in this regard. I now understand how Petri nets can represent concurrent/parallel behavior, because transitions are like independent "processes" (a la Erlang); and that places are more like variables, or resources, possibly shared between many transitions (processes).
There's a site referenced right at the end of Ch. 2 where you can read the basics of the basics and play with some simple nets. Unfortunately you can only play with already defined ones, you can't define new ones or change those of the website.