MEVO - a Multi-threaded Evolver =============================== MEVO is a program that evolves warriors for the game of Corewar. For more information about Corewar and evolvers see the following web sites: http://www.corewar.co.uk/ http://www.corewar.info/ http://www.koth.org/ This document assumes familiarity with Corewar parameters such as coresize, rounds, Redcode, etc, these things are explained on the linked pages. MEVO is a "pure" evolver in that it does not impart specific knowledge to the sequence of instructions, algorithms arise purely through the principles of mutation and natural selection. Some knowledge of corewar is specified by the parameters such as the odds of selecting certain instructions, modifiers and address modes more frequently than others to increase the chances of creating viable warrior strategies, but the parameters do not specify the order in which the instructions appear or what types of operators should be used with particular instructions. The goal of MEVO and other similar pure evolvers is to create a semi-accurate model of natural evolutionary processes. Absolute warrior strength is not a primary goal, other evolvers are available that also specify sequences to create stronger warriors but these programs are not as useful for studying genetic algorithms that can be applied to other scenarios besides creating Corewar programs. MEVO can create fully-competitive warriors for core size 80 (nano), capable of placing near the top of the SAL nano hill. Like most pure evolvers it is not as effective at creating warriors for core sizes 800 (tiny) and 8000 (standard), producing only beginner-level and "strange" warriors due to many factors but primarily because of the vastly increased search space. Human cleverness prevails for larger core sizes. Hardware impact of file-based evolving -------------------------------------- Evolving requires lots of computations, it might take well over a million individual coreware battles and mutations over the course of several days to produce a relatively strong warrior. Most evolvers use close to 100% of the available CPU cycles, which can be a problem for systems that have more processing power than cooling ability. MEVO has a threadsleep option that can be used to lessen CPU usage. Some evolvers use an embedded simulator and produce no disk activity at all, but MEVO isn't one of them. Rather (like most simple evolvers) MEVO uses the standard pmars program to perform corewar battles. Some evolvers use individual files for each soup warrior, resulting in quite a bit of disk activity as file are written to scattered locations with little opportunity for caching the writes. MEVO and other recent evolvers stores the warriors in a memory array and writing the warriors doing battle to fixed filenames while collecting the scores in another fixed filename (a different set of filenames is used for each additional thread), while this increases the total number of bytes written, the files tend to be close to one another on the disk, and usually get overwritten before the disk cache has a chance to flush the file to disk so the end result on most operating systems is much less disk activity, usually a flicker of the drive light every few seconds. Nevertheless, I recommend using a ram disk to eliminate all disk activity when running file-based evolvers such as MEVO for long periods of time. Never run MEVO (or any other app that does frequent disk writes) on a limited-write solid-state disk such as a thumbdrive or directly from the disk of some notebook computers. The total number of writes such a disk can sustain is approximately (free space / block size) * endurance rating, divide by writes per second to obtain approximate lifetime in seconds. Assuming a rate of about 1.33 writes per second, for an inexpensive MLC-type disk with a block size of 128K, an endurance rating of 3000 writes per block, and 500 megabytes free, this works out to about 100 days before failed blocks start to appear. Possibly much less depending on the OS, some systems write access time info every time a file is read. The situation is much different for a server-grade SSD, according to the rough estimate a disk rated for 1 million writes per block with 5 gigabytes free should last 900 years. The packaging would have long turned to dust by then. About MEVO ---------- MEVO is mostly a rewrite of the RedMixer evolver. RedMixer worked well but was written in the QBasic language which has a few drawbacks, mainly lack of memory forcing warriors to be stored as files, and lack of structured error handling forcing the use of ON ERROR GOTO spaghetti code to detect missing files. Although cross-compatibility was possible by compiling with FreeBasic, the -lang qb language subset didn't allow using open pipe under Linux, triggering a compiler bug and requiring a custom library to compile to a binary besides not being able to eliminate an extra file write under Linux. MEVO is written in the native FreeBasic language and avoids these issues. Another reason for making MEVO was to better use multi-threaded and multi-core machines by optionally launching several pmars battles at once, which hopefully the OS will assign to different cores. On a single-core hyper-threaded CPU I see an increase in speed by about 15% by using 4 threads rather than a single thread. Performance on true multi-core machines remains to be seen, likely memory bandwidth and OS functions will prevent linear scaling (but every bit helps). Yet another reason for making MEVO was the RedMixer platform had pretty much played itself out, I needed a new platform that was easier to modify for new experiments. Initially I left out some of RedMixer's features such as soup wrap, crossover starting warrior odds and starting location evolution but I eventually added these to MEVO. The main evolving feature RedMixer has that isn't in MEVO is separate mutation rates for the A and B fields, typically I would set these to the same numbers anyway. MEVO has a few things that are not in RedMixer, including the swap-lines mutation and re-insertion of randomly selected saved warriors back into the soup. Evolving Method --------------- MEVO uses a simple algorithm, which is essentially... Start with a population of warriors (the "soup", random or otherwise) DO Randomly pick two nearby warriors Battle them in a MARS program and collect the scores Replace the losing warrior with a mutated copy of the winning warrior LOOP UNTIL the evolver is stopped. The key concepts are "nearby" and "mutated". MEVO uses a 2-dimensional grid of warriors and battles only adjacent warrior pairs, thus it takes a certain amount of time before distant warriors encounter each other, and a warrior can still win a battle against a weaker warrior even if stronger warriors are in the immediate vicinity. This is an important concept that parallels biological evolution since it permits weaker species to survive and evolve into stronger species rather than immediately eliminating them. Absolute evaluation makes it difficult to evolve more sophisticated algorithms such as "paper" replicators, which almost always start out weak them strengthen with successive mutations. Simpler "stone" algorithms tend to arise first and would consume any baby papers if not for a mechanism that permits weaker members to survive long enough to mutate to other warriors. Think rabbits and wolves... if every rabbit had to battle a wolf then there'd be no rabbits (but wolves are less fun to play with). The process of battling adjacent warriors provides selection, stronger warriors defeat and replace weaker warriors. In the event of a tie MEVO considers the 2nd warrior (the opponent) the winner since in Corewar the 1st warrior gets the first code cycle so should have the advantage. In practice it doesn't make much difference which warrior is declared the winner for tie battles. There are other more sophisticated ways to determine the "best" warrior but I chose the most obvious method. Some evolvers benchmark the warriors to determine absolute strength which quickly improves the scores but also tends to create warriors that are weak against warriors that are not in the benchmark set. Performing battles only against other soup warriors tends to result in warriors that can do better against new warriors that have not been encountered. The last step is mutation, or making random changes that can improve or weaken a warrior. Successful evolution requires a medium where individual changes can change the level of performance rather than always result in a dead member, it is here that the Redcode language and the nature of Corewar makes it ideal for performing evolving experiments. The redcode '94 draft specifies no illegal combinations of instructions, instruction modifiers, address modes and numerical values, so all elements of code can be changed with no regard to syntax beyond using the correct set of elements. The trick for successful simulation of evolution is to select mutation rates that are low enough to avoid damaging the subjects, but frequently enough to cause mutated members to appear with better skills. MEVO applies the mutation rates to every element type equally, some warriors might have no change at all but sometimes multiple changes can be applied at once. Permitting multiple changes at once increases the odds that a stronger warrior can be created in a mutated copy, for example inserting a line and incrementing a number at the same time so that the processing loop remains functional. Several kinds of mutations are supported by MEVO: Select a new instruction Select a new instruction modifier Select a new addressing mode (twice for both the A and B fields) Select a new value (twice for both the A and B fields) Insert a new line of code Delete a line of code Swap two adjacent lines of code Select a new starting location Line inserts can be random code or a duplicate of the previous line. Value changes can be an increment or decrement of the existing value or a new random number, random values can be randomly selected to be plus or minus the size of the warrior for control structures, or plus or minus coresize/2 to cover the entire core using a flat distribution within each category. Starting location changes can be an increment or decrement, the first warrior instruction (the most common case) or a random number between 1 and warriorsize-1. MEVO supports crossover, or combining two warriors into one mutated copy. Just as in nature mixing different species doesn't work very well, so crossover is (usually) restricted to warriors that are of the same code size and species. In MEVO a new species number is assigned to the mutated warrior if more than a certain percent of the instructions are changed, in addition to helping create a more interesting display, this permits choosing related warriors for crossover and improve the chances of creating a new warrior that inherits characteristics of both warriors (maybe, redcode crossover is a tricky thing that in my experience only marginally improves performance). Creatures in nature also tend to choose the most attractive mate around them, so of the available candidates MEVO (usually) selects the warrior that won the most battles (randomly choosing from ties). An odds setting determines whether the winner or the mate goes first, other odds settings determine the chances of changing the source warrior for each line of the copy/mutation, and to control how selective it is when choosing a mate. When these things are applied over and over to a population of warriors it tends to result in an overall increase in the strength of the population as a whole as well as occasionally creating stronger-than-average individuals. However the strength doesn't increase indefinitely, different sets of evolving parameters each have a maximum strength level that can be supported, above which the forces of destruction inhibit further improvement. Finding the optimum settings is difficult as every run is different and it usually takes days for a soup of warriors to improve as much as it is going to. Often a dominant strategy arises that inhibits the production of new strategies, causing the scores to level out before reaching the maximum strength that could be obtained so typically several runs are needed to evaluate the effectiveness of a given set of parameters. Compiling and setting up MEVO ----------------------------- MEVO is written in the native FreeBasic language (http://www.freebasic.net) and can be compiled for Windows and x86 Linux systems. Pre-compiled packages that include benchmark sets, INI files and all needed binaries are at: http://newton.freehostia.com/cw/mevo.html The remainder of this section describes manual compilation and setup. MEVO requires pmars for performing the battles, and pmarsv for visually running and battling warriors using the soup explorer interface. These are the official programs used to simulate corewar battles. For Windows the SDL versions work well, these are named pmars-server.exe and pmarsw.exe (which requires sdl.dll), either rename to pmars.exe and pmarsv.exe, or edit the mevo.ini file to specify the correct names. Both filenames must contain the string "mars" (to protect against editing mistakes). MEVO can also use the exmars program, set maxlen to 0 if using the stock 0.01 version. For Linux the pmars source code can be compiled to produce pmars and pmarsv binaries (according to settings in the makefile), the binaries I use are at: http://newton.freehostia.com/cw/pmars092N.tar.gz The MEVO source code must be configured for the OS. For Linux the beginning lines after the initial comments should read... rem --- OS/display setup --- dim shared usewin as integer = 0 '0 for linux 1 for windows dim shared useuni as integer = 1 '0 for ascii 1 for unicode (UTF-8) For Windows edit to set usewin and clear useuni... rem --- OS/display setup --- dim shared usewin as integer = 1 '0 for linux 1 for windows dim shared useuni as integer = 0 '0 for ascii 1 for unicode (UTF-8) (the useuni setting can be overridden using an INI setting, but Windows does not support unicode in a console, if desired the assignments under "rem --- set up soup box characters" can be modified to use custom characters for drawing the box surrounding the soup) For Linux, compile MEVO using the command line: fbc -mt mevo.bas For Windows, compile using the command line: "c:\program files\freebasic\fbc" -mt mevo.bas (assuming FreeBasic is installed to the default location, modify accordingly) If bounds checking and debugging info is needed add the -exx option after -mt. The Linux version of MEVO must be run from within a terminal so that the output can be seen (if no terminal is detected it exits), for convenience a shell script should be used to set up a path for the binaries and launch mevo in a terminal, preferably with a black background: ----------- begin run_mevo.sh ----------------------------- #!/bin/bash cd `dirname $0` # change to program directory PATH=".:bin:$PATH" # add current and bin directory to the path # try running in the xterm terminal (permits setting size color etc) xterm -geometry 80x24 -bg black -fg green -e mevo # if that doesn't work try other terminals (using defaults) if [ "$?" -ne 0 ];then konsole -e mevo || terminal -e mevo || rxvt -e mevo || gnome-terminal -e mevo fi ----------- end run_mevo.sh ------------------------------- This script tries several common terminals, however only xterm permits setting terminal size and colors from the command line (that I know of). The script sets the path so the binaries can be put in the current directory or in a directory named "bin" under the current directory. Edit as needed. If copy/pasting convert to "unix" line-end format and make executable. Note that the initial change-directory only works if MEVO is placed in a directory tree that does not contain spaces. There are ways to support spaces using quotes etc but it doesn't work on some systems and it's a bad idea in general, under Linux use _ or - to separate words. For Windows the mevo.exe file can be run directly provided the binaries are in the current directory or in a path directory, however under newer versions of Windows cmd.exe slows down binary launch speed. Nano evolving speed can be improved by about 3X by using a utility that directly executes the binary without loading cmd.exe, I wrote one called binrun which is at: http://newton.freehostia.com/cw/binrun.zip Using binrun requires setting the comspec variable to binrun.exe using a batch file so it will be loaded rather than cmd.exe, the same batch can also set a path for the binaries: ----------- begin "run_mevo.bat" -------------------------- @echo off if .%binpathset%==. path bin;%path% set binpathset=yes set comspec=bin\binrun.exe start "MEVO" Mevo.exe ----------- end "run_mevo.bat" ---------------------------- This batch gives the MEVO window a name so that the console's size and other settings can be adjusted separately without affecting other windows. The batch assumes that binrun.exe and other binaries are placed in a directory named "bin" under the main program directory. Edit as needed. Alternatively the console size can be specified directly... ----------- begin "run_mevo2.bat" ------------------------- @echo off mode con lines=25 if .%binpathset%==. path bin;%path% set binpathset=yes set comspec=bin\binrun.exe Mevo.exe ----------- end "run_mevo2.bat" --------------------------- Lines can typically be set to 25, 43 or 50 lines. MEVO's default soup size of 21x77 warriors works with 24 or 25 line consoles, for larger soups the console size has to be increased to at least 3 more in the X and Y directions. Also adjust the first number in the displayopts setting so that the file lister will know how many lines to display. Typically the MEVO directory structure is set up something like... main directory `---- bin directory | `--- mevo[.exe] | `--- pmars[.exe] | `--- pmarsv[.exe] | `--- [binrun.exe] `---- nanobm07 directory | `--- benchmark warriors (*.red files) `---- other benchmark directories `---- run_mevo[.sh or .bat] `---- mevo.ini When run MEVO creates a temp directory for temp files and if automatic benchmarking is enabled, creates a save directory for saving warriors to. If logging is enabled a mevo.log file is created to record start and stop times and benchmark results. On exit MEVO creates a soup directory and writes all soup warriors to it, and writes a soup.dat file containing a numerical representation of the soup for restarting a run. Using MEVO ---------- To start a new run, edit mevo.ini with the desired parameters and remove soup.dat and the save directory if they exist. See the next section for sample mevo.ini files and explanations of the settings. After starting MEVO it should display a random soup in a box with a menu below that. Here is an initial random starting soup (using tiny settings)... .-----------------------------------------------------------------------------. |EBIKBJ16AHKHJB1D7DA322D42IJEDBID584CC39I37G25692BA7G4KJ22KEBID197KA8I76AA7FCB| |JI3J62HKB47GJF44H9BHEI233CKBEFE33G3IF468IB9HGJ63JFC2GD55682D47329B73B46FB5CJB| |EFH2562B62322F79JC59I4HBIDI7423716KG61FJ8FG8A4A162HGK2A2AG271JC3124FEAJA14K4A| |81399A6AF4H4EAC1G678GH1CH411F4FE4CBB7622B6FAB5J7G91D6F4I9EDJ6585F4EBE6KJD8D2F| |CG67KCF7D95292HCBEJJGABK49HCB8HG6FGDE4A6C6E2H4ACD52K822EB9HHA28BE798IE3K7KF2G| |5CKJ5K2CGBA71KB9D9A14E242E6CCIA1CBKJ3C3E7G8IID34A24H9EIC8K25JE7AFDKE77FCF1IFK| |B4A2FE7G45BIE8H3KDD8D8CH5G1I5IB2JHH36EBAA2275J63IAH2K698J4C19DJ92135B6FJB3BF6| |C5F11F7FKK85KJGEGFAJII31DAKHGGIFG73BI247G14D7H81ACIA473755FF7K75IJ6BE8K4AJ49B| |A7H485B5JKIF3FD93AI7G3KDEH91K4C27B5EA1351CCKG376KI88DAKEIJE5F33KCD6D922DDB264| |9J1JIC45A3JE2B4CG2J41AD4EF6BJ25E8AAGFGBG4127CE3IECHG99DBG621A6I23CB9C3EBG15C3| |K2GG1E78IAGJK3K356I4FDDI53F48F97A7DF38D1A2HF83DK383CCJ75JI9EDGI834GF36586JJ3E| |JEIFD76C919CAKGHI9J2D6791F2IAA8D72F5HIF8IB37F27EC4GJIG9373KH12G34AGEJ3F51I57F| |ID68H9DHCE1B3616CDII92BDEBK127EH79HBD438CEE32E1GHFDD392JJB1BC1117H9J36DF3HBA9| |J2921478CHJ8FEG4B1A2DA98HA8JJ1A34KC54EJCB3CJ7ECDB5197IAFJJ1J6KJ48E535KK6BFDJC| |1GHH3FD81287724FH3HB1J4I19F8I4587KH765J86J6HE123I1D2CD6DC8I75AH71KC6C715EJE96| |518GD9CEDF1K9AEH868C5G37EJEHD5242J6253E8G9KJ243FFEDEICHIKI2148JBHH75EEIAH824F| |HEBE7EH85IBI19EI59E4793594KEIFDFFJ76AK8JB12FGE1B4IK4ADJ4IC5A223F5827387C85539| |3813KCFD66GAFEE9387E3FG83969F47J6A89E6C5AFEH4I49CEHB6B535C6BACD57GFKK99HA9DC4| |IGEBF993EBAI1H31K87KB59E24G1DCBI4B5KICF5J9GFF1C6EC7CE257ABIJK71E5C74J4J4883C4| |C2AB8A1B9BCB1H939B16K39J4HJ3699H53HIAGJ2E69KF6KA967CC314I127K4J349I54F4F8A7C8| |9511D9BI5FA4EF8FBHA88J6C67214AHDC7HKA4E351H787821A1928KKF1IH2EKKAG2HJF686E54C| `-----------------------------------------------------------------------------' E) Evolve L) List R) Run 1-9) Battle T) Test Q) Quit The numbers and letters represent the number of code lines in each warrior (A=10 B=11 etc), the warriors are colored (using 14 colors) to represent individual species of warriors, initially random. As warriors mutate to new warriors they are assigned a new species number if more than a certain percentage of instructions are changed, which usually results in a different color but not always. The warrior sizes help to further discriminate between different warrior species. From the menu the following options are available... E) Evolve - starts evolution L) List - lists the currently selected warrior to the screen R) Run - runs the currently selected warrior in pmarsv 1-9) Battle - using the numlock key, battles the selected warriors in pmarsv T) Test - tests the currently selected warrior to determine strength Q) Quit - saves the soup and quits the program Note - don't use the corner "X" to exit unless you want to abandon the soup, delete the temp directory to restore operation. While evolving soup warriors are battled and mutated according to the evolving algorithm and settings. If auto-benchmarking is enabled then messages are printed when a warrior is saved or a new top-scoring warrior is found, or if a reinsertion operation is performed. The warriors should group into "islands" of similar sizes and species... .-----------------------------------------------------------------------------. |HGHHIH9AJJAACDBBBBADEDD999D99FFGFFFEHGGGGGGGGGFG2HHH22IHGJKHHIGIGJGGJHGGGEEDD| |FHHJHIHA888ABBEBBACDCD999BDDCFHHFFGEGEGGFGGHGFFHFJEH2FJGGGKHJHJIGGGFHHHGGEFDF| |FEEHEHJ9AH989BBDBBBCDBDDCCCHHDHBFEFGGEGFIIHHGHHFIIGFGJ2KGGHJJJJJJGGGHHHFGEFFF| |EIFGKJHAHI998CBBBBCBCADD9CCDIIDBGFDEFFEEEEGGGGHGHIIJ2HJIFGGJ5EJ6JKIIJHKKJDEEF| |GGGHKD9999998CBBBCBBBBB9DDCDDGDDDGEGEEEEEEEEFFGGGGGGJHIIGGG5G55JKKJHIIJDDEEEG| |GHHCKAAAA999A9BBBCDBBDCCBECDDGGCEDFGGHDFDFGFFHGGGIGKJJIGGGHGHGIKJHGJGGGGGGDGG| |GICBBBABAAAA98JABDABACBCCCCDDDDEDFGGHGDDFGGGFGGFKKIIHHGGGGIHHIIHIGGGGGGGGFGFG| |HCI9ABBABAAAAAABAAAAAACCCCDDCGGFEFGEGFFEFGDDFFFFKKKHHGGGGIHHIIIGIGGIGGGGGHGHG| |GI9ACBIAAAAABCECA888AAECCCBCCDDFFFCDFFDFFGD9HFFHHGHDGJFGGGGIIIHGGGGEFHGGGGFFH| |FGG7BBIJAI99BECCCB8DDCDDCEEDDDDEFFCDFCFFGDDFFFFBFGBBGGGGGGIHIIG5GFFEFHGHFFFFF| |FGHDDBBHIIIIBDEDBBDDDEEEDEDADFEFEFDDDGGGG9D9FGBABBBBDGGGGHHHHEF5GFGFFGGFGFGFF| |GGCED8HHHI9CIEDDCCDCFEEEDCDBDEDEFBBBDGG99DDC9AHBABBGGGHGGF5555FFFFFGFGGFFGFIF| |GGEDDHEHGIH98DDCDBCCBFDEFEECDEEFFFEEBD999EGA9AB8BAAADGGHGFG555FFEFFFJFDEFGFHH| |GEFEHEEGGIIHDDCDECBDBEEFFFDCDDECDFEAE999EDD9ABBA9AAACDGFGGGFFEFFEGFEFFFFFGGGF| |EFEEDEEEIIC9DEDDCEFBBCCEGFECBCCCFCBEEEB89DDDABACBAAACCJFEFEGFFGGFFFFFFGFHFFFE| |FFEEFEEFECCC8DDFEDEECCCEGFFFCCCCCBEBBEECCBBBABA99AAAIIIJEFFFFFFFGFFFDFFFFFFEE| |FEEEEEEDEECCCDDGCDEDCCEEEFFFCACCCBAB99CCCBBBCA99ABAAIIIIJEFGFFFFFFFFHHECCEDEF| |FEEEEFGEDFCFDCCDCDDCCCCEEEFCCCCCBBBBC99CCCCBAA9BBBBBG3FGFGEGGFFFFFFEHHECCCCBC| |GEEEEFEEEFFDDDDDCECDECCEEECCCCCCCBBC9ACCCCDDEDDBABBB3FFFFFIGGFFFFHFEHHGGCCEBB| |HEGFFGGEEEDEDDDDDCCCCCCCCEECDCCCCBBB99CCBBBDEEDDDAB3BBFFFGHFGGFDGGFEBFGCDHDEE| |DEEEFEFEDDEDDEDCDCCBCCCCEEFCCDCCBCBCCCCCBDDDCEEDD33C3BFIFIHHJIDDCFFEHFFEFFHEH| `-----------------------------------------------------------------------------' Saved 7 score=90.55 Top 7 score=90.55 Last RI 21 15 Press Esc to stop evolution and return to the menu. When quitting, the soup is written to the soup.dat file, and all of the soup warriors are saved to the soup directory. The soup warriors are saved for convenience and to permit running external benchmark programs (especially if not using auto-benchmarking). If the mevo.ini file, the soup.dat file and the save directory remain intact, then re-running the program restarts a run from where it was stopped. Use the cursor keys to select the warrior for the other options. When listing warriors or displaying test results, use the cursor up/down keys to scroll and Esc to exit. A run may take days to reach peak score, but if dead-end evolution is noticed (for nano, the soup completely filling with a weak form, or if a soup of papers all turn to stone) it may be desirable to terminate a run. To start over, remove the soup.dat file and save directory. If the soup size was changed also remove the soup directory. To archive a run for later study or restarting, save the mevo.ini file, the soup.dat file, the save directory and optionally the top.red file and soup warriors (the soup warriors can be recreated by running MEVO with the mevo.ini file and soup.dat file then quitting). Alternatively just save or zip up the entire work directory, which is more convenient when restarting (the master setup can be simply copied to a new directory) but requires more disk space. The mevo.ini file ----------------- The following settings have had some run time but are far from being optimized. Consider them to be only starting points and subject to change. Here is an example INI file for evolving standard warriors... ----------- begin mevo.ini (for coresize 8000) ------------ ;ini file for mevo xsize: 77 ;width of soup ysize: 21 ;height of soup xwrap: no ;if yes enable side-side wraparound ywrap: no ;if yes enable top-bottom wraparound maxsize: 20 ;max evolved length ;pmars parameters... coresize: 8000 ;size of core array processes:8000 ;max processes cycles: 80000 ;cycles before tie maxlen: 100 ;maximum warrior length mindist: 100 ;minimum separation rounds: 40 ;# of battle rounds pmarsbin: exmars ;path/name of pmars binary pmarsvbin: pmarsv ;path/name of pmarsv binary pmarsvopt: -v 014 ;pmarsv view options etc ;mutation parameters... instrate: 0.015 ;chance of instruction change modrate: 0.03 ;chance of modifier change moderate: 0.03 ;chance of address mode change datarate: 0.06 ;chance of field value change insrate: 0.01 ;chance of line insert delrate: 0.01 ;chance of line delete swaprate: 0.01 ;chance of line swap endrate: 0.05 ;chance of changing end number dupline: 0.1 ;if insert, chance of dup line incdec: 0.3 ;if data, chance of inc or dec bignum: 0.5 ;if data, chance of big number endincdec: 0.5 ;if end, chance of inc or dec end0chance: 0.3 ;chance of end 0 ;crossover parameters... enablecross: no ;if yes then cross with surrounding warrior flipstart: 0.5 ;chance of starting with winning warrior flipmaterate: 0.3 ;chance of changing to mate flipbackrate: 0.3 ;chance of flipping back anychance: 0 ;chance of crossing with dissimilar warrior bestchance: 1 ;chance of crossing with warrior with most wins ;code generation... instructions: nop mov mov mov mov mov spl spl spl spl djn djn instructions: add sub mul div mod jmp jmz jmn sne seq slt dat modifiers: .i .i .i .a .b .f .x .ab.ba modes: $$#@*<>{} ;bench parameters... enablebench: yes ;yes to enable these settings benchrounds: 100 ;rounds used for benchmarking savethresh: 92 ;percent of top score to save reinsertmode: 2 ;0=none 1=top.red 2=from save benchinterval: 1000 ;bench every n iterations (0=none) reinsertinterval: 5000 ;re-insert every n iterations (0=none) benchdir: wilkies ;directory containing benchmark warriors savedir: save ;directory to save warriors to testdir: ;directory for single-test warriors (def.benchdir) ;other parameters... initmode: 1 ;start warriors 0=first inst, 1=random spthresh: 5 ;percent change before different color infoline: evolved ;added to strategy line threads: 1 ;# of processing threads threadsleep: 0 ;# ms to sleep between threads enablelog: no ;yes to log to mevo.log file displayopts: 24,10,11,0 ;term height,text col,frame col,unicode ;end of ini file ----------- end mevo.ini ---------------------------------- Here is an example INI file for evolving tiny warriors... ----------- begin mevo.ini (for coresize 800) ------------- ;ini file for mevo xsize: 77 ;width of soup ysize: 21 ;height of soup xwrap: no ;if yes enable side-side wraparound ywrap: no ;if yes enable top-bottom wraparound maxsize: 20 ;max evolved length ;pmars parameters... coresize: 800 ;size of core array processes:800 ;max processes cycles: 8000 ;cycles before tie maxlen: 20 ;maximum warrior length mindist: 20 ;minimum separation rounds: 40 ;# of battle rounds pmarsbin: pmars ;path/name of pmars binary pmarsvbin: pmarsv ;path/name of pmarsv binary pmarsvopt: -v 344 ;pmarsv view options etc ;mutation parameters... instrate: 0.015 ;chance of instruction change modrate: 0.02 ;chance of modifier change moderate: 0.03 ;chance of address mode change datarate: 0.07 ;chance of field value change insrate: 0.007 ;chance of line insert delrate: 0.01 ;chance of line delete swaprate: 0 ;chance of line swap endrate: 0.05 ;chance of changing end number dupline: 0.1 ;if insert, chance of dup line incdec: 0.5 ;if data, chance of inc or dec bignum: 0.6 ;if data, chance of big number endincdec: 0.5 ;if end, chance of inc or dec end0chance: 0.3 ;chance of end 0 ;crossover parameters... enablecross: yes ;if yes then cross with surrounding warrior flipstart: 0.5 ;chance of starting with winning warrior flipmaterate: 0.3 ;chance of changing to mate flipbackrate: 0.3 ;chance of flipping back anychance: 0 ;chance of crossing with dissimilar warrior bestchance: 1 ;chance of crossing with warrior with most wins ;code generation... instructions: spl spl spl spl spl mov mov mov instructions: mov dat dat dat jmp jmn jmz djn instructions: sne seq slt add sub mul div mod modifiers: .i .i .i .a .b .f .x .ab.ba modes: $$#@*<>{} ;bench parameters... enablebench: yes ;yes to enable auto-bench/re-ins benchrounds: 200 ;rounds used for benchmarking savethresh: 93 ;percent of top score to save reinsertmode: 2 ;0=none 1=top.red 2=from save benchinterval: 1000 ;bench every n iterations (0=none) reinsertinterval: 10000 ;re-insert every n iterations (0=none) benchdir: franz ;directory containing benchmark warriors savedir: save ;directory to save warriors to testdir: ;directory for single-test warriors (def.benchdir) ;other parameters... initmode: 1 ;start warriors 0=first inst, 1=random spthresh: 5 ;percent change before different color infoline: evolved ;added to strategy line threads: 1 ;# of processing threads threadsleep: 0 ;# ms to sleep between threads enablelog: no ;yes to log to mevo.log file displayopts: 24,10,11,0 ;term height,text col,frame col,unicode ;end of ini file ----------- end mevo.ini ---------------------------------- Here is an example INI file for evolving nano warriors... ----------- begin mevo.ini (for coresize 80) -------------- ;ini file for mevo xsize: 77 ;width of soup ysize: 21 ;height of soup xwrap: yes ;if yes enable side-side wraparound ywrap: no ;if yes enable top-bottom wraparound maxsize: 5 ;max evolved length ;pmars parameters... coresize: 80 ;size of core array processes:80 ;max processes cycles: 800 ;cycles before tie maxlen: 5 ;maximum warrior length mindist: 5 ;minimum separation rounds: 250 ;# of battle rounds pmarsbin: pmars ;path/name of pmars binary pmarsvbin: pmarsv ;path/name of pmarsv binary pmarsvopt: -v 564 ;pmarsv view options etc ;mutation parameters... instrate: 0.02 ;chance of instruction change modrate: 0.03 ;chance of modifier change moderate: 0.03 ;chance of address mode change datarate: 0.06 ;chance of field value change insrate: 0.01 ;chance of line insert delrate: 0.01 ;chance of line delete swaprate: 0.02 ;chance of line swap endrate: 0.1 ;chance of changing end number dupline: 0 ;if insert, chance of dup line incdec: 0.3 ;if data, chance of inc or dec bignum: 0.5 ;if data, chance of big number endincdec: 0.5 ;if end, chance of inc or dec end0chance: 0.3 ;chance of end 0 ;crossover parameters... enablecross: yes ;if yes then cross with surrounding warrior flipstart: 0.8 ;chance of starting with winning warrior flipmaterate: 0.3 ;chance of changing to mate flipbackrate: 0.3 ;chance of flipping back anychance: 0 ;chance of crossing with dissimilar warrior bestchance: 1 ;chance of crossing with warrior with most wins ;code generation... instructions: mov mov mov mov mov spl spl spl djn djn instructions: add sne seq slt jmn jmz mod modifiers: .i .i .i .a .b .f .x .ab.ba modes: $$#@*<>{} ;bench parameters... enablebench: yes ;yes to enable auto-bench/re-ins benchrounds: 142 ;rounds used for benchmarking savethresh: 95 ;percent of top score to save reinsertmode: 2 ;0=none 1=top.red 2=from save benchinterval: 500 ;bench every n iterations (0=none) reinsertinterval: 5000 ;re-insert every n iterations (0=none) benchdir: nanobm07 ;directory containing benchmark warriors savedir: save ;directory to save warriors to testdir: nanob2 ;directory for single-test warriors (def.benchdir) ;other parameters... initmode: 1 ;start warriors 0=first inst, 1=random spthresh: 5 ;percent change before different color infoline: evolved ;added to strategy line threads: 1 ;# of processing threads threadsleep: 0 ;# ms to sleep between threads enablelog: no ;yes to log to mevo.log file displayopts: 24,10,11,0 ;term height,text col,frame col,unicode ;end of ini file ----------- end mevo.ini ---------------------------------- If MEVO is run with no mevo.ini file present it creates an INI file for coresize 800 containing guesses I made while writing the program. The following is a detailed explanation of the INI settings. ;ini file for mevo xsize: 77 ;width of soup ysize: 21 ;height of soup These settings specify the size of the soup, the terminal window used to run MEVO should be at least 3 positions larger in both the X and Y directions. Maximum supported size is 130 by 100 (13,000 warriors), modify the code to change the limits but a soup of this size is probably not practical except on a very powerful PC with enough display area to display such a large soup. For the Linux xterm program the -geometry option can be used to specify the terminal size, i.e. if using a soup size of say 100 by 50 add -geometry 100x50 to the xterm command line in the run_mevo.sh file. For Windows there's probably a clicky thing to set size properties. Note... the file listing subroutine assumes a minimum terminal height of 24 lines so don't use with a terminal with fewer lines unless the displayopts setting is adjusted. If ysize is more than 21 then the terminal is assumed to have a height of at least ysize+3 lines. xwrap: yes ;if yes enable side-side wraparound ywrap: no ;if yes enable top-bottom wraparound These enable wrap-around so that warriors on an edge of the soup can spread to the opposite side. This might have a subtle effect, the original RedMixer program used side-side wrap (simulating a cylinder) which prevents warrior strategies from being trapped on one side of the soup. maxsize: 5 ;max evolved length This setting determines the maximum length of evolved warriors. For larger sizes the initial warriors are created with 1 to maxsize instructions. If maxsize is 5 or less then all warriors are initially maxsize long. ;pmars parameters... coresize: 80 ;size of core array processes:80 ;max processes cycles: 800 ;cycles before tie maxlen: 5 ;maximum warrior length mindist: 5 ;minimum separation These parameters specify the MARS environment. If using pmars the maxlen setting must be the same or greater than the maxsize setting. If using the stock exmars simulator then set maxlen to 0 to inhibit using the -l parm. rounds: 250 ;# of battle rounds This setting determines how many individual rounds are performed for each battle. Higher number of rounds produces more accurate scoring and potentially higher maximum soup strength, but requires more processing time and in larger coresizes, tends to inhibit the production of paper-type warriors. pmarsbin: pmars ;path/name of pmars binary pmarsvbin: pmarsv ;path/name of pmarsv binary These set the binary names, they must contain the string "mars". If the binaries are not in the current directory or in a path directory then include the full path to the binary (i.e. c:\myprogs\pmars-server.exe or for Linux something like ~/pmars if placed in the user home directory). pmarsvopt: -v 564 ;pmarsv view options etc These are options passed to pmarsv when running or battling warriors. The -v specifies view parm with a 3-digit number afterwards to specify speed (0=fastest, 9=slowest), graphics display (experiment) and detail level (typically 4 for all). Older versions of pmarsv might not be slow enough when running nano warriors, add [space]-r 10 to run 10 rounds instead (also may be handy when using the battle function). ;mutation parameters... instrate: 0.02 ;chance of instruction change modrate: 0.03 ;chance of modifier change moderate: 0.03 ;chance of address mode change datarate: 0.06 ;chance of field value change These determine the chances of performing different mutations, ranging from 0 (never) to 1 (always, not a reasonable setting). The odds are applied evenly to all items (or lines). Typically mutation rates are selected to be low enough so that sometimes to often nothing at all changes, but high enough to possibly change multiple things at once. Data (number) changes tend to be most useful for adjusting existing forms without breaking the code so this rate is usually set to be the highest, instruction changes often result in broken code but are necessary to create new forms, so instrate is usually set fairly low. The modrate and moderate settings usually fall somewhere in between instrate and datarate. insrate: 0.01 ;chance of line insert delrate: 0.01 ;chance of line delete swaprate: 0.02 ;chance of line swap These settings perform major mutations by rearranging code, or in the case of insrate, possibly creating new code. Lines are removed only if the current warrior size is more than 1. Inserted lines move other code lines forward, truncating lines if the warrior exceeds maxsize. Swaprate is used only if on the 2nd or greater line, and swaps the line with the previous line. endrate: 0.05 ;chance of changing end number This setting determines the odds of (attempting) to change the end number that determines the instruction offset that the warrior starts running at. End 0 is written as simply "end" to start at the beginning (the most common case), end 1 starts at 2nd instruction, etc. dupline: 0 ;if insert, chance of dup line This setting determines the odds of an inserted line being a duplicate of the previous line (assuming code line 2 or greater), otherwise a random line of code is inserted. incdec: 0.3 ;if data, chance of inc or dec If a data change is triggered, this setting determines the odds of performing an increment or decrement of the existing number rather than choosing a new random number. This can be helpful for finding loop points again after an insert or delete, but it is also a somewhat dubious setting - in past experiments good results were obtained even if set to 0 for no adjustments. bignum: 0.5 ;if data, chance of big number If a data change is triggered and a random number is selected, then this setting determines the odds of choosing a large number that spans the entire core rather than a small number that (approximately) spans the size of the warrior. endincdec: 0.5 ;if end, chance of inc or dec end0chance: 0.3 ;chance of end 0 If a end number change is triggered, endincdec determines the odds of incrementing or decrementing the existing number, if that doesn't happen then end0chance determines the chance of a simple end to start at first location, otherwise a random end number from 1 to warsize-1 is selected. ;crossover parameters... enablecross: yes ;if yes then cross with surrounding warrior If no then only mutation is performed. If yes, looks for a surrounding warrior that's the same size and species (usually, see anychance), and with the most wins. If there are multiple candidates with the same number of wins it randomly chooses one. The warrior that just lost the battle is excluded from consideration. If a mate is not found then uses just mutation. If a mate is found then the first instruction(s) will randomly come from the winning warrior or the mate. As the copy/mutation proceeds a "flip" flag determines if lines are copied from the winning warrior or the crossover mate, the flip settings determine how often the flip flag is changed. flipstart: 0.8 ;chance of starting with winning warrior This sets the odds of starting the new mutated warrior with the warrior that just won the battle, 0 = always start with mate, 1 = always start with winning warrior. flipmaterate: 0.3 ;chance of changing to mate If the copy source is the winner, determines the odds of changing the source to the crossover mate. flipbackrate: 0.3 ;chance of flipping back If the copy source is the mate, determines the odds of changing the source to the winning warrior. The flipmaterate and flipbackrate settings determine the average number of lines in each chunk (1/setting), and the proportion of code from the crossover mate. To include mostly the winning warrior code make the flipmaterate setting smaller than the flipbackrate setting. anychance: 0 ;chance of crossing with dissimilar warrior This setting affects the chance of crossing with dissimilar code. Normally crossover is restricted to warriors that are the same size and of the same species. If anychance is above 0 then it determines the chances of disabling the checks for size and species, ranging from 0 (always check) to 1 (never check), i.e 0.1 disables the size/species check for 10% of the crossover operations. Usually warriors are surrounded by other warriors of the same size and species anyway so there's no effect but if the warriors are different then "strange" crosses can result. The target warrior size, species and origin are always taken from the winning warrior, if the mate is shorter and happens to be selected when it gets to the end it flips back to the winner to avoid crossing with "ghost" code that happens to be left over in the array from previous warriors. bestchance: 1 ;chance of crossing with warrior with most wins This setting controls how picky warriors are when selecting a mate for crossover. If 1 then a warrior with the highest number of wins is selected, if 0 then any candidate warrior is selected at random, values between 0 and 1 select the odds per crossover operation. ;code generation... instructions: mov mov mov mov mov spl spl spl djn djn instructions: add sne seq slt jmn jmz mod modifiers: .i .i .i .a .b .f .x .ab.ba modes: $$#@*<>{} These strings determine the code that is generated and must be correct or a shower of errors will result when evolving. If soup.dat is present then these settings are ignored. Each instruction must be 3 characters long separated by a single space, additional instructions: lines add to the internal string. Each modifier must be 3 characters long (including padding space) with no padding between 3-character fields. Use 3 spaces to include a no-modifier option but has to be surrounded by other entries. Set modifiers: to a tab character to use no modifiers at all. Addressing modes must be one after the other with no spaces. ;bench parameters... enablebench: yes ;yes to enable auto-bench/re-ins Set this to yes to enable automatic benchmarking and/or re-insertion, set to no to disable these features. benchrounds: 142 ;rounds used for benchmarking This setting determines how many rounds per battle are used when benchmarking warriors, automatically or manually using the test function. If coresize is 80 and benchrounds is 142, then the pmars -P parameter is used to perform a "permutate" sequence for maximum accuracy and speed, this requires pmars 0.9.2 or above. If using with exmars or an older pmars with nano warriors then set benchrounds to 500 or so (1000 is more accurate). Typically for coresize 800 a benchrounds setting of 200 or more is needed, and for coresize 8000 a benchrounds setting of 100 or more is needed to produce reasonably accurate benchmark results (+/- 5 points or less). savethresh: 95 ;percent of top score to save When automatically benchmarking warriors the program keeps track of the highest score so far in the run, warriors are saved to the save directory if they score within savethresh percent of the top score. reinsertmode: 2 ;0=none 1=top.red 2=from save Set to 0 to disable reinsertion, set to 1 to periodically reinsert the top.red warrior back into the soup, or set to 2 to periodically reinsert a randomly selected warrior from the save directory. This is a somewhat dubious function but still a subject of study. Reinserted warriors might further evolve and become stronger, or they may cause warriors around the newly inserted warrior and its decendents to evolve to learn to defeat the inserted warrior(s), and possibly produce lower benchmark scores. Using option 2 minimizes this effect. Reinsertion can help drive up benchmark scores by rewarding high-scoring warriors, but can also cause the soup to evolve techniques that are "focused" on defeating the benchmark warriors and not other warriors, resulting in lower scores against other benchmark sets. benchinterval: 500 ;bench every n iterations (0=none) Determines the frequency of benchmarking, set to 0 to disable automatic benchmarking. Don't set too low or it'll spend most of the time benchmarking and not evolving and may generate an excessive number of saved warriors (warriors that score the same as previous tests are not saved to avoid duplicates but only 500 previous scores are saved). reinsertinterval: 5000 ;re-insert every n iterations (0=none) Determines the frequency of re-insertion. Typically this should be set to 3 times the total number of soup warriors (xsize * ysize * 3) or higher to avoid excessive focusing effects (unless that's what you want). benchdir: nanobm07 ;directory containing benchmark warriors [path]name of a directory containing benchmark warriors, which must be appropriate for the configured coresize. If enablebench is yes then this directory must contain warriors or the program won't start. Benchmark warriors must have .red, .war or .rc extensions, other files present in the specified directory are ignored. savedir: save ;directory to save warriors to This setting permits changing the name of the directory to save warriors to. Useful if running on a ram disk but desirable to preserve saved warriors in the event of a power failure etc. testdir: nanob2 ;directory for single-test warriors (def.benchdir) Permits using a different benchmark set for the test function, if omitted the test function uses the warriors specified by benchdir. ;other parameters... initmode: 1 ;start warriors 0=first inst, 1=random If set to 0, new populations begin with the 1st instruction, modifier and mode specified in the code settings, with 0 numbers. If set to 1 (the usual setting) new warriors start with random code. This setting is ignored when continuing a run. spthresh: 5 ;percent change before different color This setting determines when warriors in the soup display change colors, expressed as a percentage of maxsize. If the number of instruction changes *exceeds* spthresh % of maxsize then a new color is selected. infoline: evolved ;added to strategy line For convenience. threads: 1 ;# of processing threads This setting specifies the number of parallel threads to use to increase performance on machines with multiple CPU's. For single-core processors without HyperThreading set to 1. Maximum setting allowed is 20. Typically for a HyperThreaded or (theoretically) a multi-core processor a setting of 4 to 8 threads results in maximum performance. A new set of temp files is written to in the temp directory for each additional thread. threadsleep: 0 ;# ms to sleep between threads How many milliseconds to sleep between launching each thread, or if a single thread, after running pmars and the mutation process. To reduce CPU usage and system load, set threads to 1 and set threadsleep to a number from about 25 to 1000 or so (larger numbers for larger coresizes), relative to how long pmars usually takes to complete a battle. enablelog: no ;yes to log to mevo.log file If set too yes then start and stop times and iteration counts and the results of all benchmark tests are appended to the mevo.log file. This can be useful for determining evolution speed for optimizing the threads setting, and generating data to use to analyse a run. For benchmarks the following items are logged: bench score, top score, generation, date, time, iteration count and if saved, filename saved to. displayopts: 24,10,11,0 ;term height,text col,frame col,unicode These options set display parameters. The first option is the minimum number of lines used for displaying text files (if ysize+3 is larger then increases). The 2nd and 3rd numbers are the colors used for text and the soup border. The 4th option specifies text or unicode border (,0 for text or ,1 for unicode), unicode border only works under Linux. ;end of ini file MEVO must be restarted for any INI changes to take effect. Some settings should not be changed during a run, specifically the soup size parameters, maxsize, the pmars coresize, and only change the pmars processes cycles maxlen and mindist settings during a run if you know what you're doing. Code generation settings (instructions, modifiers, modes) are ignored when continuing a run so don't change them to avoid confusion, if absolutely necessary edit the soup.dat file to alter the code strings but don't alter existing items, only add new items and make the same changes to the .ini file to document. Avoid changing the benchdir setting unless the save directory is also renamed or the scores produced by the new benchmark set are very similar, different benchmarks often produce different scores and this can throw off the extraction method. Techniques ---------- Settings can be more quickly tested by using a small soup size, such as xsize = 20 and ysize = 10. If using reinsertion, reduce reinsertinterval in proportion to the total number of soup warriors. Usually larger soups produce more diversity and stronger results, but take longer to evolve. Sometimes a few more points can be added by concentrating the soup, one way is to temporarily set reinsertmode to 1 and reinsertinterval to a low number like 10 to quickly saturate the soup with the top-scoring warrior, then set reinsertinterval back to a high number to continue. Another way is to start a new run but with the save directory containing strong warriors from previous runs, numbered 1.red 2.red etc. If the benchmark set is changed, re-benchmark the warriors and adjust the benchscore comment. Run briefly with reinsertmode 2 and reinsertinterval 10 to saturate the soup with copies of the previous warriors, then increase reinsertinterval to a reasonable value. For larger coresizes usually rounds has to be set fairly low (20-40) to get paper warriors. Once the papers are firmly established then rounds can be increased for more accurate battles and somewhat higher strength. Don't assume my settings are "correct". Any given set of parameters should be run several times to better judge the effect (every run is different), so it can take me a week just to evaluate the effect a single change. Sometimes better results can be obtained by just guessing. I haven't optimized things like the intruction, modifier and mode weightings, or much of anything else except to get it in the ballpark. Results ------- Here is a nano warrior evolved by the 11/27/09 version of MEVO... ;redcode ;name 46_6 ;author mevo ;strategy evolved ;generation 734 ;species 9121 ;origin 72_6 ;assert 1 spl.i #-3,<-40 mov.i <-1,{-27 mov.i >17,{-2 mov.i {-29,<-3 djn.i $-2,<-20 end ;benchscore 155.19 (nanobm07 142 rounds) Battle details for warrior 46_6 Opponent Scores Results Performance of 46_6 --------------- --------- ----------- ---------=---------=---------=---------= 8c09fc1a-479925 1575 1380 510 445 45 ********************* rdrc: Alcoholis 1494 1458 482 470 48 ******************* b1f3ad11-a6073e 1731 1260 574 417 9 *********************** Bacillus anthra 1470 1485 475 480 45 ******************* Black Sun III 1486 1393 455 424 121 ******************* rdrc: Breakaway 1487 1262 412 337 251 ******************* c82f15b5-85011f 1467 1491 475 483 42 ******************* Clear-2 1516 1429 487 458 55 ******************** Cosmic Horror 1806 1071 561 316 123 ************************ Different Day 1474 1507 485 496 19 ******************* written in a dr 1429 1429 429 429 142 ******************* early morning v 1365 1626 452 539 9 ****************** Escherichia col 1670 1307 549 428 23 ********************** e6843-5724-xt43 1129 1627 295 461 244 *************** Foggy Maus (bet 1746 1239 577 408 15 *********************** girl from the u 1667 1298 544 421 35 ********************** human resistanc 1931 1052 638 345 17 ************************* the kraken awak 1858 982 566 274 160 ************************ Leishmania dean 1684 1255 541 398 61 ********************** looking glass 1435 1513 461 487 52 ******************* lord of the dig 1587 1359 511 435 54 ********************* Man&Machine 1388 1547 441 494 65 ****************** Military Grade 1429 1525 461 493 46 ******************* New Vera City 1484 1484 484 484 32 ******************* Obsidian peasou 1279 1690 416 553 31 ***************** Plasmodium viva 1964 1025 651 338 11 ************************** qEvo[[3]] 1525 1375 475 425 100 ******************** realm of the fi 1390 1408 396 402 202 ****************** Red Moon 1409 1568 462 515 23 ****************** rdrc: Repent Li 1733 1232 566 399 35 *********************** Rocket propelle 1466 1514 482 498 20 ******************* rumpelstiltskin 1307 1472 362 417 221 ***************** Salmonella ente 1595 1355 515 435 50 ********************* Science Abuse 1632 1344 536 440 24 ********************* scythe 1554 1149 419 284 297 ******************** rdrc: Snapback 1347 1581 425 503 72 ***************** spawn of the da 1683 1173 513 343 144 ********************** Staphylococcus 1411 1468 430 449 121 ****************** Stegodon Aurora 1435 1489 453 471 76 ******************* rdrc: Strychnin 1555 1360 490 425 85 ******************** Subterranean Ho 1654 1072 460 266 274 ********************** tinderbox 1531 1288 450 369 181 ******************** toy soldier 1371 1518 420 469 111 ****************** Trypanosoma bru 1771 1126 556 341 103 *********************** victim of the n 1858 1120 612 366 22 ************************ war of the snow 1627 1063 439 251 310 ********************* wisdom of the g 1631 1316 526 421 53 ********************* wreath of thist 1722 1278 574 426 0 ********************** written in the 1798 1177 591 384 25 *********************** Xinyl 1464 1479 469 474 57 ******************* --------------- --------- ----------- ---------=---------=---------=---------= Adjusted Score: 156 Battle details for warrior 46_6 Opponent Scores Results Performance of 46_6 --------------- --------- ----------- ---------=---------=---------=---------= 8c09fc1a-479925 1575 1380 510 445 45 ********************* c82f15b5-85011f 1467 1491 475 483 42 ******************* Chiki Chiki 1687 1183 519 351 130 ********************** eerie glow 1490 1349 443 396 161 ******************* Foggy Maus (bet 1746 1239 577 408 15 *********************** glowing embers 1911 1005 609 307 84 ************************* hemlock 1650 1203 501 352 147 ********************** Old Lamplights 1443 1518 468 493 39 ******************* Left Alone 1267 1705 413 559 28 **************** Man&Machine 1388 1547 441 494 65 ****************** a slice of moon 1514 1433 487 460 53 ******************** Muddy Mouse (RB 1507 1456 490 473 37 ******************** 01_62 1661 1310 544 427 29 ********************** 02_08 1343 1619 435 527 38 ***************** Pacler Deux 1242 1572 352 462 186 **************** Red Moon 1409 1568 462 515 23 ****************** ripples 22 1526 1361 471 416 113 ******************** Shutting Down E 1600 1375 525 450 25 ********************* the spiders cre 1601 1280 494 387 119 ********************* White Moon 1706 1250 554 402 44 ********************** --------------- --------- ----------- ---------=---------=---------=---------= Adjusted Score: 153.6 The following mevo.ini file was used to create this warrior... ;ini file for mevo xsize: 77 ;width of soup ysize: 21 ;height of soup xwrap: yes ;if yes enable side-side wraparound ywrap: no ;if yes enable top-bottom wraparound maxsize: 5 ;max evolved length ;pmars parameters... coresize: 80 ;size of core array processes:80 ;max processes cycles: 800 ;cycles before tie maxlen: 5 ;maximum warrior length mindist: 5 ;minimum separation rounds: 250 ;# of battle rounds pmarsbin: pmars ;path/name of pmars binary pmarsvbin: pmarsv ;path/name of pmarsv binary pmarsvopt: -v 564 ;pmarsv view options etc ;mutation parameters... instrate: 0.02 ;chance of instruction change modrate: 0.03 ;chance of modifier change moderate: 0.03 ;chance of address mode change datarate: 0.06 ;chance of field value change insrate: 0.01 ;chance of line insert delrate: 0.01 ;chance of line delete swaprate: 0.02 ;chance of line swap endrate: 0.1 ;chance of changing end number dupline: 0 ;if insert, chance of dup line incdec: 0.3 ;if data, chance of inc or dec bignum: 0.5 ;if data, chance of big number endincdec: 0.5 ;if end, chance of inc or dec end0chance: 0.3 ;chance of end 0 ;crossover parameters... enablecross: yes ;if yes then cross with surrounding warrior flipstart: 0.8 ;chance of starting with winning warrior flipmaterate: 0.3 ;chance of changing to mate flipbackrate: 0.3 ;chance of flipping back ;code generation... instructions: mov mov mov mov mov spl spl spl djn djn instructions: add sne seq slt jmn jmz mod modifiers: .i .i .i .a .b .f .x .ab.ba modes: $$#@*<>{} ;bench parameters... enablebench: yes ;yes to enable auto-bench/re-ins benchrounds: 142 ;rounds used for benchmarking savethresh: 95 ;percent of top score to save reinsertmode: 2 ;0=none 1=top.red 2=from save benchinterval: 500 ;bench every n iterations (0=none) reinsertinterval: 5000 ;re-insert every n iterations (0=none) benchdir: nanobm07 ;directory containing benchmark warriors savedir: save ;directory to save warriors to testdir: nanob2 ;directory for single-test warriors (def.benchdir) ;other parameters... initmode: 1 ;start warriors 0=first inst, 1=random spthresh: 5 ;percent change before different color infoline: evolved ;added to strategy line threads: 1 ;# of processing threads threadsleep: 0 ;# ms to sleep between threads enablelog: yes ;yes to log to mevo.log file displayopts: 24,10,11,1 ;term height,text col,frame col,unicode ;end of ini file Here is a stone-type warrior for coresize 800 using the 11/19/09 version... ;redcode ;name 75_15 ;author mevo ;strategy evolved ;generation 733 ;species 3258 ;origin 26_16 ;assert 1 spl.ab #-331,$8 mov.i #20,}-6 mov.i $3,}-7 djn.i $-1,}-8 end ;benchscore 170.6 (franz 200 rounds) Battle details for warrior 75_15 Opponent Scores Results Performance of 75_15 --------------- --------- ----------- ---------=---------=---------=---------= Tiny Wicked Pet 1722 1221 555 388 57 ********************** Tiny AK-47 1648 1246 514 380 106 ********************* Tiny Barbarian 2175 717 689 203 108 ***************************** Tiny Brutality 1892 893 559 226 215 ************************* Tiny Everclear 1500 1494 498 496 6 ******************** Golden Gate v4 1383 1476 414 445 141 ****************** Tiny Porter (+1 1408 1570 462 516 22 ****************** Tiny Spiral 2932 58 974 16 10 *************************************** Tiny Tiberius 409 2434 84 759 157 ***** D-Clear 1649 1340 546 443 11 ********************* --------------- --------- ----------- ---------=---------=---------=---------= Adjusted Score: 167.1 The following INI file was used to create this warrior... ;ini file for mevo xsize: 77 ;width of soup ysize: 21 ;height of soup xwrap: no ;if yes enable side-side wraparound ywrap: no ;if yes enable top-bottom wraparound maxsize: 20 ;max evolved length ;pmars parameters... coresize: 800 ;size of core array processes:800 ;max processes cycles: 8000 ;cycles before tie maxlen: 20 ;maximum warrior length mindist: 20 ;minimum separation rounds: 30 ;# of battle rounds pmarsbin: pmars ;path/name of pmars binary pmarsvbin: pmarsv ;path/name of pmarsv binary pmarsvopt: -v 344 ;pmarsv view options etc ;mutation parameters... instrate: 0.01 ;chance of instruction change modrate: 0.02 ;chance of modifier change moderate: 0.03 ;chance of address mode change datarate: 0.05 ;chance of field value change insrate: 0.008 ;chance of line insert delrate: 0.01 ;chance of line delete swaprate: 0 ;chance of line swap dupline: 0.1 ;if insert, chance of dup line incdec: 0.2 ;if data, chance of inc or dec bignum: 0.5 ;if data, chance of big number ;crossover parameters... enablecross: yes ;if yes then cross with surrounding warrior flipstart: 0.7 ;chance of starting with winning warrior flipmaterate: 0.3 ;chance of changing to mate flipbackrate: 0.3 ;chance of flipping back ;code generation... instructions: spl spl spl spl spl mov mov mov instructions: mov dat dat dat jmp jmn jmz djn instructions: sne seq add sub mul div mod modifiers: .i .i .i .a .b .f .x .ab.ba modes: $#@*<>{} ;bench parameters... enablebench: yes ;yes to enable auto-bench/re-ins benchrounds: 200 ;rounds used for benchmarking savethresh: 95 ;percent of top score to save reinsertmode: 0 ;0=none 1=top.red 2=from save benchinterval: 500 ;bench every n iterations (0=none) reinsertinterval: 10000 ;re-insert every n iterations (0=none) benchdir: franz ;directory containing benchmark warriors savedir: save ;directory to save warriors to testdir: ;directory for single-test warriors (def.benchdir) ;other parameters... initmode: 1 ;start warriors 0=first inst, 1=random spthresh: 5 ;percent change before different color infoline: evolved ;added to strategy line threads: 1 ;# of processing threads threadsleep: 0 ;# ms to sleep between threads enablelog: yes ;yes to log to mevo.log file displayopts: 24,10,11,1 ;term height,text col,frame col,unicode ;end of ini file Here are various coresize 8000 warriors made using earlier versions... ;redcode ;name 64_4 ;author mevo/WTN ;strategy evolved ;generation 394 ;species 6487 ;origin 65_4 ;assert 1 spl.i #-9,$9 mov.i {15,{1 djn.ab $2570,<-1419 end ;(about 70 wilkies) ;redcode ;name 6_3 ;author mevo ;strategy evolved ;generation 170 ;species 7936 ;origin 54_3 ;assert 1 mul.i {-7,<-1655 nop.i {-3856,@-1014 add.ba #-17,>-3073 sne.f <-743,#-2319 spl.f #-928,#16 spl.i #1015,{2 mov.i <15,<-4 mov.i @-2980,<-8 mov.i #15,>1336 djn.x {-2,{1005 mod.a {2793,{-593 sub.f *519,#15 end ;benchscore 81.583 (wilkies 100 rounds) ;redcode ;name 17_4 ;author mevo ;strategy evolved ;generation 627 ;species 1254 ;origin 65_4 ;assert 1 spl.i #381,{1668 mov.i #-3003,>-1 mov.i <2,{1 djn.x $-1381,<-1746 end ;benchscore 84.25 (wilkies 100 rounds) ;redcode ;name 60_13 ;author mevo ;strategy evolved ;generation 189 ;species 3220 ;origin 49_13 ;assert 1 mov.i $-7,<17 mov.i {2635,*-2075 spl.ba #3715,}-1561 spl.i {-3134,>18 spl.i >703,*1045 spl.ba #3089,>2322 mov.i }-8,}-3 mov.i >-9,}-3 div.i #7,{2985 mov.i $-2958,{580 end ;benchscore 95.75 (wilkies 100 rounds) ;redcode ;name 9_8 ;author mevo ;strategy evolved ;generation 982 ;species 4018 ;origin 23_7 ;assert 1 spl.i #13,*-3647 sub.i #-11,}16 spl.ab #-15,<-19 mov.i }-5,>-3 mov.i @-1818,<-21 mov.i <-22,{2249 djn.ba >-3654,<1323 end ;benchscore 92 (wilkies 100 rounds) The last warrior was made using the 9/20/09 version and following INI... ;ini file for mevo xsize: 40 ;width of soup ysize: 10 ;height of soup maxsize: 25 ;max evolved length ;pmars parameters... coresize: 8000 ;size of core array processes:8000 ;max processes cycles: 80000 ;cycles before tie maxlen: 100 ;maximum warrior length mindist: 100 ;minimum separation rounds: 20 ;# of battle rounds pmarsbin: exmars ;path/name of pmars binary pmarsvbin: pmarsv ;path/name of pmarsv binary pmarsvopt: -v 014 ;pmarsv view options etc ;mutation parameters... instrate: 0.01 ;chance of instruction change modrate: 0.02 ;chance of modifier change moderate: 0.03 ;chance of address mode change datarate: 0.06 ;chance of field value change insrate: 0.01 ;chance of line insert delrate: 0.01 ;chance of line delete swaprate: 0.01 ;chance of line swap dupline: 0.1 ;if insert, chance of dup line incdec: 0.3 ;if data, chance of inc or dec bignum: 0.5 ;if data, chance of big number ;code generation... instructions: nop mov mov mov mov mov spl spl spl spl djn djn instructions: add sub mul div mod jmp jmz jmn sne seq slt dat modifiers: .i .i .i .a .b .f .x .ab.ba modes: $$#@*<>{} ;bench parameters... enablebench: yes ;yes to enable these settings benchrounds: 100 ;rounds used for benchmarking savethresh: 92 ;percent of top score to save reinsertmode: 2 ;0=none 1=top.red 2=from save benchinterval: 500 ;bench every n iterations (0=none) reinsertinterval: 2000 ;re-insert every n iterations (0=none) benchdir: wilkies ;directory containing benchmark warriors savedir: save ;directory to save warriors to testdir: ;directory for single-test warriors (def.benchdir) ;other parameters... initmode: 1 ;start warriors 0=first inst, 1=random spthresh: 5 ;percent change before different color infoline: evolved ;added to strategy line threads: 1 ;# of processing threads threadsleep: 0 ;# ms to sleep between threads ;end of ini file The following defaults are used for unspecified settings to preserve the original behavior when using older INI files... xwrap: no ywrap: no endrate: 0 end0chance: 1 enablecross: no flipstart: 0.5 anychance: 0 bestchance: 1 enablelog: no displayopts: 24,10,11,x (x=0 for Windows, 1 for Linux) Legal/Protocol Stuff -------------------- The MEVO program and its associated documentation are Copyright Terry Newton under the terms of the GNU General Public License (GPL, version 3 or later). The GPL license is at: http://www.gnu.org/licenses/gpl.html The software is provided as-is and without warranty. The software may be distributed as-is or modified, provided that the copyright notice remains intact and that the source code is made available. See license for details. If the software or documentation is modified (beyond normal configuration), make a note of the change with attribution in the source or text so that it may be distinguished from original versions. ----------------------------------------------------------- Last modified 12/4/09, for code version 12/3/09 Terry Newton (wtn90125@yahoo.com)