Maezumo is Copyright Christian Schmidt and shared under the terms of
the GNU Public License (v3). The packages on this page are configured
for x86 GNU/Linux systems. The Windows version is at the Maezumo home
page: http://www.corewar.info/maezumo/
This page is for modifications, discoveries and thoughts about
Maezumo. The materials here are my responsibility so if there are any
problems or comments send them to me: Terry Newton (wtn90125@yahoo.com)
Current Version
Maezumo_Linux_110.tar.gz -
packaged 12/10/11 - 1.10 Fizmo version recompiled/packaged for Linux
Previous Versions
Maezumo_Linux_106cs.tar.gz
- version 1.06cs 10/27/09 - takeover watcher options, hint mods
Maezumo_Linux_test106x17.tar.gz
- version 1.06x17 4/18/10 - with additional reinsertion options
Maezumo_Linux_102.tar.gz -
previous 1.02x2b version (added stats and benchmarking)
Maezumo_Linux_103.tar.gz -
previous 1.03x7 version (added soup display, hint mods)
Maezumo_Linux_104.tar.gz -
version
1.04 8/3/09 - hint probability settings, benchmarking tools
Maezumo_Linux_test105x10.tar.gz
-
version 1.05(pre)x10 8/16/09 - nano hints,
re-insertion mods
Random Thoughts
When developing things change, these notes will be edited as needed
to preserve consistency. Previous
notes, much of
which no longer apply to more recent versions, have been moved to the
unlinked maezumo_oldnotes.html file in this directory.
12/10/11 - Modified the 1.10 archive - fixed some of the file
permissions, added a couple nano benchmark sets, changes to the readme
including a note that libncurses5:i386 is required to run under 64-bit
versions of GNU/Linux.
12/5/11 - Added a "stock" 1.10 version based on the Windows version
(released 10/30/11)
recompiled for Linux (at the moment no changes to source code which is
dated 12/27/10). The Maezumo code is based a previous 1.06x16 version
with a new
optimize hint mode added to it (haven't tested it yet under Linux), the
archive is based on 1.06x17 updated with the new 1.10 code. This is a
brand
new packaging so might need some tweaking...
4/18/10 - slightly modified the 'x17 archive - altered the nano,
standard
and tinylp INI files, removed the extra nano INI files (mostly
redundant, scrounge around here for alternate settings) and added a few
more
notes to the readme.txt, mainly about how variable the process is but
also a bit about running warriors in pmarsv from the browser.
4/16/10 - Trying something... added ReInsMode settings 6 and 7 to
randomly select the reinsertion mode for each hill cycle. Mode 6
randomly selects modes 0 through 5, Mode 7 randomly selects between
modes 3 and 5 (reinsert from the hill or from the species directory).
Perhaps this might help avoid evolving "anti-high-score" warriors that
sometimes occurs when reinserting only from topscore or species -
mixing it up might help keep the soup warriors on their toes, exposing
them to a wider variety of guiding code (both to compete against and to
further mutate). Perhaps might help... it's an imprecise art that's
often driven more by luck than the exact settings, and just because a
given INI does well doesn't mean it'll do well again (for this reason
the included INI's might or might not produce reasonable warriors,
results will vary considerably).
The 'x17 version includes a few other things: Can now be recompiled
for Windows or Linux without editing the source code, includes the LP
tests sets from Fizmo's 1.06 archive and a new experimental tinylp INI
(probably needs work), includes a new nanoht2 bench set that better
mimicks the current SAL nano hill (at least with known code), and the
bench.bas and rebench.bas programs now sort the report so that the
highest scoring warriors are at the end.
4/9/10 - Found a minor bug in the soup display code I wrote - if the
SoupDisplay setting was even (2 or 4) it didn't display the soup. This
probably wouldn't be noticed under Windows as last I checked those
unicode strings weren't supported anyway (so doesn't really matter
there) but I noticed when I tried to use the narrow blocks option, now
1.06x16.
Sleepy Lepus (a paper made with 1.06cs) got KOTH at the Koenigstuhl
Infinite Nano Hill (just barely). Nano 3551 (a paper from the
4/7/10 post below) got 6th place, and Little Red Rat (a stone made
using a 1.04 proto, listed in the 8/1/09 post) got 4th place. Not bad.
Here's Sleepy Lepus...
;redcode-nano
;name Sleepy Lepus
;author Terry Newton
;strategy evolved with -=< Maezumo >=- (1.06cs)
;strategy generation 269 of a hint-made paper
;strategy benchscore 156.32 (nanoBM07 1000 rounds)
;species name Nano 2302
;evolved:07:36:11 11-05-2009
;origin Paper 26
;generation 269
;assert CORESIZE==80
spl.b # 0 ,> 13
mov.i } -1 ,} 1
spl.b { 52 ,> 40
mov @ -5 ,{ -6
djn.x $ -1 ,< 46
end
...and here's the code for Paper 26 Generation 0 from which it
evolved from...
spl.b # 0 ,* -31
mov.i } -1 ,} 1
spl.b < 17 ,* 11
mov.i $ 26 ,{ -27
mov.i @ 32 ,} 30
This seed warrior scored 113 points against the nanobm07 test set.
Top-score reinsertion was used to drive the score up, here's the INI file (has .txt extension for display
purposes). Mutation didn't alter the code as
much as with Frothering Foam (8/17/09 entry), just had to put a DJN at
the end and rewrite most of the modes and numbers. The process still
amazes me.
4/7/10 - The 106x15 test
version is modified to include an option to reinsert previous warriors
from
the species directory, has an option to display the top score warrior
in the HTML report, and includes a custom nano test set. The default
INI is set to generate paper warriors
for nano. I already had a 106x14 version with the new re-insert option
from last year but hadn't really tested the mod, after reading the 1.06
announcement I dragged it out to give it a workout. The new
re-insertion option is similar to the "Valhalla"
process found in some other evolvers, when a re-insertion operation is
triggered, it chooses a previous warrior that scores within a specified
percentage of the current top score. The idea is to try to keep the
soup scores from sliding backwards while maintaining diversity but as
usual with a random process such as this, doesn't necessarily cause
stronger code to be generated, just another thing to try. The 'x15 mod
is a simple hack I made to keep from having to frequently open
topscore.red to see the current high-score, one of the side-effects of
using re-insertion is it tends to evolve warriors to combat the
re-inserted warriors, quickly driving top-scoring warriors from the
hill.
Another technique I found useful when targeting the SAL nano hill
was to use a custom benchmark set that scores published warriors
similarly to their hill scores, 'x15 includes the nanoht1
test
set I put together to sort of mimick the hill from early
December of '09. The hill has changed since then so not sure how close
it is now, back then it could predict hill score within around 4
points. To fine tune the test set I'd use a benchmark batch (a version
of test800b.bat edited for nano) to see
what warriors were affecting the scores for the known warriors, then
alter the test set as needed to approximate the hill scores.
Here's a nano paper warrior generated using the new ReInsMode 5
option... [warrior comments edited]
;redcode-nano
;name Nano 3551
;author Terry Newton
;assert CORESIZE==80
;strategy evolved with -=< Maezumo >=- (1.06x15)
;strategy generation 236 of a hint-made paper
;strategy nanoht1 score 152, nanobm07 score 150
;evolved:06:08:24 04-07-2010
;origin Paper 6
;generation 236
;benchscore 152.47 (nanoht1 1000 rounds)
spl # 0 ,< 69
mov.i } -1 ,} 1
spl.b < 28 ,> 12
mov * 8 ,{ -5
djn.x $ 79 ,{ 45
end
For
most of the run the settings were No of Koth=5, RItopPerc=95,
ReInsChance=0.03, MutSelect=0.2, SoupIter=100. At the beginning of the
run No of Koth was 3 ReInsChance was 0.01 but the re-inserted warriors
didn't seem to be able to get a foothold, other warriors evolved to
defeat them but those warriors didn't score particularly well. Even
with the higher re-insertion rate the better-scoring warriors still
tended to be driven from the hill but enough made the hill to push the
top score up a bit more. Increasing No of Koth results in more failed
benchmarks but seems to increase the odds of better-scoring warriors
slipping past the anti-topscore warriors that often inhabit the top of
the hill.
Looking at the evolved output, I see a couple of possible
optimizations that could be made... but evolved code is supposed to be
a bit weird and even though mov is the same as mov.i and for nano 79 is
the same as -1, differences like that provide a good clue to determine
what evolved from what so probably should leave that alone.
4/6/10 [edited] - Maezumo 1.06 has been released with improved hints
and an option that enables and disables the
hint probabilities to try to keep the hill more balanced rather than
one type of warrior dominating the hill. I already had a previous
version of 1.06 that Fizmo sent me, the program code (besides a few
comment differences) is identical to the released 1.06 version and
the port was ready-to-go, so tar-gz'd and posted. Fizmo's 1.06
package includes benchmark sets for LP warriors and alternate embedding
code, not included in the 1.06cs version here. The default INI for this
version is set for standard warriors with no mutation to demonstrate
the new "takeover watcher" feature (it appears to be one of the
original INI's for this version), alternate INI files
included for nano, tiny, standard and X.
8/17/09 - Nano hints are fun, but mad mad bombers still rule the
nano hill. The trouble seems to be the weaker SPL MOV MOV DJN [junk]
form usually forms first, preventing the development of the (usually)
stronger SPL MOV MOV MOV DJN or MOV SPL MOV MOV DJN forms. The only
reliable solution to this [that I've found so far] is to watch the
soup, if the weaker 4-line
form takes over, start over (I use a script for this that deletes all
.red files from the main, soup and species directories and deletes
evo.ini, age.ini and warrior.ini). It often takes several tries before
the superior form takes over. I seem to have more trouble with this
effect than with other evolvers, the Maezumo soup seems to prefer the
weaker form for some reason I haven't figured out yet. I suspect it has
to do with the instruction and/or address mode weighting, and possibly
due to not mutating the instruction modifier separately (although
that's probably not it - other evolvers using a fixed
instruction.modifier list have an easier time converging to the
stronger form). Fundamentally Maezumo is a hint-driven evolver, as such
the fixed instruction.modifier architecture cannot change without
breaking the hints. This isn't really a problem, even though not
originally designed for nano, Maezumo is perfectly capable of
generating
nano warriors that can take KOTH at SAL (and at the moment, Little Red
Rat is in the #1 spot). That it's a bit finicky might be considered an
advantage... we can probably do without hordes of effortlessly evolved
warriors taking over the nano hill - it really should take work on the
part of the user to make it happen. Yet the hacker in me still wants to
either find better settings, or a modification, that naturally
converges to the stronger form. More importantly, learn what it is that
determines this. I have a feeling it's going to be a mod... likely in
the form of custom instruction.modifier and address modes, which if
specified replace the fixed tables (but in a way that doesn't affect
the hints and so that, as with other mods, existing INI files still
function the same). Sure this would give the user the power to generate
totally incorrect redcode and a shower of errors, but that's OK if it's
optional and gives advanced users the ability to specify the desired
mix. [maybe... it'll probably won't happen very soon... despite having
to restart it a few times to get it going in the right direction I'm
quite happy with the current stock and experimental versions].
Ok back to experimental nano paper hints. Here is Frothering Foam...
;redcode-nano
;name Frothering Foam
;author Terry Newton
;assert CORESIZE==80
;strategy evolved with -=< Maezumo >=- v1.05(pre)x10
;strategy evolved:05:43:35 08-16-2009 as Nano 4873
;strategy generation 373 of a hint-made paper
;strategy nanoBM07 score 164, nanob2 score 146
;origin Paper 7
;generation 373
;benchscore 164.25 (nanoBM07 1000 rounds)
spl # 0 ,> 14
mov } -1 ,} 1
spl.ab < 53 ,< 18
mov $ 3 ,< -7
djn.f $ -1 ,< 47
end
This was made using the INI file
in the 1.05(pre)x10 package, using
topscore.red re-insertion. It's not a perfect paper (when run in
isolation it stops replicating before running out of cycles) but not
too shabby. The really amazing part to me is that it evolved from this
initial hint-made code...
spl.b # 0 ,* -24
spl.b $ 24 ,{ 37
mov.i } -2 ,} -1
mov.i * -36 ,< 14
dat.f $ 0 ,$ 0
...totally different. I expected tweaked constants etc but evolution
almost completely rewrote the code, greatly improving its strength, but
somehow preserved its paperness. That blows me away. This isn't an
isolated case, the previous x9 mod version using high-scoring hill
warrior reinsertion produced this...
;redcode-nano
;name NanoWorms
;author Terry Newton
;strategy evolved with .=< Maezumo >=. version 1.05(pre)x9
;strategy 8/13/09 hill cycle 1226 paper hint generation 297
;strategy NanoBM07 score 159, nanob2 score 145
;assert CORESIZE==80
spl.b # 0 ,< -4
mov.i } -1 ,} 1
spl.b < 56 ,< 41
mov * 6 ,< 77
djn.f $ -1 ,< 48
end
...from this initial warrior code...
spl.b # 0 ,{ 39
spl.b $ 10 ,* -31
mov.i } -2 ,} -1
mov.i { 26 ,< 15
mov.i @ -13 ,@ -33
In other news... I just got a brand new HP 110 mini sub-laptop with
a 160 gig HD and HP's "Mi" brand of Ubuntu. Runs Maezumo perfectly :-)
although I did have to use Synaptic to install libstdc++5 (and
gcc-3.3-base) to get Blassic to work for the bench tools. I was a bit
worried after reading something about having to recompile binaries
(written about the older 1000 mini) but that doesn't seem to be a
problem with this machine, just have to give plain x86 Linux binaries
the libraries they need and they run. Not crazy about the
consumer-grade interface skin but I do most of my work from the file
manager and terminal anyway. Despite the prominent "terminal disabled"
stuff on HP's web site it took all of 10 seconds to find it (press
alt-F2 and type gnome-terminal) and another few minutes to add a
terminal script to the nautilus-scripts directory so I can launch a
terminal wherever I'm at. The Linux pmars/pmarsv binaries from my /cw/
list run fine (using the pmars[v]092N1 versions), should make a fine
little evolving setup. Keeps the stuff from clogging up my desktop
system's CPU... I've got real work to do :-)
8/16/09 - Posted a new 1.05(pre)x10 "experimental" version with
better re-insertion options and a preview of Fizmo's new hints which
now work even with nano. Consider the new hints
a work-in-progress, but even like it is it's a pretty darn good work!
For nano, the soup can be seeded with hint-made papers which then
increase in strength through evolution to become much stronger than the
initial papers. However they are still weak against "mad mad bombers"
(like just about every nano warrior except other mad bombers) so unless
steps are taken the soup will simply evolve warriors that defeat them
or turn the papers into bombers. To counter this for the "x10"
variation I added some code that copies the best-scoring warrior of the
run to "topscore.red" then added a new ReInsMode option to copy
topscore.red back to the soup instead of a hill warrior, so even if all
the strong warriors get pushed off the hill it will still keep
re-inserting the best-scoring warrior. Provided that warrior doesn't
turn to stone, this keeps the soup from forgetting it's supposed to be
evolving strong warriors. This option is similar to how the SEWAX
evolver works so even without hints it should help to drive the
benchmark score higher. This can lead to the "focus" effect where the
evolved warriors do well against one set of warriors but not other
warriors, so it's still a tricky thing... but not as tricky as it was
in the x8 version where the strong warriors could simply be pushed from
the hill, leading to a decrease in bench scores.
To make a Windows version of 'x10 get the Linux test version and
extract it with an extractor that understands tar.gz files, get the
stock 1.04 version from Fizmo's site and extract it (rename the
directory to indicate 1.05), install FreeBasic, copy the
files/maezumo.bas file from the Linux version to the base directory of
the Windows version and rename it to say Maezumo105x10.bas, copy the
files/embback.txt and files/embfront.txt files to the files directory
of the Windows version (this is a new feature that allows embedding
evolved warriors within other warrior code), copy over the updated
faq.htm file and new INI file(s), edit the Maezumo105x10.bas file and
change UseWin=0 to UseWin=1, open a command prompt in the Windows
Maezumo directory and enter:
"c:\program files\freebasic\fbc" Maezumo105x10.bas
This should produce a Maezumo105x10.exe file.
[if needed the previous 1.04x8 experimental version is in the
Maezumo_Linux_test104x8.tar.gz archive for now.]
8/4/09 - The re-insertion rate in the experimental version's INI
seems to be too high... converged to weak SPL MOV MOV DJN forms in two
consecutive runs. Backing off ReInsChance to 0.01 (with the present
settings equivalent to about 13 soup battles per re-insertion) and
reducing data change rate from 0.08 to 0.07 seems to be producing
better results, converging more towards the much stronger SPL MOV MOV
MOV DJN form, at least in this run. So why not just initialize it to
the desired form to begin with? Well, tried that but it doesn't work
well, evolution does not like to be forced. With only 5 instructions,
nano warriors need to arise naturally so the interactions between the
instructions form a unified whole and it resists attempts to interfere
with the process. It seems that in the early stages of development, the
desirable forms need the other forms to teach them how to be strong
warriors.
8/3/09 - Updated to version 1.04 with new INI settings to control
the probability for each hint mode when using hint mode 7 (all hints at
once), this helps to control the mix of strategies on the hill. Fizmo's
page now hosts the equivalent Maezumo 1.04 Windows version. To kick off
the next round of experiments, the experimental "test" version adds a
(sort of) "Valhalla" scheme where hill warriors are re-inserted back
into the soup. One of the options is to re-insert higher-scoring
warriors to (maybe) help drive up the strength of the soup, it doesn't
always choose the highest scoring warrior but to help improve diversity
each higher-scoring warrior on the hill has a 50% chance of being the
one chosen for re-insertion. The effect of re-insertion is complex, the
re-inserted warriors might replicate and strengthen to improve the
scores (the intended effect), or the soup warriors might evolve
strategies to defeat them but possibly score lower in the process and
drive high-scoring warriors off the hill.
The previous .bas.tar.gz source-only file has been removed (for
now)... it's easier to simply archive the latest experimental version.
The source is in the files directory, to update a Windows version edit
so that UseWin = 1 and recompile using FreeBasic - i.e. install
FreeBasic, extract or open using an extracter that understands .tar.gz,
copy the files/maezumo.bas file to the base directory of the Windows
version along with the updated INI file(s) and faq, edit maezumo.bas
and set UseWin = 1, open a dos prompt in the base directory and enter...
"c:\program files\freebasic\fbc" maezumo.bas
New features in experimental versions are subject to change or might
have bugs (more so than the regular version), the experimental version
is the test-bed for new ideas. Some ideas might not work out.
8/2/09 - Yesterday and last night's run with the 1.03x7 nano INI did
fairly good, produced a warrior at hill cycle 2139 that scored over 150
on both nano test sets (152.5 and 155.2 using pmars -P). It was
slow-going though, it took until about 1100 hill cycles before I
started getting scores over 140. So to summarize... after 5 runs (that
I saved) with these parameters, run 1 made a warrior at hill age 1352
that placed 2nd on nano, run 2 got stuck on a weak SPL MOV MOV DJN form
and hadn't improved after almost 3000 hill cycles, run 3 made weak
papers of the form of SPL MOV SPL MOV DJN and by about hill cycle 900
had mostly replaced them with bombers (but I had changed the INI to try
to strengthen the papers... didn't work), run 4 settled into a
potentially strong MOV SPL MOV MOV DJN form but by about hill cycle
1400 the best score was only 144 (might continue this run), and run 5
was last night's run that peaked over 150 after running a couple
thousand hill cycles. For reference in case the settings get changed,
this was with the following settings (plus usual nano settings with a
hill size of 21)...
EnableSeed :0
MutByProb :0
MutSelect :1
MinChanges :0
SoupIter :100
SoupRounds :100
InstrRate :0.02
AddrRate :0.04
DataRate :0.08
SwapRate :0.01
InsertRate :0.01
DeleteRate :0
DupLine :0.2
IncDec :0.2
BigNum :0.6
Topology :0
SoupSize :1500
SoupX :50
8/1/09 - I discovered a new trick... if style="line-height:0.85;" is
added to the pre tag just before the soup prints then the spacing
between the lines is eliminated (and then some), this causes solid
blocks to look much better and eliminates having to play with the
background color etc. Like this sample
output showing a 1500-warrior nano soup in a very early stage. A
new version is in the works that has this and other enhancements, for
now added the 'x7 changes to the current "experimental" 1.03 [version].
Also includes new nano settings which almost got a
warrior named Little Red Rat to the top of the hill, lacked 0.1 points.
So close. More interestingly, these settings also generated nano
papers for part of one run, including these warriors...
;redcode-nano
;name Nano 390
;author Maezumo
;assert 1
;evolved with -=< Maezumo >=-
;evolved:20:12:20 07-31-2009
;origin Random 216
;generation 226
;benchscore 137.45 (nanoBM07 1000 rounds)
spl # 21 ,} 43
mov.i } -2 ,} 1
spl < 44 ,> 66
mov $ 21 ,< -5
djn.f $ -1 ,@ 65
end
;redcode-nano
;name Nano 590
;author Maezumo
;assert 1
;evolved with -=< Maezumo >=-
;evolved:22:26:57 07-31-2009
;origin Random 216
;generation 292
;benchscore 146.42 (nanoBM07 1000 rounds)
spl.x # 24 ,> 33
mov.i } -2 ,} 1
spl.a < 15 ,> 27
mov $ 55 ,< 55
djn.f $ -1 ,{ 43
end
The last warrior is losing its replicating ability, as the run
progressed the papers were replaced by bombers (changing the INI
settings while evolving might have caused that, I might have disturbed
the balance). These warriors were made with a new version being tested
but none of the pure
mutation code was changed from the 1.03 experimental version so should
be capable of producing similar results (maybe... every run is
different).
A previous run with the new nano settings produced this mad bomber,
which got 2nd place on SAL nano...
;redcode-nano
;name Little Red Rat
;author Terry Newton
;assert CORESIZE==80
;strategy evolved with -=< Maezumo >=- (1.04 proto version)
;strategy grid soup of 1500 warriors, hill age 1352 gen 847
;strategy nanbm07 score 153 Koenigstuhl-20(6/09) score 156
;evolved:21:31:30 07-30-2009
;origin Random 89
;generation 847
;benchscore 154.97 (nanoBM07 1000 rounds)
spl.x # -3 ,> 24
mov $ 1 ,< 1
mov > 51 ,> 19
mov @ 39 ,{ -3
djn.x $ -1 ,{ 61
end
The new grid soup and "swap lines" mutation options seem to work
well, but pure evolution is a very random process, some runs produce
strong results while other runs with exactly the same parameters
produce weak results. Just like in nature... quite often the dominant
form in a given environment is not the most intelligent one, and a
relatively intelligent (high-scoring) species can be taken out by a
simple core-stomper that does not rate well.
Evolving Stronger Nano Warriors
With Maezumo (take II)
Originally Maezumo wasn't considered for evolving nano warriors, the
original 1.00 version had an unnoticed bug that had to be patched to
effectively evolve nano warriors at all. Version 1.01 is capable of
producing strong nano warriors but finding them requires running an
external benchmark program. Version 1.02 added automatic benchmark
capability to make it easier to spot strong warriors, that helps but by
itself is not enough, the strong warriors need to be re-tested against
another benchmark set to find warriors capable of placing near the top
of the nano hill. Version 1.02
and eventually version 1.03 (with new hints from Fizmo) was modified to
allow using a grid-based soup which provided somewhat better diversity
and added a soup display to see what was happening in the soup. Also
added a new "swap lines" mutation operation which I found to be very
useful with another small test evolver. To produce stronger nano
warriors the settings needed to be adjusted so that good warriors could
propagate through the soup without being disrupted too much, but with
enough mutation to increase diversity and increase the chances of
finding better
warriors. Using the display, the parameters were set to generate
warrior
"islands" of about 20 to 200 warriors per instruction sequence, if
mutation is too low then the same sequence will take over the soup, if
mutation is too high then reasonably-sized islands don't develop and
usually the warriors will be weak, unable to "remember" useful
techniques. HTML can be tricky and displays differently depending on
what browser is used, so the 1.03 version went through a few iterations
in search of a better-looking soup display that worked equally well
under Linux and Windows.
With the new mutation and visualization tools, Maezumo is now about
as strong as any for making nano warriors provided the user is patient
enough - it often requires several lengthy runs before really strong
nano warriors are found, that's just the way an unguided pure evolver
works... the warriors evolve to beat other warriors in the soup and on
the hill, there is no guarantee that they evolve to please the human
operator. One of the tricks is to set up the evolving environment so
that it favors the production of desirable warriors. This requires
careful adjustment of the mutation and other parameters, the nano INI
file included with the latest 1.03 versions should be fairly close but
there will probably always be room for improvement. Quite often a
"lesser" form develops (like SPL MOV MOV DJN junk) and
the warriors never get very strong, have to start over and try again.
One trick to try is once a desirable warrior form
is produced, increase the number of soup rounds, but that doesn't
always
work. Fewer soup rounds tends to produce more diversity due to the
increased scoring error, which gives newly mutated warriors that would
otherwise be wiped out a chance to further mutate into something
stronger.
Once strong warriors are being produced, to do well on the nano hill
the best warrior has to be selected. The latest versions include new
benchmarking tools to help with that. The findtop program lists all
warriors in the species directory that score within 95 percent of the
highest detected score (according to the bench score comments), and
outputs to a "topscore.txt" file. The rebench program reads
topscore.txt and re-tests the warriors against another nano test set
and outputs to another file, which can be sorted using the command-line
sort utility so that the top scores appear at the end of the list. The
better warriors will score high on both benchmark sets, so to select a
warrior for the hill I find the warrior that has the highest score on
both the nanoBM07 and the nanob2 (Koenigstuhl top 20) test sets. A
warrior that scores very high on one but not so high on another usually
won't do that well on the hill (even if the total of both benchmarks is
higher). Since the nano hill content is unknown, the goal is to select
a warrior that shows strength in general, not just against specific
warriors in specific benchmarks. It may help to put together a custom
benchmark that better imitates the hill contents but beware of warriors
that score well on the custom benchmark but not others, they might
initially post high but will drop in placement as the hill contents
change. Warriors that score high against multiple test sets tend to
maintain their placement better as new warriors are posted to the hill.
These are things I've noticed but there are no firm rules when it
comes to a random process like pure evolving. For each observation
there are likely exceptions... sometimes warriors do well despite
scoring poorly against one or another benchmark, sometimes just picking
the best-scoring warrior can gain good placement. Sometimes very strong
code is produced on the first try, but it might take 10 tries. INI
settings might work very well the first time, then never work well
again. Other settings might be more consistent but only produce
moderately strong warriors.
There are a few more tricks that could be tried... one is Valhalla
where a warrior on the hill can be selected to put back into the soup.
A variation would be to select the hill warrior with the highest
benchmark score. Hmmm... but there could be adverse side effects from
doing this. There's a chance that the inserted warriors will just keep
the soup making the same thing rather than finding improvements.
There's also a chance that the soup warriors will evolve to beat the
inserted warriors but in the process not score well but instead just
push the good-scoring warriors off the hill. There's one way to find
out... later [added to the 1.04x8 experimental version].