Potential inconsistencies among <all> nodes with symmetries

[LMCuber]

This question is about the BasicSnake.xml file when run.
When processing it frame by frame, the first <all> node creates four pixels adjacent to the white center dot. I have two questions about this:

1. I assume that the input is static in between different input patterns which are symmetries of each other. This is because otherwise the situation below could happen, where the first match creates a situation where the second match (a symmetry of DBB) is matched:

But this situation never happened in the online viewer of MarkovJunior.
Instead, this is the next step:

But, this means that, in the second markov node, the PGG->DBP all node should in theory create multiple snake heads, since this pattern matches across multiple symmetries (top down left right etc), since I am working on a Python port of this amazing project.
So can someone help me understand all nodes better, and how they differ from prl? And help me understand this specific scenario. I hope that my question is clear enough.

[mxgmn]

Hi!

First, I think you made a typo: PGG->DBP does not create snake heads, it shortens snake's tail.

But your question is still valid for RBD->GGR - why does this not create multiple snake heads, but DBB->**D propagates the grid in all directions?

The reason is that all node

chooses a maximal subset of non-conflicting matches.

And a new GGR conflicts with RBD because G!=R. But **D does not conflict with DBB because the wildcard symbol * does not conflict with anything.

[LMCuber]

Hi! Thanks for the reply. This is a quote from the documentation:

The <all> node takes a set of rewrite rules and applies all possible rewrites of all its rules in sequence, all within one step. The sequence in which all possible rewrites is performed is random, and an earlier rewrite in the sequence might prevent later rewrites from taking place.

I know understand that only chooses non-conflicting matches. I still have follow up questions:

1. Does the DBB->**D step match against a static state or not, given that it doesn't conflict? This is about the first image in my previous post.
2. Additionally, wouldn't the D from **D conflict since D!=B (last B of DBB)? What determines what is a conflict and what is not?
3. According to your answer, I understand that only one head gets lengthened, because the heads in other directions have conflicts. But the snippet above says that the rules can overwrite each other. What does that mean? And how does this differ from parallel nodes?

Thank you.

[kaya3]

Here's my understanding:

1. Rules are applied atomically, not recursively within one step, so DBB -> **D is not applied when the D in the input pattern was put there by a rewrite which occurs in the same step. Think of the <all> rule as applying a random maximal set of non-overlapping rewrites simultaneously - each rewrite is based on the state of the grid at the start of the current time step. Another way of looking at it is that an <all> node can never write something to any individual grid location that a <one> node with the same rules wouldn't be able to write to the same location within one time step.
2. A conflict occurs when a rewrite would write to a grid location in the same step as that location is written to by another rewrite. (Even if both rewrites would put the same colour there, it still counts as a conflict.) A * in an output pattern means nothing is written to that location, so it does not cause a conflict.
3. I'm not sure what you mean by "rules can overwrite each other" - that doesn't appear in the documentation which you quoted. The documentation says that one rewrite "might prevent later rewrites from taking place", which means that if two rewrites can both be applied from the grid's state at the start of the current time step, but the rewrites would conflict (i.e. write to the same location), then the first rewrite prevents the second from taking place.

The semantics for <prl> nodes are a bit harder to describe; essentially they apply all possible rewrites, still based on the grid state at the start of the current time step, even if some would "conflict", and any conflicting rewrites are performed in a random order. Personally, I recommend only using <prl> with rules like B -> D where rewrites cannot overlap, or with rules like BB -> DD where if two rewrites write to the same grid location then they both write the same colour there. In those cases, it cannot make a difference what order the rewrites are applied in.