Author:

• Name: Philip Blakely
  Location: GB - United Kingdom of Great Britain and Northern Ireland (United Kingdom)

To build:

    make

To use:

Zoom out and make your terminal window 53 or more lines deep.

    ./blakely < blakely.c | head -300

Try:

    ./try.sh

For those who have a lot of time, try:

    ./blakely < t0_3.dat

though one might or might not need to kill it, depending on your boredom threshold.

Judges’ remarks:

This program plays Life (see here also), computes Pi to 16 digits if given its own source as input, and allows to check if your garden is a Garden of Eden, all in one source.

If you have enough time to spare, put the plan of your garden in a text file, and run:

    ./blakely - < garden.txt

Author’s remarks:

This program uses a well-known algorithm in order to display pi to fifteen decimal places. The source-layout itself demonstrates the importance of using the correct amount of whitespace in code and the clear superiority of spaces over tabs.

In order to see the main feature of the code, type:

    ./blakely < blakely.c

and wait for about four seconds before using Ctrl-C (or whatever) to end the program. The results are best viewed in a terminal window at least 60 characters high and wide. Alternatively, redirect the output to a separate file (killing when necessary).

Overview

The program emulates John Conway’s cellular automaton known as “The Game of Life”, using standard input as a starting grid. The layout of the source-code is such that it evolves to a digital representation of the first 15 decimal places of pi after 4 time steps. This was setup using the other feature of the program which can be demonstrated as follows:

    ./blakely - < 3.dat

The program will first display the grid given in 3.dat, and then three more grids (taking a few minutes to display the last). Waiting for any more grids will take a substantial amount of time. The final grid has been put into evolve_to_3.dat, and if you type

    ./blakely < evolve_to_3.dat

then the 3 will reappear after three time steps.

As should now be clear, this use of the program will attempt to evolve a given setup backwards in time according to the Life rules. The resulting grid is clearly not necessarily unique. The program will evolve backwards given any single command line option.

When evolving forwards, the code can only be stopped by killing the program. In the reverse direction, the code can either be killed, or will stop if it is unable to find a grid that will evolve to the current layout correctly. This can be seen with the sample grid t0_3.dat, which evolves backwards by only two time-steps.

Input file format

The input files must encode a square grid, where a space is a dead cell, and any other character (except a newline) is a living cell. Each line must be the same length, and end with a single newline character \n (ASCII 10), including the last line. When designing grids, it may help to type full-stops (dots) in place of spaces, and do a global replace afterwards. Any deviation from this format will cause errors in the output.

Limitations

This is only an approximation to the original Life, as it takes place on a finite grid, with borders that are automatically killed off before each time step. However, when evolving backwards, the resulting grids will not cause any cells on the boundaries to come alive. As the display is performed before killing off the borders, some boundary cells may sometimes appear to be alive, but not be treated as such for the following time-step, although any living cells on the right border will never be displayed.

The maximum grid size is currently 99 by 99 (exceeding this will cause a segfault), but changing the two 9802s to MAX_SIZE*MAX_SIZE+1 will solve this, although some reformatting of the code might have to be done to allow larger numbers.

Compiler warnings/assumptions

When compiled with the -Wall -pedantic -ansi options of gcc, some warnings suggesting extra parentheses occur (not necessary for anyone fully conversant with operator precedence). There is one unused variable, v, but unnamed function parameters are not permitted in ANSI C, so naming it is necessary, and gcc no longer warns about its existence, although earlier versions do.

Since the program calculates ASCII character values for display, an ASCII based system is required to run it. Also, as mentioned above, any system that uses anything other than a plain \n to end a line will cause problems when reading in files.

Obfuscation

Given the finely-tuned layout required to evolve into pi, this is one of the main obfuscations used in the code. However, running the code through the preprocessor, expanding the #defines, and applying GNU’s indent, although making the location of functions and statements clear, by no means makes the code entirely clear. Note that expanding out the #defines does not take the program over the character limit. The main reason for these is to do with the layout, since there are few places that keywords or tokens of over 2 characters can be fitted, and requiring the first few lines to be #includes would cause similar problems.

Other obfuscations used are:

• Use of the classic 2[a] syntax to access the third element of the array a.
• Nested ternary operators, combined with shortcut evaluation being required for correct operation.
• Use of the comma operator to embed operations inside one another.
• Calculation of ASCII codes.
• Needlessly recursive functions.
• Use of bitwise-operations.
• Storing a variable whose value could easily be found from another.
• Use of gotos to emulate a for loop.

Algorithm

The forwards evolution of the grid is straightforward.

The reverse evolution is done using a brute-force method. As far as I know, a brute-force method is the only viable automatic approach for general grids, although more intelligent algorithms would be possible given more space.

The program starts with an empty “trial” grid and, starting from the top-left, tries all possibilities for the neighbours of the current cell that will cause the cell to evolve to the required state. It then proceeds to the right and down. Thus, it only ever needs to look at the cells below and to the right when testing. However, the already defined cells above and/or to the left of the cell may mean that there are no possibilities that will give the correct state, in which case the code backtracks and tries other possibilities on previous cells. The program knows it has a valid grid if it gets to the last cell. If it cannot find a valid grid, the program exits.

Since this uses brute-force, it can be very slow. (In fact, the various obfuscations have, at least for the gcc compiler, caused a substantial slowdown.)

Program layout

The “calculation” of pi was chosen purely because algorithms to find pi are numerous, but the Game of Life is rarely (if ever?) used for this purpose. Also, separate digits made determining the layout somewhat easier.

Deriving the layout was the most complicated part of the program. As is clear from the final layout featuring pi, the grid was divided into sixteen squares, and layouts that would evolve to each of the nine digits required were found. (This used the three-by-five digit-layout embedded in, at first, a nine-by-nine grid, then in larger grids, until fifteen-by-fifteen was reached.) The fifteen-by-fifteen grids give enough blank cells around them that the digits will not collide when evolving.

However, this did not allow for sufficient characters to fit the code into. Therefore it was necessary to add some regions that would quickly die off without expanding to collide with the digits’ evolution. Groups of cells such as singletons, pairs, and larger groups like

    * * * * * * * * * *
     *****************
    * * * * * * * * * *

were useful in this regard.

Other problems were keywords which need to be all in one string, keywords requiring space after them, and multi-character tokens. Some of these problems were dealt with by using the #defines and #includes given in the build-script, as there was no way to have sufficient separate lines in the code to do this without causing many difficulties. Some rejigging of the grid’s layout as the code was fitted into its format was also done, resorting to trial-and-improvement in some cases. Occasional use of constructs such as f -= -3 was made as f += 3 could not be fitted into the required format. The fact that the borders would be killed off immediately was also helpful.

It should be noted that evolving a full 60-by-60 grid backwards using this code would probably take us at least up to the heat-death of the universe.

The command ./blakely - < blakely.c is therefore not recommended.

Primary files

• blakely.c - entry source code
• Makefile - entry Makefile
• blakely.orig.c - original source code
• 3.dat - input data file
• evolve_to_3.dat - input data file
• t0_3.dat - input data file
• try.sh - script to try entry

Secondary files

• 2011_blakely.tar.bz2 - download entry tarball
• README.md - markdown source for this web page
• .entry.json - entry summary and manifest in JSON
• .gitignore - list of files that should not be committed under git
• .path - directory path from top level directory
• index.html - this web page

Jump to: top