using so far: the events we the "states" (just integers) are all considered indivisible. And this means that So the only way one state---or the update events that can be applied to it---can "causally depend" on another So what about Later on we'll see how If we explicitly show events in this case we don't see anything new:
But essentially this is because the “states” of the system---here just numbers---are effectively indivisible, and are always used in their entirety to provide the expressions to which the rule is applied. But in the string multiway system we considered above, the story is different. Because here, for example,
Token Events Graph
Single history (with a maxscan)
No tokens deduplicated.....
If the tokens were collected into states, one can tell what can be deduplicated based on isomorphism
Latest master branch:
This picks a “random” set of events:
Only one token on LHS, so no conflicts....
Full event set produces all combinatorially possible events (i.e. all reachable tokens)
(Map of all possible events) [For a given history, only a particular multipath will be chosen]
[[ there should be dangling events to indicate events that can happen, whose output tokens we have not yet generated ]]
To get evolution, run this as a Petri net (AKA token flow automaton) (occupancy flow automaton)
[ Place an indicator / marker / chip ... / occupancy ]
This is like lemmas ; i.e. a new collection of rules for specific tokens.... Eventually this maps out all tokens that can ever occur.
To reconstruct our experience as an observer: we must knit tokens into states ; we see what tokens exist at a given “moment” based on which ones have markers.....
Spacelike vs. branchlike
Tokens are spacelike separated.... [output tokens of a single event are spacelike separated]
[[ Includes all conceivable events, even ones not reachable from the init cond here ]]
Some pairs can’t appear together; as the markers “wash into” this structure, they can only get to certain places simultaneously....