Evolved Core-Warriors

Or... If you can't make them, grow them.

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].


GA_WAR

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.


Brewing a batch of Warriors.

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?


Sifting through a mountain of data.

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.


Full Battle Results.

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


SYS 4

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

Sys4b port notes...

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...

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.


RedMaker

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.


Y.A.C.E

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...

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:

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


Fizzle

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...


TEST

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).


XP Compatibility Notes

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.


Linux Compatibility Notes

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.



Redcode Evolver Bash Script

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




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.


Small Evolvers

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.



Maezumo

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.


MEVO

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.




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