This page was archived from my old infionline pages so I don't
edit it much except to add notes like this... newer evolvers and
other corewar-related things are linked from my new(er) Core War
Files page, including YABevolver.
When I first set up this archive I added links to the newer
versions as needed but otherwise this stuff is quite old and
frozen in time. I fixed up the links below in "Related links and
papers" but didn't go beyond that as this is archive, expect
broken or incorrect links.
Evolving core warriors usually involves starting with a bunch of random redcode then running a process which battles them against each other, removing the low scoring ones and imperfectly copying the winners to unoccupied space. Several systems are available if you look hard enough, mostly for Unix but I managed to get a few running [in the early days, these days many evolvers are available for various platforms].
Related links and papers...
Listings and benchmarks of evolved warriors...
If anyone is wondering why someone might evolve warriors, there isn't a simple answer. If you aren't naturally attracted to artificial code-life etc this stuff probably won't make much sense. Why do people run Conway's Life? look at Mandelbrot plots? study Tierra? carefully tend to an aquarium full of evolving core warriors? Who knows, just stuff I do.
I probably need to start a section for dos batch files... these aren't particular to any one evolver...
TESTALL.BAT - benchmarks all warriors
in
the
current directory against c:\warbench\*.red and produces a report
in
warbench.txt
containing sorted scores and a listing and performance chart for
each
warrior
tested. Requires qbasic and pmars, edit batch to specify command
line
and
bench directory, set to 800 size, 100 rounds fixed. The original
TESTALL.BAT can only handle up to about 300 rounds before messing
up
the chart (and doesn't work in FreeDos), the version I presently
(2/09)
use is in testall.bat.txt
with the settings in a separate testaset.bat.txt
(from my other cw
files,
rename them .bat to run).
BATTLE.BAT - runs a hill on all redcode in current directory. Requires pmars and scorelog.bat, edit to specify pmars parameters, set to size 800 100 rounds fixed.
SCORELOG.BAT - processes a pmars-generated log file and produces a sorted list of scores. Requires qbasic.
SAVERD.BAT and LOADRD.BAT - batch files for saving and loading ram disk contents.
Many other batches are scattered about this page. All are for
msdos
6 or greater, tested only with dos7/win95 except for some old ones
from
the 3.1 days. Most require QBASIC.EXE, which was shipped with
older
doses
but nowadays usually isn't installed by default. Sometimes it's on
the
Windows CD in other/oldmsdos, it's also on Microsoft's web site...
somewhere.
Try: ftp://ftp.microsoft.com/Softlib/mslfiles/OLDDOS.EXE
- at least that's where it was [these days it's all over, look for
qbasic11.zip].
The first evolved warriors I "brewed" were produced using the GA_WAR program by Jason Boer. No modifications were made to the software, just compiled it with Turbo C++ (for Dos) and it worked the first time.
These batch tools were also used...
MARS.BAT - a shell for pMars with
options
for battling and scoring groups of warriors.
TESTRC.BAT - a batch for battling and
scoring
group of warriors against one or more groups.
SCORELOG.BAT - processes raw scores
to
produce
ordered warrior score percentages.
INSPECTS.BAT - inspects raw scores
to see
how a particular warrior performed.
The latter two are command-line utilities that duplicate the scoring and inspect functions of MARS.BAT, but faster when analysing logs from previous battles. All require QBasic. Some call LIST for listing results. If you use these, you'll probably have to customize them to your system and needs, in particular edit TESTRC.BAT to set the correct pMars directory.
If you tuned in earlier you saw preliminary results but I have better data now, so time to prune the complexity of this page once again to make room for new results. To summarize, I used Jason's GA_WAR program to create a population of 40 warriors which I let evolve for a total of 3968 generations, taking samples at various points and also making changes to the config file as I went. In total, I ended up with twelve directories, a main and valhalla directory with 40 warriors apiece sampled at six different generations.
What's interesting about Jason's evolution program is it's a closed system - external code is never used to evaluate anything. It all begins with randomly chosen instructions which pass only the minimum of fitness, then they are mutated and crossed amongst themselves. As they battle each other the evolution system copies definite winners over definite losers while slowly introducing random mutations into the mix. The good mutations win more, so pass their code on to the now lesser members of the population. Highly simplified but close. After thousands of iterations a few can hold their own against some human-written warriors, but only incidently. Except for messing with the config file and picking out winners, these evolved warriors have no benefit of human encounter, no opportunity to better themselves in response to a new threat. They're at the bomber (and crasher:) stage of evolution, it'll be a long time before a paper pops out of the pit. A vampire maybe?
One thing for certain, consistant corewars is not - a warrior that does good against one test set does not necessarily do well against another. And unless a large number of rounds are played per battle the results are not accurate. That includes the results so far which were scored at 20 rounds per. Not enough really, a warrior can get lucky a few times and end up with an inflated score. The problem is numbers and processing time - evolving the ha_ series produced 480 warriors to have to sift through, most of which are not very good.
What I did was use a master job batch to call TESTRC many, many times to battle everything against three test sets: the first set of 7 older warriors (mice, bravo, etc), a group of 28 warriors from my corewar page, and a set of 12 benchmark warriors picked out by someone, can't remember who. Good set though, they slam. I ran separate tests against all three sets at 25 rounds per battle, this took a couple of days. Next I picked out everything that scored 45% or better against the easy 7, 33%+ against the diverse 28, and 20%+ against the difficult 12. This gave me 23 possibilities after weeding out the duplicates (made a neat batch for doing this, of course). Currently I'm battling them all at 100 rounds against all of the benchmark warriors at once, 44 warriors in all which I hope will give me a reasonable cross section. Once I get the best-of-the-best from the ha_ generations, it'll be time for another full-play battle along with a couple of samples from earlier runs (especially that ez_16) and a couple of evolved warriors from others to see where we all stand.
For this test I selected the best 8 of the ha_ series, 2 of Jason's evolved warriors (ga_24 and zz_972), 2 evolved warriors from previous runs (ez_16 and cz_3), 2 evolved warriors produced by "karl", the 12 really good benchmark warriors and 6 more older ones thrown in for good measure, 32 in all. In this test, every member plays every other member twice, once in each position, and itself once. The battles were run 50 rounds per match, each warrior battles each warrior a total of 100 times.
073.1 Porch Swing by Randy Graham
073.0 Marcia Trionfale 1.3 by Beppe Bezzi
071.3 nobody special by Mike Nonemacher
070.7 TimeScape (1.0) by J. Pohjalainen
067.7 Rave by Stefan Strack
067.7 Paperone by Beppe Bezzi
062.7 Iron Gate by Wayne Sheppard
061.2 Thermite 1.0 by Robert Macrae
058.1 Cannonade by P.Kline, Paul Kline, pk6811s@acad.drake.edu
056.4 Blue Funk 3 by Steven Morrell
049.6 Ecstacy by : Stefan Roettger / Sandstrasse 3 / W-8525 Uttenreuth / Germany
047.9 MICE by Chip Wendell
047.6 Torch by P.Kline
045.2 Fire Storm v1.1 by W. Mintardjo
042.8 zz_972.red by Anonymous
042.1 ha_5.red by Anonymous
040.9 ha_36v.red by Anonymous
040.3 Comper-2a by Andy Pierce (ajpierce@med.unc.edu)
040.1 Virus by Jay Han
039.7 Tornado by Beppe Bezzi
038.5 ha_37.red by Anonymous
037.6 ha_18.red by Anonymous
033.5 GA_24.red by Anonymous
029.2 W0078V00 by RC94 Evolver v2
029.0 ez_16.red by Anonymous
028.8 ha_31a.red by Anonymous
027.8 ha_28c.red by Anonymous
027.8 ha_12c.red by Anonymous
027.7 Bravo by Corey Lynn Nelson
027.0 ha_3c.red by Anonymous
023.5 G008W041 by RC94 Evolover
023.1 cz_3.red by Anonymous
Performance of some using the "Wilkies benchmark"...
HA_31A
pmars -r 100 HA_31A.red HA_31A.red
- - - - - - W L T Score
time.red : 0 76 24 24
nobody.re: 0 82 18 18
paperone.: 4 77 19 31
marcia13.: 0 84 16 16
bluefunk.: 0 18 82 82
cannon.re: 54 33 13 175
tornado.r: 25 14 61 136
fstorm.re: 71 26 3 216
rave.red : 14 86 0 42
irongate.: 17 78 5 56
pswing.re: 2 67 31 37
thermite.: 6 53 41 59
- - - - - - - - - - - - - - -
Total wins = 193
Total losses = 694
Total ties = 313
Overall score is 74.33334
HA_3C
pmars -r 100 HA_3C.red HA_3C.red
- - - - - - W L T Score
time.red : 0 96 4 4
nobody.re: 1 98 1 4
paperone.: 0 86 14 14
marcia13.: 0 100 0 0
bluefunk.: 0 15 85 85
cannon.re: 39 60 1 118
tornado.r: 29 18 53 140
fstorm.re: 66 33 1 199
rave.red : 12 88 0 36
irongate.: 43 54 3 132
pswing.re: 2 92 6 12
thermite.: 1 64 35 38
- - - - - - - - - - - - - - -
Total wins = 193
Total losses = 804
Total ties = 203
Overall score is 65.16666
EZ_16
pmars -r 100 EZ_16.red EZ_16.red
- - - - - - W L T Score
time.red : 0 99 1 1
nobody.re: 0 99 1 1
paperone.: 5 85 10 25
marcia13.: 0 100 0 0
bluefunk.: 0 15 85 85
cannon.re: 36 63 1 109
tornado.r: 28 18 54 138
fstorm.re: 46 54 0 138
rave.red : 44 56 0 132
irongate.: 47 51 2 143
pswing.re: 5 67 28 43
thermite.: 1 86 13 16
- - - - - - - - - - - - - - -
Total wins = 212
Total losses = 793
Total ties = 195
Overall score is 69.25
The Sys 4 evolver is a set of perl scripts written by George Lebl that simulates a two-dimensional array of redcode where the warriors battle their neighbors. It is alife-like in its approach, very interesting to watch...
Here's a dos/win32 version of Sys 4, includes the original code in a tar file. It's GPL. See port notes. To run you'll need a Windows 95 machine, Perl for Win32, and pmars 0.8 for dos. You'll also need QBasic (and maybe other "missing" dos files, get the dos suppliment from MS), and some test warriors like those from the Wilkies Benchmark.
Warriors it made for me...
Benchmarks...
OZEL106
pmars -r 100 OZEL106.red OZEL106.red
- - - - - - W L T Score
time.red : 1 93 6 9
nobody.re: 0 95 5 5
paperone.: 2 83 15 21
marcia13.: 0 100 0 0
bluefunk.: 0 22 78 78
cannon.re: 14 82 4 46
tornado.r: 23 22 55 124
fstorm.re: 71 26 3 216
rave.red : 34 66 0 102
irongate.: 32 65 3 99
pswing.re: 7 56 37 58
thermite.: 11 50 39 72
- - - - - - - - - - - - - - -
Total wins = 195
Total losses = 760
Total ties = 245
Overall score is 69.16666
BMEA014
pmars -r 100 BMEA014.red BMEA014.red
- - - - - - W L T Score
time.red : 0 91 9 9
nobody.re: 0 98 2 2
paperone.: 3 86 11 20
marcia13.: 0 100 0 0
bluefunk.: 0 23 77 77
cannon.re: 42 33 25 151
tornado.r: 25 37 38 113
fstorm.re: 68 26 6 210
rave.red : 15 85 0 45
irongate.: 47 52 1 142
pswing.re: 7 70 23 44
thermite.: 12 56 32 68
- - - - - - - - - - - - - - -
Total wins = 219
Total losses = 757
Total ties = 224
Overall score is 73.41666
DZAR513
pmars -r 100 dzar513.red dzar513.red
- - - - - - W L T Score
time.red : 0 94 6 6
nobody.re: 1 96 3 6
paperone.: 0 84 16 16
marcia13.: 0 78 22 22
bluefunk.: 0 19 81 81
cannon.re: 21 58 21 84
tornado.r: 23 21 56 125
fstorm.re: 83 17 0 249
rave.red : 23 77 0 69
irongate.: 43 51 6 135
pswing.re: 1 73 26 29
thermite.: 4 56 40 52
- - - - - - - - - - - - - - -
Total wins = 199
Total losses = 724
Total ties = 277
Overall score is 72.83334
My implementation makes heavy use of batch files and although it's designed for Windows 95 it's as dos as it gets. As far as the port itself, the modifications are mainly confined to the sys4.pl file. I'm not really a Perl programmer, but I can cut paste and hack until it works... Fortunately it didn't take much, pipes and messages aren't the same (if they even exist...) in the Windows environment so pipes are changed to temp files (that's what they are anyway) and messages, unless I figure out how to do it otherwise, are passed by deleting signal files. Crude but effective. Another irritating aspect of Perl under Dos is a script cannot rerun itself, at least not without keeping the old copy in memory. Something about extreme string manipulation for hours makes it run out of memory so if it doesn't periodically restart it'll be waiting with an 'out of memory' message for the operator. To solve this problem, the code was modified to write a flag file and terminate so that a batch file can detect the flag and rerun the script. So that it remains self-contained the script is contained within the batch itself.
The front end batch handles the starting and stoping of tasks and allows the evolved warriors to be charted and examined in various ways. The tasks involved are initialization, evolution and testing. Evolution shouldn't run while testing, and neither can do anything until initialized, the menu options change to indicate what's available to do. For looking at the warriors, the array can be mapped by name, size, score or generation. An inspect option overlays a cursor for listing, testing, editing, saving and deleting individual warriors. Finally got color! All this coolness comes at a price though, being "just" a batch file it's subject to errors should your installation differ much from mine, to get it running not only to you need Perl for Win32, but qbasic, find, mode, debug and other standard dos commands. Standard Windows 95 installations leave out some of the files but they are on the Windows installation CD and downloadable from Microsoft.
File updated March 6, 1998 - If today's date is anywhere close
consider
it under construction...
Latest hacks: minor... makeword.bas now included in slightly
cleaned up
form, handy thing to do between runs. Added back an ansi home
option
for
me and anyone who still uses ansi, edit batch to enable.
August 15, 2000 - Link to SYS4CONV.BAT - an msdos batch file that converts other warriors to System 4 format, qbasic and pmars must be on the path. Warrior must start execution on the first redcode line, hardcoded for length 25 - edit batch and change set maxlen=25 for other lengths.
Evolutionary Observations...
Scores for evolved warriors made by either Sys 4 or Ga_war tend to top out at less than 80 in my experiments, decent man-made warriors usually score well over 100. My warriors might get 60 on a good day. There are reasons why better warriors don't appear, first and foremost is the evolution array usually fills up with brain-dead djn thingies (the worst are like ez_16.red, a single DJN instruction) and a warrior that does well against such stupidity usually will not do well when battled against real code. The inverse is also true, a warrior that does well in benchmarks usually gets devoured by the djns. Good warriors can appear only to be swallowed up by simpler forms. Such is life! They must get detected and saved before they go away. One trick that seems to work is to delete all of the warriors except for a few high scorers. Another trick might be to introduce "predator" code into the warrior array, Sys 4 saves family names, making it easy to ignore the damaged predator code.
Evolved warriors are an alife thing to me, entities which arise out of random change and natural selection. Comparing them to warriors written by programmers is an indication of strength but there should be no false expectations. They are their own kind and play by their rules. To further the alife aspect there should be communication of warrior samples between evolution pools (all 3:). In a way there is... the samples on this page, terrible as they are, can be used to give evolution a kick-start and further their own designs. If someone (or something) emailed me an evolved warrior it's no biggie to put it in the current brew.
Sys4 brewing notes... here's a frustrating thing... evolving a mix for a long time often produces no better results than evolving a short time. Evolution is a luck kind of thing, and usually there is not enough luck to go around for a core creature family to change from one code form to another and survive, the best it can do is improve the existing form. Poor forms still make great stupid code killers so they quickly take over, but are what they are. The trick is in the genesis, workable forms must exist at the get-go. Granted, the evolution can take the most wretched code and get it scoring in the 45 (15%) range but a good mix should score that after only a few generations. If not, start over. Real life evolution takes millions of years and members. Given the limited confines and relatively no pressure environment of corewarrior evolvers, it's not surprising that they often don't improve much. There is no reason for them to.
Ways to exert more pressure...
Randomly benchmark the warriors and delete the bad performers.
Mobility - in Sys4 warriors are stuck where they are, move the
files
around.
Directly insert good warriors, but I keep shying away from the
idea.
Keep good evolvees from many runs then put them all in the same
soup.
Generate new random warriors in large unoccupied spaces, one
might get
lucky.
Even with much effort, sometimes they just don't grow into what I would consider acceptable. I recently added a 'run' option so that I can cursor to a warrior and see what it does when it runs by itself in the core. Facinating... and sometimes depressing. In the early going, the only pressure is to make code that just runs but doesn't particularly do anything, but if better at doing nothing than its neighbors it can take over leaving the brewer with a bunch of nothings. If ran long enough they eventually turn into something but usually it isn't good. Tweeking the minscore and maxscore variables help but got to be careful, warriors that perform halfway decent often score 100 against themselves, scores of 300 usually mean the warrior was surrounded by nonfunctionals. You can't go by the scores when picking out good code, but a cluster of 20s might indicate a species that wins or loses against itself, 5 5 0 instead of 0 0 10.
This is an experimental evolver I put together using QBasic to serve as an idea testbed. I'm too impatient to learn a new language and modify existing code, so I decided to start from scratch in a less stressful language. It came together a lot faster than I expected, even works...
The look of the display is similar to the colorized Sys4 map script, updates in real time. In the original Redmaker 1, all variables are set by editing the basic program. Redmaker 2 has an interface for browsing the warrior array and provides access to most of the parameters without editing. For MsDos (or dos under Windows), requires the pmars software. The .bas files require qbasic.exe to run interpreted, in the olddos.exe package from Microsoft.
Here are some RedMaker warriors...
September 2000 - lately the SourceForge Corewar Tiny Redcode hill has been a battleground for evolved warriors, this hill uses a coresize of 800, 800 max processes and 8000 cycles. Some of my efforts.
RedMaker notes...
The evolution engines of the original RedMaker 1 and version 2 are practically identical, the main difference is version 1 has no user interface, edit the source code to change parameters. I got tired of having to browse and test the output manually, so added a user interface so I could cursor to a warrior and run in pmarsv, list or benchmark. Parameter screens allow access to most of the variables, the settings can be saved to a data file to make default. The new version is supplied as both a .bas and a compiled .exe file, there isn't hardly any speed difference but qbasic.exe is getting rare these days. The .exe version needs only dos and the pmars software on the path or in the same directory.
I've noticed a few things that majorly impact evolution speed and effectiveness. The chosen instruction set makes a lot of difference! If the full corewar instruction set is used, the warriors can evolve to be a bit stronger but it takes much longer. Selecting fewer, more useful instructions yields much faster results. The new version allows no modifiers to be specified to produce simpler '88 style instructions. Core size makes a big difference, things happen faster at 800 rather than the traditional 8000 location core. The evolution rate parameters, particularly line change rate, make a noticeable difference. Line change rates of .05 or less eventually yield stronger code however the higher rates make things happen quicker and produce more differentiation among members of the same species. Directed evolution can also be specified, this requires that all new members beat a specified warrior, defaults to jmp 0 but that has a tendency to produce many boring single instruction core clears (that often score quite well but not quite what I'm looking for). If the junk gets too much, remove the DJN instruction.
Link to RDRED.BAT, a batch I use to run Redmaker on a ram disk and keep the warriors compressed in a zip file. Requires PkZip and PkUnzip to operate. Before using, edit the batch to indicate the letters for the hard drive and the ram drive. As written runs the uncompiled version, change the line 'qbasic /run redmaker' to just 'redmaker' to use with the compiled version. (Aug 15 2000 - another ramdisk runner for Redmaker, RED.BAT)
RedMaker 2.5 was posted Aug.15, 1998. Program archive last changed Nov. 5, 1999 - version 2.7 - modified to allow using small cores, provided access to the pmars/pmarsv command line parms for tweeking, like using "-b -l 4 -d 4" for making "itty bitty" warriors for coresize 80. Other minor additions and bug fixes. No changes to the main routines.
August 14, 2000 - Link to RMCONV.BAT, a batch I made that converts general redcode into a form that Redmaker can evolve. Redmaker warriors must begin execution on the first code line, if the warrior uses ORG or END x then it cannot be converted as-is - add a jump to the entry point to make partially equivalent. Note - RMCONV.BAT requires both qbasic.exe and pmars.exe in a path directory. Takes input and output files as command line parms, to convert say warrior.red to aa.red, drop to a dos prompt in the directory and enter "rmconv warrior.red aa.red". Without the quotes of course. Input and output file can be the same to overwrite the original, as in "rmconv my.red my.red". August 15 (b) version - 4 character name can be specified on command line, as in "rmconv my.red bc.red BcBc".
August 15, 2000 - here's what I've been using to sort through RedMaker's output... RMBENCH.BAS. Requires Qbasic [Sept. 2 - no longer requires scorelog.bat, copied into the program to avoid memory problems]. Benchmark paths and pmars command lines are hard-coded, edit (or configure your bench directories to match) before using. RMCONV.BAT updated to ignore assert line, made same mods to SYS4CONV.BAT. To make it easy to convert an entire hill to redmaker I made RMALL.BAT, converts all warriors in the current directory (up to 20 or so) to redmaker format, leaves in rmconv directory with a log of what's what. Rmconv.bat must be on the path or in the current directory.
August 17, 2000 - uploaded Redmaker 2.8 - fairly minor change to add an option for battling twice with the warrior positions reversed. Thanks to Martin Ankerl for suggesting this little trick that helps to produce more interesting forms. Finally I was able to evolve replicators, a few appeared in one of the species after about 14000 iterations with the survival score at 95 (which also allows lots of dud code to exist if not challenged). After raising the survival score to get rid of the duds the replicators disappeared too... which was not unexpected since they generally tie against themselves.
August 20, 2000 - replaced with Redmaker 2.81 - added an option that replicates the selected warrior immediately if it won and the warrior it was battling was removed. Before it had to first clear space, wait another turn and then possibly get a chance to replicate - if a lesser form doesn't crowd it out and force it to do battle again.. now, if the "Replace removed loser" option is selected it replaces the beaten warrior with an evolved copy of itself, thus rewarding stronger performance with extra replication. Sounds good in theory... seems to help but about everything about this stuff is a "seems". Results of any one run do not necessarily reflect on the quality of the chosen parameters.. sometimes it does.
August 31, 2000 - New features for version 2.83...
Optionally tracks code origin and generation number in comments appended to warriors, and if "all" is selected also notes parent(s), number of battles survived and average score but that takes more disk access. Under parameters, start/eval. The origin comment stays with all offspring. To help track re-evolution experiments, updated RMCONV.BAT so that it extracts and records the original warrior name in converted warriors.
Added an experimental crossover option - Normally, Redmaker chooses a random warrior, then chooses another surrounding cell. If the surrounding cell is occupied it battles the two warriors and removes the one that loses or scores below a certain level. If the chosen surrounding cell is not occupied, the focus warrior is evolved to create a new warrior to fill the empty cell. If crossover is enabled, then before replicating another surrounding cell is chosen, if it contains a warrior of the same species, then code from both warriors are used to make the offspring otherwise replicates from the one parent. A courseness variable (under parameters, other) determines how fine the blend is, larger numbers result in larger intact chunks. The warrior to pull from first is determined randomly. Well... theoretically it should work, we'll see...
Finally, a fun new feature - can now visually battle the selected warrior against any of its neighbors to see what becomes of the code under combat conditions. Use the numeric keypad to select the warrior to battle against, for example [4] for west, [3] for southeast, etc. The [5] key battles against self.
September 2, 2000 - apparently the crossover option doesn't hurt... at least the strongest of an evolving population increased in strength when I enabled mixing. Notes about evolving size-800 warriors have been moved to tinyevol.html.
March 25, 2001 - new RedMaker version 2.84, mostly interface changes but added a new "RedMix" mode that bypasses the species check, perfect for mad experiments like evolving hill warriors into an existing soup. Made a vain attempt to account for multiple origins on the origin comment line. Minor changes like always taking evolved code from the selected warrior first regardless of mixing (was random pick), the selected warrior is used to determine generation count since usually it's the first lines that matter the most. Major interface change, now it can display warriors not only by species but also by length or battles survived, gets the color back when the soup becomes all the same species and also useful for visualising sub-species evolution and hunting down successful code. Useful interface change, now the soup directory can be specified, set to a ram disk to avoid the hassle of having to copy program and all to ram disk, just use saverd and loadrd batch files to save whatever is on the ram disk between boots. New default parameters for 800-coresize and weighted instructions.
March 29, 2001 - new RedMaker version 2.85 - finally coded it, now there's a "fix local refs" option to sometimes or always adjust numbers that refer to positions changed by insertion and deletion operations. This tends to preserve algorithms and avoid breaking the evolved warrior.. although sometimes it is beneficial to break it in the hopes of creating a new algorithm so I think I prefer the sometimes option, evolution will sort it out.
April 6/7, 2001 - 2.85a - default parm changes: adjust local refs off, double fixed battles on. The adjust local refs option helps to optimise an already interesting form, however when starting out it tends to limit the production of new strategies in unoptimised warriors. 2.85b - changed several other default parms, worked a bit on source code formatting.
December 27, 2004 - new RedMaker version 2.91 - This version was edited and compiled while running under Linux, using DosEmu running FreeDos, and it feels like MsDos 6 in a window. Cool! The same fixes that make it compatible with FreeDos also make it run well under XP (SP2) using SDL_pMARS. Now includes automatic save and restore functions, enable under Start/Eval Options (default is disabled). Saves are triggered when a warrior lasts a specified number of battles, and reintroduced according to a chance variable by default .005 or on average once every 200 iterations (can be 0 to disable reintroduction). The maximum number of saved warriors is adjustable (default 50) and you can change the save directory (warsave). Now that I can evolve while running Linux using good old QBasic it might take a bit more convincing to learn the "standard" languages... like C. Emulating MsDos under Linux takes a toll but it's not that slow, I'm getting about 10 iterations per second under Linux and the old pmars08 binary verses about 20 iterations per second using XP and the SDL binary, hard to say how much is because of the OS and how much is from using a faster version of pmars.
YACE stands for "Yet Another Corewar Evolver", it's a
Ga_War-style
evolver from Martin Ankerl, publically released in August of 2000.
Yace 0.01
Local copy in yace01.zip
This evolver is much like Ga_War - no user interface except that of editing a config file, no graphic display of the members, no support for separating and tracking multiple species, just an evolving soup of warriors. YACE supports Ga_War-style n-dimensional battling plus two different 1-dimensional topologies. One of the coolest things about YACE is it uses an internal redcode simulator, Exhaust, rather than depending on pmars, making it fast and unobtrusive. Exhaust is slightly slower than pmars on long battle runs but for short runs, typically 10 battles, and particularly when evolving 800 size warriors, what speed difference there is is more than made up for by not having to load pmars for every battle.
A 32-bit C compiler appropriate to the OS is needed to produce an executable, I used the GNU gcc tools that came with Bloodshed Dev-C++ to make a console (dos) application for Windows 95, using the supplied makefile and also by adding the program sources to new Dev C++ and VIDE (another shell for gcc/mingw) projects with each environment's default settings. The program uses the files yace.c, sim.c and asm.c, the exhaust.c file is a stand-alone interface for the exhaust redcode simulator and isn't used by the yace program, so does not need to be added to the project file. The simple way to make the program if you have compatible compiler tools installed is go to a prompt and enter "make", on my system this resulted in a 43K executable. Gcc issued warnings about Exaust's sim.c (signed/unsigned comparison on lines 156, 428 and 437) but these can probably be safely ignored. Using the integrated environments, Dev C++ produced a 31K executable and VIDE produced a 23K executable, no warnings were produced by either environment. All three of the executables function properly.
YACE needs to run from a directory besides the root, and the subdirectory "valhalla" must exist under yace's directory. Operating parameters are initiated by a configuration file, edit the file "yace.cfg" to change. Dos/win users must change the path separater to "\\". Each cycle, the file cycle.txt is written with the cycle number on the first line followed by current status. If the cycle number reaches the maximum specified in yace.cfg, or if the cycle.txt file cannot be written, the program terminates. To start a new run, create_new_population (in yace.cfg) must be =1, otherwise =0. If 0, starting_cycle should equal the cycle to start on. For best results the program should be run from a ram disk, like most evolvers it generates lots of disk access.
To make YACE easier to use I created a couple of batch files, RUNYACE.BAT checks for cycle.txt and if it exists updates yace.cfg using an echoed qbasic program then copies yace.exe, yace.cfg and all redcode in current and valhalla to ramdrive and runs yace.exe. When yace.exe terminates it copies cycle.txt and the redcode back to the harddrive. STOPYACE.BAT marks the cycle.txt file read-only to cause yace to stop, if a ramdrive copy is present it marks that one (as written there must be a drive besides the current to check), else marks the cycle.txt in the current directory. This is not exactly "proper", the remaining cycle.txt file refers to the previous generation but no other ill effects noticed. To compensate, RUNYACE bumps the cycle.txt count by 2 when calculating the starting generation. Batch files must be edited to specify the drives before using, as written D: is the hard-disk with the evolver program and F: is the ramdisk.
Aug 23, 2000 - I've only fooled around a bit with a population of 20 warriors, so far by around generation 5000 or so the best score is around 60 against ten 800-size warriors written by Franz. Similar results against the SF tiny hill. I don't think a population this small can take off to any great degree but even so diverse forms were produced, no papers but some look like they want to replicate.
Yace 0.02
Local copy in yace_0-02.zip
This version was released September 3, 2000 and is very different than the previous version. It evolves completely in memory, practically eliminating any need for ramdisk batches - it is running now as I edit this page and there is almost no disk access or any detectable drag on the system, despite close to 100% usage of free cpu time. Installation was trouble-free, I downloaded it, unzipped to a folder I called Yace02 and it creates directories for src, bin, out, save and testset - I went to a command prompt under src and entered "make" - worked perfectly, no warnings, just an executable in the bin directory. The release I got didn't have any instructions... so I ran it. Every 20 cycles (changeable in config file) it saves population warriors to the save directory, also at intervals the population is tested against the warriors in the testset directory and the highest-scoring warrior is placed in the out directory.
Sept. 4, 2000 - The original 0.02 had no exit mechanism, which was a problem for my old win95 box with broken control-break processing when running 32-bit console apps compiled with mingw/gcc. [ends up mingw has worse problems than that, recommend using Cygwin or other to compile] To solve this and similar exit problems the author sent to me a modified YACE that provides a file which will terminate the program when deleted. Perfect, a simple batch that deletes the file can be the "off" switch.
While awaiting termination instructions YACE 0.02 was able to get in a full overnight run. (clever :-) The warriors in the out directory are named according to their score, together with the file date it's easy to see trends... looks like the population steadily grew from the 40's at 8pm to a peak score of 133 around 11pm, then the scores dropped to 60's but came back for a stronger peak of 143 at 2:30am. After dropping slightly then another peak of 130 about 3:30am it's been pretty much down-hill, currently best scores against the testset are in the 60's. YACE's automatic testing and extraction is a very nice feature - no lengthy tests, provides a continuous record of the soup's progress, and nothing is missed. Normally I would have awoke to find weak warriors, oblivious to the much stronger warriors that arose and fell during the night, then have to spend hours evaluating the results... just for one datapoint - this is much better. Now if the population would just get it together again and make another climb...Sept 6 - The 0.02 code crashes intermittently when compiled with the mingw tools, so installed the Cygwin compiler from sources.redhat.com/cygwin/ using the setup.exe on the web page, took hours and about 100 megs of disk space but don't even think about trying to install the pieces manually. After adding cygwin\bin to the path line, "make" worked fine and produced a functional exe.
Things are starting to pick up in the soup...
filename date time score
------------ -------- ------ -------:----=----=----=----=----=----=:
ev_11833.red 09-05-00 9:04p 118.33 :*********** :
ev_13167.red 09-05-00 9:41p 131.67 :************* :
ev_13000.red 09-05-00 10:44p 130.00 :************* :
ev_14000.red 09-05-00 11:03p 140.00 :************** :
ev_13500.red 09-05-00 11:22p 135.00 :************* :
ev_13667.red 09-05-00 11:42p 136.67 :************* :
ev_14667.red 09-06-00 12:02a 146.67 :************** :
--------------------------------------:----=----=----=----=----=----=:
Chart by chartout.bat - seemed like a thing to do. Scores are against the 6 warriors included with the package, tiny hill scores are presently in the 80's. All of these are papers, 14667 has only 3 functional lines...
spl.x # 17, < 787
mov.i < 3, { 247
djn.f { 249, { 406
dat.b * 208, > 14
Sept. 22, 2000 - text file with a couple of trivial mods for yace 0.02 - my version of an delete-file exit mechanism, and a mod that avoids overwriting existing warriors in the out directory.
Yace 0.03
Local copy in yace_03.zip
This version was released September 18, 2000, and includes an executable so it's ready to run on Windows computers in console mode, like a dos program.
I haven't had time to really give this one a workout yet but initial observations... No problems running it, beforehand I edited the config file to specify \\ as the path separator and dropped the population size, after running for awhile on my slow computer I had a bunch of warriors in the bin\status, bin\koth and bin\soup directories. Koth includes an html file illustrating who beat who, neat. The warriors aren't that strong yet but the run is just getting started.
Yace 0.04
Released October 6, 2000 on Martin Ankerl's web site with a minor archive update on October 9. Compiles fine using Cygwin "make", produces a 65K exe file on my machine. For Windows be sure to edit yace.cfg and change the path separator to "\\". So far it works ok in testing, after about 3 hours on my 133mhz the best status warrior was scoring about 110 against the tiny hill (population size = 50 for testing, will probably have to increase to improve scores).
Added to yacebats.txt...
CHARTSTA.BAT - a modification of
chartout.bat
for charting the performance of warriors in the status directory.
Yace 1.0
Dec. 16, 2000 - a new release of Yace has been posted to:
[old link removed] 3/16/06 - local copy in yace_1_0.zip
This one comes with a pre-compiled Win32 exe and is similar to the 0.04 version. I tried it out with a population of 100 and it got up to a "sourceforge" score of around 110 after an overnight run. Chartsta.bat (for Win95) works fine for tracking the results over time.
The new benchmark function doesn't rate my system very well...
-------------------------------------------------------------
Fights per second (the higher the better): 120.67
Tolerance (should be lower than 2 percent): 3.49%
-------------------------------------------------------------
0.09 times faster than AMD Duron650, PC133, Win2k.
I have a 133mhz AMD 586 with Windows 95 - I suppose one day I really should upgrade...
After a few more days (a few hours on good systems:) the soup is thick with papers scoring around 125 on various benchmarks. To help tally the results I made "BENCHKOT.BAT" (in the yacebats.txt file) to take a snapshot of the "koth" directory and produce a file containing benchmark charts and listings of the warriors. I had to edit some of the test warriors to get their names reasonably correct, some were missing the newline after the ">" in the email address, in one case resulting in an "unknown" warrior in the bench report from my batch. Other files were in unix format which I fixed with "qbasic /edit" for compatibility with notepad, but the evolver and most other programs don't care. These are minor batch-detected "features", the evolver itself has been totally stable, both the included exe and one compiled with Cygwin, benches ~100 fps.
Things were picking up, then the population went down...
13400000.red 12-19-00 11:16p 134 :************* :
13200000.red 12-20-00 12:07a 132 :************* :
13020000.red 12-20-00 12:50a 130 :************* :
12925000.red 12-20-00 1:34a 129 :************ :
12745000.red 12-20-00 2:24a 127 :************ :
12210000.red 12-20-00 3:20a 122 :************ :
12085000.red 12-20-00 4:11a 120 :************ :
04015000.red 12-20-00 5:01a 040 :**** :
03965000.red 12-20-00 5:56a 039 :*** :
05360000.red 12-20-00 6:52a 053 :***** :
The koth directory is doing better, 12 out of 21 warriors are
scoring
120 or better, top score 127, low score 77 using the Franz test
set.
However
a previous test performed just after the peak (first line of the
above
chart extract) shows all koth warriors scoring more than 119 with
6
scoring
around 130. Notes.. the status scores in the chart are against the
SF
tiny
warriors and are only roughly comparable with the Franz results (I
think
I'll switch to the Franz set for status too). Population size is
200,
hill
size specified as 20 (results in 21 warriors), duplication_rate
from
0.5
to 0.2, soup battles set to 20, koth/testset battles set to 50.
The latest version of YACE is at: http://corewar.co.uk/ankerl/yace.htm
Download Fizzle 1.2 for Windows (but it's a "dos" program) · last modified 9/30/03
This is a fairly simple evolver I wrote to try out a few ideas in the hopes of evolving stronger warriors. The name "Fizzle" describes what usually happens to soups of warriors, they tend to gather strength then stop improving at some point.
Fizzle features a fuzzy ring geometry using warriors numbered zero to population size minus one, a localness parameter controls how close the chosen warriors are to each other and varies from 0 for no topology at all to 1 for the nearest neighbor either way on the ring. Just about all the odds (instruction frequencies etc) are adjustable, the defaults were derived from analysing the Franz test set, a slightly old evolved hill and all the redcode in my RedMaker directory (mostly evolved) and averaging the results. The defaults for some odds like the rate of change ratios for various components are guesses. Most evolvers battle the selected warriors against each other, this one does too, but can also evaluate the warriors by battling them against test warriors rather than against each other. In "directed" modes the evolved warriors never fight each other. The fastest directed method randomly selects a test warrior to battle both selected warriors against, a more accurate but much slower method battles both chosen warriors against all of the test warriors, in effect using benchmark scores to drive the evolution process.
The documentation I wrote for Fizzle observes that once a population reaches a certain optimum, further improvements are not likely to occur due to the extreme luck a warrior form would have to have to survive a period of stategy change. This is mostly true (and qualified by observing that determining when the optimum is reached can be tricky) so I'll leave the docs alone for now, but I now observe that given a relatively strong form to work with, slow improvement does occur. The soup of papers I am presently evolving appeared at first to stop improving when it got to a SF tiny hill benchmark of about 127 but I let it run anyway. Each day is bringing about 2-3 points improvement, four days later it was up to a maximum of about 137. One factor I think helps is localness, when the selected warriors are close it allows weak code to self-improve more before being consumed, and maybe just maybe develope new tactics. Single-point changes (changing one thing on any given line) can only go so far, at that point (when improvement slows to a crawl) multi-point changes are required to yield further improvement. Localness increases the odds that a good multi-point change can be found, for example first a new instruction is tried but it makes the warrior weaker, but it is surrounded by other weak warriors to replicate over and find optimum data for the new instruction and in the end be stronger than the warriors before the instruction change. Fizzle also has an option that directly controls multi-point changes, if RND is less than multichance then another change is made to that line, making it possible to accidently create stronger code when multi-point changes are required. This appears to work only up to point, defined by the true (unknown) optimum of the dominent form and the likelyhood of changes required to effect improvement. After another day of evolution my soup is still at 137 peak. Fizzled.
9/30/03 - Fizzle 1.0/1.1 did well, producing a warrior which (luckily) placed first on the Sourceforge evolved hill, and after extended runs with a different soup produced warriors which benchmark around 150 against the evolved hill warriors, and the 140's against the Franz test set. Everything worked fine but the scoring function was unable to discern fractional-point differences, seems like that would get in the way of evolutionary fine-tuning. Practically it probably wasn't a problem but it bothered me, so decoupled the displayed score from the decision-making process and called it version 1.2.
10/10/03 - Fizzle warriors from an experiment that has been running for weeks. After several more days of evolution scores improved by 2-3 points but it is pretty much peaked, moving on. I found the Infinite Tiny Hill and picked 12 of the strongest warriors to make a test set (see TEST section for conversion batch), trying something...
Download the TEST benchmarker for dos\Windows · version 1.51 last modified 3/7/09
TEST requires pmars.exe or
exhaust.exe
(in the Fizzle archive) "on the path" and
warriors to benchmark against such as the Franz
test
set for coresize 800 warriors or the Wilkies or Wilmoo test
sets
for coresize 8000 warriors. TEST is a menu driven program
that
benchmarks
an entire directory of warriors against a directory of test
warriors,
warriors
must have a ".red" extension. Core size can be set at 80, 800
or 8000 with any number of fixed or random rounds, maximum
instructions, spacing, processes and cycles are hard-coded for
each
core size. Self-battle can be
enabled
to better predict hill results, or disabled for normal
benchmarking.
Settings
are saved between runs and can be interrupted and restarted later
to
continue
a benchmark. The bench process creates a report file containing
scores,
filenames and a bargraph version of the score with one * per 5
points.
Menu options can (crudely) display unsorted and reverse-sorted (to
make
high-scorers come to the top) versions of the report.
To assist in converting warriors to a form suitable for Exhaust I
created
CONVRED.BAT (shift-clift to download), a
batch
file that converts all .RED files in the current directory into
"load"
format with no labels. To use, put the batch file in the same
directory
as the warriors to convert and run it. Simplified redcode is
created in
a directory named rcload and includes selected comments from the
original
code. Note... set up for coresize 800, edit the batch and change
the
numbers
after set size= etc if converting warriors for other core sizes
(don't
change the part before=, just the numbers). The parameters must
match
any
equivalent asserts present in the warriors being converted.
Latest changes... v1.5 supports
"Permutate" option if used with pmars version 0.9.2+ compiled to
support the -P option, handy for quickly but accurately testing
nano
warriors. v1.51 changes maximum size and spacing for coresize 8000
to
100 instructions (was 200 for testing bigger warriors but this
skewed
the scores a bit, as far as I can tell all "standard" hills
specify 100
instructions maximum).
The batch files probably need minor tweeking to run on XP and other NT-like OS's, possibly due to syntax but more likely because of different rules regarding whether or not to leave an inactive window open, fixes for that involve inserting PAUSE into the batch code or setting up PIF files. QBasic.exe must be in a path directory to run batch files containing basic script.
In order to run any dos app and in particular the kind I tend to write, the msdos subsystem must be operational. Beware if you upgraded a 98 system to XP, when I did that the setup program applied my dos settings which were incompatible with XP but I didn't know that they were. It took some digging but eventually I found the autoexec.nt and config.nt files in C:\Windows\System32 directories and straightened things out. Find the dialog box that contains default environment variables, these are used when you launch a command prompt (whereas the .nt files are used when you start a dos exe). Disclaimer - I think, this is all very new to me. Programs running in a dos window flickered constantly until I made both the looked under default properties and made the buffer and screen size equal, both 80x25.
There seems to be a problem detecting single keystrokes when a dos program spends most of its time shelling other programs, I think Windows XP is assigning a different keyboard buffer to the shelled programs so keystrokes tend to fill up buffers that are never checked (again I think, that's how it behaves anyway). To fix this for now I added code to both Fizzle and TEST that detects if a file named "DeleteMe" is deleted. Using PMARS with TEST produces an ugly display under XP but otherwise works, the report looks fine. The messages compaining about missing asserts in the bench warriors go away after the first few warriors have been tested, don't know why but I'll take it - on second try no I won't, was killing the local environment in its attempt to be compatible and honor the ctty nul requests, causing the report viewing options to fail (no path). Oh well, no use hiding the assert warnings, changed TEST to use a more compatible shelling method. Funny the press Q to quit method is now working reliably, in fact everything seems smoother, as if XP adapted. Perhaps it did.
My LCC-compiled Exhaust works fine. The 386 version of PMARS does not work under XP, but one that does is here. Rename pmars_server.exe to pmars.exe and put in a path directory with the macro and sdl.dll file, and set the PMARSHOME environment variable to the directory containing the files.
Redmaker seems to (mostly) work ok under XP. There is an "Extended error" message that appears on the screen when evolution is first started (with both the 286 pmars and the "sdl" server pmars), eventually all but "Ext" is overwritten by growing warriors. The Ctrl-C stop method works. The path\nul method to check for the existence of a directory doesn't work, so it asks to create the initial population every time, Press N if you already have a soup in progress.
Redmaker 2.91 fixes the directory detection bug by checking for the existence of files rather than a directory. Under XP SP2 I no longer get the extended error using RedMaker 2.91 and SDL_pMARS however another version of pmars that used to work randomly failed (in text mode) after installing SP2. I had to redo all my warrior associations, something defaulted, stuff broke. To fix I had to specify the full path to my corewar helpers instead of just the command name, no longer "on the path" for Windows but RedMaker sees the path I set that included my utilities and runs well now.
Most of my old stuff was written for Dos/Windows/QBasic and standard MSDOS (6) batch. I have no defense except to say I chose the fastest programming route that worked for me because I'd rather spend my time evolving and trying to understand, not trying to understand a program language that I do not know. I know it sucks (from a language POV) but it gets the job done with a minimum of thought on my part. Figuring out the algorithms was hard enough. Now (1/9/05) I'm running Linux (Knoppix 3.6 on HD at the moment) and at first I felt the pain of my folly of not writing the tools in a more compatible language and did without CoreWar for awhile. Then I found DosEmu, a Dos Emulator for Linux. More accurately it emulates the dos interrupt calls allowing x86 dos code to run natively, so it's much faster than a real emulator but only runs on x86 machines. So if you have a standard PC with Linux and wish to run my evolvers and batch files, read on.
DosEmu has a limited function "dos" built-in but it isn't enough to run Redmaker or the batch file tools, you need at least FreeDos beta 9. To get things working I used KPackage (the KDE apt wrapper) to install dosemu and dosemu-freedos, manually downloaded dosemu-freedos beta 9 from http://www.dosemu.org/ and unpacked it to "freedos_b9" alongside the beta 8 freedos installed by apt, copied the dosemu directory from beta 8 to beta 9, copied all the dos stuff I wanted dosemu to see to MYDOS under home (including qbasic.exe), edited autoexec.bat to set up the drives like beta8 does, C: read only, D: home, and E: to a temp dir but added /MYDOS to the redirect command so dos won't see the whole home dir, also added a few directories to the path so things can be easily started, then edited dosemu.conf to specify a link to the freedos_b9 directory so it'll boot beta 9. At least that's what I had to do, your procedures will likely vary. Lots of doc-reading is required to get the most out of DosEmu but it is quite nice once set up.
DosEmu can be supplied a command to run then exit, this is the key to integrating dos tools into the Linux environment. A few Linux-native tools are available, including console and graphical versions of pmars if you compile them yourself (easy) but the majority of my new CoreWar redcode associations are provided by slightly modified versions of the batch files I've always used, including 5 variations of test.bat that tests the specified warriors against various benchmarks, and a right-click that simulates a hill challenge. To pull these tricks off I wrote shell scripts that extract the base name of the file to test, copy the warrior to a directory dos can see, call xdosemu with a command line that performs the desired action, then delete the file being tested from the dos directory structure. My test800e shell-script for example contains...
#!/bin/bash
bn=`basename $1`
cp -f $1 ~/MYDOS/args
xdosemu "test800e d:\\args\\$bn"
rm -f ~/MYDOS/args/$bn
This sets bn to the base name of the first argument ($1), copies the specified file to a directory dosemu/freedos is set up to see as D:\args (must exist), runs a batch named test800e.bat (must be "on the path") supplying the dos filename of the warrior to test, then deletes the file it added and everything exits. I modified test800e.bat for my local bench directory and to use list.com to display the results so it would remain on-screen, more/pause would work but the list utility is nicer. Once added as an association for *.red files all I have to do is right-click a warrior then select open with, test800e to bench a warrior with the evolved hill as a testset. Of course all this is specific to how your system is set up. For example.
In the case of the hill-sim battle.bat I had to get fancier. Battle.bat battles everything in the current directory against each other so I have to copy the target to the ~/MYDOS/CWSTUFF/battle directory alongside the test warriors but I don't want to overwrite a warrior of the same name. I ended up with a batch named dohill.bat on the dos path that CD's to D:\CWSTUFF\battle directory then runs battle.bat, and on the Linux side a dohill script containing...
#!/bin/bash
bn=`basename $1`
if [ ! -e ~/MYDOS/CWSTUFF/battle/$bn ]; then
cp $1 ~/MYDOS/CWSTUFF/battle
xdosemu "dohill"
rm -f ~/MYDOS/CWSTUFF/battle/$bn
fi
This variation does the cp/xdosemu/rm steps only if the file doesn't exist, otherwise does nothing.
DosEmu/FreeDos b9 is highly compatible with my qbasic and batch programs once I fixed RedMaker but the same fixes were also required for XP compatibility. The main difference I can tell (XP also) is there is no support for testing directory existence by looking for nul in the directory to test, anything that does "if not exist blah\nul md blah" or other variations has to be rewritten not to do this. Redmaker was the biggest offender and fixed, the other batches I use seem to work fine as-is except for the usual editing to tweek directories and make them stay on the screen instead of closing before I can read the output. The only thing not working is Fizzle but only because my self-compiled exhaust binary requires Windows, I need to recompile exhaust with something like Turbo-C for dos, or stick with pmars-based evolvers. Some versions of pmars and pmarsv don't work but the ones supplied in the standard (old) distro seem to work fine, even display graphically in a window, something I didn't have under Windows until recently.
Ok it's a crutch but for me a nice sturdy one! Eventually I'll start using native Linux scripts and programs to do some of what I do under dos, I'm sure it would be faster. But first I have to learn more about bash and sed and perl and C and... these things take lots of time but in the mean time I'm back to enjoying playing around with warriors.
3/11/05 - Finally a native Linux evolver, REBS. I'm not sure the
bash
scripting language is a step forward compared to Qbasic but at
least I
don't have to emulate to evolve and the script format makes it
easier
to
tinker with the code. I'm still using the emulated dos tools to
test
the
results but I'm having problems copying text from the emulated dos
screen,
I need to code my benchmarkers and hill simulator in bash to fix
that.
1/11/09 - I've been using Ubuntu for the last few years and still
most of my test programs etc are the same old batches etc for
dos/QBasic (running under DosEmu/FreeDos)... if it ain't broke
don't
fix it. The Gnome GUI isn't too smart when it comes to
user-defined
associations, to the OS warriors were text files and any tool
assigned
to work with .red files also appeared in the right-click open-with
selections for all text files. No visible provision for a user to
add
custom types - I guess for typical users who never associate
anything
that's fine but for me I found the ROX Mime Editor and added a
file
type just for .red and .RED files so the associations apply only
to
those files and not every other text file. Before I found the mime
editor my right-clicks were as tall as the screen. Now when I
right-click a warrior I can select 80, 800 and 8000 varients of
the
testwar.bat each coded to the appropriate test set, "run"
selections
for each size (for size 80 had to use the older v8 dos version of
pmarsv, v9 complained about the coresize being too small and under
Linux even with the slowest -v setting it was too fast),
variations of
dohill for each size and selections for variants of a script I
wrote
that battles the warrior visually against a warrior selected from
a
menu. Normal open-with selections are only useful if a single
warrior
is selected (otherwise it runs all as separate instances rather
than
adding them all to the command line). The file manager has a
scripts
directory, bash scripts put there do interpret multiple selections
properly so I can select up to 8 warriors at once and run in
pmars.
Passing warrior filenames to pmarsv running under DosEmu was
tricky,
had to add a batch file which changed to the "arg" directory then
run
pmarsv with the appropriate switches passing the command line
parms...
----- begin pmvnano.bat -----
:: change to D:\ARG then run PMARSV command with specified warriors
:: for nano (coresize 80)
@echo off
D:
cd \args
pmarsv -s 80 -p 80 -c 800 -l 5 -d 5 -r 10 -v 914 %1 %2 %3 %4 %5 %6 %7 %8 %9
pause
----- end pmvnano.bat -------
...then the bash script for the Linux side could copy the
specified
warriors to where D:\args is mapped, run the pmvnano batch passing
the
base names of the specified files, then clean up afterwards.
Specifics
will vary, in my DosEmu setup C: is the dos system disk and D: is
my
user files which I mapped to a directory called MYDOS in my home
dir,
so on my system D:\args to dos maps to ~/MYDOS/args in Linux,
scripts
must be edited as needed. Here's my "pm80" script I run via
association...
----- begin pm80 -----
#!/bin/bash
# older pmars used to support small coresize, -l and -d must be spec'd
# to avoid segfault. 10 rounds to see what's happening (too fast).
# linux version is still too fast...
# pmarsv8 -l 5 -d 5 -s 80 -p 80 -c 800 -v 964 -r 10 $1 $2 $3 $4 $5 $6 $7 $8
# use dos version instead...
w1=`basename "$1"`
w2=`basename "$2"`
w3=`basename "$3"`
w4=`basename "$4"`
w5=`basename "$5"`
w6=`basename "$6"`
w7=`basename "$7"`
w8=`basename "$8"`
cp -f $1 $2 $3 $4 $5 $6 $7 $8 ~/MYDOS/args
xdosemu "pmvnano $w1 $w2 $w3 $w4 $w5 $w6 $w7 $w8"
rm -f ~/MYDOS/args/*.red
rm -f ~/MYDOS/args/*.RED
----- end pm80 -------
This kind of script should be in /usr/local/bin so it can be run
from anywhere without specifying the path. The script for the
nautilus-scripts directory for running multiple warriors at once
is
simply:
----- begin NanoBattle -----
#!/bin/bash
pm80 $1 $2 $3 $4 $5 $6 $7 $8
----- end NanoBattle -------
...or it could have just been a symlink or copy of the main pm80
script. Size 800 and 8000 varients display OK using the native
Linux
version of pmarsv using a command similar to the commented out
command
in pm80, without the -r 10 part (which makes it repeat 10 times so
I
can better see what's happening), however if battling multiple
warriors
got to see the text-mode scores and Gnome doesn't run a console
unless
told, so a pair of scripts is needed, for example...
----- begin TinyBattle -----
#!/bin/bash
gnome-terminal -e "pm800.sh $1 $2 $3 $4 $5 $6 $7 $8"
----- end TinyBattle -------
----- begin pm800.sh -----
#!/bin/bash
pmarsv -s 800 -p 800 -c 8000 -v 964 $1 $2 $3 $4 $5 $6 $7 $8
echo ----- press enter -----
read nothing
----- end pm800.sh -------
TinyBattle can go in the Nautilus scripts dir for running
multiple
warriors, pm800.sh goes in /usr/local/bin. For regular association
I
have a plain pm800 script without the echo and read, with only one
warrior being run I don't
need to pause for a score, no terminal needed.
1/14/09 - I've been setting up my Asus 701SD "Eee PC" with
Xandros
to do nano-warrior evolving. This little machine has a solid state
disk
so writes MUST be controlled or something like an evolver will
burn it
out rather quickly. The /dev/ram15 ramdisk method doesn't work as
the
ramdisk size is only about 3 megs and not convenient to change.
With a
bit of surfing I found an alternate method that permits setting a
maximum size, and only consumes memory actually used for files
(mke2fs
not needed). Essentially, for a 25 meg ram disk I use commands
like...
mkdir ~/rd
sudo mount -t ramfs none ~/rd -o maxsize=25000 && sudo mkdir ~/rd/work
sudo chmod 777 ~/rd/work
...but in a script with a bit more checking to avoid rerunning.
This
mounts the ram disk to rd under the /home/user directory then
creates a
directory under that with R/W privilages for use without having to
be
root. Right now I'm just manually copying the evolver and soup
back and
forth, avoiding disk writes when stopping and restarting. The
ramfs
method seems to work well except that free disk space is always 0
(allocates what it needs) causing the file manager to complain
when
copying files to the ram disk, fortunately it copies the files
anyway
if I click ignore, so not a problem. The testing batches need
fixing
too to make sure they don't unnecessarily wear on the disk, all
temporary files, particularly raw pmars output for each battle,
should
be written to the temp filesystem which is mapped to memory on the
Eee
PC. In DosEmu this essentially means adding %temp%\ in front of
all
temp filenames. In TESTWAR.BAT varients the echo to "name.bat" and
subsequent delete should be removed and replaced by an equivalent
fixed
name.bat in a path directory, it just does set name=%1. Most
importantly, monitor disk writes when testing scripting solutions
to
make sure write frequencies are minimal, I use iostat from the
sysstat
package. Because of wear leveling, how much impact writes have
depends
on the amount of free space, with 1 gigabyte free keeping average
writes under about 9 (1K) blocks per second (as reported by
iostat)
"should" result in a disk life of over 10 years of continuous use,
assuming my math is correct for 10,000 cycle flash. There's more
on
this subject on my Eee
PC
page. Probably better to not use dos batch techniques at all
and do
everything using bash scripts on the ram disk, then there'd be no
writes at all until the results are saved... but that would mean
rewriting my testing tools. So long as I can keep disk writes
reasonably low when testing (as low or lower than other common
activities) and no writes at all when evolving, that should be
good
enough.
The Redcode Evolver Bash Script for
Linux
requires
pmars compiled without graphics, I used the pmars 0.8.6 source
from the
koth pmars page (the
0.9.2
version also works but that version of pmarsv won't run nano
warriors).
Here are my x86
linux pmars binaries if needed. The pmars binary needs to be
in a
path
directory (/usr/local/sbin here) or edit the script to specify the
full
path to pmars. To run the script, save the text to a filename
besides
rebs_nano.txt
(named that way to ensure web compatibility), if running under
Linux
mark as executable and convert to "unix" format (if copy/pasted to
an
editor and saved that should be the case), and
edit first to make sure the parms are ok and you know what you're
running.
As coded REBS puts evolved warriors in a directory named "soup",
uses a temp file named "evolver.tmp" and creates a file called
"DeleteMe" to delete when you want it to stop. Don't interrupt
the script using ctrl-c or other methods as that would likely
leave
corrupted
warriors in the soup, delete the DeleteMe file to exit cleanly.
The new
rebs_nano version is configured to evolve nano warriors for
coresize
80, works around a memory leak bug in some versions of bash, has
configurable CPU usage and has a new option to alter the colors
when
major mutations occur to keep it from turning all one color. The original REBS was configured for tiny
warriors for
coresize 800, the settings block can be copy/pasted into the new
version if desired.
Although REBS was designed for Linux-like systems, Windows users can run the script without change under the Cygwin bash environment using a Dos or Windows (console) version of pmars.
The latest version-specific information and ramblings can be found on the REBS page.
REBS uses a simple algorithm: select two warriors, if a warrior doesn't exist create a random warrior in its place, battle the two warriors using pmars, copy the winner over the loser while making random changes, and do it again. Strings specify the instructions, modifiers and addressing modes with duplicate entries for weighting, probability odds control how often each of the six fields are modified, how often the end address changes, how often the warrior starts at the beginning vs some other address, chance of size change, chance of duplicate line and for data the chance the number will be a small +/- offset rather than a large positive number. Other chance variables that control how often data and the end number are incremented or decremented rather than replaced with a new random number when a change is called for. Which warriors are selected for battle is what defines the topology of the world the evolving warriors live in, and also how rapidly code forms can spread throughout the soup. Topology choices are none (random selection), a ring of warriors where each warrior can only battle its immediate neighbors, and a grid of warriors with side-side wraparound but no wrap top-bottom. Other options specify pmars parameters, core size, processes, cycles, rounds, how many warriors to create and other stuff. All configuration is done by editing the beginning of the script, once the program is going there is no interactive user interface besides deleting a file to stop it.
REBS uses an ANSI-based display where each character represents one warrior, making it easier to keep track of the soup. Assumes a black background. Change enableplot to 0 to disable the plot display and display only the status lines. When enableplot=1 ylines sets how many screen lines of warriors to display, xsize determines how many warriors are in each column line. When xsize is small the display is arranged into columns, mentally paste together. The total width is determined by how many columns are needed. The warriors are numbered from 0 at the top left corner and increment left to right, wrapping at the end of the column. Each warrior in the soup is represented by a single character displaying warrior length (A=10, B=11 etc) and colored according to species or length depending on the colormethod variable.
Ramdisk info...
REBS creates and deletes files constantly and like any file-based evolver should be run on a ramdisk. Creating a ramdisk is system-specific, for my HD installation of Knoppix I use something like...
sudo mkdir /mnt/rd # only needed once
sudo mke2fs -m 0 /dev/ram15
sudo mount /dev/ram15 /mnt/rd
sudo mkdir /mnt/rd/rebswork
sudo chmod 777 /mnt/rd/rebswork
I chose /mnt/rd as the mount point for the ramdisk because it didn't exist and I wanted to keep all my mount points under /mnt but any directory will do. I chose /dev/ram15 because that was the highest ramdisk listed by ls /dev/ram* thus likely not to be used by anything else. Once a ramdisk and working directory on it have been created, copy the soup to evolve if one exists, change to the /mnt/rd/rebswork directory on ramdisk and run the REBS script. Delete the /mnt/rd/rebswork/DeleteMe file to stop evolution and copy the /mnt/rd/rebswork/soup directory back to hard disk to preserve the soup for the next run.
Under Cygwin install a ramdisk into config.sys or whatever method is appropriate for the version of Windows being used (XP requires installation of an XP-compatible ramdisk driver), then access under /cygdrive/x where x is the drive letter of the ramdisk. Copy the soup from hard drive to the ramdrive (if one exists), change to the ramdrive directory, run REBS and save the soup back to the hard drive when done.
To make things easier the necessary commands can be placed in a bash
script. Another script that deletes the DeleteMe file from
the
ramdisk
(rm ./rd/rebswork/DeleteMe) can be used as a "stop button". Update
-
the evol_rd script now derives the hard disk directory using the
cwd
command (less or no editing when moving around) and puts the rd
mount
point in the current directory for easy access and to avoid adding
a
directory under /mnt (which doesn't exist in some systems). I'm
currently using it on my Ubuntu system to play with nano
warriors...
evol_rd is named evol_rd.sh with an additional script containing
konsole -e ./evol_rd.sh to launch it in my preferred terminal.
RedMixer has a soup display that's similar to REBS but is written
in
QBasic with a user interface similar to RedMaker, I can stop the
evolver and cursor around the soup to list warriors, benchmark
them and
run them alone or against a neighboring warrior in pmarsv.
RedMixer has
several experimental crossover options - mutation only, cross with
a
warrior of the same origin, cross with a warrior of the same
species,
cross with a warrior of the same size, or cross with any warrior.
As
with warriors selected to battle, the crossover partners are
chosen
from one of the surrounding warriors (excluding the warrior that
lost
of course), if an attraction option is enabled rather than
choosing one
of the candidate crossover partners at random it selects the one
with
the highest accumulated score (the average score against other
soup
members multiplied by the number of battles the warrior has won).
REBS
used the species tag strictly for display purposes and considered
any
change in the sequence of base instructions (i.e. the MOV part of
a
MOV.I instruction) to be a new species, RedMixer has an option to
define what percentage of the instructions can be different and
still
be considered the same species. I found that when evolving
warriors for
coresize 8000 mutations were so common that "islands" of distinct
species tags didn't develop, permitting 5 to 15 percent of the
instructions to be different creates a more useful display and
provides
more candidates for crossover when using the cross by species
method.
Here's the QBasic source for RedMixer
version 1.0d, requires QBASIC.EXE,
PMARS.EXE and PMARSV.EXE (or PMARSW.EXE for Windows) to run. Under
Windows XP with SP3 and the latest updates it flickers while
evolving
(many "dos" programs now do this, the update broke the command
window
to a degree), the fix is to add MODE CON LINES=25 to the batch
file
that starts it...
@echo off
mode con lines=25
qbasic /run redmixer.bas
Save as "redmix.bat" or something similar in the same directory
as
redmaker.bas (if using Notepad include the quotes to keep Notepad
from
adding a txt extension), double-click the batch to start RedMixer.
Caution - if running RedMixer for any length of time run it on a
ramdisk to avoid disk wear or possible damage to the file system
should
something go wrong, it writes to files millions of times and like
any
file-based evolver you probably don't want that kind of file
meyhem
happening on your main system drive. Never run RedMixer on a solid
state drive. Under Ubuntu I use a method similar to the method in
the
REBS section above, under Windows I use the "ramdrive.sys" driver
from
Microsoft (edit the registry to specify size, 8 megabytes should
be
plenty), and on my Eee PC 701SD running Asus Xandros I use the
"ramfs"
method. More details about setting up a ramdisk are in the
readme.txt
file linked from the RedMixer
home page,
where the latest version is at.
Under Windows it runs very quickly when evolving nano warriors,
so
quickly it can be hard to stop using control-C but usually a few
tries
will
do it. Like my other evolvers it creates a file that when deleted
stops
evolution, by default it's named "deleteme" so if the control-C
method
causes problems (I can make it work enough to not bother but just
in
case) make a batch file (say "stop_redmixer.bat) and double-click
it to
delete the file and cause RedMixer to return to the user interface
menu...
@echo off
del deleteme > nul
File-based evolvers are easy to implement but can be a bugger to
stop so I always provide a delete file for backup. To be able to
detect
the control-C pmars has to run with the console enabled, however
the
versions of pmars.exe I have hang if any key is pressed, if that
happens press control-C then Evolve again. Fizzle got around this
by
using Exhaust but that requires benchmark warriors to be converted
to
"load" format, the standard pmars program isn't as fast but is
more
convenient when arbitrary code gets thrown at it. The TEST
benchmarker
uses a workaround to run pmars using a batch which runs pmars from
another batch using a new copy of command.com with input
redirected
from "nul" but this method consumes valuable dos memory for an
extra
command interpreter, is too convulted, and somewhat futile - often
it
makes it just as hard to stop, if keystrokes aren't buffered while
the
nul shell is running then the "Q" to stop it has to be pressed at
just
the right time or it doesn't work (thankfully DosEmu buffers the
keystroke but there have been times under Windows I had to delete
the
halt file to stop it). For a benchmarker that will lose the whole
run
if pmars hangs, running in a null shell makes sense and it already
needed the extra batch files anyway. For an evolver that can be
restarted with no error it's too much complication so that's why
it
hangs if a key is pressed, because that's what pmars does. Doesn't
bother me (other than writing too many words explaining it) but if
it
ever does I'll find the input code and disable all keyboard input
except for control-C and recompile it - easier said than done.
The default soup size is 77 by 21 for a standard 80 by 25
display,
RedMixer can support a soup display up to 77 by 46 when running
with a
50 line display. To enable edit the redmixer.ini file (created
when the
program is first run) and change ysize to 46 (the pmarsv entry
also
needs editing unless you have a pmarsv that works with a 50 line
display), and edit the batch that runs it to do MODE CON LINES=50
instead. Under Windows the PMARSW SDL version of pmarsv doesn't
care
but plain pmarsv dos versions won't work if the display isn't set
to 25
lines. Not to be outsmarted I made a batch file that fixes that...
@echo off
:: pmarsv doesn't like 50 line displays or resets
:: back to 25 lines when exiting. This fixes that,
:: edit redmixer.ini to specify pmarsv pmarsv50.bat
:: This is only for when running in 50 line mode.
if .%1==.runsub goto sub
mode con lines=25
set p1=%1 %2 %3 %4 %5 %6 %7 %8 %9
shift
shift
shift
shift
shift
shift
shift
shift
shift
set p2=%1 %2 %3 %4 %5 %6 %7 %8 %9
set dopause=x
for %%a in (%p1%) do call pmarsv50.bat runsub %%a
for %%a in (%p2%) do call pmarsv50.bat runsub %%a
pmarsv %p1% %p2%
if %dopause%==xxx pause
mode con lines=50
goto end
:sub
echo %2 | find ".red" > nul
if not errorlevel 1 set dopause=%dopause%x
:end
Save as "pmarsv50.bat" in the same directory as redmixer.bas then
edit the redmixer.ini file to specify pmarsv50.bat rather than
plain
pmarsv. This batch is smart enough to recognize when two warriors
are
being run and pause to show the score results (switching back to
50
lines clears the screen), when running a single warrior it doesn't
pause and immediately returns to RedMixer after pmarsv's "press
any
key" prompt.
If using multiple configurations in the same directory, rename
the
redmixer.ini file to some other same, say redbig.ini for a 77x46
config, and change the soup entry to use another name for the soup
directory to avoid conflict (stay within the 8.3 name limits of
dos),
then use a batch (say "runbig.bat") to copy the appropriate ini
file to
redmixer.ini before running RedMixer, something like...
@echo off
copy redbig.ini redmixer.ini
mode con lines=50
qbasic /run redmixer.bas
...I use several configurations for small-soup nanos, big-soup
nanos, coresize 8000 etc each with their own INI file and soup
directory. The benchmark feature requires a set of warriors to
test
with, by default these go in a directory named "nanotest" for nano
warriors but obviously for other core sizes the test directory
should
be changed. For nano warriors the "nanobm07" test set can be
downloaded
from
http://corewar.co.uk/nano.htm
or what I usually use, the top 20
warriors from the Koenigstuhl
Nano
Hill.
RedMixer (and the TEST benchmark program for finding strong soup
members) work in Linux under DosEmu/FreeDos environment.
DosEmu/FreeDos
can be a
bit tricky to set up, details of how I set up DosEmu 1.2 on my Eee
PC
are in the eeecw.txt
file. DosEmu 1.4 is a bit different and easier as it uses links to
define
the drives rather than having to edit autoexec.bat, but still need
to
edit it to define path directories etc or just put pmars, pmarsv
and
qbasic in the same directory as RedMixer. There is a bug when
running
under DosEmu/FreeDos - if control-C is pressed to stop it before
the
soup fills up then usually it exits when E is pressed to evolve.
Once
the soup fills control-C then Evolve works fine, and the problem
doesn't happen under Windows or if the "deleteme" file is deleted
to
stop it instead of pressing control-C. No idea why this happens
(probably some kind of DosEmu effect), but FreeDos has command
recall
so I just press up arrow then enter and move on.. if the soup
isn't
full yet I know the bug is going to happen so quit then rerun to
continue
evolving. [Note... improved RedMixer 1.1 and 1.2 versions can be
compiled natively for Linux, eliminating having to use dos
emulation.]
When running RedMixer interpreted in QBasic to evolve warriors
for
core size 8000 there isn't enough memory to run a dos version of
pmarsv. Not a problem when using the compiled exe version (from
the
RedMixer site), not a problem under Windows when using the SDL
"pmarsw"
or another Windows-specific version of pmarsv as these don't
consume
dos memory. Under Linux/DosEmu/FreeDos it's possible using scripts
to
run a Linux version of pmarsv instead, see the readme in the
redmixer.zip from the RedMixer site (usually I just use the exe
version
when evolving for size 8000, the exe version is limited to a 21x77
maximum soup size but evolving size 8000 warriors is slow enough
as it
is without enabling a huge soup that would require running
interpreted). BTW there isn't that much speed advantage of using
the
exe version as the majority of processing time is spent in pmars,
not
the evolver. The main advantage of the exe is screen refresh is
faster
when using the interface to explore the soup, and it avoids the
memory
problem when using a dos version of pmarsv, but neither of these
are
issues for modern Windows systems.
In almost two months of using the 2/19/09 1.0d version I've
noticed
very little about the program that I'd change, most of the issues
I've
encountered are OS-related and trivial to work around, more a
matter of
documentation than code. The remaining issues that can be fixed
with
code so far have been too trivial to bother with - for example
there
might be a tiny bug in the coloring scheme that causes different
species to get colored the same slightly more often than random
chance
(I don't care... with only 14 colors it's going to happen anyway -
but
to fix that change the two instances of x + y * ysize under
plotwarrior
to x + y * xsize), the
offset of the status line isn't ideal when using tiny soups that
don't
span the width of the screen, and it would be nice if the current
cursor position was shown in text form (but there isn't any room
in the
current design unless the menu text is shortened). Overall this is
[so
far] the
"best" evolver I've made, even if I do change the primary version
on
the RedMixer site, unless I find a gruesome bug or something I'm
inclined to leave this version 1.0d alone. It just produced one of
the
strongest size 8000 warrior I've ever evolved, (apparently) just a
stone but scores 104 on the Wilkies scale...
;redcode-94
;name Some kind of rocky thing
;author Terry Newton
;strategy Evolved by RedMixer 1.0d-8K8 4/15/09
;origin 14_05.red
;parents 03_14.red 02_15.red -> 04_14.red
;generation 703
;assert CORESIZE==8000
mov.a # 0 , > 0
spl.f # 1391 , { 1
mov.i } 5462 , } -1
djn.x $ -1 , } -2
mov.x > 6347 , { 7
sne.i $ 6007 , # 4447
djn.f < 4 , * -2
spl.f * 7192 , @ 4749
sne.f * -2 , @ -1
jmn.a > -1 , $ 5
end 1
;species 12_10
Opponent Scores Results Performance of Some kind of rocky thing
--------------- --------- ----------- ---------=---------=---------=---------=
TimeScape (1.0) 56 668 10 214 26 **
nobody special 25 700 0 225 25 *
Paperone 23 704 0 227 23 *
Marcia Trionfal 48 654 0 202 48 **
Blue Funk 3 185 425 15 95 140 *********
Cannonade 269 347 45 71 134 **************
Tornado 472 277 157 92 1 *************************
Fire Storm v1.1 483 261 159 85 6 *************************
Rave 271 478 90 159 1 **************
Iron Gate 349 400 116 133 1 ******************
Porch Swing 543 198 178 63 9 ****************************
Thermite 1.0 411 327 133 105 12 *********************
--------------- --------- ----------- ---------=---------=---------=---------=
Adjusted Score: 104.5
One of the tricks seems to be use a relatively small soup size
and
number of
battle rounds for speed (I used a 15 by 15 grid, 10 rounds per
battle)
and in the initial stages set max size to 25 or so instructions to
force it to find efficient algorithms. Once viable code is
produced
(when the soup battle scores become varied instead of 0 300 or 100
100)
then maximum size can be increased to 100 but I still make the
deletion
chance slightly greater than the insertion chance to keep the
pressure
on to generate smaller warriors.
Corewar evolvers tend to be fairly big, but they don't have to
be.
In fact it's possible to evolve nano warriors capable of making
the SAL
Nano hill using a mere 1.2 kilobytes of line-numbered BASIC code.
These
small
evolvers
are also a good opportunity to try a few new things
without the complexity of a larger program. John Metcalf started
this
line of experimentation
when he mentioned on IRC he had an evolver consisting of only 30
lines
of GWBASIC code. Hmm... had to try that, so I tried my hand at
trivial
evolvers, eventually ending up with a Little Corewar
Evolver
that (after adding in everything I wanted it to do) weighed in at
about
4K-bytes of dense QBasic code. Very dense, pleasently unreadable,
and I
had great fun creating it. The compact format had useful benefits,
because I could see all the code at once, making development
easier
than usual. This odd little program is the only evolver I've made
(or
seen) that was capable of generating true-'88 redcode, and was
used to
research ring vs grid soups, the benefit (or lack thereof) of the
number increment/decrement mutation and finding parameters that
naturally resulted in paper-type warriors when evolving for larger
coresizes.
Then I saw John's TEV
program and realized I really missed the mark in the
simplicity
department, TEV was a very simple 1.5K-byte evolver that used
direct
benchmarking to increase the performance of the evolved warriors
while
using a fairly small soup. A 1.2K-byte
version
of TEV was also produced, other TEV notes are on John's evolving
blog.
As I learned from playing with TEV (and have previously noted),
benchmark-driven evolvers can produce warriors with impressive
scores,
but often the warriors learn techniques that are "focused" to a
particular set of warriors and don't necessarily perform well
against
other warriors. But sometimes they do and can hold their own, as
with
most evolvers good results take patience and good warrior
selection
skills. One of the most significant features of TEV was it used
arrays
to represent the soup, eliminating having to use individual
warrior
files and mutate by parsing and manipulating strings. This greatly
simplifies the code and reduces disk access by restricting writes
to
just a few files which (on modern OS's) stay mostly in the disk
cache
and on a single disk track.
TEV is written in simple line-numbered GWBASIC code and can be
adapted to QBasic or run natively under Windows or
Linux using the Blassic interpreter.
For small programs this style of coding is quite efficient and
compatible with minimal effort required to run the code, so that's
what
I used for further small evolving experiments and other small
programs
such as warbench.
My first try at this style of evolving was Just Because,
with a
1.9K-byte version (0.3) that implements a ring-shaped soup and
basic
pure nano-evolving features. This was expanded into a 4.8K-byte
version
(0.7) with a grid-shape soup, storage of parameters in the soup
file, a
new "swap lines" mutation and a "cylons" display while evolving.
Both
of these use a fixed instruction.modifier list. JB worked fairly
well,
presently (9/24/09) a JB 0.3 warrior is presently 13th on the SAL
nano
hill, with a TEV warrior in 12th and a REBS warrior in 14th.
The 4.8K-byte SEWAX
program (small evolver with automatic extraction) uses a
ring-shaped
soup, evolves the modifier separately, includes the swap mutation
but
like JB, uses a fixed warrior size without traditional line
insert/delete mutations. Periodically SEWAX benchmarks a warrior,
and
copies the top-scoring warrior to a separate file, and saves all
warriors that score within a certain amount of the top score. This
permits periodically re-inserting the top-scoring warrior back
into the
soup to help encourage higher scores, but attempting to avoid the
focusing effect that often occurs with direct guidance by
benchmark
scores. I learned that re-insertion was tricky, sometimes it gives
an
evolutionary advantage to well-scoring warriors and the inserted
warriors mutate further and improve, but sometimes the other
warriors
evolved techniques to defeat the inserted warriors, not
necessarily
scoring better in the process. Careful adjustment of the
re-insertion
rate can compensate for this effect. Presently a SEWAX warrior is
in
10th place on the SAL nano hill, and another SEWAX-produced
warrior
previously got KOTH.
The SubK
evolver
takes small evolving to the extreme (less than 1024 bytes of
evolving
code) but its best results score around 140 against the nanobm07
test
set, probably not enough to make the nano hill. It uses similar
methods
as JB but for some reason doesn't perform as well. I thought that
perhaps it was because JB starts with random code and SubK starts
with
essentially nothing, adding a line to randomize the soup before
starting improved performance in the early stages but didn't help
improve things after that. Could be a bug, could be an indication
of
the limits of small evolving and an opportunity to learn what
those
limitations are. So far it looks like TEV produces the best nano
hill
performance while using the least amount of code, but programmers
like
contests (even imaginary ones) so we'll see about that.
Fizmo's Maezumo
evolver
is one of the few truly different evolvers, it definitely has a
"twist". At its core it uses sophisticated knowledge-driven hints
to
automatically produce stone, scanner and paper warriors with
additional
"pure" and fragment hints. The hint-made warriors are evaluated
using a
hill so that stronger warriors are produced by brute force. Also
has a
really cool HTML status report for monitoring progress. At first I
wasn't sure if it really was an "evolver" as normally defined as
early
versions used no mutation at all, yet it created the strongest
coresize
8000 warriors I've ever seen come from an automated program.
Despite
the framework approach the overwhelming majority of the warriors
are
totally unique, love those weird papers. Hmm... only a redcode
master
can pull of something like this! To passify the purists (and me) a
mutation engine was added that runs in parallel with the hints,
able to
further mutate the hint-made warriors or run entirely on its own.
Pure
techniques can't compete strength-wise with the hints for larger
coresizes, but it gave Maezumo the ability to effectively compete
on
the SAL nano hill, presently (11/26/09) with warriors in 2nd, 7th,
16th, 22nd,
25th and 37th place by 3 different users. The one in 22nd place is
an
evolved nano paper created using an experimental
Linux
version of Maezumo with hints enabled for nano warriors and
Valhalla-like techniques for reinserting warriors. Although the
hint-made nano papers were weak, mutation-based evolution totally
rearranged the code to produce a population of much stronger nano
papers that contained no trace of the original hint code, yet
still
replicated like papers. Evolved mad mad bombers do better on the
nano
hill but still this is the only evolver I've seen that can sustain
a
population of nano papers.
I wrote MEVO (Multi-threaded Evolver) because after playing around with the small evolvers and Maezumo my previous "flagship" evolver RedMixer seemed rather dated. I wanted something that was like RedMixer but using an in-memory soup and other newly-discovered techniques, simplified to include what works and omit the more dubious techniques, written in a more structured language to make it easier to add code, and able to launch multiple copies of pmars to improve performance on my Atom-based HP 110 Mi sub-laptop and hopefully run much faster on true multi-core machines. MEVO implements a grid-shaped soup but this time with no forced wraparound (wraparound can be configured in the INI file), produces variable-length warriors and includes the usual mutations - instructions, modifiers, modes, numbers including odds for inc/dec and big numbers, line insert including odds for dup lines, line delete and line swap. Now it also has starting location mutation (in the original version warriors always started at the beginning). Has automatic benchmarking and extraction, insertion can reinsert the best warrior or choose from among all saved warriors for a possibly more effective Valhalla effect.
The user interface for MEVO implements options for listing
warriors, running or battling them in pmarsv or testing single
soup
warriors against a benchmark set. An external benchmark program
such as
TEST or warbench
can
be used to further rate the performance of the evolved warriors.
The
MEVO source code (updated 12/8/09 for
code
version 12/3/09) requires FreeBasic
to compile for Linux or
Windows and requires pmars
and
pmarsv
and suitable benchmark
warriors for operation. Go to the MEVO
page for pre-compiled versions that include all necessary
files.
MEVO, like most "pure" evolvers, can produce competitive warriors
for the nano environment but is not effective against good
hand-written
warriors when evolving for larger coresizes. It's still fun to
try, and
the results are at least semi-competitive against other evolved
warriors. Here are a few screen dumps of MEVO with a 40x10 soup of
coresize 8000 warriors, examining the paper warrior under the
cursor...
The last screendump is of the pmarsv program running the warrior
(MEVO's R option), halted and listing one of its replicants.
Although this warrior isn't
particularly strong as
coresize 8000 warriors go, it is interesting that evolution chose
to
use only 7 instructions even though the
settings permitted using up to 25 instructions. Another MEVO
run
produced a 3-line paper, it only
scores about 70 Wilkies but it's about as minimal as a paper can
be.
The present version of MEVO includes crossover and a simple
application for graphically charting the performance of the
evolved
warriors over time. When crossover is enabled it checks warriors
surrounding the winning warrior (excluding the losing warrior) for
another warrior of the same species and length, preferring the one
with
the highest number of wins. If a match is found then it switches
back
and forth between the two source warriors based on two INI
settings
that determine the chance of switching to the crossover mate and
switching to the winning warrior. The initial source is randomly
selected and switches are made only on line boundaries. Normally
to
select a crossover mate it selects another warrior that is the
same
size and species and with the most wins. Sounds about right in
theory
but this also limits possibilities, so the 12/3/09 version adds a
couple more options to specify the chances of crossing with any
warrior
regardless of species, and reduce the odds of picking the "best"
warrior (which might not really be the best choice). The anychance
option permits controlling a phenomenon called "headless chicken"
crossover, which is technically mixing with random genetic
material but
for redcode mixing with a totally different warrior accomplishes
about
the same thing and might accidently produce a new strategy. More
likely
the result is a damaged or non-functional warrior. Too much of
that is
not good but a certain amount can have a beneficial effect by
providing
warriors which weaker members can beat and thus have further
opportunity to mutate and strengthen, encouraging the development
of
new strategies.
Modified March 4, 2024 to fix dead related papers link, added
archive note and a link to the new Core War Files
Fixed some links July 18, 2010
Modified December 8, 2009 - updated MEVO source and notes.
Modified September 26, 2009 - added sections for Small Evolvers,
Maezumo and MEVO.
Modified April 15, 2009 - updated TEST, added to RedMixer notes.
Modified February 28, 2009 - updated TEST (now supports Permutate)
Modified February 20, 2009 - added section for RedMixer, links to
new testall.bat
Modified February 2, 2009 - adjusted links and notes for the new
version of REBS
Modified January 10-14, 2009 - links, updated TEST, scripting
notes
Modified March 16, 2005 - fixing links and stuff
Modified March 9 to April 8, 2005 (REBS, Linux notes)
Modified December 27, 2004 to January 9, 2005 (RedMaker 2.91,
Compatibility
Notes)
Links fixed September 30, 2004
Modified August 30 to October 10 2003 (Compatibility Notes,
Fizzle,
TEST)
Modified April 7 2001 (RedMaker 2.85b)
Page created sometime in 1997