Well, as if most of the other stuff on this site isn't rather
odd.
I was only 7 when Conway's
Game
of Life was introduced in the pages of Scientific American
in October 1970, don't recall when I first heard about it but when
I got my first computer in 1981 (a ZX81 with a whopping 1K of ram
that I soldered together myself) it was one of the first programs
I wrote. First in BASIC but I wanted speed so rewrote it in Z80
machine code and was mesmerized by its fast-moving patterns! That
piece of code is long gone but I found a similar version of LIFE
that I wrote for the C64...
I don't have the assembly source for it, in those days I coded
the assembly on paper then converted the opcodes to the actual
bytes. Here's the original files, the
loader graphics to the left was made from three screen shots,
cropped and color-edited - the C64's default colors were rather
pale.
I coded versions of LIFE for every 8-bit computer I had, starting
with the ZX81, then the Tandy Color Computer, the C64 then the
Atari 800 and derivitives. Here's an animation made from my old
Atari CELLS program...
I fooled around with LIFE a bit in QBasic when I got a PC in 1993
but PC machine coding was nowhere near the fun of coding for
8-bitters and soon there were much better programs than anything I
could possibly come up with. LIFE is Turing-complete and it's
possible to craft a general-purpose computer in LIFE. Here's one
that runs Tetris. And one that runs LIFE in
LIFE. (!!! yikes !!!)
11/27/23 - Here's a version of LIFE written in Javascript... use the mouse
to change the cell states.
This is a strange one...
I wrote this when I had a gig as a night-time computer operator at Citrus World in 1986.. that's what happens when you teach a young computer geek COBOL then leave them alone with a mainframe. The Wang VS also had BASIC, played with it too but had to be careful as it did not multitask well and had a tendency to mess up the work jobs I was running. This COBOL version of LIFE didn't have a random mode (Wang VS COBOL didn't have a random number generator that I could tell), after entering a starting pattern it ran for a fixed number of cycles then I could keep going, clear the screen and enter a new pattern, or stop wasting time.
In the late '80's I worked at Shiloh Music in Mt. Juliet, TN and
we were an Atari dealer. Mostly for the Atari ST which was used by
many musicians back then, but also sold and serviced the Atari 800
line. I really liked the way the original 800 was made - like a
tank - but with only 48K was limited so ended up with an Atari XE
with 128K, the extra 64K could be configured as a ram disk but
eventually got another box with several hundred K of ram with
battery backup that I could trust better with my data. Atari DOS
was functional but mostly used SpartaDOS along with the Ace C
compiler and M65 assembler. The environment was primitive but
could edit, compile and link code that I wrote. The resulting
programs were extremely slow and low resolution by modern
computing standards but back then it was pretty much all I had to
work with. Here are some of the things I played with...
CELLS
This was a colorized version of LIFE, with different colors for
birth, survival by 2 and survival by 3. The original program
computed about one generation per second but it goes super-fast
when running under the Atari800 emulator in turbo mode.
HODGE
This is a 2D cellular automaton called the Hodgepodge Machine,
found in A.K. Dewdney's Computer Recreations column in the August
1988 issue of Scientific American. It was created by Martin
Gerhardt and Heike Schuster to simulate the waves that occur in
some kinds of chemical reactions. This implementation uses an 80
by 96 grid, each cell can have a number of states ranging from 0
for healthy and the maximum state for ill. Any state between the
two was termed infected. The multiple states are (somehow) reduced
to 4 colors for display.
The input variables are:
NS Number of cell states
K1 Constant 1 (infect)
K2 Constant 2 (ill)
G Rate of infection
For each generation the program makes the following computations
on each cell:
A = number of surr. infected cells
(currentstate>0 and <NS)
B = number of surr. ill cells
(currentstate = NS)
S = sum of surr. cell states
If currentstate=0 then newstate=[A/K1]+[B/K2]
If currentstate>0 and currentstate<NS then newstate=[S/A]+G
If currentstate=NS then newstate=0
...while keeping
track of the counts, after the future states of all the cells have
been computed then copies the new state to the current state,
displays and repeats. I forgot to press N for new when I took this
screen dump so it used the current memory contents as the starting
pattern...
HOP
This is a version of the HOPALONG algorithm from Computer
Recreations, September 1986 Scientific American and also reprinted
in A.K. Dewdney's "THE ARMCHAIR UNIVERSE". I couldn't find the
source code for this particular program but this is the basic
algorithm, adapted from the article...
input a, b, c
x = 0
y = 0
clear screen
do
plot pixel x,y
x1 = y - sign(x) * sqrt(abs(b * x - c))
y = a - x
x = x1
until stopped
The S H and V parameters are the scaling factor and horizontal
and vertical position. Despite the imprecision of floating point
computer math (especially on an 8-bit computer) the "hop" tended
to avoid certain regions, leaving a pattern of voids...
After many many more hops there are still voids...
BURST
This is a color version of HOPALONG, using the iteration count to
periodically change the plotting color...
LNAUTO
This program generates various one-dimensional, or "line"
automata, using a user-entered rule string. Line automata have
been covered in the March and September 1984 issues of Scientific
American and in the December 1986 issue of Byte, and also heavily
researched by Stephen Wolfram. In this kind of automata the cell
influences its own outcome along with the states of its
surrounding cells. This program supports neighborhood sizes of 3,
5 or 7, determined by the length of the rule string, and up to 4
states numbered 0-3. To compute the next state of each cell the
program adds up the states of all the cells in the neighborhood
then looks up the appropriate digit in the rule string, with the
left-most digit specifying the new state for a count of 0. When
successive generations are plotted from top to bottom interesting
patterns emerge...
MORPH
This program plots "Biomorphs", invented when IBM researcher
Clifford Pickover had a bug in a fractal program that produced
unexpected results, and reported by A.K. Dewdney in the July 1989
issue of Scientific American. The idea is for each pixel iterate
Z=something(Z)+C with Z and C being complex numbers. C is held
constant to determine the type of plot and the real and imaginary
components of starting value of Z are swept to generate a 2D plot.
Something(Z) can be any function of Z, from simple to complex. In
my version I use one of 4 formulas from Z=Z^2+C to Z=Z^5+C. Each
pixel is iterated until the absolute size of Z exceeds a limit or
an iteration limit is reached. For my plots if both components of
Z are less than the limit that point is plotted with color 0,
color 1 if only the real component is less than the limit, color 2
if only the imaginary component is less than the limit, or color 3
if both components exceed the limit. There's something in there...
SCOPE
This is a Mandelbrot
Set plotter. It produced interesting images for the day...
...but was infuratingly slow! Many hours per plot on the original
Atari computer. Even with the Atari800 emulator's super-fast turbo
mode it still takes several minutes per image. Back then I'd still
run it overnight to see what would come out, and wonder how such
images appear in otherwise ordinary numbers processed by
relatively simple math.. as if Nature is an artist! When I got a
PC in 1993 it wasn't too long thereafter when I discovered
FractInt and many other fractal programs, each generation
exponentially increasing in speed. These days the Mandelbrot set
can be zoomed into in real time using software such as XaoS, but it still
takes a lot of computing for an extreme zoom. Here are some things I found around 8 years ago using
a program called Fraqtive,
they make nice desktop wallpaper.
TREK
I played with more than math... had many games back then but this
was one of my favorites...
This version of Mike
Mayfield's TREK game is based on "Super Star Trek",
published by David Ahl in 1978 in his book "BASIC Computer Games,
Microcomputer Edition". I typed it in and converted it to Atari
BASIC sometime around 1990. I remember playing it quite a bit but
the code I found still had several cosmetic glitches - not sure if
this was an early conversion (some things hadn't been converted at
all) or if I just didn't care at the time - the game logic worked
fine. The main conversion was to keep the main screen at the top
so I wouldn't have to keep typing SRS all the time (plus it looked
cool), then display temporary data on the bottom half of the
screen. Which mostly worked but got tricky when firing at a bunch
of Klingons then they'd shoot back, overwriting the previous text
and sometimes leaving a messy display. Or worse scrolling the top
display. Most of the recent fixes involved adding space padding to
keep things neat and making sure the top display is properly
updated. In most versions of this game the enemy ships fired first
when entering a new quadrant. This one didn't do that and also
seemed a bit on the easy side, so added a difficulty level prompt
when the program starts. Level 0 keeps the easy gameplay, higher
levels strengthen the enemies and increase the chance they'll
shoot first.
Update Febuary 2021 - At it again.. recently I got back into Trek
hacking and sure enough found a few more display glitches in this
version where it would overwrite existing text without clearing it
first, or in the case of technicians fixing my ship, completely
obliterating the SRS display - bad techs! Can't have that.. fixed
that and other glitches, should be better now but there are likely
other bugs. One bug that I know of is on the new higher levels,
sometimes SRS will trigger another round of incoming fire -
normally SRS isn't needed as its mostly automatic in this version,
except for when the display glitches.
Download the maprogs.zip file for disk images containing all of these programs plus scripts for running with the Atari800 emulator (last updated 2/22/2021). The disk images also work with other Atari emulators such as Altirra for Windows. Or browse through the converted source code and text.
This is fun program...
-------------- begin lineauto.bas ------------------
REM LineAuto - WTN 231203-12 - FreeBASIC version, -lang qb -exx REM Generates line automata with up to 10 states, 3 cell neighborhood REM For each cell the next state is determined by the sum of states REM in the neighborhood and the rule string which specifies the next REM state for every possible sum. The rule string starts at sum 0 and REM can be up to 28 digits long. ON ERROR GOTO ProgError RANDOMIZE 'TIMER 'uncomment timer for QBasic DEFINT A-Y 'start floating point vars with z scmode = 18 'for QBasic make 12 (disables S key) 'otherwise 18=640x480 19=800x600 20=1024x768 21=1280x1024 xres = 1280 'for dimensioning arrays, make 640 for QBasic DIM rule(28), oldstate(xres), newstate(xres) startline = 16 'must be even magnify = 0 'in magnify mode the middle is printed with double sized pixels historysize = 1000 'divisible by 4, for QBasic have to greatly reduce (24) DIM history(28, historysize) 'rule history for back DIM historystart(xres, historysize) 'saved starting lines for back feature DIM previous(xres, historysize) 'saved starting lines for previous feature hp = 0: bp = 0: nrf = 0 'history pointer, back pointer, new rule flag maxhp = 0 'highest saved history rule Xclose$ = CHR$(0) + "k" 'code for window close CursorLeft$ = CHR$(0) + "K" 'code for cursor left CursorRight$ = CHR$(0) + "M" 'code for cursor right GOSUB SetScreenMode resetfactors: CLS znfactor = 3.7 'used to weight random rule digits lower zsfactor = 0.4 'used to weight random rule states higher zxfactor = 0.7 'used to weight random rule digits higher for higher sums PRINT "*** LineAuto *** by WTN 231203-12" PRINT PRINT "This program generates line automata graphics with up to 10 states" PRINT "per cell. Generation starts with a random line, for each new line" PRINT "the cell states are determined by summing the 3 cells above it then" PRINT "getting the next state from the rule string. The rule string starts" PRINT "with the state for a sum of zero. The line wraps at the edges." PRINT "Press a key within 3 seconds to pause this screen." PRINT PRINT "Edit mode keys..." PRINT "Left/Right move green cursor" PRINT "0 through 9 change rule digit" PRINT "Enter generate using current rule" PRINT "N generate from new random rule" PRINT "C clear rule string to zeros" PRINT "M toggle magnify mode" PRINT "S change screen size" PRINT "X exit the program" PRINT PRINT "After generating..." PRINT "Space generate next screen" PRINT "Esc back to edit mode" PRINT "P regenerate previous screen" PRINT "N generate from new random rule" PRINT "B go back through rule history" PRINT "F go forward in rule history" PRINT "X exit the program" PRINT: i = 3 'seconds to wait stwait1: SLEEP 1: a$ = INKEY$: IF a$ <> "" THEN GOTO stwait2 i = i - 1: IF i > 0 THEN GOTO stwait1 ELSE GOTO ClearScreen stwait2: PRINT "(press W for weights or any key to continue)" SLEEP: a$ = INKEY$: IF a$ = Xclose$ THEN SYSTEM IF a$ <> "w" THEN GOTO ClearScreen CLS PRINT "Weights when making new random rules, must be > 0" PRINT "1=no weight, < 1 weights higher, > 1 weights lower" PRINT "znfactor weights digit selections, generally lower" PRINT "zsfactor weights number of states, generally higher" PRINT "zxfactor weights digits towards the end, generally higher" PRINT PRINT "Enter znfactor, currently"; znfactor; INPUT ": ", znfactor: IF znfactor <= 0 THEN GOTO resetfactors PRINT "Enter zsfactor, currently"; zsfactor; INPUT ": ", zsfactor: IF zsfactor <= 0 THEN GOTO resetfactors PRINT "Enter zxfactor, currently"; zxfactor; INPUT ": ", zxfactor: IF zxfactor <= 0 THEN GOTO resetfactors ClearScreen: CLS : PRINT "*** LineAuto *** "; EnterRule: LOCATE 1, 18: PRINT "X-exit Enter-go NewClrMS Rule: "; LOCATE 1, 79: IF magnify = 0 THEN PRINT " "; ELSE PRINT "M"; nrf = 0: rp = 48: dp = 1: GOSUB ShowRule entry1: a$ = INKEY$: IF a$ <> "" THEN GOTO entry1 LOCATE 1, dp + rp: COLOR 2: PRINT CHR$(rule(dp) + rp); LOCATE 1, dp + rp: SLEEP 1: a$ = INKEY$: GOSUB RndStuff IF a$ = "" THEN GOTO entry1 IF a$ = "c" THEN GOSUB ResetColor FOR i = 1 TO 28: rule(i) = 0: NEXT i: GOTO EnterRule END IF IF a$ = "m" THEN GOSUB ResetColor IF magnify = 0 THEN magnify = 1 ELSE magnify = 0 GOTO ClearScreen END IF IF a$ = "x" OR a$ = Xclose$ THEN GOTO ExitProgram IF a$ = CHR$(13) THEN GOSUB ResetColor: GOTO DoAutomata IF a$ = CursorLeft$ THEN IF dp > 1 THEN GOSUB ResetColor: dp = dp - 1 GOTO entry1 END IF IF a$ = CursorRight$ THEN IF dp < 28 THEN GOSUB ResetColor: dp = dp + 1 GOTO entry1 END IF IF a$ = "n" THEN GOSUB ResetColor: GOTO RandomRule IF a$ = "s" AND scmode > 17 THEN 'change screen size scmode = scmode + 1: IF scmode > 21 THEN scmode = 18 GOSUB SetScreenMode: GOTO ClearScreen END IF IF LEN(a$) > 1 THEN GOTO entry1 IF a$ < "0" OR a$ > "9" THEN GOTO entry1 GOSUB ResetColor: PRINT a$; : rule(dp) = VAL(a$): nrf = 1 IF dp < 28 THEN dp = dp + 1 GOSUB ShowRule: GOTO entry1 SetScreenMode: SCREEN scmode IF scmode = 12 OR scmode = 18 THEN xres = 640: yres = 480 IF scmode = 19 THEN xres = 800: yres = 600 IF scmode = 20 THEN xres = 1024: yres = 768 IF scmode = 21 THEN xres = 1280: yres = 1024 RETURN ResetColor: COLOR 15: PRINT CHR$(rule(dp) + rp): LOCATE 1, dp + rp RETURN ShowRule: REM determine the biggest digit in the rule, cursor pos in dp maxdigit = 0 FOR i = 1 TO 28 IF rule(i) > maxdigit THEN maxdigit = rule(i) NEXT i rulesize = maxdigit * 3 + 1 IF rulesize < 4 THEN rulesize = 4 'not less than 4 REM print the rule, suppressing unreachable digits after cursor LOCATE 1, rp + 1 FOR i = 1 TO 28 IF i > rulesize AND i > dp THEN PRINT " "; ELSE PRINT CHR$(rule(i) + 48); NEXT i RETURN RandomRule: FOR i = 1 TO 28: rule(i) = 0: NEXT i 'zero previous rule nstates = INT(RND(1) ^ zsfactor * 9 + 2) '2 to 10 states znf2 = (znfactor * nstates) / 10 'adjust znfactor for number of states okflag = 0: IF znf2 < 1 THEN znf2 = 1 'minimum no weighting rulesize = (nstates - 1) * 3 + 1 FOR i = 1 TO rulesize 'weight lower with znf2, then higher for later digits rint = INT((RND(1) ^ znf2) ^ (zxfactor ^ (i / rulesize)) * nstates) rule(i) = rint: IF rint = nstates - 1 THEN okflag = 1 'ensure at least 1 max NEXT i: IF okflag = 0 THEN GOTO RandomRule 'do again if bad rule nrf = 1 'new rule DoAutomata: dp = 1: LOCATE 1, 18: PRINT "X-exit Spc-next EscPNBF "; : pkey = 39 GOSUB ShowRule 'also calculates maxdigit used below IF maxdigit = 0 THEN GOTO EnterRule REM initialize line to random states from 0 to maxdigit FOR i = 1 TO xres: newstate(i) = INT(RND(1) * (maxdigit + 1)): NEXT i ln = startline: GOSUB DrawLine 'increments ln by 1 or 2 if magnified IF nrf <> 0 THEN 'new rule, copy to history hp = hp + 1: IF hp > historysize THEN hp = 1 FOR i = 1 TO 28: history(i, hp) = rule(i): NEXT i 'save rule FOR i = 1 TO xres: historystart(i, hp) = newstate(i): NEXT i 'save start bp = hp 'set back pointer to current history ptr IF hp > maxhp THEN maxhp = hp 'highest saved history END IF: pp = 0 'clear previous starting pattern history Generate: IF pp < historysize THEN 'save starting pattern to allow previous pp = pp + 1: FOR i = 1 TO xres: previous(i, pp) = newstate(i): NEXT i ELSE 'save last fourth of history and reset pp to 3/4 LOCATE 1, pkeY: COLOR 4: PRINT "P"; : COLOR 15 'turn the P reminder red p5 = historysize / 2: p75 = historysize / 4 + p5 FOR j = historysize TO p75 STEP -1 FOR i = 1 TO xres: previous(i, j - p5) = previous(i, j): NEXT i NEXT j: pp = p75 GOTO Generate END IF __ScreenLock() 'prevents screen updates until unlock, comment for QBasic autoloop: REM copy newstate array to oldstate FOR i = 1 TO xres: oldstate(i) = newstate(i): NEXT i REM loop for each cell FOR i = 1 TO xres REM count the states in the neighborhood sum = 0 FOR j = i - 1 TO i + 1 k = j IF k < 1 THEN k = k + xres IF k > xres THEN k = k - xres sum = sum + oldstate(k) NEXT j REM use the count to get the next state from the rule array newstate(i) = rule(sum + 1) NEXT i GOSUB DrawLine IF INKEY$ = CHR$(27) THEN __ScreenUnLock() 'comment for QBasic GOTO EnterRule END IF IF ln < yres THEN GOTO autoloop __ScreenUnlock() 'comment for QBasic waitloop: IF INKEY$ <> "" THEN GOTO waitloop SLEEP 1: a$ = INKEY$: GOSUB RndStuff IF a$ = "" THEN GOTO waitloop IF a$ = "n" THEN GOTO RandomRule IF a$ = "b" THEN GOTO GoBack IF a$ = "f" THEN GOTO GoForward IF a$ = " " THEN ln = startline: GOTO Generate IF a$ = "x" OR a$ = Xclose$ THEN GOTO ExitProgram IF a$ = CHR$(27) THEN GOTO EnterRule IF a$ = "p" AND pp > 1 THEN 'go back to previous start pp = pp - 1: FOR i = 1 TO xres: newstate(i) = previous(i, pp) NEXT i: pp = pp - 1: ln = startline: GOTO Generate END IF GOTO waitloop GoBack: bp = bp - 1 IF bp < 1 THEN bp = maxhp RestoreRule: FOR i = 1 TO 28: rule(i) = history(i, bp): NEXT i 'restore rule FOR i = 1 TO xres: newstate(i) = historystart(i, bp): NEXT i 'restore start ln = startline: pp = 0: nrf = 0 'reset pointers, clear new rule flag GOSUB ShowRule: GOSUB DrawLine: GOTO Generate GoForward: bp = bp + 1 IF bp > maxhp THEN bp = 1 GOTO RestoreRule DrawLine: IF magnify = 0 THEN FOR p = 1 TO xres PSET (p - 1, ln), newstate(p) NEXT p ln = ln + 1 ELSE 'plot only half the line using 4 pixels per cell FOR p = 1 TO xres / 2 c = newstate(p) PSET (p * 2 - 2, ln), c PSET (p * 2 - 2, ln + 1), c PSET (p * 2 - 1, ln), c PSET (p * 2 - 1, ln + 1), c NEXT p ln = ln + 2 END IF RETURN RndStuff: 'called once a second while waiting for keypress z = RND(1) IF z < 0.01 THEN 'probably remove this block for QBasic FOR myi = 1 TO xres: FOR myj = 0 TO newstate(myi) 'loop through line z = RND(1): NEXT myj: NEXT myi 'calling rnd state times to scramble rng END IF RETURN ProgError: __ScreenUnlock() 'comment for QBasic LOCATE 1,1: PRINT "Error";ERR;"at line";ERL; " press E to exit "; errorwait: IF INKEY$ <> "e" THEN GOTO errorwait ExitProgram: SCREEN 0: SYSTEM -------------- end lineauto.bas --------------------
When compiled with FreeBASIC and executed it
produces images like these... (screen dumps from an earlier
version)
I've dabbled with line automata generators pretty much ever since
I had computers but they were limited to only 4 states since they
only had 4 colors in "high" resolution mode. My inspirations for
these back in the day usually came from the Computer Recreations
column in Scientific American (see LNAUTO references above),
however recently I've been reading "A New Kind Of
Science" by Stephen Wolfram and all the pretty pictures got
me thinking again. In the book many of the automata are fully
specified using his "rule" system where all possible combinations
of surrounding cells are specified, but this gets unwieldy fast
when there are more than a few states - for the 10-state automata
generator above fully specifying the next state would require a
1000 digit rule string to specify the next state for previous
states 000 to 999. Rather this lineauto program does what I have
always done and considers only the sum of states in the 3 cell
neighborhood, this method only requires a 28 digit rule for 10
states. Despite not being fully specified (or for that matter
hardly at all, the cell's previous state is just another
summation) the patterns it produces are very similar to the
original research, but with more color. This method is termed
"totalistic", a description of the method is in this reposting
of the May 1985 Computer Recreations column. My technique is
pretty much the same except I specify the rule string backwards,
starting with the next state for a sum of 0. This program is
compatible with the rule strings from LNAUTO and other line
automata programs I've made, but now the digits can range from 0-9
rather than being limited to 0-3.
Here's a QBasic-style program that converts the totalistic codes
from the NKS book into the lineauto rule string format...
'convert 1D automata codes from NKS to lineauto format digits$ = "0123456789" again: INPUT "Enter number of states (typ 3 or 4): ", ns% IF ns% < 2 OR ns% > 10 THEN SYSTEM INPUT "Enter NKS code to convert: ", code& result$ = "" calcresult: result$ = MID$(digits$, (code& MOD ns%) + 1, 1) + result$ code& = code& \ ns%: IF code& > 0 THEN GOTO calcresult PRINT "Equivalent lineauto rule = "; FOR i = LEN(result$) TO 1 STEP -1 'reverse the output PRINT MID$(result$, i, 1); NEXT i PRINT : GOTO again
...or use any number base converter, just reverse the converted
number string when entering into lineauto as it starts with digit
0.
Here's a zip
package (179K version 231203-12) containing the lineauto
source code, docs and binaries for Windows and Linux. The Windows
is 32-bit, worked on my VirtualBox Windows 7 and 10 installs. The
Linux binary is 64-bit to match the vast majority of systems, it
has dependencies - libX11 stuff, libtinfo libpthread etc - but
worked on a fresh Ubuntu 23.10 without having to install anything.
11/21/23 - Ok took a couple days to stabilize but I think the
lineauto program is doing pretty close to what I want it to do.
The basics have always worked fine since the initial posting on
11/19/23, which was suppost to be to make me stick a fork in it
but of course that never seems to happen, but it did have the
effect of locking in the basic concept so that I wouldn't tinker
with it too much. The tweaks and updates come from playing with
the program, fixing things as I go. Things like locking the screen
while updating to avoid screen flicker, which had the side effect
of making it much faster and making be run past interesting
patterns, so added rule and pattern history buffers to go back to
what I missed.
The other thing I was trying to figure out how best to randomly
generate rules that resulted in less noise and more good stuff.
With a rule string of 28 digits each 0-9 there are more than a
trillion trillion possible combinations, but the random number
generator has a 24 bit seed, so at best can output only about 4
million possible sequences so first step was adding additional
randomness by making extra calls to RND based on time at the
prompt and using the obvious internal source of entropy - the
automata states - to further perturb the random generator. This
should make it at least possible to generate a given rule string
(the universe might end before it lands on it, but being
theoretically possible is better than numerically impossible).
Simply randomly generating rule digits doesn't work so well, as
can be tested by running the program and pressing a key to pause
the intro screen then pressing W to set the weights all to 1 to
evenly distribute the digits. Pressing N repeatedly produces a few
interesting patterns but most of the rules just generate noise.
The trick is to weight the digit selection to tend towards smaller
digits and zero, more so when there are more states. Another
optimization I am experimenting with is weighting the rule string
digits for higher sums towards higher values, possibly canceling
out the weighting towards smaller digits, so that higher digits
tend to occupy higher sum positions and extra pattern generators
can live up there, I call these "gadgets". What I am noticing with
10 states is that makes the rule big enough that multiple types of
patterns can coexist at the same time. Simpler 4 state automata
did that too but it can do more of that when there are up to 10
states. The scheme I have now seems to work fairly well - it
doesn't take very many N presses to produce cool pictures that
likely have never been seen before - but I'm sure the weighting
can be improved. I'm still trying to get a feel for trying to
predict what a given rule digit distribution will do. Fortunately
many different rules will produce similar or even exactly the same
patterns, it doesn't have to hit it spot on. Sometimes with
interesting rules I'll zero out rule digits one at a time to find
the ones that have little or no effect. Sometimes seemingly simple
rules exibit surprisingly complex behavior, check out rule string
000340000000...
...in this case blue "won" but about half the time the red
triangles take over. Note that the 3 is in the sum 3 position and
the 4 is in the sum 4 position. So what happens if I add a 5 in
the 5 position? You guessed it...
2 and 6 didn't work but 7 did...
Let's add a gadget higher in the rule string...
...I so don't understand what's going on here, it's like peering
into the brain of an alien computer (or nature).
11/22/23 - One thing that was bothering me was the Back feature
to restore the previous rule didn't restore the starting pattern
so even though it was the same general pattern the image was
different. Now it saves and restores the starting pattern too.
11/27/23 - Here's a version of LineAuto written in Javascript...
Terry Newton <wtn90125@yahoo.com>