From: Scott_-_Nelson@cup.portal.com Subject: warriors Message-ID: <56722@cup.portal.com> Date: Wed, 1 Apr 92 01:27:31 PST O.K. here is another warrior from my collection, Rock. Rock has been on the hill but has not made it to the top yet. ----- cut ----- ;redcode ;author Scott Nelson ;name Rock ;strategy sort of Dwarf with bigger steps. rock add s, p p mov <1, 2 jmp rock dat #0 s dat #5084, #-5084 end rock ----- end cut ----- Rock is basically just dwarf with a step size of 5084. The larger step size and extra decrement makes Rock perform slightly better than Dwarf against most warriors. From: Scott_-_Nelson@cup.portal.com Subject: warriors Message-ID: <56723@cup.portal.com> Date: Wed, 1 Apr 92 01:28:32 PST Yet another warrior from my collection, Scissors 88. Scissors 88 is the first slaver-type program I wrote which uses the 'double add' strategy (which only became possible under the '88 standards) Scissors 88 made it to the top of the hill, but was quickly pushed off. ----- cut ----- ;redcode ;name scissors88 ;author Scott Nelson ;strategy capture the enemy and put him to work. ; ;main code loop ; loop add s, ptr ;double add makes ptr both jump and point mov ptr, @ptr ;move the jmp to the right place jmp loop ;Tiny, isn't it? ptr jmp pit s dat #5084, #-5084 ; ;Slave pit ; wptr dat #loop p dat #1 jmp pit pit mov p, Date: Wed, 1 Apr 92 01:30:36 PST Yet another warrior from my collection, Scissors 3.1 Scissors 3.0 is the first program I wrote which used the SLT instruction, (which also only became possible under the '88 standards) Scissors 3.1 made it to the top of the hill many times, and livce to a ripe old age of 91 before being bumped off. ----- cut ----- ;redcode ;name scissors3.1 ;author Scott Nelson ;strategy capture the enemy and put him to work. ;strategy only 5 code lines, scans every location. ;strategy ;strategy 3.1 - fewer DAT statements start add addval, jp ;scan for non-zero B-field (double add) jmz start, @jp ; slt #-16, jp ;O.K. if it's me skip the next instruction mov jp, @jp ; not me! bombs away jmp start ;go find another one. ; ; slave pit ; pit spl 1 ;enemy comes in here spl 1 addval mov 11, <-11 ;this is multi-purpose, it will ;elimate other enemies, kill the pit ;after clearing core, and I use it as ;an ADD value in the main code. jmp pit ; jp jmp pit ;jp at end so SLT will work right end start ----- end cut ----- Notes on scissors 3.1: The step size of 11 is one of the nicest features of this warrior, because it eventually hits EVERY location in core. This is also one of the few warriors which functions as well in a weird coresize (i.e. 11307) as it does in a standard one. (Molerat is another.) From: Scott_-_Nelson@cup.portal.com Subject: warriors Message-ID: <56725@cup.portal.com> Date: Wed, 1 Apr 92 01:31:40 PST One more warrior from my collection, Molerat. Molerat is a variant on Lemmings (see TCWN, spring 1988, page 11) It won the 1990 ICWS tourney and took second in the Grand finally held just afterward. It is not easy to follow the code, so I will outline the basic flow. Start 5 processes running inline (all 5 executing the same instructions) split to one of two "types", add or sub (more on this later) type add ; adds 5 locations to another location makes a copy of itself, splits to the beginning and repeats -and/or- bombs the location pointed to by the adds (perhaps a slave pit?) jumps to the copy. type sub ; subtracts 5 locations from another location makes a copy of itself, splits to the beginning and repeats -and/or- bombs the location pointed to by the subtracts (perhaps a slave pit?) jumps to the copy. ----- cut ----- ;redcode ;name Molrat A.K.A paper ;author Scott Nelson ;strategy - Replicate - start ; start up five inline process spl 1 mov -1, 0 mov -1, 0 spl paper4 ;type add spl paper3 ;type sub spl paper2 ;type add jmp paper1 ;type sub count dat #5 src1 mov #10, 10 ;initialize src for copy sub <203, 204 ;subtract for pit-bombing paper1 mov Date: Wed, 1 Apr 1992 02:32:03 GMT Another question in the same spirit. I can't tell from the instruction set description whether a task is descheduled ONLY after making a jump, or at the end of each instruction. Makes a large difference to how you code critical sections, and how much control you have over processor allocation.... ---------------------------------------------------------------------- stephen p spackman Center for Information and Language Studies stephen@estragon.uchicago.edu University of Chicago ---------------------------------------------------------------------- From: jperry@oahu.cs.ucla.edu (John Perry) Subject: Re: about C2N863.RED + other fighters in hex... Message-ID: <1992Apr1.032725.5963@cs.ucla.edu> Date: 1 Apr 92 03:27:25 GMT In article <1992Mar30.065458.20330@usenet.ins.cwru.edu> fau@po.CWRU.Edu (Francis A. Uy) writes: > >My copies of the 1990 fighters c2n863 + c10n642 > appear to be written in hexadecimal or somthing > similar. In any case, I can't read them, I can't > run them. Could someone post their code in plain > red? >-- >Francis A. Uy >fau@po.cwru.edu >cs201329@umbc5.umbc.edu Those two warriors were my entrants. I can't really say that I "coded" them per se, because actually they were evolved using a genetic algorithm. The first attempt I made at this was for the '89 ICWS tournament, and the two warriors I evolved for that came in second and third to last. These two actually did much better as you see. The reason there was no source for them is because they were evolved in Redcode object code format. I knew the chairman (president?) of the ICWS at the time (Bill Buckley), so I asked him what format the tournament would be held in. To no great surprize, he held it in the format of his own MARS. I got a copy of it and evolved warriors by competing them against past winners for fitness testing. If you want, I'll try to dig up a copy of the spec for his object code and you can disassemble them by hand if you'd like. Better yet, send email to Bill and try to convince him to make his MARS public domain. His email address is l5usabd@calstate.bitnet. John -- A message from the Anybody But Bush campaign: Saddam Hussein still has a job. Do you? From: kwhyte@math.uchicago.edu (Kevin Whyte) Subject: Re: modified '90 warrior, (was Re: Help! Need fighter!) Message-ID: <1992Apr2.201952.16523@midway.uchicago.edu> Date: 2 Apr 92 20:19:52 GMT I'm sure I posted this before, but Andy's reference to Sargent brought it to mind. Sargent was a decent idea, but wastes much time having the opponent imp stomp (of all things) if caught. Kinch is the next developement (although I never really got it past the crude stage), and is a better warrior than Sargent. The large #'s of dat #0,#0 are only to space the diffent segments of code. These really should be changed to dat 0,0 to make empty core. ;name Kinch ;author Kevin (kwhyte@math.uchicago.edu) bomb jmp pit,0 offset dat #436,#-436 dat #0,#0 dat #0,#0 dat #0,#0 dat #0,#0 dat #0,#0 dat #0,#0 dat #0,#0 dat #0,#0 dat #0,#0 dat #0,#0 dat #0,#0 dat #0,#0 dat #0,#0 dat #0,#0 dat #0,#0 start add offset,bomb jmz start,@bomb add #7,bomb loop mov #13,loop get mov bomb, Date: 3 Apr 92 04:36:53 GMT In article stephen@estragon.uchicago.edu (Stephen P Spackman) writes: >The point being, that 64 is small enough to be algorithmically useful, >while 8000 is the time it takes to wipe core, and therefore isn't. >Gotcha. Actually, 16000 is the time it takes to wipe the entire core as there is no single instruction capable of doing this so you need a looping instruction too. The best a single instruction can do would be a tie (Imp) or confusion (djn 0,<0). -Andy ajpierce@med.unc.edu From: Scott.Maxwell@bbs.oit.unc.edu (Scott Maxwell) Subject: Re: Neophyte questions. Message-ID: <1992Apr3.060824.794@samba.oit.unc.edu> Date: 3 Apr 92 06:08:24 GMT In article <1992Apr3.043653.29068@samba.oit.unc.edu> ajpierce@med.unc.edu (Andrew Pierce) writes: >In article stephen@estragon.uchicago.edu (Stephen P Spackman) writes: >>The point being, that 64 is small enough to be algorithmically useful, >>while 8000 is the time it takes to wipe core, and therefore isn't. >>Gotcha. > > Actually, 16000 is the time it takes to wipe the entire core as there >is no single instruction capable of doing this so you need a looping >instruction too. The best a single instruction can do would be a tie >(Imp) or confusion (djn 0,<0). Well, you can do better than that by unrolling the loop. Off the top of my head, bomb dat #0 loop mov bomb, -Andy >ajpierce@med.unc.edu By the way, in reference to one of Stephen's other questions ... in MADgic Core 4.0, at least, the instruction XCH swaps the A and B values of its A-operand. (That is, "XCH foo" swaps the A-field and B-field of foo.) The instruction is non-standard, to the best of my knowledge, but perhaps your system supports it. -- Scott Maxwell (CSMAXWEL@ECUVM1.BITNET or Scott.Maxwell@bbs.oit.unc.edu) -- The opinions expressed are not necessarily those of the University of North Carolina at Chapel Hill, the Campus Office for Information Technology, or the Experimental Bulletin Board Service. internet: bbs.oit.unc.edu or 152.2.22.80 From: haha@vipunen.hut.fi (Harri Haanp{{) Subject: Re: Neophyte questions. Message-ID: Date: 3 Apr 92 14:15:16 GMT In <56661@cup.portal.com> Scott_-_Nelson@cup.portal.com writes: > This sounds like a good idea for a puzzle: > What's the fastest way to move the B-field of a location to the A-field > in 100 words or less. (assume the A-field is initialized to zero as in > the above example.) Post your best time! How about this? moveme dat #0, #foo start slt moveme, #4096 add p+12, moveme slt moveme, #2048 add p+11, moveme slt moveme, #1024 add p+10, moveme slt moveme, #512 add p+9, moveme slt moveme, #256 add p+8, moveme slt moveme, #128 add p+7, moveme slt moveme, #64 add p+6, moveme slt moveme, #32 add p+5, moveme slt moveme, #16 add p+4, moveme slt moveme, #8 add p+3, moveme slt moveme, #4 add p+2, moveme slt moveme, #2 add p+1, moveme slt moveme, #1 add p, moveme <...> p dat #1, #-1 dat #2, #-2 dat #4, #-4 dat #8, #-8 dat #16, #-16 dat #32, #-32 dat #64, #-64 dat #128, #-128 dat #256, #-256 dat #512, #-512 dat #1024, #-1024 dat #2048, #-2048 dat #4096, #-4096 Now, who wants to implement QuickSort? Harri H. From: miles@athena.cs.uga.edu (Miles Meekhof) Subject: Problems with corewar Message-ID: <1992Apr3.171957.22736@athena.cs.uga.edu> Date: 3 Apr 92 17:19:57 GMT I got the files for the IBM version of corewars from soda.berkeley.edu. After putting all of the parts together and cutting out the comments and such, I used uudecode . Then I used zoo -extract corwp20.zoo. It seemed to work okay...all of the files unzooed correctly. I downloaded it to my system, and tried to run core.exe, but my system froze. I rebooted and tried rpp.exe, and it frozed also. I looked at the manual and it said something about configuring core.sys. It said if you delete it, core.exe will make a new one, so that is what I did. I don't believe it created a new one. Instead it gave me a division by zero error. Does anyone know what I might have done wrong? -- ========================================================================= # M I L E S @ A T H E N A . C S . U G A . E D U # From: JJJ101@psuvm.psu.edu Subject: Acid Rain 1.0 Message-ID: <92094.122752JJJ101@psuvm.psu.edu> Date: 3 Apr 92 17:27:52 GMT Here's my program Acid Rain. It's been floating around the x-hill for a few days around 8th,9th,or 10th. James ;redcode-x verbose ;name Acid Rain 1.0 ;author James Jesensky start mov i1, Date: 04 Apr 92 04:50:01 GMT Is information available on the KoTH tournament (specifically the one at wms@iwarp.intel.com): What are the rules and guidelines? Is there a way to get current standings without submitting a warrior? What is the scoring system? (W-3, T-1, L-0?) What is the age unit? (days?) What are the rules for resubmission of successful warriors? (bug fixes, etc.) I looked at soda.berkley.edu and didn't find enough information on these specifics. -- Julius Andrew Cisek ,_, t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated One Microsoft Way // <>__| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Subject: Valentine Tournament Round 3 Message-ID: <167BF1C53.DURHAM@ricevm1.rice.edu> Date: Sat, 4 Apr 1992 08:00:50 GMT Here are the results from Round 3 of the Valentine tournament: 0 / 1202 Winner Cycle -------- ------ ----- Stefan Strack's Drone allows him to continue to advance. Scott Adkin's Killer sends him to the Loser's Bracket. Drone / Killer Drone 25377 Killer / Drone Drone 26498 Stefan Haenssgen's Dime and Nandor Sieben's Return of the Living Dead exchanged games for a tie. Dime / Return of the Living Dead Return of the L. Dead 12813 Return of the Living Dead / Dime Dime 13245 William Shubert's Leech and Aleksey Baulin's V3 exchange again for a tie. Leech / V3 Leech 31 V3 / Leech V3 7830 Arne Juul's Rat and Campbell Fraser's and Scott Drummond's Intangible Worm also exchange battles for a tie. Rat / Intangible Worm Rat 1236 Intangible Worm / Rat Intangible Worm 3285 John Wetmiller's Gulliver tied Stig Hemmer's Scanner Y both times. Gulliver / Scanner Y Tie Scanner Y / Gulliver Tie Newcomers Jack Twilley's Apple Seed and Ray Cromwell's BullWhip exchanged battles for a tie. Apple Seed / BullWhip AppleSeed 520 BullWhip / Apple Seed BullWhip 728 Kevin Whyte's Kinch beat Kurt Werle's and Stephen Beitzel's Mr. Nasty once and tied it once to take a win. Kinch / Mr. Nasty Kinch 16339 Mr. Nasty / Kinch Tie Vincent Li's Paratrooper tied John's and Mike Nidd's Tamper both times. Paratrooper / Tamper Tie Tamper / Paratrooper Tie Peter Olcott's Dwarf28 lost to James Jesensky's HeapIMP once and tied once, giving the win to HeapIMP. Dwarf28 / HeapIMP HeapIMP 2525 HeapIMP / Dwarf28 Tie Here are the brackets so far: Beg/Winner's Bracket -------------------- Stefan Strack----- vs > Stefan Strack-- Stefan Haenssgen-- \ vs > Stefan Strack- Scott Adkins------ / \ vs > Scott Adkins--- \ Nandor Sieben----- \ >------------------ Arne Juul--------- / vs > Adam Caldwell-- / Adam Caldwell----- \ / vs > Adam Caldwell-- Fraser & Drummond- / vs > S. Halvorsen--- S. Halvorsen------ William Shubert--- vs > William Shubert John Wetmiller---- \ vs >---------------- Stig Hemmer------- / \ vs > Aleksey Baulin- \ Aleksey Baulin---- \ >------------------ Kevin Whyte------- / vs > Kevin Whyte---- / Werle & Beitzel--- \ / >---------------- Peter Olcott------ / vs > James Jesensky- James Jesensky---- Vincent Li-------- vs >---------------- John & Mike Nidd-- \ >---------------- Jack Twilley------ / vs >---------------- Ray Cromwell------ Loser's Bracket --------------- Arne Juul--------- vs >---------------- Fraser & Drummond- \ >---------------- John Wetmiller---- / \ vs >---------------- \ Stig Hemmer------- \ >----------------- Stefan Haenssgen-- / vs >---------------- / Nandor Sieben----- \ / >---------------- S. Halvorsen------ / vs >---------------- Scott Adkins------ From: wms@iwarp.intel.com (William Shubert) Subject: KotH Changes Message-ID: <1992Apr5.195427.25171@iWarp.intel.com> Date: Sun, 5 Apr 1992 19:54:27 GMT OK, KotH news. First, I've been getting tired of all these multiple versions of the same program, so I've added a ";kill" option. If a line like ";kill myprog" appears in your listing, then the program "myprog" will be removed from the hill. In addition, anything called "myprog V1.0", "myprog 2.5", or anything that has the string "myprog" in the title will be wiped out. This means that if you keep submitting new version of myprog, you can just leave ";kill myprog" in the file and it'll wipe out the previous version every time a new one shows up. PLEASE USE THIS. Before wiping out other programs, KotH will check to make sure the return addresses match - a pretty flimsy protection scheme, but there you are. The experimental hill had been sort of stagnating recently, and in general I'd say it wasn't a lot more fun than the ICWS hill, so poof! It's gone! The final standing as the hill was destroyed: W/ L/ T Name Score Age 219/145/ 76 Double Pesticide 733 45 194/110/136 Death by Misadventure v1.0 718 14 223/179/ 38 Dynamic Duo -x 2.0 707 7 202/176/ 62 prime directive 668 3 204/187/ 49 Dynamic Duo -x 2.2 661 4 195/178/ 67 csapda -x 652 6 179/151/110 color shark 1.1 -x 647 1 161/123/156 Acid Rain 1.0 639 5 181/167/ 92 living worm -x 635 2 129/ 71/240 Bow-n-Arrow 2.5 627 16 Using ";redcode-x" will now get you the following rules (for those who use my KotH corewar): "-all_modes -postinc -wdist 250" In english: All addressing modes are allowed with each instruction Postincrement addressing (">") is allowed A program may NOT modify a memory location more than 250 instructions from itself. For example, the instruction: mov 1000,250 acts like it always does, but mov 1000,251 does nothing. Try it out! -Bill (wms@iwarp.intel.com) Date: Monday, 6 Apr 1992 10:22:03 MST From: Message-ID: <92097.102204ASMQK@ASUACAD.BITNET> Subject: dwarf optima Consider the simplest dwarf warrior shift equ 4 start add #shift , 1 mov -2 , -2 jmp start end start It's clear, that 4 can be replace with any number a if gcd( a, coresize )=4. The question is how to choose a. I defined a function s(a) /*strength of a*/ the following way. nh:=coresize div 4 /*number of hits*/ s(a):= Sum (distance from the i. hit to the closest previous hit)/nh i=1 to nh For example if coresize=8000 then s(4)=4. XTC uses 412 to scan the core s(412)=13.19 I have the feeling, that the bigger s(a) the better a to scan or bomb. Clearly a=4 the worst choose. I used an a with s(a)=17.11 in dwarf optima and it made to the first place. It's possible that the choice of a really does not matter. What's your opinion? How can we define s(a) other ways? Nandor. From: wms@iwarp.intel.com (William Shubert) Subject: KotH weekly update Message-ID: <1992Apr6.155702.123@iWarp.intel.com> Date: Mon, 6 Apr 1992 15:57:02 GMT OK, here it is. In the ICWS '88 hill, Andy Pierce's "Synch" family of programs have finally been pushed off of the #1 slot. W/ L/ T Name Score Age 181/ 82/177 PiedPiperKOTH.2 720 10 181/100/159 return of the living dead 702 80 198/176/106 dwarf optima 700 1 214/181/ 45 Synch 4 687 11 209/187/ 44 scissors88 671 7 161/162/117 Small 4 600 9 173/205/ 62 smart shark 581 3 151/179/110 Rock 1.2 563 2 155/189/ 96 shark 1.0 561 4 160/213/ 67 Red Oktober KOTH .1 547 5 Campbell Fraser's PiedPiperKOTH.2's strategy is: ;strategy +-----------------------------------------------+ ;strategy |A vampiric attack program which defends itself | ;strategy +-----------------------------------------------+ Not too enlightening. As you probably know from yesterday's news, the experimental hill was restarted yesterday under different rules. So far most programs submitted to it seem to be operating under the old rules and haven't done too well, so I'll leave it off for thie week. -Bill (wms@iwarp.intel.com) From: kwhyte@zarquon.uchicago.edu (Kevin Whyte) Subject: Programs ... Message-ID: <1992Apr6.213422.27764@midway.uchicago.edu> Date: Mon, 6 Apr 1992 21:34:22 GMT I just ran a huge round robin between all the programs I have (mine and other's). There were 32 warriors, and each pair fought three times. The top five, in order, were: XTC Drone Kinch Mice (!!) Return of the Living Dead Thought you all might be interested. Kevin From: wms@iwarp.intel.com (William Shubert) Subject: Re: dwarf optima Message-ID: <1992Apr7.034432.23564@iWarp.intel.com> Date: Tue, 7 Apr 1992 03:44:32 GMT On what constants are best to use when spacing your bombs... I figure that putting two bombs nearby (for a Dwarf, that means 4 spaces apart) is very bad, so I would always choose spacing constants that take a long, long time before they put two bombs near each other. Like Nandor, however, I don't know how important this is for a bomber. -Bill (wms@iwarp.intel.com) From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: dwarf optima Message-ID: <57071@cup.portal.com> Date: 8 Apr 92 05:58:26 GMT -> Consider the simplest dwarf warrior . . . -> It's clear, that 4 can be replace with any number a if gcd( a, coresize )= -> The question is how to choose a. I defined a function s(a) /*strength of . . . -> It's possible that the choice of a really does not matter. -> What's your opinion? How can we define s(a) other ways? -> Nandor. Clearly the number matters, (note the hill position of dwarf optima), but I feel that the important thing is to space the bombs atleast as far apart as the size of ones opponent. It is unlikely in the extreme that an oppenent on KOTH will be larger than 100 words, so when the bombs are falling more than 100 apart, it doesn't matter how much more than 100. However, how the bombs hit closer than 100 is very important. This means that 228 is about as good as it gets, (although a few points can make the difference on the hill, so the margins might be important) ---- <> From: snroettg@faui09.informatik.uni-erlangen.de (Stefan Roettger) Subject: Re: dwarf optima Message-ID: <1992Apr8.120720.27993@informatik.uni-erlangen.de> Date: Wed, 8 Apr 1992 12:07:20 GMT >XTC uses 412 to scan the core s(412)=13.19 >I have the feeling, that the bigger s(a) the better a to scan or bomb. >Clearly a=4 the worst choose. >I used an a with s(a)=17.11 in dwarf optima and it made to the first place. >It's possible that the choice of a really does not matter. I've run some tests on this and it clearly comes to mind that bombing core with a constant that has high s(a) values is more efficient. I think this is due to the fact that the core is bombed in a much more regular way. The best way I can think of is to bomb into the middle of two previously bombed core locations and high s(a) values produce something similar to this scheme. With core size=8000 #3044 and #3364 have the biggest s(a) value=17.11. The crux is that if one offset performs good with core size=8000 it does not necessary perform well with other core sizes. In fact I didn't find an offset that did equally well with different core sizes. Suggestions and comments welcome Steff -- Stefan Roettger Student of Computer Science snroettg@cip.informatik.uni-erlangen.de Xerox your live! If you lose one it's better to have a copy! From: snroettg@faui09.informatik.uni-erlangen.de (Stefan Roettger) Subject: Re: Programs ... Message-ID: <1992Apr8.121344.28243@informatik.uni-erlangen.de> Date: Wed, 8 Apr 1992 12:13:44 GMT kwhyte@zarquon.uchicago.edu (Kevin Whyte) writes: > I just ran a huge round robin between all the programs >I have (mine and other's). There were 32 warriors, and each >pair fought three times. The top five, in order, were: > XTC > Drone > Kinch > Mice (!!) > Return of the Living Dead >Thought you all might be interested. Shure But which 32 programs, what coresize, etc? Could you please give some more detailed information? Would be very nice! Steff -- Stefan Roettger Student of Computer Science snroettg@cip.informatik.uni-erlangen.de Xerox your live! If you lose one it's better to have a copy! From: ajpierce@med.unc.edu (Andrew Pierce) Subject: Small 4 Message-ID: <1992Apr8.131527.7093@samba.oit.unc.edu> Date: 8 Apr 92 13:15:27 GMT Small 4 has survived 10 successful challenges on KotH. Here is the code. Basically this is the same as Small 2 which was posted to the net, except the bombs have been made visible to B-field scanners (I think it takes some of the elegance out of it, but it does do better), the bombing address is held within the the executable code, and the bombing sequence begins away from the executing code. -Andy ajpierce@med.unc.edu ;redcode verbose ;name Small 4 ;author Andy Pierce (ajpierce@med.unc.edu) ;strategy small bomber/clearer ;strategy v2: fix kill routine ;strategy v3: marginally more robust ;strategy v4: give bombs non-zero B-fields, start bombs away from self start add #15,1 mov hit,751 jmp start,0 hit spl 0,-1 mov 4,<-1 jmp -1,0 end start From: ajpierce@med.unc.edu (Andrew Pierce) Subject: Synch 4 Message-ID: <1992Apr8.133256.7898@samba.oit.unc.edu> Date: 8 Apr 92 13:32:56 GMT Synch 4 has survived more than 10 successful challenges on KotH. Here is the code. I really like this one. When it first appeared on KotH, the Synch series went immediately to #1 and stayed there for about a week. The highest score I saw reported was 978 or so, by Synch 3. Synch 4 is strategically almost identical to Synch 3, yet scored lower -- I take this to be due to random statistical influences on battles on the hill. Synch 4 is an off-axis cmp scanner -- it compares locations to see if they have been changed, but these locations are not coresize/2 apart so that programs cannot use the "mirror defence" of having two identical copies coresize/2 away from each other. Once an altered location has been found, Synch makes a decision: Case 1: the preceding instruction to the altered one has also been altered: In this case Synch 4 assumes it has found executing code and bombs with spl 0, following with a clear routine. Case 2: the preceding instruction to the altered one has not been altered: In this case Synch 4 uses the same strategy which my program "Stoopify" used and which I have learned the program "Hideout" also uses. This is based on the idea that "lightning never strikes twice in the same place". When building a pattern bomber, it is not very efficient to rebomb a location you have already hit (assuming non-motile programs) so Synch 4 transfers a small bombing routine on top of one of the bombs it has found. In some ways then, Synch 4 is somewhat parasitic: it beats the efficient pattern bombers but loses to "poorly designed" pattern bombers. The hill though has lots of efficient bombers on it, such as Small 4, which keep the programs that Synch 4 tends to lose to off the hill. -Andy ajpierce@med.unc.edu ;redcode verbose ;name Synch 4 ;author Andy Pierce (ajpierce@med.unc.edu) ;strategy cmp scan, spl bomb, clear core ;strategy v2: reduce footprint, convert losses to ties, better tactics ;strategy v2a: convert ties to wins, marginally better strategy ;strategy v3: reduce footprint again, more extensive smear routine ;strategy v4: move scan off axis, minor tactics fix start cmp 2939,6988 jmp hit,0 back sub offset,start jmp start,0 hit cmp @start,start-1 jmp 2,0 add flip,start slt #30,start jmp back,0 mov bomb,@start cmp Date: 9 Apr 92 00:02:20 GMT Spring 1992 IEEE CS Texas Statewide Programming Contest Announcement: (Important information inside if you are already planning to compete) Interested in competing? (This contest is for university students only.) Out-of-stater? Well, if you can get to Austin this Saturday, you're invited! The entry fee is a whopping $5, and it's being held in the Engineering Science (ENS) building 3rd-floor PC lab on the UT campus. We are still looking for teams to enter the Spring 1992 contest being held THIS Saturday, April 11. If you are interested in competing, please write to unbelver@ccwf.cc.utexas.edu as soon as possible. You must enter a team, so look for one or two teammates. We have a few teams from Rice, Texas A&M, UT, Baylor, and UT San Antonio, but we have room for more! There are some really good prizes this year as we have generous sponsorship from Dell, MKS, IBM, Quarterdeck, MacProducts, and Mix Software, so don't miss your chance! The contest will be conducted in C++ on Dell 386 and Intel 486 machines. Don't worry about the C++ stuff- if you know C, you should do just fine. We've tried to make the interface simple, and we'll have people there to help you with questions. Not only all this cool stuff, but there are most hip t-shirts for contestants, a blow-your-mind demo of OS/2 2.0, and scrumdilicious pizza! Already planning to compete? As we have every year, we are announcing the general format of the game a little early so you can think about the algorithms you are going to use. Please do not bring any code with you to the contest, but use this opportunity to study algorithms and strategies you think might be useful. Here's the game format! The game is called Spiders. You are a spider and although your sight isn't so hot (8 useless eyes), you could feel a feather land in your web if it were 20 feet away! Your mission: Eat flies! Of course, you're not going to catch flies unless you spin a web. Even if a fly does land in your web, you better have a fast way to get there, because there are other spiders in the game, and they're out to get the flies, too. More details on the contest day, but as always, be prepared for anything! Hint: Ever been bitten by a spider? They sure have *sharp* little mandibles! Another Hint: Web is web. Your player will be a C(++) program which communicates with the game server under the multitasking environment of JEMM. Your process will be given a specific timeslice so that your it cannot have more CPU time than your opponent's. So it is important that you write efficient code. If the server does not hear from your process for a turn, it will go on without you and assume you're sleeping or thinking. Most of this multi-tasking business should be transparent to your player, and your process will not be aware that it's being task-switched. About Spiders. This color VGA (640x480) game will probably not run with less than 2Mb on a 386 or 486, depending on how many players there are. It uses a home-made MS DOS based multi-tasking environment called JEMM which exploits virtual 8086 mode, written by Jason Yenawine, and features majorly hip animation thanks to the artwork of Oliver Yu. It has also been written to be portable to UNIX (X11 w/ BSD sockets required), thanks to a brilliantly new patented style of programming by Rob Gowin rumored to be called "PC's-Suck-But-They're-Everywhere Coding." Carlos Villalpando and Yulia Gelfond are responsible for the It's-a-C++-but-don't-worry-about-it interface. Some obscene number of man-hours went into this game which could probably be indirectly measured by the inverse of the semester GPA's of the programmers, so be nice to 'em; they've had an interesting six months. Disclaimer. The guy writing this had nothing to do with the incredible work done on this contest, so don't ask me real specific questions, 'cause I'll prolly make up something, and it'll prolly be wrong. =-ddt-> PS. Don't respond to me- write to unbelver@ccwf.cc.utexas.edu or call (512) 471-5038, the UT IEEE CS office! -- : "Alone or in pairs, rolls down the stairs, rolls over the neighbor's dog. : : What's good as a snack, and fits on your back? It's Log, Log, Log! : : It's Looo-og, It's Looo-og, it's big, it's heavy, it's wood! : : It's Looo-og, It's Looo-og, it better than bad- it's good!" : From: rscott@csws2.ic.sunysb.edu (Robert Scott) Subject: Robot Wars Message-ID: <1992Apr9.012215.23949@sbcs.sunysb.edu> Date: Thu, 9 Apr 1992 01:22:15 GMT I remember reading about some people who were thinking about writing some sort of Robot variation of core wars. Whatever became of this? If they are still interested in this, and are reading this newsgroup, could they please leave me E-mail as I am very interested in this. Thank you very much. Ralph Scott From: jonn@microsoft.com (Jon NEWMAN) Subject: Re: about C2N863.RED + other fighters in hex... Message-ID: <1992Apr09.064549.24370@microsoft.com> Date: 09 Apr 92 06:45:49 GMT In article DURHAM@ricevm1.rice.edu (Mark A. Durham) writes: > >Those fighters are MOB files (for MARS OBject file). They are >a format created by William R. Buckley for his Core War Colosseum >programs, but supported by some other programs such as Jon Newman's >Core! and THINK Software's CoreMaster (whose manual describes the >format). Sorry, Core! does not support MOB format. Maybe next release? At any rate, let me warn Core War programmers not to submit contest entries in MOB or any other implementation-specific format. The 1988 Core War standard specifies a standard text format understood by all MARS simulators. Contests in the future will not necessarily be held using Core War Colosseum, so avoid local extensions and use the generic format! By the way: The International Core War Society (ICWS) may be coming back on line very soon! When this happens, I will post information on ICWS activities and membership to this newsgroup, and also email it to the many people who have specifically asked me for more information. Thank you all for your patience! Jon Newman -- jonn@microsoft.com This is not the official opinion of Microsoft Corporation. Bill Rules! From: fraserc@dcs.glasgow.ac.uk (Campbell Fraser) Subject: A program for the new experimental hill Message-ID: <1992Apr9.161258.11703@dcs.glasgow.ac.uk> Date: 9 Apr 92 16:12:58 GMT To try to get things going with the experimental hill, here is a program I just submitted. It is simple but may be effective with address range limitation in place. ;redcode-x verbose ;name runner KOTH.1 experimental ;author Campbell Fraser ;strategy +--------------------------------------------------------------------+ ;strategy | Run through memory throwing 'dat' infront and leaving 'dat' behind.| ;strategy | This strategy is no use when no addressing range restriction exists| ;strategy +--------------------------------------------------------------------+ spl 1 jmp 2 dat 0, 0 mov Here, Here+5 mov There, There+5 mov Date: Thu, 9 Apr 1992 22:35:08 GMT >In article <57071@cup.portal.com> ScottNelson@cup.portal.com (Scott - Nelson) writes: >-> Consider the simplest dwarf warrior >. . . >-> It's clear, that 4 can be replace with any number a if gcd( a, coresize )= >-> The question is how to choose a. I defined a function s(a) /*strength of >. . . >-> It's possible that the choice of a really does not matter. >-> What's your opinion? How can we define s(a) other ways? >-> Nandor. >Clearly the number matters, (note the hill position of dwarf optima), but I >feel that the important thing is to space the bombs atleast as far apart as >the size of ones opponent. It is unlikely in the extreme that an oppenent on >KOTH will be larger than 100 words, so when the bombs are falling more than >100 apart, it doesn't matter how much more than 100. However, how the bombs >hit closer than 100 is very important. This means that 228 is about as good >as it gets, (although a few points can make the difference on the hill, so >the margins might be important) >---- ><> Mostly I agree. It is also important that the dist. be large compared to the distance between the warriors (to avoid any "seeing them coming for you" type programs). Of course, with a distance of 228 the chance of such a thing is small at best. I once worked out the mathematics of filling up core uniformly by bombing. If people really care about such things I'll dig it up. Maybe I'll run a dwarf tourney and see how theory follows reality. Yeah...sounds like fun. (Damn! I have to teach in 15 min. Oh the agony ... well patience is a virtue :) Kevin kwhyte@math.uchicago.edu From: kwhyte@math.uchicago.edu (Kevin Whyte) Subject: Re: Programs ... Message-ID: <1992Apr10.161038.7772@midway.uchicago.edu> Date: Fri, 10 Apr 1992 16:10:38 GMT In article <1992Apr8.121344.28243@informatik.uni-erlangen.de> snroettg@faui09.informatik.uni-erlangen.de (Stefan Roettger) writes: >kwhyte@zarquon.uchicago.edu (Kevin Whyte) writes: > > >> I just ran a huge round robin between all the programs >>I have (mine and other's). There were 32 warriors, and each >>pair fought three times. The top five, in order, were: > >> XTC >> Drone >> Kinch >> Mice (!!) >> Return of the Living Dead > >>Thought you all might be interested. >Shure > >But which 32 programs, what coresize, etc? >Could you please give some more detailed information? >Would be very nice! > Steff > >-- >Stefan Roettger >Student of Computer Science >snroettg@cip.informatik.uni-erlangen.de >Xerox your live! If you lose one it's better to have a copy! Chang1 Commando Cowboy Dime Droid Drone Dwarf Dwarf28 Ferret HeapIMP Killer LivingDead Mice Mortar MrNasty Paratrooper Pits-of-doom Quartet Raidar Roll ScannerY Small2 X5 XTC fleas ghost kinch luck mice mortar myte pits-of-doom redbaron sargent seek-and-go-hide Those are all the ones I didn't delete right after the tourney ;) Those starting w/caps belong to other people, the lower case ones are mine. Conditions were as close to KotH as I could remember. Now, each pair only fought 3 times, and the top 4 were all very close ... that ordering is probably no more accurate than random. Anyway, I'm not sure I trust the compiler ... Kevin kwhyte@math.uchicago.edu From: kwhyte@math.uchicago.edu (Kevin Whyte) Subject: Re: dwarf optima Message-ID: <1992Apr10.164139.9475@midway.uchicago.edu> Date: Fri, 10 Apr 1992 16:41:39 GMT In article <1992Apr8.120720.27993@informatik.uni-erlangen.de> snroettg@faui09.informatik.uni-erlangen.de (Stefan Roettger) writes: >>XTC uses 412 to scan the core s(412)=13.19 >>I have the feeling, that the bigger s(a) the better a to scan or bomb. >>Clearly a=4 the worst choose. >>I used an a with s(a)=17.11 in dwarf optima and it made to the first place. >>It's possible that the choice of a really does not matter. > >I've run some tests on this and it clearly comes to mind >that bombing core with a constant that has high s(a) values >is more efficient. I think this is due to the fact that the core >is bombed in a much more regular way. The best way I can think of >is to bomb into the middle of two previously bombed core locations >and high s(a) values produce something similar to this scheme. > >With core size=8000 #3044 and #3364 have the biggest s(a) >value=17.11. The crux is that if one offset performs >good with core size=8000 it does not necessary perform well with >other core sizes. In fact I didn't find an offset that did equally >well with different core sizes. > >Suggestions and comments welcome > Steff > > > >-- >Stefan Roettger >Student of Computer Science >snroettg@cip.informatik.uni-erlangen.de >Xerox your live! If you lose one it's better to have a copy! I promised some serious analysis ... but I can't find it. It wasn't that hard, so I'll redo it right after my taxes. Off the cuff : Divide by coresize, so that we are using real # mod 1. Now we want the multiples to be as far away from zero as possible, which amounts to asking the real to be badly approximable by rationals. In at least one sense, the worst approx. # is sqrt(1.25)/2 So something right around that fraction of core should be good for most core sizes. For N=8000 and asking that we bomb every fourth memory location that gives either 4932 or 4948. Unfortunately (I'll let someone else compute s(.) for those #'s), that is the wrong notion of rational approx. The function others have defined is also not quite right. The (main) reason bombing with high numbers is useful is as follows: If the opponent is (say) 10 lines long, then initially there are 8000 places in core the program could be (yes, they do overlap). After 1 bomb that misses, there are only 7990 places left it could be. Every hit will remove another 10 possible hiding places PROVIDED the distances between bombs are no closer than 10. If they are, then fewer places are removed. Now we don't know how long our opponents are going to be, so we have to design for a distribution of lengths. The function s(a) does not really take in to account that virtually all programs are under length 30 ... s(a) is the function (almost) if you assume program lengths are unif. dist. 1..Coresize. The other factor missing in s(a) is that we care more about what happens early on. A short gap after filling 3/4 of core is MUCH better than one earlier. Why? Because the chances that the fight will still be going after all that are much less, around 1/16 th as much. This scaling should also be included. Anyway, I wrote this all up once - I can do it again (together with the ? of how much to unroll a loop). Kevin kwhyte@math.uchicago.edu Subject: Re: dwarf optima Message-ID: <92101.190526ASMQK@ASUACAD.BITNET> From: Date: Friday, 10 Apr 1992 19:05:26 MST I would be interested in that theory. Dwarf tournament sounds great. How do you think it? Dwarfs against what? Every a with big s(a) is relatively big, so you don't have to worry about that is too small. Nandor. From: jperry@oahu.cs.ucla.edu (John Perry) Subject: Evolving Core Warriors Message-ID: <1992Apr10.221004.2682@cs.ucla.edu> Date: Fri, 10 Apr 92 22:10:04 GMT I mentioned in a previous post that I had used genetic algorithms to evolve Core Wars warriors which were in the 90 and 91 ICWS international tournaments. I subsequently got a deluge of requests of a description of the code or the code itself, and I've been telling people that when I find the stuff in my archives I'll send them a copy. Unfortunately, I neglected to save any email addresses. Well I found the term paper that describes the first phase of the experiment. It was in Microsoft word (MAC) format, but I converted it to ASCII and uploaded it to unix, and after a little cleanup its ready to send out. If you're interested, send me email and I'll send you a copy. I haven't found the code yet (it should be among my DOS archive disks, but there are quite a few of them and I haven't dug it up yet. When I find it I'll post it to the group (it's shorter than the paper) and perhaps place a copy in the Core Wars archive (is it still on soda?). Also, I wrote a paper on the later stages of the research in latex, but I haven't found that yet either. When I find other stuff, I'll let you know. John -- A message from the Anybody But Bush campaign: Saddam Hussein still has a job. Do you? From: ez003207@hamlet.ucdavis.edu (Psycho-Dwarf Model #13000A24Fd) Subject: KOTH Message-ID: <12142@ucdavis.ucdavis.edu> Date: 11 Apr 92 01:29:46 GMT Could someone post a help file or point me in the right direction on how to submit corewar files to the King of the Hill? I've been writing for about a month and a half now, and I want to see if my programs will make it! Also -> whats the difference in : ;redcode ;redcore verbose ;redcode -x ;redcode -x verbose when I submit them? One more thing: It was mentioned that with ';redcode -x' you could use this and that and then also your program couldn't change memory locations more than 250 space away! Under such conditions, wouldn't a dwarf be useless in a core 8000 big? thanks in advance -- this is my .signature file From: wms@iwarp.intel.com (William Shubert) Subject: KotH Message-ID: <1992Apr11.163729.29008@iWarp.intel.com> Date: Sat, 11 Apr 1992 16:37:29 GMT Sad news: Last night our system had all it's UIDs remapped (we're going to merge with another area). I took down all living processes as I was supposed to and restarted them this morning. Unfortunately, something seems to have gone wrong, because it ate all programs waiting to run and produced a slew of nonsense error messages. I'll probably look into this later today, but for the meantime, KotH is down. If you want to submit programs, feel free, but they won't run. -Bill (wms@iwarp.intel.com) From: wms@iwarp.intel.com (William Shubert) Subject: Re: KotH Message-ID: <1992Apr11.204036.2367@iWarp.intel.com> Date: Sat, 11 Apr 1992 20:40:36 GMT OK, KotH is back up. Please re-submit any program that was waiting to run. -Bill (wms@iwarp.intel.com) From: rjc@hal.gnu.ai.mit.edu (Ray) Subject: Binary Subdivision bombing Message-ID: <1992Apr12.233751.8607@mintaka.lcs.mit.edu> Date: Sun, 12 Apr 1992 23:37:51 GMT I have been experimenting lately with a bombing technique that I'd call binary subdivision. It works like this. -- program's location -- / \ bomb loc -2000 bomb loc +2000 / \ / \ -1000 +1000 -1000 +1000 / \ / \ / \ / \ -500 +500 -500 +500 -500 +500 -500 +500 / \ / \ / \ / \/ \ / \ / \ / \ -250 +250 Well, you get the picture. On each iteration, a bomb is placed between two previous bombs. On the 7th iteration, the core is bombed every 32 locations, hence a program of length greater than 32 will be hit. On the next iteration, every 16th location is hit. And so on. The problem is with the implementation. Right now, I have implemented a version which copies itself to each node on this tree, and splits to each of the subnodes on its left and right. This slows down the bombing process but the program is more likely to survive non-spl bombers. A hit only kills one of the branches of the tree. What I'd like to do is implement a faster version that uses iteration rather than recursion (spawning copies). It's hard to do without a stack of some sort though. With post increment on the Xhill it is easy to implement a stack, however, the stack will grow exponentially large as each iteration is evaluated. At the 7th iteration, the stack is about 256 locations large. That's much to big (as it can be bombed easily) What I need is a non-stack, non-spawning algorithm that can bomb each node on that tree. Here's a copy of my current program. ;redcode verbose ;name Binary Tree ;author Ray Cromwell ;strategy Spawn off two copies of itself at ;strategy dest+epsilon and dest-epsilon, then epsilon=epsilon/2 ;strategy as a result, the distribution through the core is maximized. dest1 dat #0,#0 dest2 dat #0,#0 size dat #tbl-dest1,#tbl-dest1 ;size of prog start mov #0,dest1 ;zero dest1,dest2 mov #0,dest2 add @ptr,dest1 ;dest1+offset sub @ptr,dest2 ;dest2-offset djn 1,ptr ;decrement ptr to offset table mov size,dest1-1 ;move copy size djn 1,size ;decrement size mov @dest1-1, Date: Mon, 13 Apr 1992 01:28:37 GMT King of the Hill V2.2 is finally available. This is the first version that I would say has a "decent" user interface. The V2.2 interface still has a few rough edges, but at least the capability needed to easily test programs is there. As usual, anybody who wants it can send me email. Now you have a choice between one 120K shar file or 3 40K shar files. I think I'll probably upload it to soda soon, too. -Bill (wms@iwarp.intel.com) From: wms@iwarp.intel.com (William Shubert) Subject: KotH Weekly Update Message-ID: <1992Apr13.190653.846@iWarp.intel.com> Date: Mon, 13 Apr 1992 19:06:53 GMT Weekly update time! In the ICWS '88 hill, PiedPiperKOTH.2 has taken the lead, closely followed by two variants on extremely old fighters(!), Dwarf and Mice. W/ L/ T Name Score Age 185/ 73/182 PiedPiperKOTH.2 737 24 212/194/ 74 dwarf optima 710 15 189/119/132 multi mice 699 12 220/185/ 35 Synch 4 695 25 208/184/ 48 scissors88 672 21 177/122/141 return of the living dead 672 94 191/173/ 76 Red Oktober KOTH .3 649 1 194/190/ 56 XTC2 638 7 154/163/123 Wasp 1.1 585 4 166/192/ 82 Rock 1.2 580 16 ;name PiedPiperKOTH.2 ;author Campbell Fraser ;strategy +-----------------------------------------------+ ;strategy |A vampiric attack program which defends itself | ;strategy +-----------------------------------------------+ I've been really please with the response for the experimental hill. A bunch of programs have been submitted to it, pushing my two entries way down the hill :-(. Here's the standings: W/ L/ T Name Score Age 126/ 36/278 multi mice -x 656 14 123/ 51/266 Absolute 250 635 9 176/158/106 Essex (X-hill) 634 2 176/179/ 85 Quasit (X-hill) 613 3 93/ 74/273 Virus 552 11 88/ 74/278 Oddball (X-hill) 542 7 72/ 57/311 Hunter 1.0 527 25 150/213/ 77 Shoggoth 1.0 527 1 141/197/102 Kobold Gun V2.0 525 16 73/ 79/288 Paratroopers 1.2 507 8 ;Name multi mice -x ;Author nandor sieben Multi mice has no ;strategy, but I don't think Nandor will mind if I say that it's basically a variant of the original Mice program. Now for a question: the "-x" hill seems to show a lot of ties. I've seen programs not make it onto the hill because they get beaten by programs that just tie all the time. Hopefully as better programs are written this will end, but in the meantime, what are the general opinions on making ties worth less? Just an idea; I won't act on this anytime soon. -Bill (wms@iwarp.intel.com) From: ian@inf.ethz.ch (Ian) Subject: Re: Binary Subdivision bombing Message-ID: <1992Apr14.102057.21348@neptune.inf.ethz.ch> Date: 14 Apr 92 10:20:57 GMT In article <1992Apr12.233751.8607@mintaka.lcs.mit.edu> rjc@hal.gnu.ai.mit.edu (Ray) writes: > > I have been experimenting lately with a bombing technique that I'd >call binary subdivision. It works like this. ... Wouldn't it have been easier to use a dwarf-like program that halved it's bombing increment (from a look up) with each completed circuit of the core? This would hit some locations twice (unless you added an offset as well) but that's not necessarily a bad thing. From: milewski@su5m.uucp (Kevin Milewski) Subject: Sun Sparc Core Wars? Graphical!!!? ftp site? Message-ID: <1992Apr14.130420.14827@trantor.harris-atd.com> Date: 14 Apr 92 13:04:20 GMT Hello, World! I'm looking for Core Wars for a Sun Sparcstation. If there are any graphical versions out there, I'd prefer them. (I've got one for my Amiga & it's great!) Please send info to the email address below, as my header address may not be correct. Tanks in advance (rumble, rumble, rumble, ...) Kevin Milewski o----------------------------------------------------------o | Calgon, take me away!!! | Harris Corp, ESS | | Kevin Milewski 407-729-7351 | PO Box 91000, M/S 5W/5837 | | milewski@su5m.ess.harris.com | Melbourne, FL 32902 | From: un035300@wvnvms.wvnet.edu Subject: Hunter 1.0 Message-ID: <1992Apr15.000601.2876@wvnvms.wvnet.edu> Date: 15 Apr 92 05:04:47 GMT Here is my FIRST posting of a warrior! Hunter has done ok on the -x hill floating between 5th and 10th. I don't really understand "exactly" what is does but it works and that's what is important! Any comments or suggestions are welcome! Rob Shultz ;redcode-x verbose ;author Rob Shultz ;name Hunter 1.0 ;strategy hits warriors with a SPL and then hunts them down. temp DAT #0 target DAT #0 bomb DAT #0 start stop SPL stop2 bomb2 MOV bomb,target stop2 JMP bomb2 SPL imp DJN killer,temp MOV @start,@temp+611 MOV @start+1,@temp+611 MOV @start+2,@temp+611 MOV @start+3,@temp+611 MOV @start+4,@temp+611 JMP start killer SPL stop,0 JMP start imp MOV imp,imp+1 From: lindblad@cc.helsinki.fi Subject: How to KotH??? Message-ID: <1992Apr15.183433.1@cc.helsinki.fi> Date: 15 Apr 92 16:34:33 GMT How do I send my warriors to KotH? Also, what's the core size used on KotH? Thank's in advance. -- Jarkko Lindblad lindblad@cc.helsinki.fi From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Subject: VDT apologies Message-ID: <167CAC5C2.DURHAM@ricevm1.rice.edu> Date: Wed, 15 Apr 1992 19:03:46 GMT For those of you following and/or participating in the Valentine's Day Tournament of Programmers, I have to apologize for not having completed the latest round yet. In fact, I will not be able to post results until sometime next week. I thank you for your patience. Mark A. Durham MAD From: ASMQK@ASUACAD.BITNET Subject: age top Message-ID: <92106.133117ASMQK@ASUACAD.BITNET> Date: 15 Apr 92 20:31:17 GMT return of the living dead 102 alive scissors 3.1 91 double pesticide 74 pesticide-x 68 pesticide 1.2 35 shark 1.0 34 synch 4 33 alive pied piper KOTH.1 32 alive scissors 88 29 alive If you find any mistakes on the list please let me know. Nandor asmqk@asuacad.bitnet From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: KotH Weekly Update Message-ID: <57443@cup.portal.com> Date: Thu, 16 Apr 92 01:34:57 PDT >Now for a question: the "-x" hill seems to show a lot of ties. I've seen >programs not make it onto the hill because they get beaten by programs that >just tie all the time. Hopefully as better programs are written this will >end, but in the meantime, what are the general opinions on making ties worth >less? Just an idea; I won't act on this anytime soon. Somehow I think that statement came out wrong, (did you really mean that the programs that lost 30, won 0 and tied 410, were better than thoses that lost 0, won 0, and tied 440?) IMHO people are already doing their best to win, not tie, and if anything the score for a tie is too low, not too high. |+-----------------------------------------------------------------------+| Half a loaf is better than no bread. <<>> From: fraserc@dcs.glasgow.ac.uk (Campbell Fraser) Subject: Re: Hunter 1.0 Message-ID: <1992Apr16.100919.29117@dcs.glasgow.ac.uk> Date: 16 Apr 92 10:09:19 GMT In article <1992Apr15.000601.2876@wvnvms.wvnet.edu>, un035300@wvnvms.wvnet.edu writes: > Here is my FIRST posting of a warrior! Hunter has done ok on the > -x hill floating between 5th and 10th. I don't really understand > "exactly" what is does but it works and that's what is important! > Any comments or suggestions are welcome! > > Rob Shultz > > ;redcode-x verbose > ;author Rob Shultz > ;name Hunter 1.0 > ;strategy hits warriors with a SPL and then hunts them down. > > temp DAT #0 > target DAT #0 > bomb DAT #0 > start > stop SPL stop2 > bomb2 MOV bomb,target > stop2 JMP bomb2 > SPL imp > DJN killer,temp > MOV @start,@temp+611 > MOV @start+1,@temp+611 > MOV @start+2,@temp+611 > MOV @start+3,@temp+611 *** > MOV @start+4,@temp+611 > JMP start > killer SPL stop,0 > JMP start > imp MOV imp,imp+1 eh, well, um, I don't know what it does either. It looks as if 2 processes will just loop on "bomb2" and "stop2". In fact everywhere seems to lead to that loop so no matter where execution starts, it will end up there very quickly with perhaps an imp running through memory. So I suppose its an imp with impstomp. Incidentally, "@temp+611" will evaluate as "@(temp+611)" and "@start+1" will evaluate as "@(start+1)". e.g line marked *** will evaluate as MOV @-5, @600 So it won't copy part of itself forward which I reckon was the intention. Hope this makes sense to you. Campbell --- Hi, I'm a .signature virus. Copy me to yours and then wipe all your files. -- Campbell Fraser \/ JANET : fraserc@uk.ac.dcs.glasgow Computing Science Dept /\ INTERNET: fraserc%dcs.glasgow.ac.uk@nsfnet-relay.ac.uk Glasgow University \/ USENET : fraserc.glasgow.uucp Glasgow G12 8QQ, U.K. /\ PHONE : A student with phone, you must be kidding. From: stig@Lise.Unit.NO (Stig Hemmer) Subject: What does "address range limitation" forbid? Message-ID: <1992Apr16.103311.1049@ugle.unit.no> Date: Thu, 16 Apr 92 10:33:11 GMT Given an "address range limitation" of 250, which of these MOV's get to write their data? a) MOV #1,249 (Just for completeness) b) MOV #1,-249 c) MOV #1,250 d) MOV #1,-250 e) MOV #1,@200 ...200... DAT #200 f) MOV #1,@400 ...400... DAT #-200 g) MOV 400,200 Stig 'Tortoise' Hemmer aka stig@lise.unit.no .no means Norway, a minor kingdom in northern Europe. Europe is a moon of Jupiters. This is NOT a .signature virus. Do NOT copy it into your .signature From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Moving the B-field to the A-field Message-ID: <57500@cup.portal.com> Date: Fri, 17 Apr 92 00:51:05 PDT Here's a faster way to move the A-field to the B-field. I think there is a way to eliminate the add #1, moveme but I can not think of a way to do it. ;redcode slt moveme, n4096 sub n4096, moveme slt moveme, n2048 sub n2048, moveme slt moveme, n1024 sub n1024, moveme slt moveme, n512 sub n512, moveme slt moveme, n256 sub n256, moveme slt moveme, n128 sub n128, moveme slt moveme, n64 sub n64, moveme add #1, moveme sub @moveme, moveme ; ; Ta da! ; n4096 dat #-4096, #4096 n2048 dat #-2048, #2048 n1024 dat #-1024, #1024 n512 dat #-512, #512 n256 dat #-256, #256 n128 dat #-128, #128 n64 dat #-64, #64 ; ;the value to move ; moveme dat #0, #2048+7 table dat #-0, #1 dat #-1, #2 dat #-2, #3 dat #-3, #4 dat #-4, #5 dat #-5, #6 dat #-6, #7 dat #-7, #8 dat #-8, #9 dat #-9, #10 dat #-10, #11 dat #-11, #12 dat #-12, #13 dat #-13, #14 dat #-14, #15 dat #-15, #16 dat #-16, #17 dat #-17, #18 dat #-18, #19 dat #-19, #20 dat #-20, #21 dat #-21, #22 dat #-22, #23 dat #-23, #24 dat #-24, #25 dat #-25, #26 dat #-26, #27 dat #-27, #28 dat #-28, #29 dat #-29, #30 dat #-30, #31 dat #-31, #32 dat #-32, #33 dat #-33, #34 dat #-34, #35 dat #-35, #36 dat #-36, #37 dat #-37, #38 dat #-38, #39 dat #-39, #40 dat #-40, #41 dat #-41, #42 dat #-42, #43 dat #-43, #44 dat #-44, #45 dat #-45, #46 dat #-46, #47 dat #-47, #48 dat #-48, #49 dat #-49, #50 dat #-50, #51 dat #-51, #52 dat #-52, #53 dat #-53, #54 dat #-54, #55 dat #-55, #56 dat #-56, #57 dat #-57, #58 dat #-58, #59 dat #-59, #60 dat #-60, #61 dat #-61, #62 dat #-62, #63 dat #-63, #64 dat #-64, #65 ;This is probably not the fastest, but it is the fastest I know of. ;|+--------------------------------------------------------------+| ;I had a really nice implementation of QuickSort, but this ;signature is too small to contain it. ; <<>> From: ASMQK@ASUACAD.BITNET Subject: Re: age top Message-ID: <92107.175331ASMQK@ASUACAD.BITNET> Date: 17 Apr 92 00:53:30 GMT As you probably know Koth is 20 long now. I don't think I can handle it so please send me your program's oldest age if you'd like it on the age top. Since it's is easier to get older so I think age 50 or older would be a good limit. Thanks. Nandor. asmqk@asuacad.bitnet From: dms@uno.vis.citri.EDU.AU (David Mcgregor SQUIRE) Subject: Where's the FAQ? Message-ID: <9210815.8793@mulga.cs.mu.OZ.AU> Date: Fri, 17 Apr 1992 05:28:23 GMT Hi. I just read this group for the first time. I know *nothing* about core wars, but would like to learn. Where do I start? Squizz -- | David McG. Squire (Squizz), | A physicist doing Computer Science. | | Vision Group, CITRI, 723 Swanston St.,| For a while. He claims. | | 723 Swanston St, Melbourne, AUSTRALIA.| haven't sold my soul...... | | Net: dms@due.vis.citri.EDU.AU | I've pawned it." | From: wms@iwarp.intel.com (William Shubert) Subject: Re: What does "address range limitation" forbid? Message-ID: <1992Apr17.200557.20989@iWarp.intel.com> Date: Fri, 17 Apr 1992 20:05:57 GMT About corewar: Yes, the hill is 20 programs long now...I got a new workstation that's MUCH faster so this is no problem any more. I found a farily serious bug in V2.2 of KotH. Basically, if you can load programs, you don't have the bug. It shows up on some machines but not others; I'm working on a solution and should have a new version ready soon. About address range limitations: the "MOV #1,250" works. The "MOV #1,-250" also works. "MOV #1,@200" with core[pc+200]=200 FAILS (the write is outside the radius of 250 instrucionts). "MOV <400,200" with core[pc+400]=100 will copy core[pc+499] to core[pc+200] as it should, but the value at core[pc+400] will NOT be changed. There is a very simple rule in effect here: Imagine you are the MARS. Process the instruction as normal, but every time you are about to modify a memory location, first check to see that it is within 250 instructions of the PC. If it is, continue as normal. If it is too far away, do not modify the core but continue with the rest of the instruction. I hope that that clears things up. -Bill (wms@iwarp.intel.com) From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: Binary Subdivision bombing Message-ID: <57559@cup.portal.com> Date: Fri, 17 Apr 92 23:27:43 PDT First let me point out that if you want post-increment, you can always do it in two instructions (MOV @stack,b ADD #1,stack). Here is a single-process bomber that bombs with a "binary subdivision". ---- cut ----- ; ;name Binary bomber ; ; basic bomber loop mov bomb, @offsets l2 add @i1, @loop djn loop, @i2 ; now change the parameters add #1, loop add #1, i1 add #1, i2 jmp loop ; i1 dat addvals i2 dat counts ;the table of add values addvals dat #0 dat #4096 dat #2048 dat #1024 dat #512 dat #256 dat #128 dat #64 dat #32 dat #16 dat #8 dat #4 dat #2 ;the table of counts counts dat #1 dat #2 dat #4 dat #8 dat #16 dat #32-1 dat #64-2 dat #128-4 dat #256-8 dat #512-15 dat #1024-30 dat #2048-60 dat #4096-120 ;the table of offsets offsets dat #bomb+4096 dat #bomb+2048 dat #bomb+1024 dat #bomb+512 dat #bomb+256 dat #bomb+128 dat #bomb+64 dat #bomb+32 dat #bomb+16 dat #bomb+8 dat #bomb+4 dat #bomb+2 dat #bomb+1 ; bomb dat #0 ---- end cut ----- Subdividing core in this manor can also be accomplished by having one dwarf for each step size. This is not as bad as it sounds, eleven dwarves, and three mov's accomplish the whole task. (It is actually shorter than "Binary bomber") I suspect that even a perfect binary subdivision program would not perform very well, because of the large tables needed. Until some sort of division instruction exists, I think binary subdividers will take a back seat to the "optima" style of bombing. |+--------------------------------------------------------------+| Half a bee, philosophically, must ipso facto, half not be. <<>> From: rjc@hal.gnu.ai.mit.edu (Ray) Subject: Re: Binary Subdivision bombing Message-ID: <1992Apr18.082557.824@mintaka.lcs.mit.edu> Date: Sat, 18 Apr 1992 08:25:57 GMT Well I did a single process bomber about 3 days ago and it lost miserably on the hill. It's just too big a target (although much smaller than yours) compared to dwarf optima and their ilk. ----------------------------------- ;redcode verbose ;name Binrary Tree 2.0 (beta) ;author Ray Cromwell ;strategy Greatly enhanced version of my Binary Tree program ;strategy thousands of times faster! bomb spl 0,#42 offset dat #0,#0 temp dat #0,#0 dat #0,#0 num dat #16,#16 start mov Date: Sun, 19 Apr 1992 22:48:47 GMT Well, there was a bug in KotH V2.2 that made some people incabale of loading programs, so I've already prepared V2.3. Improvements: - Fixed bug just mentioned - Added color capability(!) - Minor improvements in user interface I predict that this will be the last version of KotH for quite some time. As before, mail me and I can give you one 120K file or 3 40K files of the source code. It runs on just about any Unix system with X11R5. I'll upload it to soda as soon as soda will let me (anybody know why this is down so much?) -Bill (wms@iwarp.intel.com) From: jperry@oahu.cs.ucla.edu (John Perry) Subject: Core War Genetics & address problems Message-ID: <1992Apr21.161537.14415@cs.ucla.edu> Date: Tue, 21 Apr 92 16:15:37 GMT Howdy, Well, I sent out a bunch of copies of the first and second papers, and now I've located the source code for my Core Wars Genetics experiments. Unfortunately, its a later version which incorporates several subroutines from Bill Buckley's Core War Colloseum. Since I don't have copyrights to that code, I'll have to spend some extra time teasing out the genetic part of the code before I make it available. I'll also write up some additional documentation on how the code itself works and why I chose certain constants. Rather than sending out a bunch of copies by email, however, I'd rather post it to Soda and make it directly accessible by FTP. Is there a particular directory on soda that I'm supposed to place it in, or can I place it directly in the directory that has all the other Core Wars junk? Anyway, I'll post again here after I upload the goods. John -- A message from the Anybody But Bush campaign: Saddam Hussein still has a job. Do you? From: big@yoyo.cc.monash.edu.au (Andrew Mills) Subject: A request for information. Message-ID: <1992Apr23.003748.4621@monu6.cc.monash.edu.au> Date: 23 Apr 92 00:37:48 GMT I am new to corewars and rec.games.corewar and don't know very much about them apart from what they are. However, I am interested in setting one up on our system. Would it be possible for the FAQ's to be reposted as well as any information that might be of use to me, or in preference for someone to mail this info to me ? In particular, the information I need is: - What programs are needed to run one ? - Where can I get them ? - What compilers, etc, are needed to set up the game ? - How is a corewar game run ? - Is there anything else I haven't though of ? Any help at all would be greatly appreciated. ___________________________________ _________________________________________ < | > < big | Young Crone : "How did you know that?" > < (aka Andrew Mills) | > < | Black Adder : "Just a wild stab in > < can be found at : | the dark. Which, incidentally, is > < | what you'll be getting if you're > < big@yoyo.cc.monash.edu.au | not a bit more helpful !" > <___________________________________|_________________________________________> From: ajpierce@med.unc.edu (Andrew Pierce) Subject: KotH statistics Message-ID: <1992Apr23.045310.13307@samba.oit.unc.edu> Date: 23 Apr 92 04:53:10 GMT Hi all. Recently I submitted a minor variant of Synch 5 to KotH called "test". To my great surprise, when it fought Synch 5 is scored: 17/29/4 where I had expected an idealized result of x/x/y (wins = losses). This prompted me to resubmit "test" in order to check variability of results within KotH, even with 50 battles. By the time I got around to this, there were three new entries on the hill, nevertheless, the exact same program (test) fought 17 different KotH progs 50 times, twice. Here's what happened: Ret. Liv. Dead: 17/24/9 16/28/6 Plain Paper: 44/4/2 46/3/1 Zipper: 10/39/1 6/44/0 Pied Piper 2: 15/26/9 8/30/12 Agony: 29/21/0 32/18/0 Worm Optima: 11/39/0 18/32/0 Wasp 1.1: 16/15/19 19/17/14 Dwarf Optima: 21/20/9 19/21/10 Synch 5: 17/29/4 22/26/2 Scissors 88.2: 14/32/4 11/31/8 Sucker: 48/2/0 48/1/1 Armadillo: 47/3/0 42/7/1 Charon 2.0: 25/18/7 17/31/2 Pit Trap 2.2a: 13/37/0 9/41/0 Dwarf 12-b: 34/14/2 29/12/9 Am I Evil 4: 34/16/0 32/15/3 "test": 27/23/0 23/27/0 totals: 422/362/66 397/384/69 overall score: 156.7 148.2 Make of this what you will. I suspect though that a KotH score should be considered as accurate +/- 10 points. Unfortunately, a glance at the hill shows that most programs are within 20 points of each other so relative rankings really don't mean very much. What can be done about it? Clearly, a perfectly accurate score between two programs can be found if they fight each other 8000 times; one always at location 1 and the other at locations 2,3,4,5,6... (minus the sum of the two program lengths to avoid overlap). At first 8000 seems like a ridiculous number of battles, but now with KotH running on kick butt hardware I'm not so sure. After all, this is the equivalent of 8 fresh challenges on the hill and determines relative scores for two programs (not just one). Maybe KotH could run such exhaustive battles during "slack" times, completing say, three such runs per day. If KotH perferentially figured complete scores for programs both within the top 5 or top 10, these programs would be likely to stick around for an extended period of time and so after the initial effort, it might not be too much of a drain to maintain such a level of thoroughness. Consider that with programs staying on the hill longer, an initial unlucky (or lucky) run will give a consistently distorted score, especially within the top 10. Anyone else have thoughts on this matter? -Andy ajpierce@med.unc.edu Date: Thursday, 23 Apr 1992 10:28:09 EDT From: Message-ID: <92114.102810JJJ101@psuvm.psu.edu> Subject: Re: KotH statistics In article <1992Apr23.045310.13307@samba.oit.unc.edu>, ajpierce@med.unc.edu (Andrew Pierce) says: [Stuff Deleted...] > > Make of this what you will. I suspect though that a KotH score should >be considered as accurate +/- 10 points. Unfortunately, a glance at the >hill shows that most programs are within 20 points of each other so >relative rankings really don't mean very much. > > What can be done about it? Clearly, a perfectly accurate score between >two programs can be found if they fight each other 8000 times; one always >at location 1 and the other at locations 2,3,4,5,6... (minus the sum of >the two program lengths to avoid overlap). At first 8000 seems like a >ridiculous number of battles, but now with KotH running on kick butt >hardware I'm not so sure. After all, this is the equivalent of 8 fresh >challenges on the hill and determines relative scores for two programs >(not just one). Maybe KotH could run such exhaustive battles during >"slack" times, completing say, three such runs per day. If KotH >perferentially figured complete scores for programs both within the top 5 >or top 10, these programs would be likely to stick around for an extended >period of time and so after the initial effort, it might not be too much >of a drain to maintain such a level of thoroughness. Consider that with >programs staying on the hill longer, an initial unlucky (or lucky) run >will give a consistently distorted score, especially within the top 10. > Anyone else have thoughts on this matter? > -Andy >ajpierce@med.unc.edu I don't if I'm the only one, but I think 20 programs is just way too many. Here's my idea based on Andy's observations and Bill's new kick-ass machine :). How I understand it right now, with each challenger there are about 21*21*25-20*50 = 10025 matches. Running 10 programs and 500 matches would yield about 27000 matches per challenger--only a x3 increase in running time. Here is an algorithm for generating 500 starting address which is more "fair" than a random one. Divide the legal starting address space (100-7900) into 250 equal subsections. Randomly choose an address in each subsection. Call these address s1, s2, ..., s250. For 250 matches, Program A starts at 0 and Program B at s1,s2,...,s250 For 250 matches, Program B starts at 0 and Program A at s1,s2,...,s250 James jjj101@psuvm.psu.edu jesensky@endor.cs.psu.edu Date: Thursday, 23 Apr 1992 13:59:52 EDT From: Message-ID: <92114.135952JJJ101@psuvm.psu.edu> Subject: Absolute 250 This program has been on the -x hill for quite some time so I thought I'd post it. It hung around #2-#3 on the old 10 program Hill making #1 I think twice. On the new Hill it hangs out about 8th. ;redcode-x verbose ;name Absolute 250 ;author James Jesensky start spl imp, <-199 jmp -1, <-200 imp mov 0, >1 From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Subject: Re: KotH statistics Message-ID: <167D29255.DURHAM@ricevm1.rice.edu> Date: 23 Apr 92 15:24:13 GMT In article <1992Apr23.045310.13307@samba.oit.unc.edu> ajpierce@med.unc.edu (Andrew Pierce) writes: > I suspect though that a KotH score should >be considered as accurate +/- 10 points. Unfortunately, a glance at the >hill shows that most programs are within 20 points of each other so >relative rankings really don't mean very much. > What can be done about it? Clearly, a perfectly accurate score between >two programs can be found if they fight each other 8000 times; one always >at location 1 and the other at locations 2,3,4,5,6... (minus the sum of >the two program lengths to avoid overlap). > Anyone else have thoughts on this matter? Mr. Robert Reed III (author of Ferret) has a program he called MCP (for Mass Compare Program) which did exactly as you suggest - play every possible unique match between two programs. I have the massive printouts to verify that. It may be a useful development tool, but if it were a matter of practice I believe it would dramatically alter the types of warriors which are submitted and win. The reason is, if every possible separation is played, then the programmer knows exactly where the opponent's warrior is going to start. I can guarantee at least one win by starting my program with MOV bomb, BOTTOM+1 where BOTTOM is 100 or whatever is the minimum separation. Whether desirable or not, playing all possible separations would alter current Core War strategies. KotH question: Are those 50 battles each unique? Or is it possible that two warriors may repeat a battle? Are battles reciprocal? That is, for 25 battles of A versus B, are there 25 identical battles of B versus A (B in A's place, A in B's place, and B starting first where A had been first)? Mark A. Durham MAD From: wms@iwarp.intel.com (William Shubert) Subject: Re: KotH statistics Message-ID: <1992Apr23.154839.12216@iWarp.intel.com> Date: Thu, 23 Apr 1992 15:48:39 GMT OK, I guess I should speak up now. The actual number of fights IS 1025 per program. I'm not willing to cut the hill back to 10 programs. Why? Because I think that it is far more important to keep programs from falling off the hill due to a quirk than to keep them properly ordered. You see, with a 10 program hill each new challenge could change your score by +/- 10%; programs would often go from #1 to off the hill in three or so challenges. With a 20 program hill your score can only change by +/- 5%, so a slight change in the makeup of the hill is much less likely to kill a good program. However, the programs ARE packed in tighter now, so the difference between #4 and #5 is smaller. About the "perfect" hill, it would require 7800 fights per program - that's 156 times as much as currently. Even fighting #1 vs. #2 this many times would require over 7.5 times as much time a a new challenge now. The way computers are getting faster, in 10 years this might be possible, but for now I think we'll have to stick with numbers around 50. The main thing of importance is to get as many fights per program as possible, and (IMHO) the current scheme strikes a nice balance between number of fights and CPU time. I'd rather not go back to the way it was with my old hardware where the queue would sometimes build up to 30 programs and people would have to wait over a day to get a response. -Bill (wms@iwarp.intel.com) From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: KotH statistics Message-ID: <1992Apr23.164059.11333@vuse.vanderbilt.edu> Date: Thu, 23 Apr 1992 16:40:59 GMT Seems to be the right time to insert my plug for "eliminating KotH variability by seeding the random number generator with a warrior-derived checksum". I had a little vote on this a few weeks back, but the outcome was pretty much 50/50. With the recent hill expansion, I thought the variability would be reduced, so I let the matter rest. Let me bring this up again now, with the "new evidence". I am aware that my approach replaces randomness with arbitrariness, but, hell, at least you'll be able to tell whether v2 of your program is doing any better than v1. In my scheme, if you feel that "you've been burned by the random number generator" (quoting Andy), you can always change an insignificant B-field of your code to get a new checksum. Comments? -Stefan (stst@vuse.vanderbilt.edu) From: wms@iwarp.intel.com (William Shubert) Subject: Re: KotH statistics Message-ID: <1992Apr23.210539.16507@iWarp.intel.com> Date: Thu, 23 Apr 1992 21:05:39 GMT MAD posted: >KotH question: Are those 50 battles each unique? Or is it possible that >two warriors may repeat a battle? Are battles reciprocal? That is, for >25 battles of A versus B, are there 25 identical battles of B versus A >(B in A's place, A in B's place, and B starting first where A had been first)? KotH simply picks 25 random battles with A going first, plays them, then picks 25 random battles with B going first. No symmetry, no predicatbility, no repeatibility. It is possible that two warriors may repeat a battle; in fact, I'd say that it was fairly likely that in a set of 25 battles the same fight would show up twice (I'd guess 10%-20% chance of happening). However, this bit of noise shouldn't show up as even a single point out of the 1025 battles total that will be fought. And on the average, of course, it makes no difference. I repeat my statement: I am not willing to use a fixed set of loading positions because I don't want any chance for a program to use this knowledge. If you really feel burned by the random number generator you're always welcome to re-submit (provided you use ";kill" to get rid of your old program). -Bill (wms@iwarp.intel.com) From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: KotH statistics Message-ID: <1992Apr23.230117.4506@vuse.vanderbilt.edu> Date: Thu, 23 Apr 1992 23:01:17 GMT In article <1992Apr23.210539.16507@iWarp.intel.com> wms@iwarp.intel.com (William Shubert) writes: > I repeat my statement: I am not willing to use a fixed set of loading >positions because I don't want any chance for a program to use this >knowledge. If you really feel burned by the random number generator you're >always welcome to re-submit (provided you use ";kill" to get rid of your >old program). > -Bill (wms@iwarp.intel.com) Just to clear this up: "checksum-seeding" the random number generator does not result in a fixed set of loading positions, since the checksum will be different for each pairing of programs. "Manipulation" is a theoretical possibility only if the source of the opponent is known. (assuming the above was in reference to my post) -Stefan (stst@vuse.vanderbilt.edu) From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: KotH statistics Message-ID: <57916@cup.portal.com> Date: Fri, 24 Apr 92 01:57:27 PDT . . . > It may be a useful development tool, but if it were a matter of >practice I believe it would dramatically alter the types of warriors which >are submitted and win. > >The reason is, if every possible separation is played, then the programmer >knows exactly where the opponent's warrior is going to start. I can >guarantee at least one win by starting my program with > > MOV bomb, BOTTOM+1 > >where BOTTOM is 100 or whatever is the minimum separation. > >Whether desirable or not, playing all possible separations would alter >current Core War strategies. Well it might alter MAD's strategies, but the only difference is if a warrior wins 1 out of 15,600 battles, or has a 1 in 15,600 chance of winning a battle. My warriors would look exactly the same in either case, and I suspect, most others would too. |+---------------------------------------------------------------------+| It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. <<>> From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: KotH stats (rigourous treatment) Message-ID: <57918@cup.portal.com> Date: Fri, 24 Apr 92 02:14:56 PDT I feel a 10% variance in the scores a warrior receives is acceptable. (note that Test only varied by 6%) If 10% is all that separates third from tenth, then tenth is pretty good! Instead of adjusting King of the Hill, perhaps one should just adjust his expectations. I'm not sure I agree that the random number generator doesn't affect this If the "random" number returns an exactly equal number of even and odd numbers, or only returns values less than 32768, (which is then taken mod 8000 by KOTH, giving a preference for numbers less than 768) then the varianc would be even lower than the "random" variance one would expect. p.s. The total number of battles needed to completely test a pair of warriors is 15,600, twice from every separation, alternating going first and second. |+---------------------------------------------------------------------+| That still leaves an infinite amount of improbability unaccounted for. <<>> From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Subject: Re: "Computer Recreations" games Message-ID: <167D2135AE.DURHAM@ricevm1.rice.edu> Date: Fri, 24 Apr 1992 03:01:12 GMT In article <1992Apr22.055010.9670@vuse.vanderbilt.edu> stst@vuse.vanderbilt.edu (Stefan Strack) writes: >I'm quite shure that all over the world lots of versions of > > core wars, turmites, spikophytes, beasties, biomorphs, > gridiums, cellular automata, graphtal plants, racters etc. > etc. > >have already be programmed, and most of them not for commercial >reasons. For those interested in a commercial product derived from Dewdney's articles, there is "Six Worlds". Six Worlds contains six different "excursions": Cellular Automata, Hypercubes, Mandelzoom (Mandelbrot set), Mental Wallpaper, Star Clusters, and Wator (Sharks and Fish). The program was written in Turbo Pascal and is available on 5 1/4" diskette. Both the compiled code and the source code programs are included. The price is $12.95 in the U.S., $15.95 in Canada (7% sales tax in Ontario). It is available from Turing Omnibus, Inc. P.O. Box 1456 London, Ontario Canada N6A 5M2 This information is a bit dated and is therefore not entirely reliable. I have no further information on Six Worlds, and I have not even seen the program. Other suppliers of Computer Recreations-derived programs are listed in the back of Dewdney's book, "The Armchair Universe". Dewdney also has a new book of computer recreations out now. >PS: Do you know, if it is possible to contact A. K Dewdney via > e-mail? Yes, it is possible. Unfortunately, I do not know what is his address. Mark A. Durham MAD From: ajpierce@med.unc.edu (Andrew Pierce) Subject: KotH stats (rigourous treatment) Message-ID: <1992Apr24.065942.17554@samba.oit.unc.edu> Date: 24 Apr 92 06:59:42 GMT Well people, after wondering about KotH reproducibility, I looked up the rigourous statistical treatment of the problem. Basically, your overall score is composed of two sample universes: that for the wins and that for the ties (the losses contribute 0 points). The way to figure overall score confidence levels is thus the sum of the confidence levels of these two universes. Here's how to do it: First convert your percentage scores to actual number won, lost and tied by multiplying by 850/100 (the total number of battles). I will refer to this as w/l/t. In the KotH report below, w/l/t for Sucker would be 416/264/170. Now compute standard deviations (with 850 samples, the universal standard (mu) is pretty much equal to the sample standard (s). With a statistical calculator, for wins enter 3 pts x number of wins + 0 pts x number of everything else. Similarly for ties enter 1 pt x number of ties + 0 pts x number of everything else. For those of you without statistical calculators the standard deviations for wins and ties (sw, st) are: sw=((9w-9w^2/850)/849)^.5 st=((t-t^2/850)/849)^.5 Now to obtain confidence intervals for the standard deviations about the mean for your total score: (MSD= Mean Standard Deviation) M.S.D. = 165(sw+st)/850^.5 (90% confidence) M.S.D. = 196(sw+st)/850^.5 (95% confidence) M.S.D. = 258(sw+st)/850^.5 (99% confidence) So for Sucker then, the MSD(90%) is 10.76 and the MSD(95%) is 12.78 This means that Sucker's _real_ score is 90% likely to be within +/- 11 pts from its listed score, and/or that Sucker's _real_ score is 95% likely to be within +/- 13 pts from its listed score. For a listed score of 167 then, Sucker's actual score is 90% likely to be somewhere in the range of 156-178 (and thus 10% likely to be outside this range) and 95% likely to be in the range of 154-180 (and thus 5% likely to be outside this range). Note that the range for a given confidence level (say 90%) will become narrower at the extreme top and bottom of the hill. Here follows a recent KotH report, along with the 90% confidence levels for the scores (something to include in the next version of KotH?): 90% %W/ %L/ %T Name Score Age +/- 49/ 31/ 20 Sucker 167 42 11 45/ 25/ 30 dead end 166 1 11 47/ 29/ 25 return of the living dead 165 93 11 43/ 25/ 32 Armadillo 161 50 11 46/ 31/ 23 Plain Paper 160 19 11 46/ 44/ 10 Am I Evil v4.5 149 8 10 45/ 45/ 9 Synch 5 146 65 10 42/ 39/ 19 scissors88.2 145 43 11 34/ 25/ 41 PiedPiperKOTH.2 142 91 11 45/ 48/ 7 worm optima (Eat your heart out nandor) 142 84 10 41/ 41/ 18 Charon v2.0 142 5 11 39/ 38/ 23 zipper 140 17 11 41/ 43/ 15 PitTrap v2.2a 139 34 10 39/ 49/ 12 The Call of Ktulu 1.6 129 2 10 39/ 50/ 11 Gnastier Gnats 128 4 10 38/ 50/ 12 Nevermore 3.2 126 14 10 33/ 42/ 25 Dwarf-12b 125 62 10 33/ 42/ 25 dwarf optima 124 35 10 31/ 38/ 31 Wasp 1.1 124 69 10 28/ 42/ 29 Overload 1.1 114 15 10 Just for illustration, a %score of 89/10/2 would be +/- 6 and a score of 2/96/2 would be +/- 3. It seems that the range of the confidence levels for KotH are remarkably flat in the range that programs seem to realistically obtain and that my initial guess that KotH was +/- 10 pts was pretty much dead on (at the 90% confidence level anyway). This being the case, 95% confidence levels would be about +/- 12 pts and 99% confidence levels would be +/- 16 pts. THE BOTTOM LINE: KotH scores are 90% accurate within +/- 10 pts of the listed score, i.e. the true score is 90% likely to be within a range of 20 pts with midpoint at the listed value. What can be done to improve the accuracy of KotH? The quick answer is: not much. Note that the nature of the random number generator is irrelevant to the discussion. The only parameter that affects the accuracy of the reported scores is the total number of battles. Accuracy is increased as the square root of the number of battles, thus with the current 50 battles per program, accuracy at 90% confidence of +/- 10 pts for the range of scores usually obtained could be doubled to +/- 5 pts if the number of battles per program were increased from 50 to 200 which may not be a practical thing to do. This also means that the "new" KotH set-up of 50 battles instead of 40 battles, is only 12% more accurate. My suggestion: realize that your score is +/- 10 to 12 points and learn to live with it. Be very careful when drawing conclusions about which programs are #1, #2, #3 etc. on KotH. -Andy ajpierce@med.unc.edu Subject: PD MARS for PC? Message-ID: <1992Apr25.124052.2638@otago.ac.nz> From: psyxsgp@otago.ac.nz Date: 25 Apr 92 12:40:52 +1300 2/Is there a Public Domain MARS for the IMB PC? (maybe including source maybe even in C?) 2/Is there a corewar archive site accessible from internet -- Stephen Pearce, University of Otago, Dunedin, New Zealand. ph 064-3-7470999 ext 8166 home 064-3-4763778 From: ajpierce@med.unc.edu (Andrew Pierce) Subject: Re: KotH stats (rigourous treatment) Message-ID: <1992Apr25.161709.29795@samba.oit.unc.edu> Date: 25 Apr 92 16:17:09 GMT Oops! As Bill rightly pointed out, the total number of battles is 1050, not 850 as I had (incorrectly) figured. To figure your confidence limits on KotH, just do the exact same treatment as I previously posted, except substitute 1050 for 850 and 1049 for 849. Also, be sure that you convert your percentage scores by multiplying by 1050 instead of 850. You get the idea. As predicted, it doesn't make a big difference. Since accuracy goes as the square root of the number of battles, 1050 is 11% more accurate than 850. This means that instead of the progs on the hill having 90% confidence intervals of +/- 10 or 11, they are +/- 9 or 10. So the +/-10 pts figure is still substantially accurate. -Andy ajpierce@med.unc.edu From: ajpierce@med.unc.edu (Andrew Pierce) Subject: Re: KotH stats (rigourous treatment) Message-ID: <1992Apr25.162329.29952@samba.oit.unc.edu> Date: 25 Apr 92 16:23:29 GMT Just as a postscipt to that last message, since you fight 1050 battles on the new hill vs 420 on the old KotH, your variability (which is now +/-10 pts 90% confidence) is much improved from what it was previously (+/-16 pts 90% confidence). The range of random ranking on the new KotH is 20 pts (90%) compared to 32 pts (90%) on the old hill. -Andy ajpierce@med.unc.edu From: ajpierce@med.unc.edu (Andrew Pierce) Subject: random position generation Message-ID: <1992Apr25.215048.7325@samba.oit.unc.edu> Date: 25 Apr 92 21:50:48 GMT In article <1992Apr23.230117.4506@vuse.vanderbilt.edu> stst@vuse.vanderbilt.edu (Stefan Strack) writes: >Just to clear this up: "checksum-seeding" the random number generator does >not result in a fixed set of loading positions, since the checksum will be >different for each pairing of programs. "Manipulation" is a theoretical >possibility only if the source of the opponent is known. Yes but what is the point of a checksum at all? Why not just have a ;seed=x line in your program? Then it could do some funky permutation of the two seeds (one from each program) and go from there. In a more practical vein, if people would post their source more, you could run battles exhaustively on your own time. -Andy ajpierce@med.unc.edu From: t-jcisek@microsoft.com (Julius CISEK) Subject: King of the Hill solutions (?) Message-ID: <1992Apr26.194211.29423@microsoft.com> Date: 26 Apr 92 19:42:11 GMT [My rec.games.corewar newsfeed is almost a week behind, so if this has already been said...] Here's another suggestion for KotH and the problems recently discussed. Instead of re-running the same battles every time a new challenger appears, how about saving the results in a database, and only playing the new battles (the ones against the challenger). Instead of 50 battles, make it 1000 battles. This would still only total to 20,500 battles (against the hill, and against yourself). Once you know how one program does against another (a number like 1000 would insure fairness), you could just keep that in a database. Only one challenger comes up at a time, so only the NEW battles need to be actually played. Just food for thought. J.Cisek -- Julius Andrew Cisek ,_, t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated One Microsoft Way // <>__| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| From: kwhyte@arthur.uchicago.edu (Kevin Whyte) Subject: Re: King of the Hill solutions (?) Message-ID: <1992Apr26.233224.26787@midway.uchicago.edu> Date: Sun, 26 Apr 1992 23:32:24 GMT In article <1992Apr26.194211.29423@microsoft.com> t-jcisek@microsoft.com (Julius CISEK) writes: > >[My rec.games.corewar newsfeed is almost a week behind, so if this > has already been said...] > >Here's another suggestion for KotH and the problems recently discussed. > >Instead of re-running the same battles every time a new challenger >appears, how about saving the results in a database, and only playing >the new battles (the ones against the challenger). Instead of 50 >battles, make it 1000 battles. This would still only total to 20,500 >battles (against the hill, and against yourself). Once you know how >one program does against another (a number like 1000 would insure >fairness), you could just keep that in a database. Only one challenger >comes up at a time, so only the NEW battles need to be actually played. > >Just food for thought. > > J.Cisek >-- >Julius Andrew Cisek ,_, >t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated >One Microsoft Way // <>__| /- O O idiot!" >Redmond, WA 98052 \X/ | U| \| It is my understanding that this is how it is done already. I would be VERY impressed if Bill's machine were fast enough to be doing it the other way. Kevin kwhyte@math.uchicago.edu From: jesensky@nogrod.endor.cs.psu.edu (James J Jesensky) Subject: Re: King of the Hill solutions (?) Message-ID: Date: Sun, 26 Apr 1992 23:33:25 GMT In article <1992Apr26.194211.29423@microsoft.com> t-jcisek@microsoft.com (Julius CISEK) writes: > >[My rec.games.corewar newsfeed is almost a week behind, so if this > has already been said...] > >Here's another suggestion for KotH and the problems recently discussed. > >Instead of re-running the same battles every time a new challenger >appears, how about saving the results in a database, and only playing >the new battles (the ones against the challenger). Instead of 50 >battles, make it 1000 battles. This would still only total to 20,500 >battles (against the hill, and against yourself). Once you know how >one program does against another (a number like 1000 would insure >fairness), you could just keep that in a database. Only one challenger >comes up at a time, so only the NEW battles need to be actually played. > >Just food for thought. > > J.Cisek >-- >Julius Andrew Cisek ,_, >t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated >One Microsoft Way // <>__| /- O O idiot!" >Redmond, WA 98052 \X/ | U| \| I really like this idea. -- James Jesensky jjj101@psuvm.psu.edu jesensky@endor.cs.psu.edu jesensky@cs.psu.edu jjj@arlvax.psu.edu jesensky@math.psu.edu From: t-jcisek@microsoft.com (Julius Cisek) Subject: Re: King of the Hill solutions (?) Message-ID: <1992Apr27.092454.20666@microsoft.com> Date: 27 Apr 92 09:24:54 GMT In article <1992Apr26.233224.26787@midway.uchicago.edu> kwhyte@arthur.uchicago.edu (Kevin Whyte) writes: >In article <1992Apr26.194211.29423@microsoft.com> t-jcisek@microsoft.com (Julius CISEK) writes: >>Instead of re-running the same battles every time a new challenger >>appears, how about saving the results in a database, and only playing >>the new battles (the ones against the challenger). Instead of 50 >>battles, make it 1000 battles. This would still only total to 20,500 >>battles (against the hill, and against yourself). Once you know how >>one program does against another (a number like 1000 would insure >>fairness), you could just keep that in a database. Only one challenger >>comes up at a time, so only the NEW battles need to be actually played. > > It is my understanding that this is how it is done already. >I would be VERY impressed if Bill's machine were fast enough to >be doing it the other way. > >Kevin >kwhyte@math.uchicago.edu Unfortunately, you ARE correct. As Stefan Strack pointed out to me in an e-mail message (thanks for the quick reply, Stefan), battles between warriors already on the hill are remembered, not replayed. Now I see how Charon v2.0 could jump from 12th to 2nd after a resubmission (And I thought I had stumbled across something while experimenting with step values...) To resolve 20,500 battles, matches would have to be resolved at the rate of 3 per second (on the average) if we wanted results in 2 hrs. That seems an unlikely thing, especially considering that ties take the full 80,000 cycles to resolve. However, I have a feeling that a really smart and efficient corewar simulator could be written where such a number could be approached. It would have to be all machine code. Absolute addressing should replace relative in every case possible (I think MOV is the only instruction where relative addressing is necessary). A really smart analyses might be able to reveal ties without having to run through the 80,000 cycles, etc. (Oh, no graphics...) I won't just speculate, either. It's a pretty interesting project and I'm willing to spend some time on it. If anyone has any other suggestions on speeding up execution, please let me know. By the way, I thought that maybe Bill Shubert had access to something REALLY, REALLY fast and secret (he DOES work at Intel, doesn't he??? :) -- Julius Andrew Cisek ,_, t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated One Microsoft Way // <>__| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| From: snroettg@faui09.informatik.uni-erlangen.de (Stefan Roettger) Subject: Re: King of the Hill solutions (?) Message-ID: <1992Apr27.125455.5170@informatik.uni-erlangen.de> Date: Mon, 27 Apr 1992 12:54:55 GMT t-jcisek@microsoft.com (Julius Cisek) writes: >In article <1992Apr26.233224.26787@midway.uchicago.edu> kwhyte@arthur.uchicago.edu (Kevin Whyte) writes: >>In article <1992Apr26.194211.29423@microsoft.com> t-jcisek@microsoft.com (Julius CISEK) writes: >>>Instead of re-running the same battles every time a new challenger >>>appears, how about saving the results in a database, and only playing >>>the new battles (the ones against the challenger). Instead of 50 >>>battles, make it 1000 battles. This would still only total to 20,500 >>>battles (against the hill, and against yourself). Once you know how >>>one program does against another (a number like 1000 would insure >>>fairness), you could just keep that in a database. Only one challenger >>>comes up at a time, so only the NEW battles need to be actually played. >> >> It is my understanding that this is how it is done already. >>I would be VERY impressed if Bill's machine were fast enough to >>be doing it the other way. >> >>Kevin >>kwhyte@math.uchicago.edu >Unfortunately, you ARE correct. As Stefan Strack pointed out to me in >an e-mail message (thanks for the quick reply, Stefan), battles between >warriors already on the hill are remembered, not replayed. Now I see >how Charon v2.0 could jump from 12th to 2nd after a resubmission (And I >thought I had stumbled across something while experimenting with >step values...) Could you please give some more precise information? >To resolve 20,500 battles, matches would have to be resolved at the >rate of 3 per second (on the average) if we wanted results in 2 hrs. >That seems an unlikely thing, especially considering that ties take >the full 80,000 cycles to resolve. >However, I have a feeling that a really smart and efficient corewar >simulator could be written where such a number could be approached. >It would have to be all machine code. Absolute addressing should >replace relative in every case possible (I think MOV is the only >instruction where relative addressing is necessary). A really smart >analyses might be able to reveal ties without having to run through >the 80,000 cycles, etc. (Oh, no graphics...) In 88 I wrote a redcode simulator that made up to 10000 ips on an 8Mhz Atari ST. I did some precompilation as it is done by some Basic interpreters. So I guess on a Sparc or similar System it must be possible to perform with more than 200000 ips. That would be quite enough to fight more than four or five battles per second in the averge. 20000 battles would therefore take about 2 hours. In the worst case of course. By the way it is not possible to determine if a game goes tie or not without running the full 80000 cycles. This is related to the busy beaver problem. If you could develope such an algorithm you will probably win the nobel prize if there were a nobel prize for informatics. (Nobels wife ran away with an "Informatiker" :-) >I won't just speculate, either. It's a pretty interesting project and >I'm willing to spend some time on it. If anyone has any other suggestions >on speeding up execution, please let me know. >By the way, I thought that maybe Bill Shubert had access to something >REALLY, REALLY fast and secret (he DOES work at Intel, doesn't he??? :) >-- >Julius Andrew Cisek ,_, >t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated >One Microsoft Way // <>__| /- O O idiot!" >Redmond, WA 98052 \X/ | U| \| -- Stefan Roettger Student of Computer Science snroettg@cip.informatik.uni-erlangen.de Xerox your live! If you lose one it's better to have a copy! From: stephen@estragon.uchicago.edu (Stephen P Spackman) Subject: Re: King of the Hill solutions (?) Message-ID: Date: Mon, 27 Apr 1992 16:35:42 GMT yA programme with this kind of performance would be very easy to write in C; I've been considering doing it as a design tool. All you need is to write a function for every combination of opcode and addressing modes (this is < 256 of them, and you can use macros to pull the coding effort down to near zero). Then represent a memory cell by a structure consisting of a pointer to the right function and the two operands. Bingo. Each function will be much less than 100 native instructions, so if you can raise 10 native MIPS that's significantly more than 10 redcode MIPS or a workstation or 1 on a cruddy PC. Better than a game a second, at any rate, if not quite 8 (but then, there must be more than one CPU on your local network :-). (The crucial point is that there is no instruction to change an addressing mode: it is PART OF the instruction, surface syntax be damned.) I thought this was what you were doing, and you were being slow because you replayed all the games! ( :-). ---------------------------------------------------------------------- stephen p spackman Center for Information and Language Studies stephen@estragon.uchicago.edu University of Chicago ---------------------------------------------------------------------- From: wms@iwarp.intel.com (William Shubert) Subject: Re: King of the Hill solutions (?) Message-ID: <1992Apr27.165912.3220@iWarp.intel.com> Date: Mon, 27 Apr 1992 16:59:12 GMT OK, as has been posted, KotH DOES keep around it's old scores. For speed, I am not willing to recode in assembly. Why? Because it reduces portability. Lots. After all, when I just switched from a Sun 3 to a Sparc I got a 10x speedup; if I had coded in assembly, I would have had to recode. Yuck. HLLs are there for a reason. (Don't get me wrong; I love assembly programming - that's why I like Corewar. But not for projects this size). I from time to time make adjustments in corewar that give speedups, but you can only get so much performance out of a given machine without going to assembly code. J Cisek posted: >By the way, I thought that maybe Bill Shubert had access to something >REALLY, REALLY fast and secret (he DOES work at Intel, doesn't he??? :) Well, in fact, I work in the supercomputer project here, so yes I do have access to very fast machines...I believe our press releases rate one machine that's sitting in the lab at 1280 MFLOPS peak (that's about 50x the speed of my new Sparc workstation). I'd like to use this machine, but there is one really really big problem: reliability. When somebody else wanted to use this machine for real work (We do work here, you know) I might lose it for days at a time...I suppose that I could run on the iWarp when it's available, then switch to my Sparc when it's not, but somehow I don't think the company would approve. -Bill (wms@iwarp.intel.com) From: nicholso@pioneer.arc.nasa.gov (Melvin H. Nicholson YBH) Subject: Gee, this is all quite incoherent Message-ID: <1992Apr27.183024.24169@riacs.edu> Date: 27 Apr 92 18:30:24 GMT Now that this is a newsgroup and not a mailing list, you have a whole large bunch of new readers (like me) who have no idea what the King of the Hill contest is, how to enter, or what assumptions about the nature of redcode are made in creating it. Someone please be kind enough to put the relevant details out for all the potential new contestants. I am especially interested in a list of commands and address modes and syntax for indicating them... Any assmebler goodies should be mentioned as well. Thanks. Mel From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Subject: Intel, Microsoft, and Core War Message-ID: <167D6115D4.DURHAM@ricevm1.rice.edu> Date: Tue, 28 Apr 1992 00:45:16 GMT We really don't need to run Core War on Intel's supercomputer. What we need is Intel to come out with an ICWS'88 MARS-on-a-chip! They used to make an '88 something, didn't they? Does someone have a complete list of major companies Core War has infiltrated? Right now the ICWS Director works for Microsoft (more on/from our new Director soon) and KotH runs at Intel. I have exchanged communications with people working for UniSys and DEC interested in Core War. How many others out there? Mark A. Durham MAD From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: King of the Hill solutions (?) Message-ID: <58114@cup.portal.com> Date: Tue, 28 Apr 92 01:02:01 PDT snroettg@cip.informatik.uni-erlangen.de writes: . . . >By the way it is not possible to determine if a game goes tie or not >without running the full 80000 cycles. This is related to the >busy beaver problem. If you could develope such an algorithm >you will probably win the nobel prize if there were a nobel >prize for informatics. (Nobels wife ran away with an "Informatiker" :-) . . . Well, sort of. Yes the halting problem does prevent you from being able to tell if a program is not going to stop in _all_ cases, but there are some cases which can be tested for which might improve the speed of a tie. (I suspect the noble prize comity wouldn't even give me an honorable mention for them.) For example, one could keep count of the number of remaining DAT instructions. Since there is no longer any way to create a DAT instruction, if the number of DAT's becomes 0, no more process will die (This happens frequently on the X-hill, where IMP's are common). There are other things one could check for, but I suspect even the DAT check would add more time to the battles which did NOT end in tie, than it would save in those that do (even on the X-hill.) On the subject of speed, one of my REDCODE simulaters uses logical ANDs to do modulo arthimetic, has 96 routines (one for every legal instruction/A-mode/b-mode field) and keeps the A-field B-field and opcode_n_mode fields in seperate arrays (to speed pointer arthimetic.) It only runs 2-3 times as fast as my other, more general REDCODE simulator (about 20,000 ips on a 25Mhtz, no cache IBM-clone) it's was 96 times as hard to debug, and it will be 96 times as hard to change if a new standard is adopted. |+-----------------------------------------------------------------+| In my youth I realized that teachers didn't want the right answers, they wanted their answers. <<>> From: kdmiller@athena.mit.edu (Kenneth D Miller) Subject: Re: King of the Hill solutions (?) Message-ID: <1992Apr28.014903.14105@athena.mit.edu> Date: 28 Apr 92 01:49:03 GMT Here's one random though to improve speed. You might be doing this already, but I wouldn't know. 1. Keep an allocated block of memory just big enough to hold the playfield i.e. something like (Number of Spaces) x (bytes per space) 2. When you want to access a space in "relative" mode, just add the offset (which will be a positive number after assembly, right?) to the current program counter, then modulo the result by the playfield size. 3. If the playfield size is an integer power of 2, and the space size is also an integer power of 2, then you can simply use a Logical AND instead of modulo. EXAMPLE: Playfield size = 4096 = 0x1000 Bytes per Space = 4 = 0x0004 this assumes that the byte structure will be something like 1 byte for the instruction itself, and then 12 bits for each operand field. This yields 32 bits, or 4 bytes. Extracting these values is not that hard. Side note: the permutations of operand types ( val #val @val >val) are assumed to be part of the instruction, as there are only 4 possibilities. Anyhow, then the modulo would be an AND 0x3FFF, which is really easy for most CPU's to calculate. This may be limiting, but it should work. If necessary, the Instruction part could be 2 bytes, and each Operand field could be 3, for a total of 8 bytes. I can't think of anything faster. Once you have a pointer to the beginning of the playfield space, manipulating locations relative to this pointer is fairly easy, something like *(playfieldptr + memoryloc) OK, that's enough for now. Tell me if it helps... -- kdmiller@athena.mit.edu | Kenny Miller, sole member of Digital Horizons USA /// | UPCOMING COOL STUFF: KMUS music format, BrotBusters \\\/// Amiga Makes | Demo, Scrolly Roller Demo, Columns, Psycho Ball, \XX/ It Possible! | AmigAtaxx, etc. (don't hold your breath ;^) Date: Tuesday, 28 Apr 1992 04:33:54 EDT From: Message-ID: <92119.043354JJJ101@psuvm.psu.edu> Subject: Re: King of the Hill solutions (?) In article <58114@cup.portal.com>, ScottNelson@cup.portal.com (Scott - Nelson) says: > >snroettg@cip.informatik.uni-erlangen.de writes: >. . . >>By the way it is not possible to determine if a game goes tie or not >>without running the full 80000 cycles. This is related to the >>busy beaver problem. If you could develope such an algorithm Wrong I'm afraid. With an infinite amount of cycles you can still detect ties 100% of the time. (Though not practically.) After each cycle, remember what the core and process queues look like. If the programs are going to tie, then there will be a repeat. ... >give me an honorable mention for them.) For example, one could keep >count of the number of remaining DAT instructions. Since there is >no longer any way to create a DAT instruction, if the number of >DAT's becomes 0, no more process will die (This happens frequently on >the X-hill, where IMP's are common). There are other things one >could check for, but I suspect even the DAT check would add more >time to the battles which did NOT end in tie, than it would save in >those that do (even on the X-hill.) I also thought that an instruction like SUB FOO,FOO would create DAT #0,#0 at address FOO. Anybody know? James From: snroettg@faui09.informatik.uni-erlangen.de (Stefan Roettger) Subject: Re: King of the Hill solutions (?) Message-ID: <1992Apr28.074911.11217@informatik.uni-erlangen.de> Date: Tue, 28 Apr 1992 07:49:11 GMT stephen@estragon.uchicago.edu (Stephen P Spackman) writes: >yA programme with this kind of performance would be very easy to write >in C; I've been considering doing it as a design tool. All you need is >to write a function for every combination of opcode and addressing >modes (this is < 256 of them, and you can use macros to pull the >coding effort down to near zero). Then represent a memory cell by a >structure consisting of a pointer to the right function and the two >operands. Bingo. Each function will be much less than 100 native >instructions, so if you can raise 10 native MIPS that's significantly >more than 10 redcode MIPS or a workstation or 1 on a cruddy PC. Better >than a game a second, at any rate, if not quite 8 (but then, there >must be more than one CPU on your local network :-). >(The crucial point is that there is no instruction to change an >addressing mode: it is PART OF the instruction, surface syntax be >damned.) >I thought this was what you were doing, and you were being slow >because you replayed all the games! ( :-). Yea! You got it. That was exactly what I was doing! -- Stefan Roettger Student of Computer Science snroettg@cip.informatik.uni-erlangen.de Xerox your life! If you lose one it's better to have a copy! From: snroettg@faui09.informatik.uni-erlangen.de (Stefan Roettger) Subject: Re: King of the Hill solutions (?) Message-ID: <1992Apr28.123535.18628@informatik.uni-erlangen.de> Date: Tue, 28 Apr 1992 12:35:35 GMT writes: >In article <58114@cup.portal.com>, ScottNelson@cup.portal.com (Scott - Nelson) >says: >> >>snroettg@cip.informatik.uni-erlangen.de writes: >>. . . >>>By the way it is not possible to determine if a game goes tie or not >>>without running the full 80000 cycles. This is related to the >>>busy beaver problem. If you could develope such an algorithm >Wrong I'm afraid. With an infinite amount of cycles >you can still detect ties 100% of the time. >(Though not practically.) After each cycle, remember what >the core and process queues look like. If the programs are >going to tie, then there will be a repeat. No, you were wrong! The subject was to determine if a game ties without running all 80000 cycles, not with an infinite amount of time. BTW you don't even need infinite time. After 8000^8000 cycles all games will end in a loop. This is of course a fairly long time. Longer than the univers will last I guess :-) Steff -- Stefan Roettger Student of Computer Science snroettg@cip.informatik.uni-erlangen.de Xerox your life! If you lose one it's better to have a copy! Date: Tuesday, 28 Apr 1992 14:17:09 EDT From: Jeff Raven Message-ID: <92119.141709JAR129@psuvm.psu.edu> Subject: Nevermore 3.2 For those of you out there who could use another warrior to test against, here's Nevermore 3.2. It's a fairly simple B-field scanner, but it does OK against most competition (although it gets massacred by dwarves). The only thing distinctive about it is the bombing mechanism, which alternates between DAT and SPL bombs. I'm not sure that the alternating is particulary useful, but without it the original algorithm looked entirely too much like XTC. (Incidentally, if anyone's got any recommendations for improvements, I'd like to hear them ;) ------CUT HERE------ ;redcode verbose ;name Nevermore 3.2 ;author Jeff Raven ; ;strategy - Version 3.2 ;strategy - Scans the core, looking for a non-zero B-field, and then ;strategy - proceeds to bomb the memory around the suspicious address. ;strategy - As for how it bombs .......... the algorithm has finally ;strategy - been fixed, and hopefully it should tie a lot less now. ; basis EQU 4 ; Basic step size for the search step EQU 3044 ; Step size for the search delta EQU (point - alpha) ; Constant used in the bomb exchange double EQU (2 * delta) ; Constant used in the bomb exchange offset EQU basis ; Distance ahead of target to start bombing correct EQU (basis - 1) ; Corrective value used after bombing times EQU (2 * basis - 1) ; Number of bombs to place start ADD #step, target target JMZ start, counter ADD @point, point SUB #delta, point ADD #offset, target counter MOV #times, counter kill MOV @point, Date: Tue, 28 Apr 1992 20:27:37 GMT In article <92119.043354JJJ101@psuvm.psu.edu> writes: >I also thought that an instruction like SUB FOO,FOO would >create DAT #0,#0 at address FOO. Anybody know? I know. On the subject of speed, I would like to request that people be more careful throwing "instructions per second" around. I realize that most are just giving "order of magnitude" estimates, but I have an interest in more specific and reproducible figures. We do not really have any established benchmarks, but some common warriors should serve us well. How about listing IMPs per second? Maybe Dwarf-loops per second? Mice instructions per second? A JMP 0 may not take as long as an IMP's MOV 0, 1. Perhaps a SPL 0/JMP -1 combination takes longer (per instruction on average). Anyway, I have an interest in accurate benchmarks and reviews of Core War systems. How about posting some real numbers and comparative reviews of comparable systems? Mark A. Durham MAD P.S. SUB FOO, FOO zeroes both fields of the instruction at FOO but does not alter the opcode or the modes. From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: More code: Agony 2.1 Message-ID: <1992Apr29.002402.29361@vuse.vanderbilt.edu> Date: Wed, 29 Apr 1992 00:24:02 GMT In article <92119.141709JAR129@psuvm.psu.edu> JAR129@psuvm.psu.edu (Jeff Raven) writes: >For those of you out there who could use another warrior to test against, >here's Nevermore 3.2. [..] Keep it up, Jeff! Another Core Warrior for your collection: Agony 2.1 is a scanner that bombs with a SPL-carpet, just like XTC or Jeff's Nevermore. For thoroughness and greater speed (2 scans/3 instruction loop) it uses a CMP-scan engine. Agony doesn't switch bombs to kill, but clears the core when scanning is complete. It was briefly #1 and is now somewhere in the middle of the hill. Enjoy, Stefan (stst@vuse.vanderbilt.edu) ;redcode verbose ;name Agony 2.1 ;author Stefan Strack ;strategy Small-interval CMP scanner that bombs with a SPL 0 carpet. ;strategy 2.0: smaller ;strategy 2.1: larger, but should tie less; changed scan constants ;strategy Submitted: @date@ CDIST EQU 23 ; distance between addresses CoMPared IVAL EQU 994 ; scan increment (mod-2 pattern) scan ADD incr, comp ; CMP scan loop: comp CMP 0, CDIST ; SLT #incr-comp+CDIST+(bptr-comp)+1,comp ; don't bomb self JMP scan ; MOV #CDIST+(bptr-comp)+1,count ; init bomb-loop w/ # of bombs MOV comp, bptr ; use "comp" as bomb-pointer bptr DAT #0 ; this will be "comp" when exec split MOV bomb, Date: 30 Apr 92 06:19:47 GMT Hi there, Here's another fellow you can try out against. I've submitted it twice to the hill and it made it on there only briefly. It's like dwarf optima except where the bomb would've gone is a dwarf that sweeps the core. Seems to be effective against single process bombers, but because it's multi-process, quite vulnerable to trappers, which seems to be a dominant force on the hill! -- Vince --------------------------------------- vli@mprgate.mpr.ca |-) It works well under pressure: Another thing |-] you can say about your pillow. -- Mr Boffo -------------------------------------------------------------------------------- ;redcode verbose ;name multidwarf ;author Vincent Li (vli@atom.mpr.ca) ;strategy many dwarfs working together ;strategy credits to Nandor Sieban for insights ; start mov ptr, Date: Thu, 30 Apr 92 07:17:06 GMT I have two ST Core Wars programs, one by F.Wade, and one by Dan something or other... The one by Dan seems to me pretty close to ICWS'88 compatiblem but it doesn't allow all the labels I find in redcode I get from the servers or messages here... Does anyone know of an ST implementation of Corewars that can compile all these recode programs around as-is? Thanks. -- ||| Jonathan Roy (The Ninja) Internet: as666@cleveland.freenet.edu ||| -- BBS: Darkest Realm - (Down for now) - Public UUCP/Usenet -- / | \ "...make him want to change his name,take him to the cleaners, devastate him, wipe him out, humiliate him." -CHESS GEnie: J.ROY18 From: wms@iwarp.intel.com (William Shubert) Subject: Re: Gee, this is all quite incoherent Message-ID: <1992Apr30.152109.2753@iWarp.intel.com> Date: Thu, 30 Apr 1992 15:21:09 GMT nicholso@pioneer.arc.nasa.gov (Melvin H. Nicholson YBH) posted: >Now that this is a newsgroup and not a mailing list, you have a whole >large bunch of new readers (like me) who have no idea what the King of >the Hill contest is, how to enter, or what assumptions about the nature >of redcode are made in creating it. Well, here's the entry instructions. I haven't posted them in a while. They DON'T explain much about the version of redcode used; if you need to know what ICWS '88 redcode looks like, check around. It's pretty simple. ---------------------------------------------------------------------- Entry rules for King of the Hill "standard" Corewar: 1) Write a corewar program. KotH is fully ICWS '88 compatible, EXCEPT that a comma (",") is required between two arguments. 2) Put the line ";redcode" at the top of your program. This MUST be the first line. Anything before it will be lost. Writing ";redcode verbose" or ";redcode quiet" will alter how much information you get on your program. See part 5) below. Adding ";name " and ";author " will be helpful in the performance reports. Do NOT have a line beginning with ";address" in your code; this will confuse the mail demon and you won't get mail back. In addition, it would be nice if you have lines beginning with ";strategy" that describe the algorithm you use. 3) Mail this file to "wms@iwarp.intel.com". 4) Within a few minutes you should get mail back telling you whether your program compiled correctly or not. If it did compile correctly, sit back and wait; if not, make the change required and re-submit. 5) In a hour or so you should get more mail telling you how your program performed against the current top 20 programs. If no news arrives in an hour, don't worry; entries are put in a queue and run through the tournament one at a time. A backlog may develop. Be patient. If your program makes it onto the hill, you will get mail every time a new program makes it onto the hill. If this is too much mail, you can use ";redcode quiet" when you first mail in your program; then you will only get mail when you make it on the top 20 list or when you are knocked off. Using ";redcode verbose" will give you even more mail; here you get mail every time a new challenger arrives, even if they don't make it onto the top 20 list. Often programmers want to try out slight variations in their programs. If you already have a program named "Foo V1.0" on the hill, adding the line ";kill foo" to a new program will automatically bump foo 1.0 off the hill. Just ";kill" will remove all of your programs when you submit the new one. That's it! MORE ON KOTH COREWAR IMPLEMENTATION Core size: 8,000 instructions Max processes: 8,000 per program Duration: After 80,000 cycles per program a tie is declared. SAMPLE ENTRY: ;redcode verbose ;name Dwarf ;author A. K. Dewdney ;strategy Throw DAT bombs around memory, hitting every 4th memory cell. ;strategy This program was presented in the first Corewar article. bomb dat #0 dwarf add #4,bomb mov bomb,@bomb jmp dwarf end dwarf Rule variants for "eXperimental" corewar: The same as above but use ";redcode-x" to start your program. Your program will be entered into a second tournament with slightly different rules. The rules are: - All addressing modes are allowed with all instructions. - There is an additional addressing mode, called "postincrement". To use it try an instruction like "mov >5,6". - The maximum write distance is 250 instructions. That is, every time your program tries to modify memory, the address is checked; if it is more than 250 instructions from the process doing the modify, then memory is left unchanged, but the instruction continues as normal. KotH is run on a Unix system. The source code to the corewar program used is freely available; it runs on any Unix system with an X windows interface. Send mail to wms@iwarp.intel.com for a copy. From: t-jcisek@microsoft.com (Julius Cisek) Subject: Down with PitTrap - ICWS'88 too simple? Message-ID: <1992Apr30.190647.21754@microsoft.com> Date: 30 Apr 92 19:06:47 GMT As some of you may know, I removed PitTrap v2.3a from the King of the Hill tournament. I do this because I found that PitTrap was almost identical to scissors88, a warrior written by Scott Nelson long before I even knew about corewar. I didn't write PitTrap using Scott's code; it was a completely original program, but this is the problem with ICWS'88. There is just not enough variety to facilitate truly original programs. Just the fact the step values can play such a crucial role in the success of a program (Dwarf-12b, also by Scott Nelson survived for over 100 successful challenges before parting) shows you that we need a new standard. The only TRULY original program I've seen since I started playing KotH is Synch by Andy Pierce (a really brilliant idea) and there have been hybrids (not nearly as successful) since. For now, my suggestion is to follow Andy's, Scott's, and Stefan's suit and start posting the source to your programs. Here is PitTrap v2.3a (with "decoys" removed for sake of length): ;redcode verbose ;name PitTrap v2.3a ;author J.Cisek ;strategy creation date 4/6/92 ;strategy steal processes into slave pit ;strategy slave pit is a simple bomber that kills itself ;strategy v1.1 4/7/92 doesn't trap itself... ;strategy v2.0 4/8/92 smaller code/quicker search ;strategy v2.1 4/13/92 better slave pit ;strategy v2.2a 4/22/92 better step value ;strategy v2.3 4/24/92 decoys [v2.3a optimal step] INSTALL equ 3000 STEP equ 3044 init mov trap, INSTALL mov intval, INSTALL mov bomb, INSTALL here mov search, INSTALL+1 mov search+1, INSTALL+1 mov search+2, INSTALL+1 mov pit, INSTALL+2 mov pit+1, INSTALL+2 mov pit+2, INSTALL+2 jmp INSTALL+here+1 trap jmp pit+1, #-1 intval dat #STEP, #-STEP bomb dat #trap dat #42 search add intval, trap mov trap, @trap jmp search, #0 dat #42 pit mov bomb, __| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| From: t-jcisek@microsoft.com (Julius Cisek) Subject: Charon v2.0 Message-ID: <1992Apr30.192529.22277@microsoft.com> Date: 30 Apr 92 19:25:29 GMT By the way, PitTrap survived 129 successful challenges through its many versions. Here is Charon v2.0 which has been in the top 10 of the Hill for several days, even reaching 1st a couple of times. Charon scans with a distance of 1/2 core (this doesn't work against programs that mirror themselves, but there doesn't seem to be too many of those). When it finds code, it bombs it with a SPL 0, JMP -1 combination which effectively shuts the enemy down. He counts down during his search and starts a clear core routine when the counter is down to zero: ;redcode verbose ;name Charon v2.0 ;author J.Cisek ;strategy creation date 4/11/92 ;strategy cmp scan, spl trap, clear core, etc. ;strategy v1.1 4/14/92 improved trap [reversed in v1.3] ;strategy v1.2 4/16/92 improved clear core routine ;strategy v1.3 4/21/92 original trap, optimal step, smaller code ;strategy v2.0 4/22/92 total code overhaul ;strategy mod 3 cmp scan with optimal step, new deadly trap START equ 1581 STEP equ 1581 HALF equ 4000 COUNT equ 1333 target cmp START, START+HALF ;this must be first for SLT to work counter jmp gotem, #COUNT ;also used as counter search add steps, target ;start new search here djn target, counter ;countdown to clear clear mov bomb, __| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| From: t-jcisek@microsoft.com (Julius Cisek) Subject: Crimson v1.1 - KotH-x Message-ID: <1992Apr30.193210.22517@microsoft.com> Date: 30 Apr 92 19:32:10 GMT Here is my first program specifically designed for the current KotH experimental hill. It's a very simple but quite effective program which borrows the trap from my Charon v2.0 program on the regular hill. It copies itself backwards in core after bombing backwards with SPL 0, JMP -1. As it moves it counts down and eventually turns it's own trap into a DAT statement. From now on when it moves, it kills. Crimson v1.1 hovers between 3rd and 5th (if hovers is the right word for KotH-x with its myriad of submissions... :) ;redcode-x verbose ;name Crimson v1.1 ;author J.Cisek ;strategy creation date 4/26/92 ;strategy This is my first program designed specifically ;strategy for the KotH experimental hill. ;strategy Bombs the local area, then jumps to the next area. ;strategy Traps the first time through core, clears the second. ;strategy v1.1 4/29/92 Doesn't leave back uncovered anymore. STEP equ -150 ; new copy offset TRAPS equ 1 ; space between traps NTRAPS equ 64 ; number of traps [STEP+50 / (TRAPS+2)] JUMPS equ 50 ; number of times we trap length dat #0, #0 ; program data split spl 0, #0 jump jmp split, #0 start mov #NTRAPS, jump ; use jump to store this counter attack mov jump, __| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| From: t-jcisek@microsoft.com (Julius Cisek) Subject: ProtonDance Message-ID: <1992Apr30.194501.23261@microsoft.com> Date: 30 Apr 92 19:45:01 GMT Here's a really nifty little program, ProtonDance-X (the X is NOT for the experimental hill, I didn't know about it when I named this program...). It uses a really nifty trick (also used by my Tiny and Gnats programs) of decrementing a value using the B-operand of an instruction that doesn't even use the B-operand. Since operands are evaluated the same way no matter what the instruction, this: JMP label, __| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| From: t-jcisek@microsoft.com (Julius Cisek) Subject: Tiny and Gnats Message-ID: <1992Apr30.195809.23677@microsoft.com> Date: 30 Apr 92 19:58:09 GMT ProtonDance-X prompted the development of Tiny and Gnats which were short time visitors on the hill. Tiny is like Andy Pierce's Small, in a demented kind of way. Tiny v1.2 made it to the hill, hit a high of 19th, and was knocked off at the age of 4. Gnats made it as high as 5th once (yes really) and had a total age (versions Gnasty and Gnastier included) of 20. Lets knock off gnats first. Here's what a Gnat looks like: ;redcode verbose ;author J.Cisek ;date 4/16/92 gnat mov -1, <-2 jmp gnat, <-3 Of course, this isn't good enough, so the versions I submitted spread 8-32 of these things through the core. Not very exciting, but they did pretty well against some programs. Finally, here's Tiny v1.2 (with decoys removed). His biggest advantage is that he doesn't have any piece of code that's longer than a dwarf. Also, the pieces are strewn 60 places away. What this does is assures that if a program that scans by either mod 3, mod 4, or mod 5 misses one piece, it'll miss 'em all (Tiny needs time to do his work...) ;redcode verbose ;name Tiny v1.2 ;author J.Cisek ;strategy creation date 4/19/92 ;strategy very small spl 0 bomber/clearer with decoys ;strategy v1.1 4/20/92 better location ;strategy v1.2 4/21/92 bombs with spl -1 start mov trap, 3000 mov slow-1, 3119 mov slow, 3119 mov slow+1, 3119 spl 3117, #42 mov clear, 3055 mov clear+1, 3055 dat #42 trap spl -1, #42 clear mov -2, <-2 jmp clear, #0 jmp -60, #0 slow mov -121, <-122 ; gets hit here with a SPL -1 jmp slow, <-123 dat #42 ;Here's where your decoys go. Go crazy! end start ;kill Tiny -- Julius Andrew Cisek ,_, t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated One Microsoft Way // <>__| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| From: t-jcisek@microsoft.com (Julius Cisek) Subject: Incentive Message-ID: <1992Apr30.210946.25787@microsoft.com> Date: 30 Apr 92 21:09:46 GMT Man, I hate it when things get posted in the wrong order. The ProtonDance post was made BEFORE the Tiny and Gnats post. This should clear up any weirdness. Anyways... Here's some incentive for you people who are still iffy on the idea of posting your code (yes, I know, and I too was afraid that by showing off some wonderful trick I would condemn my own programs to being overrun by programs that use my tricks better than I! However, let's face it: there are very few new tricks that haven't been done before with the ICWS'88 standard the way it is). Think of it this way: When a corewar tournament arrives (are there plans for an ICWS'92 tournie) it's quite unlikely that virtually identical programs will be allowed to compete (at least I hope not, since a really good program that happens to do poorly against the identical programs will be unfairly judged). However, if you post your code to this newsgroup, you can be sure which programs are identical and do away with the problem before it starts. No flames now! No one is forcing you to post. In many ways CoreWar is like a real war. No military is going to display their secret weapons in fear that it can be used against them. Therefore let me be redundant and say that it's quite unlikely that something you've done hasn't already been done in the past. My PitTrap is an obvious example. Charon, by the way, uses the SPL 0, JMP -1 bomb which appeared in CatCan (my appologies to the author who's name I forgot) in the ICWS'90 tournament. No, I didn't know that it used it (a friend pointed this out), but that nevertheless changes the fact that it WAS used before. Of course the rest of Charon is nothing LIKE CatCan. The only fair way for a tournament judge to resolve the problem of identical warriors is by which program was written first. I know this stinks for those who come up with programs on their own that already have an identical "alter-ego" in existance, but it really is the only fair way. (PitTrap is, again, a good example) So, the incentive is that by posting your programs here, you are in a way copyrighting your code (please don't pick at my choice of words...). Blah blah blah... I'd really like to hear what you guys have to say about all this. Post or send mail. By the way, I am hard at work on that corewar simulator, and the initial results are excellent. Right now the simulator supports MOV, JMP, SPL, and DAT (yes, we got an imp running through core) and has no real loader (programs are hard coded into the C code). No assembly is being used, just tons of optimization tricks. Anyway, when I'll post an update when more is ready (I have to get some sleep!) -- Julius Andrew Cisek ,_, t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated One Microsoft Way // <>__| /- O O idiot!" Redmond, WA 98052 \X/ | U| \|