Again, it's something that you can implement directly on your
synchronous model, so it's not really a problem in term of definition.
It's just a practical way you would of course
in your computer use a more efficient way to do this asynchronous updating.
Finally, you can say that you want a rule to be different
on different position of your space.
For instance, you would say that the left part of your space is updated
according to rule one, and the right part of the space to rule two.
And again,
it's enough to have an extra state which tells which rule you apply on which cell.
So again, it's not impossible with the definition I gave you before.
So when it turns to implementing a cellular automaton in a computer,
you have several ways.
So one is called the on-the-fly calculation, so for each cell,
at each time step you just compute the rule explicitly.
So for my parity rule I explain to you before,
you just have to do the sum of your four neighbors.
I use this sign, the plus with a circle around,
to say that's it's the plus modulo 2, so it will actually give me a result which
is 0 or 1, according to the sum is even or odd.
So, that's a way to compute just by a mathematical formula that you
keep repeating.
But since, actually you have only a finite set of possible configuration.
So your four neighbors, there are four neighbors here,
they can only take 16 possible different configurations.
So maybe you wanna encode all these 16 possible state to
pre-compute all the output.
And that's called a lookup table.
So what it means that from the value of your neighbor,
here four neighbors, you compute an index, which is just a number between 0 and
15, according to this simple formula.
And then you get the new state of the cells as just
the value of a table for this specific index.
So then, if the rule is complicated, you can precompute
everything at once and have a very fast implementation.
So, it's interesting to just count how many
universe I can build out of this idea.