mirror/ioccc
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add preview of 1984-2019

Browse Source 
The 2020 winners are hinted it, but the source code is not there,
nor are the hints. Someone could look into the HTML and
see what was commented out, but that is not a problem because
WHO won is known and the name of their AWARD is known already.
Moreover a number of the winners have talked about what their
entirs do, so the commented out spoiler text is not a bit problem.

One will find HTML commented out with:

    <!-- XXX remove when 2020 is ready
    2020 links here
    XXX remove when 2020 is ready -->

The "XXX remove when 2020 is ready" string is found at the
start and end comment blocks.  Again, soneone could read
what was commented out, but that is OK since most of that
information is known or can be known.  The following files
have such HTML comment blocks in them.

    ./winners.html
    ./years-spoiler.html
    ./years.html

In addition, ./all/summary.txt was modified to not
include the 2020 entries for the momemt.

The 2020 winner code AND write-ups are NOT part of this set.

p.s. The all/all.tar.bz2 does not contain the 2020 source code (yet?).
This commit is contained in:
Landon Curt Noll committed 2020-12-30 16:57:03 -08:00
1 parent 28efc67f5d
commit c0663537cb
1683 files changed
+220064
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

2011/blakely/3.dat
+13
View File
@@ -0,0 +1,13 @@
###
# #
#
##
#
# #
###
2011/blakely/Makefile
+117
View File
@@ -0,0 +1,117 @@
#!/usr/bin/env make
#
# 2011 makefile
#
# Copyright (C) 2011, Landon Curt Noll, Simon Cooper, and Leonid A. Broukhis.
#
# Creative Commons Attribution-ShareAlike 3.0 Unported License.
# See: http://creativecommons.org/licenses/by-sa/3.0/
################
# tool locations
################
#
SHELL= /bin/bash
CP= cp
CPP= cpp
GUNZIP= gunzip
LD= ld
MAKE= make
RM= rm
SED= sed
TAR= tar
TRUE= true
# optimization
#
# Most compiles will safely use -O2. Some can use only -O1 or -O.
# A few compilers have broken optimizers or this entry make break
# under those buggy optimizers and thus you may not want anything.
#
OPT= -O2
# bitness
#
# Some entries require 32-bitness,
# other entries require 64-bitess.
# By default we assume nothing.
#
ARCH=
# default flags for ANSI C compilation
#
CFLAGS= -Wall -ansi -pedantic -Do=char -Dn=return -Dd=int -Dz=memset -Dk=sizeof -include stdio.h -include string.h -include unistd.h ${ARCH} ${OPT}
# ANSI compiler
#
# Set CC to the name of your ANSI compiler.
#
CC= cc
##############################
# Special flags for this entry
##############################
#
ENTRY= blakely
DATA= 3.dat evolve_to_3.dat t0_3.dat
#################
# build the entry
#################
#
all: ${ENTRY} ${DATA}
@${TRUE}
${ENTRY}: ${ENTRY}.c
${CC} ${CFLAGS} ${ENTRY}.c -o ${ENTRY}
# alternative executable
#
alt:
@${TRUE}
###############
# utility rules
###############
#
everything: all alt
clean:
${RM} -f ${ENTRY}.o
clobber: clean
${RM} -f ${ENTRY}
nuke: clobber
@echo gnab gib!
install:
@echo "Surely you're joking Mr. Feynman!"
# backwards compatibility
#
build: all
##################
# 133t hacker rulz
##################
#
love:
@echo 'not war?'
haste:
$(MAKE) waste
waste:
@echo 'waste'
easter_egg:
@echo you expected to mis-understand this $${RANDOM} magic
@echo chongo '<was here>' "/\\oo/\\"
@echo Readers shall not be disallowed from being unable to partly misunderstand this final echo.
@${TRUE}
2011/blakely/blakely.c
+60
View File
@@ -0,0 +1,60 @@
d b,x,h;o q[9802],f[9802];void w(d i){fflush(stdout);printf(
"%c" , ( i>b)?(i%b>0?q[i-b-1]:10):5*(b==i?2:9));if(i<x+b
- 1 )w(i+1) ; } d p(o*e,d i ) { e +=i;n h = ( - b-1
) [ e ] % 2 + ( - b
) [ e ] % 2 +
(-b+1)[ e ] % 2 +( - 1 ) [ e
] % 2+ e [1 ]% 2 +b [ e - 1]% 2 + b[ e ]% 2 +
b [ e+1 ] %2 ;}d m ( d i ){ n
( i == x - 1 ) ?0 :( f [ i +
1 ]=m (i + 1) ) ,32 +3 / (
( p( q , i )> 3 || h < 2 )? 7 :
( ( h == 2 &&q[ i ] == 32
)? 8 : 1 ) );}d y
( d i ){ d j , s , t ,a ,u
;if ( x - 1== i ) n 1 ;if ( f [i]==2) {
f [i ] <<=4;if(y( i))n 1;f[i ]-=- 3 ; if (
y(i ) )n 1;n 0 ; };if((i % b ) ==
0 ||( i % b ) == b-
1 ) n y (i+1 ) ;j
= -1 ; l : ; j =j + 1 ;
if ( j >= ( i - i / b + 2
== b ? 1 : i > 2 * b ?i% b!=
1 ?2 : 2 * 1<< 1 :8 )) goto
c; u = p( f, i ) ; if ( i <
x - 2*b - 1 ) { a =( s =(( t=i % b==
1) ? 1 : i % b != b
- 2 ) ) && i < 2 * b;u+= (
a ? ( j& 4 )
>> 2 : 0 ) + (t ? ( j & 2 ) / 2 : 0) + (
s? ( j&1):0);}else a =t=s=0;if((u&2)+(u&4)!= 2 &&
(q[ i]& 2 ) ==2||u==2&& (f[i]+q[i]) % 2 ==1 ||u
== 3 && ( q [ i]&2)== 0 )
goto l ; b
[i + f ] ^= ! t ? 0
: b[ i + f ] ^ ( 10 + ( j & 2 )
/ 2 ) * 3+2;b[ i + f + 1 - b ] ^= !
a ?0 : b [i + f +1 - b]^ (10+ (
j & 4) / 4 )* 3 +2 ; b [ i
+f + 1 ] ^= ! s ?0 : b [i+ f + 1
] ^ (10 + ( j &1) ) *3+ 2 ; if ( y ( i
+ 1) ){ n 1 ; }; ( a ?
i + 1 : 0 ) [ f ] =( t
? i+ b :0
) [ f ] = ( s ? i
+ b +1:0) [ f ] = 2 ;goto l ; c:n 0 ; } d
main(d c,o**v){d i; x=b=0;while((q[x++]=getchar() ) !=
EOF ){x-=(q[x-1]==10)? b+=1,1:0;q[x-1]^= (q[x-1] ==
32)? 0 : q [ x - 1 ] ^ 35 ; } ; w ( 0 );
for ( ; ;
) { z ( f , 2 , x *
k ( o ) ) ; for ( i = 0;i<=x - 1;
i = i + b )q [ i / b] = q [ x - b+ i /b
] = q [ i ]= q [ i - (
(i == 0) ? 0: 1) ] =f [ i /
b ] = f[ x -b -1+ i/ b] = f [i ] =f[
i - ( ( i == 0 ) ?
0 :1 ) ] = 32; if ( c ==
1 ) m ( 0 ); else
if (y ( b + 1)
==0)n 1;f[0]<<=1<<2;memcpy(q,f,x*k(o));w(0);sleep(1);};n 0;}
2011/blakely/evolve_to_3.dat
+13
View File
@@ -0,0 +1,13 @@
* *
* * *
*** ** *
** * *
* *
** ** *
*** ***
** * *
* * ** *
2011/blakely/hint.html
+254
View File
@@ -0,0 +1,254 @@
<!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="&#x6d;&#x61;&#105;&#108;&#116;&#111;&#58;&#112;&#109;&#98;&#x6c;&#97;&#107;&#101;&#x6c;&#121;&#x40;&#103;&#109;&#97;&#105;&#108;&#x2e;&#99;&#111;&#109;">&#112;&#109;&#x62;&#108;&#97;&#107;&#x65;&#108;&#121;&#x40;&#103;&#x6d;&#x61;&#x69;&#x6c;&#46;&#x63;&#111;&#x6d;</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 &lt; blakely.c | head -300
</code></pre>
<h3>Try:</h3>
<pre><code>./blakely &lt; 3.dat | head -100
./blakely - &lt; 3.dat | head -40
./blakely &lt; evolve_to_3.dat | head -55
./blakely &lt; 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 - &lt; garden.txt
</code></pre>
<h2>Author&rsquo;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 &lt; 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&rsquo;s ceullular automaton known as &ldquo;The
Game of Life&rdquo;, 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 - &lt; 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 &lt; 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 &lsquo;\n&rsquo; 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&rsquo;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 &ldquo;trial&rdquo; 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 &ldquo;calculation&rdquo; 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&rsquo;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 - &lt; blakely.c is therefore <em>not</em> recommended.</p>
<hr />
<!--
(c) Copyright 1984-2012, [Leo Broukhis, Simon Cooper, Landon Curt Noll][judges] - All rights reserved
This work is licensed under a [Creative Commons Attribution-ShareAlike 3.0 Unported License][cc].
[judges]: http://www.ioccc.org/judges.html
[cc]: http://creativecommons.org/licenses/by-sa/3.0/
-->
<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>&copy; 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>&nbsp;<!--<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>
2011/blakely/hint.text
+227
View File
@@ -0,0 +1,227 @@
# Most devolving
Philip Blakely
Cambridge, UK
<pmblakely@gmail.com>
## Judges' comments:
### To build:
make blakely
### To run:
# Zoom out and make your terminal window 53 or more lines deep
./blakely < blakely.c | head -300
### Try:
./blakely < 3.dat | head -100
./blakely - < 3.dat | head -40
./blakely < evolve_to_3.dat | head -55
./blakely < t0_3.dat
### Selected Judges Remarks:
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 [Garden of Eden](http://en.wikipedia.org/wiki/Garden_of_Eden_%28cellular_automaton%29), 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 comments:
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 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:
./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 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 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
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.
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 did.
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.
Obfuscations
------------
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 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.
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.
--------------------------------------------------------------------------------
<!--
(c) Copyright 1984-2012, [Leo Broukhis, Simon Cooper, Landon Curt Noll][judges] - All rights reserved
This work is licensed under a [Creative Commons Attribution-ShareAlike 3.0 Unported License][cc].
[judges]: http://www.ioccc.org/judges.html
[cc]: http://creativecommons.org/licenses/by-sa/3.0/
-->
2011/blakely/t0_3.dat
+9
View File
@@ -0,0 +1,9 @@
###
#
###
#
###