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.