Sunday, January 25, 2015

Less trivial conserved quantities in binary block CA

Binary block cellular automata with Margolus neighborhood

A contrived title, but the thing is simple: consider an infinite field of square cells, where each cell can be dead: 0 or alive: 1 (thus binary). Now define the following evolution rule:

  • Subdivide board into 2x2 cells. Each cell can be in one of 16 states.
  • Transform every cell independently, using the same transformation function.
  • Alternate subdivision by shifting the grid by (1,1).
This subdivision scheme is called Margolus neighborhood, and the whole system defines a cellular automaton.

Block cellular automata are interesting, because it is easy to make them reversible: just ensure that block transformation function is reversible (i.e. it is described by a transposition of 16 states). A well studied examples or rules are Critters, Billiard Ball machine, miscellaneous gas automata. My personal interest is the Single rotation rule.

Conserved quantities

Having done few experiments it is easy to notice that rules for such automata generally fall into 2 categories:

  1. those that preserve population (BBM, Critters*, Single Rotation)
  2. and those that don't (Tron and most random rules).
(*) in the first group, there is a sub-group of rules that invert population on each step (Critters is a good example), thus population restores every 2 steps. Such rules can be effectively simulated with 2 non-inverting rules applied alternatively.

Rules without population conservation almost inevitably exhibit chaotic growth for the most initial patterns. (A slightly paradoxical observation: for all reversible rules, there is no difference between evolution forward and backward in time, but a random initial pattern almost surely grows, like if there is a chosen direction of time).

Small initial pattern in the rule without cell conservation. (Try live.)

The field tends to reach the state of maximal entropy, where roughly 50% of all cells are dead and 50% are alive.

Rules with conservation behave very different: they also strive to increase entropy, but this trend is limited by the conservation laws. Most interesting rules are in this class: Critters, BBM, Single Rotation.

Rules with conservation (Single Rotation). Entropy growth is limited, complex emergent behavior appears. (Try live.)

Less trivial conserved quantities

So my question was: are there any rules that have some conserved quantity other than number of alive cells. And the answer is yes. There are at least 2 ways to construct such rules.

Weighted population

It is easy to notice that in the Margolus neighborhood scheme, sum cells of the board are always on the diagonal of the block, and others are on the anti-diagonal (black and white cells of a chessboard). We can assign different weights to white and black cells, and find a rule that preserves this modified weight.

There are 3 significantly different ways to assign positive weights to the "black" \(w_b\) and "white" \(w_w\) cells:

  1. \(w_b = w_w = 1\): both weights are the same, this is the usual population.
  2. \(w_b = 1, w_w = 2\): a non-trivial case.
  3. \(w_b = 1, w_w > 2\): equivalent to counting black and white cells separately, because 2 black cells in a block can never outweigh any white cell.
In rules that preserve the (1,3) weight, populations of cells on black and white cells of the board are not interacting, so the only non-trivial case here is (1,2) weighted sum.

The (1,2) weighted population of a block takes values in range [0, 6]. Block states are divided by it into 7 groups of equal weight:

7 groups of block states by their weighted population.

Any rules that replaces block with another block of the same group, would preserve weighted population. Moreover, a rule that replaces block of weighted population \(w\) with block of w.p. \(6-w\), would be analog of the population inverting rule.

Some rules

The rules can be built by combining transpositions of states in the same group. It should be noted that most rules are anisotropic: they are not invariant to rotation bu 90°, patterns in such rules can't be rotated, only translated.

“Split and merge billiard&rdquo

This rule is defined by the following lookup table: [0,6,4,3,2,5,8,7,1,9,10,11,12,13,14,15], itis illustrated by the diagram below.

Substitution diagram for the split and merge billiard rule. Other block states remain unchanged.

It is an analog of the “Billiard Ball Machine” rule, but two anti-diagonal balls may merge on collision and create one diagonal.

Split and merge billiard animation. Try it live.

Rule [15,14,13,10,11,3,9,1,7,8,12,2,5,4,6,0]

This rule inverts weighted population on each step, thus after 2 generations weighted population is restored. This rule is relatively rare example of its family, because it have spaceships, moving in both directions along both diagonals (of course, these are different spaceships). Several tens minutes of random search discovered 35 different moving patterns.

Multiple spaceships. Try it live.

Other rules with spaceships

There is plenty of rules, supporting spaceships. Some of them are:

Negative weights

It is also possible to assign negative weights to the block cells. In rules preserving resulting invariant, total number of alive cells can grow infinitely, while invariant remains constant. This usually makes such rules “explosive&rdquo: most initial patterns grow ore or less chaotically.

An easy way to produce such rules is to take a rules with positive weights and consider it acting on a board, where half of cells is alive, forming a chessboard pattern. Then build a rule, describing evolution of the XOR between some field and the infinite chess pattern. For example, for "single rotation" resulting rule is [0,13,2,3,4,5,6,7,11,9,10,1,12,8,14,15]. It is partially "explosive", but supports some simple spaceships, moving along main diagonal.

Monday, January 12, 2015

Now in 3D (Single Rotation)

I am proud to present my most complex Three.js application so far: 3D visualization of the Single Rotation cellular automaton.

Screen-shot of the program display. Grey lines form indestructible wall, attacked by multiple patterns smashing on it.

What you see on the above picture are world lines of the cellular automaton cells, as they move according to the Single Rotation rule. World lines are rendered in the browser window using WebGL technology.

This application develops the idea, presented in the previous post: Single Rotation rules with frame interpolation (application link)

In short, Single Rotation is a simple cellular automaton rule that tells, how "alive" cells move across the rectangular grid. Movement of the cells is discrete, so to improve visual experience, intermediate positions are interpolated using Lanczos re-sampling. Additionally, low-pass Lanczos filter is applied in order to remove oscillations with period 4 and less. It is done to suppress annoying circular movement of single cells (one can easily ensure that they are period-4 oscillators). Together, filtering and interpolation give smooth, continuous trajectories for each cell. Cells move in 2 dimensions, so their word lines are 3-dimensional curves. The visualizer shows these word lines.

In case you don't have a WebGL-enabled browser, or the simulator runs too slow, here is a video demonstration. See also "Advanced usage" section below to improve performance.

Collisions in 3D

Three-dimensional view of world lines makes spaceship collisions especially charming. Don't they resemble Feynmann diagrams? Below are some collisions, seen in the simulator.

Spaceship + cell

It can be easily proved that in every reversible cellular automaton with cell count conservation, a collision of a spaceship of the lightest weight and a single-cell always produces a (possible different) lightest spaceship and single cell again. Below is an example.

Collision of a light spaceship and a single cell (bottom) translates single cell and changes direction of a spaceship.

To see this scene yourself, paste the following code to the "Custom Scene" text area and click "Load":

at -20 -20; 2bobo$b2o
at 0 0; $o

Spaceship + spaceship, symmetric

From the similar considerations, symmetric collision of 2 lightest spaceship also necessarily produces 2 (possibly different) spaceships. Here is how it looks like.

Symmetric collision of 2 light spaceships produces same spaceships after long reaction.

Interestingly, it appears that both spaceships don't even exchange their cells in the collision. Scene code for this collision is:

at -20 -20; 2bobo$b2o
at 20 20; 3b2o$bobo

Spaceship + spaceship, asymmetric

When collision of 2 spaceships is not symmetric, products may be different, but they necessarily include at least one spaceship (possibly not the lightest one). Here is an example.

Collision of 2 different light spaceships produces a spaceship and oscillators.

Scene code for this collision:

at -20 -20; 2bobo$b2o
at 20 20; 3b2o$bobo

Heavy spaceship + cell

Finally, when heavy spaceship collides with anything, it almost certainly produces lots of debris. Reversibility only requires that at least 1 spaceship is produced in this reaction, usually it is a light one. Below is a collision of a heaviest single (i.e. not chained) spaceship, made of 12 cells; and a single cell. Multiple oscillators and one light spaceship are produced.

Collision of the heaviest known spaceship (12 cells) and a single cell (bottom-left) produces a single spaceship and oscillator.

Scene code:

at -20 0; 2b4o$4b2o$bo2bo$2bo$bo2bobo
at 0 0; o

You can try any of the 328 spaceships from the library. Just copy the RLE code of the spaceship into the "Custom scene" field. Mini-language also lets you to assign colors to patterns, and combine multiple patterns with different offset. Rotating is not supported yet, you can use Reversible CA simulator to get RLE of the rotated pattern (paste RLE into the "buffer" text area and click arrow buttons).

Advanced usage

The application also takes some additional URL arguments. Add them to the URL after a "?" character, separating options with "&".

  • antialias=true
    Enables anti-aliasing, making smoother images but increasing CPU load.
  • visibility=distance
    where distance is a number in the range 1000 ~ 50'000. It defines, how farthe world lines are seen. Big distance significantly decreases FPS. Here are some sample links:
  • Additional mesh generation parameters (with their default values):
    • chunkSize=500
      number of steps in one mesh chunk
    • skipSteps=1
      Generate tube section every n'th step (1 - every step)
    • boardSize=100
      Size of the square board, must be even
    • lanczosOrder=3
      Lanczos interpolation order, 1 ... 10. 1 - linear interpolation, 3 - smooth interpolation
    • interpSteps=1
      How many mesh steps are there between 2 generation. integer, 1 ... 4
    • smoothingPeriod=4
      Low-pass filter, removing oscillations with period bigger than this. integer, 1 ... 100. 1 - no filtering.
    • timeScale=0.1
      "speed of light". z-axis length of one generation
    • tubeRadius=0.1
      Radius of a single rube
    • tubeSides=3
      Number of sides in the tube cross-section (2...10)
Probably, some more arguments would be added later.

Requirements

The application depends on the following technologies:

which means that latest versions of browsers and drivers are required. I have tested the application in Firefox (Linux, Windows) and Chrome (Linux, Windows, Android). It could run on the latest IE versions too.

Source code

Sources for this application are on Github: dmishin/singlerot-smooth, with 3D-specific code in the "3d" sub-folder. The sources are in CoffeeScript, to build them, CoffeeScript and "browserify" are required. Build system is written using GNU Make. I am not yet familiar enough with Node.js-specific tools.

Links

Here are links to the related posts and pages.

Monday, January 5, 2015

New Single Rotation spaceships

I still continue leisurely exploring the Single Rotation celluar automaton, a very simple reversible cellular automaton with complex emergent behavior. This post is a status repost on spaceships.

Brute-force spaceship search

My original library of spaceships had 205 patterns, found using random reaction method. Using a simple brute-force algorithm (C++ sources), some more spaceships having from 6 to 12 cells were discovered (well, this is an old news, but I haven't published it in the blog yet). Currently, there are 328 patterns in the library. The heaviest spaceship so far has 12 cells, and is surprisingly fast: c/71. For 13 cell patterns, several days of brute-forcing did not brought a single pattern yet. No knightships were found too.

Expansible spaceship

For me, this pattern is the most exciting discovery. While looking at the spaceship table, I have accidentally noticed a 7-cell spaceship, whose evolution resembled a ball, bouncing between 2 reflectors. A quick check showed that this impression was right: it consists of the lightest spaceship B, bouncing between 2 reflectors, of 1 and 2 cells. Each bounce moves the reflectors forward by 1 cell, thus making the pattern a single slow spaceship. The distance between the reflectors can be expanded, giving an infinite family of more and more slow and sparse spaceships. Note: because "Single Rotation" rule is chiral (i.e. not invariant to reflection), top and bottom reflectors must be different.

Evolution of the expansible spaceship.

Position of the reflector may be moved by \(2k\) cells diagonally, where \(k=0,1,...\), giving a diagonal spaceship of period \(245+56k\) and translation (1,1).

Expansible spaceship in its shortest form (bottom) and expanded by 2, 4, 6 cells. See it live in the simulator.

An interesting challenge is to find a growing variation of the ping pong ship (that would not be a spaceship, in a strict sence). If discovered, it would be the first growing pattern with growth rate below O(n).

Spaceship chains

Another (rater old) discovery, made by staring at the spaceship catalog. There are 2 patterns of 8 cells, resembling a pair of lightest 4-cell spaceships, moving in the same direction. However, the parts are not independent, they interact during the pattern evolution (though the interaction does not change period or speed of the pattern). A quick check revealed that both these patterns can be expanded, giving 2 infinite families of long spaceships of equal period and velocity.

Fast chain spaceship

Fast chain spaceships are built from the lightest spaceship B (the table of all lightest spaceships is here). The dimer of this spaceship is produced in random reaction with probability around \(2\cdot10^{-6}\)).

Lightest spaceship B and its dimer.

New spaceships can be attached to the end of the chain in 2 ways, giving 2 possible slants. All these chains have period 28 and move diagonally with velocity c/14.

Several chained spaceships. Spaceship B can be attached to the chain in 2 positions, giving 2 possible slants of the chain. See it live in the simulator.

The chains can be built by the following procedure:

  1. Take a dimer of the spaceship B, in some phase.
  2. Evaluate it step by step, until its right part will have the same configuration as the left part of the original dimer.
  3. Put the dimer to the field, matching coinciding parts.

Extending the chain: original dimer (top), its state after 10 generations (middle), trimer (bottom).

Interestingly, evaluation with tracking cell trajectories shows that all elementary spaceships in the zig-zag expansion are constantly exchanging cells.

Slow chain spaceship

The slow chain can be built from the repetitions of the lightest spaceship F. Unlike the fast chains, chains with different slant can't be connected, so no zig-zags here. Same as its monomer, these spaceships have period 368 and velocity c/184.

Two separate chains and their monomer. All move diagonally with velocity c/184. See it live in the simulator.