Remove hint.html and index.html
As per discussions on GitHub the index.html and hint.html files should be deleted in favour of README.md files (from any .text/.txt/.markdown/.md files which will be turned into README.md in an upcoming commit).
This commit is contained in:
1 parent
ee8a36310f
commit
77fb0f11a2
143 files changed
-28606
No files matched your search
@@ -1,246 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="GENERATOR" content="mkd2html 2.1.3 DL=DISCOUNT">
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
|
||||
<link rel="stylesheet"
|
||||
type="text/css"
|
||||
href="../hint.css">
|
||||
<title>Most devolving</title>
|
||||
</head>
|
||||
<body>
|
||||
<h1>Most devolving</h1>
|
||||
|
||||
<p>Philip Blakely<br>
|
||||
Cambridge, UK<br>
|
||||
<a href="mailto:pmblakely@gmail.com">pmblakely@gmail.com</a></p>
|
||||
|
||||
<h2>Judges' comments:</h2>
|
||||
|
||||
<h3>To build:</h3>
|
||||
|
||||
<pre><code>make blakely
|
||||
</code></pre>
|
||||
|
||||
<h3>To run:</h3>
|
||||
|
||||
<pre><code># Zoom out and make your terminal window 53 or more lines deep
|
||||
./blakely < blakely.c | head -300
|
||||
</code></pre>
|
||||
|
||||
<h3>Try:</h3>
|
||||
|
||||
<pre><code>./blakely < 3.dat | head -100
|
||||
./blakely - < 3.dat | head -40
|
||||
./blakely < evolve_to_3.dat | head -55
|
||||
./blakely < t0_3.dat
|
||||
</code></pre>
|
||||
|
||||
<h3>Selected Judges Remarks:</h3>
|
||||
|
||||
<p>This program plays Life, computes Pi to 16 digits
|
||||
if given its own source as input, and allows to check if your garden
|
||||
is a <a href="http://en.wikipedia.org/wiki/Garden_of_Eden_%28cellular_automaton%29">Garden of Eden</a>, all in one source.</p>
|
||||
|
||||
<p>If you have enough time to spare, put the plan of your garden in a text file,
|
||||
and run:</p>
|
||||
|
||||
<pre><code>./blakely - < garden.txt
|
||||
</code></pre>
|
||||
|
||||
<h2>Author’s comments:</h2>
|
||||
|
||||
<h2>Remarks</h2>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p>In order to see the main feature of the code, type:</p>
|
||||
|
||||
<pre><code>./blakely < blakely.c
|
||||
</code></pre>
|
||||
|
||||
<p>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).</p>
|
||||
|
||||
<h2>Overview</h2>
|
||||
|
||||
<p>The program emulates John Conway’s ceullular 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:</p>
|
||||
|
||||
<pre><code>./blakely - < 3.dat
|
||||
</code></pre>
|
||||
|
||||
<p>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</p>
|
||||
|
||||
<pre><code>./blakely < evolve_to_3.dat
|
||||
</code></pre>
|
||||
|
||||
<p>then the 3 will reappear after three time steps.</p>
|
||||
|
||||
<p>As should now be clear, this use of 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 <em>any</em> single
|
||||
command line option.</p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<h2>Input file format</h2>
|
||||
|
||||
<p>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 in place of spaces,
|
||||
and do a global replace afterwards. Any deviation from this format will
|
||||
cause errors in the output.</p>
|
||||
|
||||
<h2>Limitations</h2>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p>The maximum grid size is currently 99 by 99 (exceeding this will cause a
|
||||
seg-fault), but changing the two 9802s to MAX_SIZE*MAX_SIZE+1 will
|
||||
solve this, although some reformatting of the
|
||||
code may have to be done to allow larger numbers.</p>
|
||||
|
||||
<h2>Compiler warnings/assumptions</h2>
|
||||
|
||||
<p>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 did.</p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<h2>Obfuscations</h2>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p>Other obfuscations used are:</p>
|
||||
|
||||
<ul>
|
||||
<li>Use of the classic 2[a] syntax to access the third element of the
|
||||
array a</li>
|
||||
<li>Nested ternary operators, combined with shortcut evaluation being
|
||||
required for correct operation</li>
|
||||
<li>Use of the comma operator to embed operations inside one another</li>
|
||||
<li>Calculation of ASCII codes</li>
|
||||
<li>Needlessly recursive functions</li>
|
||||
<li>Use of bitwise-operations.</li>
|
||||
<li>Storing a variable whose value could easily be found from another</li>
|
||||
<li>Use of gotos to emulate a for loop</li>
|
||||
</ul>
|
||||
|
||||
|
||||
<h2>Algorithm</h2>
|
||||
|
||||
<p>The forwards evolution of the grid is straightforward.</p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p>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.)</p>
|
||||
|
||||
<h2>Program layout</h2>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p>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</p>
|
||||
|
||||
<pre><code>* * * * * * * * * *
|
||||
*****************
|
||||
* * * * * * * * * *
|
||||
</code></pre>
|
||||
|
||||
<p>were useful in this regard.</p>
|
||||
|
||||
<p>Other problems were given by 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.</p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p>The command ./blakely - < blakely.c is therefore <em>not</em> recommended.</p>
|
||||
|
||||
<hr />
|
||||
|
||||
<TABLE><TR>
|
||||
<TD><a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by-sa/3.0/88x31.png" /></a></TD>
|
||||
<TD><P>© Copyright 1984-2012,
|
||||
<A HREF="/judges.html">Leo Broukhis, Simon Cooper, Landon Curt Noll</A>
|
||||
- All rights reserved<BR>
|
||||
This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative Commons Attribution-ShareAlike 3.0 Unported License</a>.</P></TD>
|
||||
<TD> <!--<a href="http://validator.w3.org/check?uri=referer"><img src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01 Transitional" height="31" width="88"></a>--></TD>
|
||||
</TR></TABLE>
|
||||
</body>
|
||||
</html>
|
||||
Reference in new issue
Block a user