Notes about evolving coresize 800 warriors
August 14, 2000 - I have been evolving smaller coresize-800 warriors, some were submitted to the Tiny RC hill at SourceForge. For benchmarking I'm using both the current hill contents (source is available on that hill) and a set of 9 "tiny" warriors written by Franz. Hill dynamics are complex, to rise to the top a warrior might need the help of other warriors to drive up the target score or drive down the scores of other warriors but not the target. Here is one that made it to the top but I'm pretty sure only briefly since the hill just started... in hill dressings...
;redcode-94
;name BgBc 196767 Evolved
;assert CORESIZE==800
;author Terry Newton <wtnewton@nc5.infi.net>
;remark Produced by Redmaker on 10 Aug 2000
mov.ab $ 44 , # 789
jmz.ab * 1 , # 6
jmp.ba * 6 , < 8
mov.b $ 756 , } 155
jmp.i } 558 , $ 18
mov.f < 611 , < 587
spl.x # 1 , $ 1
mov.i * 165 , >-3
djn.x $-1 , {-4
end
Here is the same species after 412K iterations...
;RedMaker Warrior
;name BgDe
;assert 1
jmn.ab # 1 , @ 621
sub.ba $ 702 , } 616
sne.x # 1 , { 1
spl.x { 748 , {-5
mov.ba $ 2 , #-5
spl.f # 600 , $-3
mov.i > 88 , <-6
djn.f $-1 , }-1
end
A little stronger but could be better... makes a couple passes then stops.
August 23, 2000 - finally evolved a population of replicators.. added 5 replicating Fa members from iteration 14582 of the Aug 17 run to a 100% dense random start and let it go using RM 2.81. Took awhile, at times none of the Fa members could replicate but eventually by iteration 80532 the Fa species took over and has improved drastically. This member has a replicating portion of only four instructions...
;RedMaker Warrior ;name FaCk ;assert 1 spl.i @-1 , # 5 nop.f @ 0 , @ 3 spl.f # 3 , # 0 mov.i @ 6 , <-1 mov.i > 793 , } 1 jmp.b $ 103 , # 646 end
A replicating portion from core...
00492 SPL.F # 3, # -78 00493 MOV.I @ 6, < -1 00494 MOV.I > -7, } 1 00495 JMP.B $ 180, # -154
Eventually it falls apart, scores about 135 against the 8-19 SF tiny hill, about 100 against Franz' testset.
A stronger one (145/110) with a 5 instruction replicant that hangs together better...
;RedMaker Warrior ;name FaCj ;assert 1 slt.i $ 607 , } 0 mov.x } 108 , * 448 mov.i $ 2 , $ 246 mov.i < 2 , # 758 spl.a $ 411 , @ 481 spl.f # 303 , #-5 mov.i @ 6 , <-1 mov.i > 793 , } 1 jmp.b > 103 , } 646 end
00435 SPL.A $ -389, @ -319 00436 SPL.F # 303, # -139 00437 MOV.I @ 11, < -1 00438 MOV.I > -7, } 1 00439 JMP.B > 241, } -154
These were evolved using Redmaker 2.81 with double fixed battles, replace loser enabled (the mod to 2.81), and an instruction set biased with more spl, mov and jump instructions and more .i .f and .x modifiers.
September 2, 2000 - The Fa species is getting stronger... this one ranked about mid-pack on the 9-1 SF tiny hill...
;RedMaker Warrior
;name FaQs
;assert 1
mov.x # 623 , $ 683
spl.f # 7 , } 7
spl.ba # 0 , } 1
mov.i > 581 , } 4
mov.i >-6 , } 2
mov.i > 670 , { 369
jmp.b } 414 , } 308
mov.a * 502 , * 263
djn.x {-4 , { 233
end
;origin Population Fa at 88K+
;parent FaQr (201)
;generation 202
;iteration 170868
;battles 4
;score 172
After some iterations with crossover enabled both the average soup score and peak scores are up, this one (barely) got top spot on the Sept. 2 SF tiny hill... (yippie!)
;RedMaker Warrior
;name FaCk
;assert 1
mov.ab # 623 , $ 683
spl.f # 7 , } 2
spl.i # 0 , } 1
mov.i > 581 , } 4
mov.i >-6 , } 2
mov.i # 670 , { 369
jmp.a } 414 , } 1
mov.a * 36 , > 793
spl.f @ 510 , * 723
mov.i *-9 , # 275
mov.x * 558 , { 764
end
;origin Population Fa at 88K+
;parent FaCj (263)
;generation 264
;iteration 196141
;battles 7
;score 172
These are original redmaker 2.83 output, comments are altered in the hill versions. The generation counts are off since RM didn't start counting until iteration 88000 something, when I appended an ;origin ... line to the end of all members and upgraded RM to track. It is probably about generation 400 or so since 0 - but that wasn't the beginning since the run started with already-evolved Fa members who knows how many generations old since the original random creation.
December 17, 2000 - all of these have long since passed off the hill, however three Fa varients have been hanging in there... in hill-dressing...
;redcode-94
;name FaKi 510 Evolved
;author Terry Newton <wtnewton@nc5.infi.net>
;made Sept 9 2000 by RedMaker 2.83
;assert CORESIZE==800
mov.f > 623 , < 683
spl.x # 7 , } 581
spl.ba # 0 , } 1
mov.i < 581 , } 4
mov.i >-6 , } 2
mov.i @-3 , # 3
jmp.a < 423 , } 1
mov.i } 36 , } 263
mov.ba # 115 , > 705
djn.x } 521 , $ 513
end
;redcode-94
;name FaGc 607 Evolved
;author Terry Newton <wtnewton@nc5.infi.net>
;made 09/13/00 by RedMaker 2.83
;assert CORESIZE==800
sub.x > 411 , * 2
spl.i # 9 , } 6
spl.i # 694 , } 1
mov.i > 581 , } 4
mov.i >-6 , } 2
mov.i # 159 , } 258
djn.i < 280 , } 1
mov.i < 36 , } 263
mov.i { 4 , }-7
dat.f } 509 , $-5
mov.i <-7 , * 64
mov.a * 36 , < 131
dat.i { 182 , < 151
add.f > 11 , }-5
end
;redcode-94
;name FaCc 1595 Evolved
;author Terry Newton <wtnewton@nc5.infi.net>
;made with RedMaker 2.83, October 10 2000
;assert CORESIZE==800
spl.b # 1 , < 739
spl.a # 1 , } 1
mov.i > 414 , } 4
mov.i >-6 , } 2
mov.i > 146 , < 716
jmp.i $ 280 , }-1
mov.i # 45 , *-6
dat.a @ 297 , <-10
jmp.x > 45 , { 507
spl.f {-1 , { 572
end
The SF tiny hill has been slow lately, only three new warriors in over two months which explains why these haven't been bumped yet. FaCC is fairly strong, gets about 160 against the Franz test set. FaKi and FaGc turn in scores of 132 and 147. Currently (12-17-00) they're placing 4th, 8th and 14th on the hill.
FaGc places lower despite scoring 15 more bench points, obviously fixed benchmarks don't tell the entire story. When picking through the soups I mostly benched against the actual hill contents using a modified bench method that also plays and counts self-battles to better predict actual hill performance, and if I had similarly strong warriors I'd pick the one that does the best against the Franz testset. Having access to the opponents makes it much easier to select good code, otherwise one would have to rely on fixed benchmarks and take their chances.
Franz scores for the current SF tiny hill... (200 rounds fixed sequence)
156.2 1 5936 Evolver 1100 x 500 by Martin Ankerl 142.1 2 5596 yake_mk10 by William Young 147.2 3 5594 yake_mk10_Batch2 by William Young 161.6 4 5554 FaCc 1595 Evolved by Terry Newton 139.4 5 5479 redrace (10/06/00) v11 by Dave Hillis 146.5 6 5405 redrace (11/30/00) alpha.red by Dave Hillis 137.5 7 5396 Evolver 4870 x 200 by Martin Ankerl 133.5 8 5271 FaKi 510 Evolved by Terry Newton 132.3 9 5201 Evolver 1 x 30 by Martin Ankerl 122.4 10 5177 redrace v7_294.red by Dave Hillis 137.6 11 5173 redrace (10/02/00) h1_5.red by Dave Hillis 137.2 12 5145 yake_mk8 by William Young 142.8 13 5095 Evolver 4890 x 200 by Martin Ankerl 146.3 14 4999 FaGc 607 Evolved by Terry Newton 144.9 15 4997 redrace (10/02/00) h1_24.red by Dave Hillis 133.8 16 4945 redrace (10/02/00) h1_2.red by Dave Hillis 154.9 17 4902 RedRace (9/19/00) h1_5.red by Dave Hillis 138.8 18 4876 redrace (10/02/00) h1_7.red by Dave Hillis 139.1 19 4825 redrace (10/02/00) v5_106.red by Dave Hillis 141.3 20 4778 redrace (10/02/00) h1_13.red by Dave Hillis
There isn't much useful corelation between the Franz results and ranking on the hill, although the benchmarks might be more indicative of true performance but that does little good when the group is slanted heavily towards papers, 13 out of 20. Time will tell, but perhaps the higher scoring members will survive longer as new warriors and different strategies are added to the hill. Charted benchmark results and warrior listings are in the report1217.txt file.
March 27, 2001 - some notes I dug up about a newly evolved species...
Here's a set of parameters that evolved papers from
a random start... (at least it did for me once)
-----
Minimum survival score 95
Maximum survival score 125
Score adjust interval 200
Always remove loser Yes
Replace removed loser Yes
Red-mix mode Same
Line change rate .1
Perfect copy rate .2
Remove tie rate .3
-----
Start Density .5
Start Testing Off
Birth Testing Off
Extra info in comments All
-----
Instructions: dat dat dat mov mov mov mov mov spl spl spl spl
jmp jmp jmn jmz djn add sub slt sne seq mod mul
div
Modifiers: a b ab ba f f f x x x i i i i i i i i
Address modes :# $ @ * < > { }
-----
Local number chance .6
Local chance varience .2
Chance of data change 1
Chance of size change 1
Chance of addr change 1
Chance of inst change 1
Rounds per battle 20
Max warrior length 20
Max instruction cycles 8000
Max processes 8000
Core size 800
Grid size (restarts) 21
PMARS base comline pmars -b -l 20 -d 20
PMARSV base comline pmarsv -b
Test PMARS comline pmars -b -l 20 -d 20 -f
Graphics mode parm -v 014
Text mode parm -v 404
Double battle fixed Off
Mix courseness .5
-----
A warrior from iteration 239245...
;RedMaker Warrior
;name UfFj
;assert 1
mov.b @ 727 , * 0
spl.f # 452 , } 2
mov.i < 7 , { 2
mov.i < 604 , {-2
djn.i $ 533 , < 151
djn.f $-5 , } 748
djn.x $ 533 , < 151
jmn.f } 137 , } 1
div.f { 309 , {-2
end
;origin random start
;parent UfEi (424)
;generation 425
;iteration 237844
;battles 6
;score 173
Here's a young 4-line varient, the only 4-liner
in the soup at iteration 261862...
;RedMaker Warrior
;name UfIh
;assert 1
spl.ab # 452 , } 2
mov.i < 7 , { 2
mov.i < 604 , {-2
djn.x $ 533 , < 151
end
;origin random start
;parent UfJi (439)
;generation 440
;iteration 261815
;battles 0
;score 0
End extract. I don't think I have found the optimum parameters for RedMaker yet although I copied these into RedMaker's defaults since they're better but paper forms are still way too rare, let alone scanners. As to which way to go with the parms I'm not sure but things to try would include weighting the address modes various ways (seems to be a lot of "}" on the SF tiny hill at the moment) and playing with the change odds to alter data fields more frequently. Change-rate and survival score probably have a lot to do with things. I'm not convinced crossover and fixed battles are actually better, stronger warriors have resulted when enabled but I think the biggest factor is what kind of "happy accidents" occur.. boils down to luck.
3/28/01 - ok.. there seems to be at least one beneficial effect from crossover ("redmix") in that it tends to produce repeating code lines when warriors of different lengths are mixed, which can seed further structure. Same could be done by simply occasionally repeating lines. Incorporating constants "learned" by another evolution thread might be another benificial effect but my jury's still out on that one.. usually mixing different warriors results only in damaged code. However because RedMaker reproduces whatever it lands on, working or not, there is at least a chance of "fixing" the duds if they don't get killed first. A major problem when creating varients of different size is inserting or deleting instructions almost always messes up the algorithm.. it probably would help if references were adjusted accordingly but at the moment I'm not sure exactly how to approach the problem - except maybe keep it very simple - like increment all local references before the insertion point that point to a location after the insertion point, and decrement references after the i.p. that point to locations before the i.p. Reverse for instruction deletions. Perhaps. 3/29/01 - Implemented this for RM 2.85, seems to work.. at least it tends to preverve functionality after size change. Whether this is actually a good thing is unclear (also tends to make the different sized subspecies work similarly, less diversity of function) so in addition to on/off there is also a "sometimes" option.. sometimes it makes no ref changes, sometimes fixes forward refs, sometimes backwards and sometimes both.
3/30/01 - ok II.. perhaps using double fixed battles does make it more likely for papers to arise... at least after turning double-battles on in a 279k iteration soup that showed little replicating tendency, by ~290k many members were papering away. Here are a few from 294791... dumb but for the sake of documenting...
;RedMaker Warrior ;RedMaker Warrior ;RedMaker Warrior
;name NrIf ;name NrMf ;name NrMl
;assert 1 ;assert 1 ;assert 1
spl.x } 441 , * 716 slt.x } 441 , * 716 spl.x # 9 , < 648
spl.x # 8 , { 648 spl.x # 9 , < 648 spl.x # 342 , { 17
spl.x # 342 , { 6 spl.x # 342 , { 17 mov.i >-1 , < 291
mov.i >-1 , > 291 mov.i >-1 , < 291 mov.i { 2 , <-3
mov.i { 2 , <-4 mov.i { 2 , <-4 mov.i *-1 , < 1
mov.i *-1 , < 1 mov.i *-1 , < 1 jmp.i @ 11 , > 331
jmp.i @ 10 , > 331 jmp.i @ 11 , > 331 dat.f # 276 , >-7
spl.f >-7 , >-7 slt.i * 1 , # 671 mov.i #-5 , {-8
mul.i <-5 , # 8 dat.f # 276 , *-7 jmz.i @ 56 , { 8
jmp.a @-6 , { 4 spl.i <-5 , {-8 mov.x $ 670 , } 573
div.i @-5 , { 8 jmz.i @ 56 , {-9 mov.x < 345 , > 296
mov.i < 345 , > 296 mov.x $ 670 , } 573 div.a # 266 , > 6
mov.i { 1 , $ 63 mov.x < 345 , > 296 jmp.x *-1 , # 536
slt.a $-8 , @ 465 dat.i * 212 , { 227 div.f * 85 , $ 536
mov.a $ 371 , $ 465 div.ba #-13 , > 6 jmp.b * 641 , * 735
mov.a $-8 , $-15 mov.x #-15 , > 465 mov.i #-9 , $ 608
jmp.b * 641 , * 735 div.f * 85 , $ 536 slt.i > 203 , $ 167
mov.i # 449 , * 608 mov.i #-8 , $ 608 slt.i > 203 , $ 167
slt.i > 203 , $ 167 end end
end ;origin random start ;origin random start
;origin random start ;parent NrMg (462) ;parent NrNl (481)
;parent NrJe (481) ;generation 463 ;generation 482
;generation 482 ;iteration 294460 ;iteration 294080
;iteration 293387 ;battles 0 ;battles 2
;battles 3 ;score 0 ;score 181
;score 211
These score in the 70-85 range against the 3/27/01 tiny hill, 90-105 against Franz' warriors. Weak but maybe they'll evolve out of that convulted startup.
Trying a random start with double-fixed battles "on", fix local refs "on", max survival score 130, local number chance .6, everything else stock... by 8k iterations it's showing signs something might happen... a few almost-replicators.. might be onto something here.. so far the informal paper-score is double-fixed off = 1 (Uf), double-fixed on = 2 (Fa, Nr), maybe this soup will take off. I'm almost convinced now of the worth double-fixed battles, at least I tried several more times since Uf to get random battles to do anything interesting with no luck, and when it's on things got more interesting twice (then again.. I tried several random starts with it on and also nothing happened so not out of the noise yet). After 22k iterations there were a few almost-replicators but nothing to get excited about. Changing fix refs to "sometimes" for further evolution, the "sometimes" setting seems to be helping the Nr soup (maybe), lots of replicators.
April 2, 2001 - after about 413K iterations the Nr soup hasn't improved much. After about 177K the random start from above (double-fixed battles "on", fix refs "sometimes") wasn't doing anything interesting. Another random start using stock RM 2.85 parms (double-fixed "off"), run to iteration 89K, is up to a bench of about 90 against the evolved tiny hill but no true replicators have evolved. Starting a new random start, all parms the same except double-fixed "on". [didn't go anywhere interesting]
It's starting to come to me I think...
- parameters make it less or more likely to create/evolve stronger warriors
- stronger warriors do not arise unless a stronger form is created/evolved
accidently
- stronger warriors usually can survive regardless of parms (unless they
are way off)
- evolution accidents that create new forms generally are weak at first
and don't survive
Therefore, it might turn out that it is the luck of the draw when the initial start is created (which is affected by the instruction distribution and other redcode-creation variables) that mostly determines the outcome. The evolution parms like double-fixed, crossover, fixing refs, etc, affect what code is amplified, ensure the battles are fair, help to optimise the warriors and other useful things, but rarely can they take one warrior strategy and turn it into another. If the seed for a stronger form isn't layed down at the start, usually it just doesn't happen regardless of the parms.
April 6 2001 - I tentively conclude that adjusting the local refs does more harm than good when applied from the beginning. Points 2 and 4 above are a clue.. accidents happen more frequently when local refs are not adjusted, and in the beginning everything is weak so accidents that create new forms are much more likely to survive. When fixing refs from the start, evolution seems to find it easier to propagate the same boring forms because (I assume) size changes tend to not disturb loops thus mostly preserving the original strategy. Without changing refs the result is usually a dead warrior but further changes (assuming another functional warrior doesn't battle it and take it out) can result in a new functional form that might be better than the others. Once an interesting form has evolved, then preserving loops during modifications should be a useful optimization tool, able to delete unnecessary lines while preserving functionality.
This weak replicator appeared at iteration 13008...
;RedMaker Warrior
;name EeFb
;assert 1
jmn.i * 6 , $ 16
jmp.f @ 1 , @ 2
sub.x > 730 , > 10
seq.i > 6 , >-2
jmn.i < 238 , < 137
mod.i #-3 , > 604
mov.a } 1 , } 5
spl.i #-1 , # 655
slt.a } 10 , <-5
slt.a } 10 , @-5
mod.f @-1 , $ 9
spl.f #-5 , $-1
spl.i > 149 , { 496
mov.i <-3 , <-5
mov.i > 149 , { 496
spl.f > 448 , @-8
dat.ab <-15 , <-7
jmp.i } 0 , {-3
end
;origin random start
;parents EeEc (30) and EeDd (31)
;generation 31
;iteration 13008
;battles 0
;score 0
Only two instances exist at iteration ~13700.
April 7 2001 - didn't go anywhere... several other replicators came and went but none were strong enough to survive for very long. I think I had the survival score too high at 130, dropping to 110 on the existing population helped somewhat but probably too late for this soup. Starting over with altered parms.
April 12 2001 - this isn't working like I want it to, there seems to be a tendency for soups to become/stay uninteresting when ran for a long time without changing parameters. I get better results if I interact with the program while it is running, let it run with a set of parameter values for awhile and if the results bore me then change something. Sometimes half-killing the soup with bad parms is just what evolution needs to get a foothold on a better strategy. One thing that works is waiting and watching for something interesting to arise, then placing that warrior alone or with other interesting specimens in an empty soup and letting them multiply, thus multiplying what the experimenter finds interesting. Running a static set of parms for a long time without "stirring the soup" just isn't cutting it. I'd love to find a set of parms that always resulted in strong warriors but it just ain't that simple - changing environments play a major role in real evolution so I should not be surprised that non-changing parameters often result in boring warriors.