From: rrognlie@netcom.com (Richard Rognlie) Subject: PBM Server looking for a home Message-ID: Date: Wed, 1 Jun 1994 15:20:38 GMT Greetings! I have been developing a generic PBeM Server on a host that has no net access. I have access to the net via NETCOM.COM, but have been having difficulty getting them to setup an method of getting mail to the server (without it clogging my own mail box). I do not wish to spend an additional $xx/month to pay for a second shell account. Therefore, I am looking for some soul (or souls) who might be willing to allow me a shell account on their system to act as the home of this server. My requirements on the target system are: A shell account for the PBeM Server Access to a C compiler That's it. Any mail received by the Server will be processed by its .forward. I would rlogin to the system to perform maintenance and/or ftp files to it from here. So far, I have implemented some administrative functions, and a Trax server (similar to munch@soda.berkeley.edu), however, I play to implement a number of other games in the near future as time allows including, but not limited to: Abalone - hexagon board with marbles. push your opponent off the board Ataxx - take over territory by growing/jumping about the board, and flipping any adjacent pieces to your color. GNU-Robots - King of the Hill tournament (ala Corewar) in which robots are programmed in GNU-C/C++ and placed in an arena to fight it out. Twixt - connect your side of the board with preventing your opponent from doing same. Terrace - StarTrek: the Next Generation (10-forward) game. It is still in it's infancy, so I am open to suggestions... Richard Rognlie -- /\/\/\ | Richard Rognlie / Sr. Computer Analyst / PRC Inc. / McLean, VA / \ \ \ | E-Mail: rrognlie@netcom.com *or* rognlie_richard@prc.com \ / / / | Phone: (Home) (703) 361-4764 (Office) (703) 556-2458 \/\/\/ | (Fax) (703) 556-1174 From: jjfloyd@vela.acs.oakland.edu (Jered Floyd) Subject: Re: One Pass Core Clear Date: 1 Jun 1994 19:38:58 GMT Message-ID: <2sio4i$huc@oak.oakland.edu> You don't have an END label statement, so the first line executed by your program is the DAT #0. That kills it rather uncerimoniously. -- Jered Floyd jjfloyd@vela.acs.oakland.edu Geek Code: GAT d? -p+ c++++ l+ u++ e*@ m++ s/-- n--- h++ f? g- w++ t+++ r++ PGP Public key, Geek Code, picture, and assorted humor available by finger. From: timin@netcom.com (Mitchell E. Timin) Subject: Software Competition Announcement Message-ID: Date: Sat, 4 Jun 1994 18:41:58 GMT Software Competition for "Traveling Salesman" Programs Announcing a competition for the best computer programs that find solutions to the Traveling Salesman Problem (TSP). Programs will be judged both on execution speed and on the quality of their solutions. Problem Description: There are N points, plus a starting point, plus an ending point. The N points are identified as 0, 1, 2, 3,.... N-1. A "route" is any permutation of these N point numbers. A cost function exists such that the cost to move from the starting point to any of the N points, or between any of the N points, or from any point to the ending point, is known. Each route has an associated total cost, which is the sum of the N+1 costs to move to each point. (Starting point to first point on route, first to second point, etc., and finally last point on route to ending point.) Also, the point-to-point cost has two values, depending on the direction of travel. The problem is to find a route such that the total cost is not far from a global minimum, and to do so as fast (minimum computer execution time) as possible. Program Requirements: Programs must run on typical IBM PC compatibles, under DOS or Windows. Programs must be supplied as a .exe file, ready to execute. They must be able to handle up to 140 points, plus the start and stop points. Each program must begin by waiting for some keyboard input prior to reading the input file (described below). Timing, with a stopwatch, will begin when the keyboard input is satisfied and the program begins to read the input file. The program must announce, by a tone, that it has found a solution, and immediately output the solution to a file, as well as show it on the screen. The solution consists of the total cost, plus the route followed. Here is a sample output, for N = 12, corresponding to the sample input given below: ---------------------------------------------------------------------- A good route is: 4 1 7 0 10 6 8 11 5 3 9 2 The total cost is: 6696 ---------------------------------------------------------------------- Programs must read an ASCII text input file containing a problem definition. The problem is defined by giving all of the individual point-to-point costs. This file will have a value for N, the number of points, on the first line. The second line will have all of the cost values to move from the starting point to each of the N points. The third line will have all costs to go from each point to the ending point. The following lines will have all of the other costs given as an N X N matrix. The number in row i and column j of this matrix is the cost to move directly from point i to point j. (i and j both range from 0 to N-1.) Note that the diagnol elements are zero, since the routes don't specify moving from a point to itself. All costs will be positive integers < 10,000. Here is a sample input file for N = 12: ---------------------------------------------------------------------- 12 1079 583 890 1235 223 2255 1412 955 1787 1111 1222 1459 1915 1450 167 1034 1036 2234 2110 1731 2363 984 2110 1947 0 556 1887 1835 857 2255 649 308 1136 1683 237 1098 550 0 1461 1627 383 2372 1074 574 1534 1481 755 1339 1901 1456 0 824 1077 2127 2014 1675 2242 809 1968 1812 1800 1630 844 0 1298 1309 1682 1543 1737 151 1814 1284 844 390 1100 1350 0 2201 1210 739 1607 1161 1000 1312 2209 2350 2133 1321 2187 0 1730 1964 1414 1322 2097 1178 638 1043 2101 1697 1225 1731 0 501 487 1542 424 558 (5 more lines not shown) ---------------------------------------------------------------------- Problem Details: Please note that the lengths of the lines in the input file may reach several hundreds of characters when N is large. The input file is best read simply as a sequence of integers, and line lengths ignored. Problem cases will not be simple Euclidean distances on the plane. Problem cases will not be pathological nor especially contrived to have peculiar characteristics. Problems will be generated by computer beginning with random points in 2 or 3 dimensional space, computing some cost metric (not Euclidean distance), and then further modifying each cost by adding a function of x and y, plus a random component. Judging: Programs will all be run on the same PC, and with the same setup and software configuration. Each will be run several times using different input files, and also with repeated runs of the same input file. Values of N near 40, and near 100 will be used. The judges will look for a program that consistently finds a solution with total cost within 5% of of the lowest cost found by any program, and that does it faster than the other competitors. However, if program A is only very slightly faster than program B, while program B consistently finds lower cost solutions, then the judges may choose program B over program A. In all cases the decision of the judges will be based on their human judgement, and will be final. There is no claim here that judges will be restricted to purely objective criteria for decision making. In case of difficulty in choosing among competing programs, the judges may decide that two or more programs have a tie or draw in the competition. Prizes: Adept Computer Solutions, publishers of Street Wizard software, has promised to donate $1000 worth of their city and county street mapping programs, as long as there are at least five competitors to share the prizes. Map data will be supplied for the geographical regions of interest to each winner. If there are less than five competitors, then the total donation will be reduced proportionately. The prizes will be distributed according to the merit of the competitors, as judged by the judges. Neither employees of Adept Computer Solutions or Mitchell Timin Software, nor their relatives and close personal friends and associates are eligible to compete in this contest. The names of the winners, and brief biographical information, will be announced in several internet newsgroups. This may include, at the winner's option, a description of the algorithms used. When: Programs will be accepted until Sep. 15, 1994. Testing will be completed prior to October 31, 1994 and the winners announced on or before that date. Programs may be submitted immediately or at any time. Any programs received prior to July 10 will be tested promptly and results will be e-mailed to their authors. How to Enter the competition: Prior to July 10, mail a diskette to: Mitchell Timin 2201 Ardemore Drive Fullerton, CA 92633 In addition to your TSP program, be sure to include your name, address, phone no., and e-mail address. After that date, e-mail to timin@netcom.com requesting the current address. From: jjfloyd@vela.acs.oakland.edu (Jered Floyd) Subject: UPDATE 2: Genetic Algorithm Date: 5 Jun 1994 04:36:53 GMT Message-ID: <2srkp5$qbv@oak.oakland.edu> Me again. :-) I'm happy to announce that the MARS portion of my program is complete! (and I think it works right....) I'm not sure how this compares to others, but my results are: 1 round with the graphical display enabled, with a 80,000 instruction limit takes approximately 3 seconds to run. I expect the time is slightly shorter without the graphical display. I'm very happy with it. I would release this MARS right now, but the input it accepts are specialized load files..I haven't written a complete assembler yet. Load files of of the format: (byte) position of first inst. to be executed (0 for first line) (4 bytes) reserved [The next 5 bytes repeat until out of instructions] (byte) instruction type. 1=DAT, 2=MOV, etc. (write me for list) (word) A field. High 2 bits are address mode, (0=immediate, 1=direct, etc.), other 14 bits are a value from 0 to coresize-1. (word) B field. Same format as A field. Anyways, it was quite educational to write, and I expect to get the genetic part done by the end of June. As soon as I test it a little more, and write some sort of assembler portion, I will release this as a standalone MARS. Jered -- Jered Floyd jjfloyd@vela.acs.oakland.edu Geek Code: GAT d? -p+ c++++ l+ u++ e*@ m++ s/-- n--- h++ f? g- w++ t+++ r++ PGP Public key, Geek Code, picture, and assorted humor available by finger. From: jjfloyd@vela.acs.oakland.edu (Jered Floyd) Subject: REQUEST: Imp vs. Dwarf info Date: 5 Jun 1994 05:35:23 GMT Message-ID: <2sro6r$3bv@oak.oakland.edu> Is this correct? Let's say an imp battles a dwarf. (Source at end of post). Most of time time, the imp with run along the memory and overwrite the dwarf. It kills the dwarf in this way, but the dwarf never executes a DAT, so the MARS calls it a tie! Shouldn't the imp have won? (pmars and wincore call it a tie, as does my program...but should it?) Thanks. ; The classic IMP imp mov imp imp+1 end imp ; the classic DWARF dat #0 start add #5, -1 mov -3, @-2 jmp -2 end start -- Jered Floyd jjfloyd@vela.acs.oakland.edu Geek Code: GAT d? -p+ c++++ l+ u++ e*@ m++ s/-- n--- h++ f? g- w++ t+++ r++ PGP Public key, Geek Code, picture, and assorted humor available by finger. From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: REQUEST: Imp vs. Dwarf info Message-ID: <1994Jun5.070025.25844@news.vanderbilt.edu> Date: Sun, 5 Jun 1994 07:00:25 GMT In article <2sro6r$3bv@oak.oakland.edu> jjfloyd@vela.acs.oakland.edu (Jered Floyd) writes: >Is this correct? Sure. An imp cannot win unless it moves slower than 1 address/cycle (in which case the overrun adversary may "outrun" the imp-stream and die). Winning in corewar means to kill all enemy processes by making them execute DAT (or DIV/MOD by zero in ICWS'94). -Stefan (stst@vuse.vanderbilt.edu) From: connorbd@bcvms.bc.edu Subject: Anybody interested in RISC corewar? Date: 6 Jun 94 12:36:19 EDT Message-ID: <1994Jun6.123619.1@bcvms.bc.edu> Just an idea... Would anybody be interested in a proposal for a RISC version of Redcode? I'll post it here if I get som eapproving email. Brian Connors Boston College From: bdthomse@peruvian.cs.utah.edu (Brant Thomsen) Subject: The '94 Warrior Date: 7 Jun 1994 06:32:41 GMT Message-ID: <2t14a9$211@magus.cs.utah.edu> __ __| | ) _ \ | | \ \ / _) | __ \ _ \ / ( | | | \ \ \ / _` | __| __| | _ \ __| | | | | __/ \__ |___ __| \ \ \ / ( | | | | ( | | _| _| |_|\___| _/ _| \_/\_/ \__,_|_| _| _|\___/ _| June 6, 1994 Issue #8 ______________________________________________________________________________ This newletter covers the current status of the ICWS '94 Draft hills, and also attempts to keep up with the latest ideas in how the new standard will affect corewars in general. I hope you enjoy it! If you are unfamiliar with the '94 draft standard, you can learn more about it by reading the FAQ for this newsgroup. In addition, the program pMARS includes a highly recommended tutorial on the new standard. Feel free to send me e-mail if you have any difficulty finding either of them, if you need to have a corewar item mailed to you, or if you have any other questions. The FAQ is available through anonymous FTP to rtfm.mit.edu, as /pub/usenet/news.answers/games/corewar-faq.Z ______________________________________________________________________________ CHANGES and CORRECTIONS: The latest tournament is over, and Jay Han walked away the winner. Congratulations to Jay on his impressive achievement, and thanks again to Stefan Strack again for running it. Jay Han also appears to have won another on-going battle. His "corestep" program has left the two competing "optima" programs in the dust. You can get the source code for it, or Stefan Strack's varying step version "mopt", by anonymous FTP to soda.berkeley.edu. The pMARS team has been busy as well. The next release will allow the use of a-field indirect addressing, and will introduce the ability to use ";assert" to confirm that your program is running in a core type that it was written for. Be sure to download a copy when it is released. The newsgroup has also had some interesting discussion and results on working with genetic algorithms to create redcode warriors. (Using "genetic" methods to guide the development of "random" programs.) Watch the newsgroup for further details. ______________________________________________________________________________ The ICWS '94 Draft Hill: Core size: 8000 instrucitons Max processes: 8000 per program Duration: After 80,000 cycles, a tie is declared. Max entry length: 100 instructions The current ICWS '94 Draft hill on "Pizza": # %W/ %L/ %T Name Author Score Age 1 49/ 34/ 17 Pyramid v5.5 Michael Constant 163 54 2 48/ 33/ 19 Keystone t33 P.Kline 162 76 3 40/ 29/ 30 Torch t3 P.Kline 151 15 4 43/ 43/ 15 Iron Gate 1.5 Wayne Sheppard 143 253 5 32/ 21/ 47 B-Panama IX Steven Morrell 142 4 6 38/ 35/ 27 Stimpy v2.0 Brant D. Thomsen 142 5 7 30/ 18/ 52 Blue Funk Steven Morrell 142 276 8 31/ 22/ 47 Cannonade P.Kline 140 134 9 32/ 24/ 44 NC 94 Wayne Sheppard 140 289 10 41/ 43/ 16 Aleph 0 Jay Han 140 50 11 43/ 47/ 10 Rave 4.1 Stefan Strack 139 241 12 38/ 38/ 24 Christopher Steven Morrell 139 197 13 38/ 39/ 23 Request v2.0 Brant D. Thomsen 138 307 14 40/ 44/ 16 Dragon Spear c w blue 136 309 15 31/ 28/ 41 Lucky 3 Stefan Strack 134 269 16 29/ 25/ 46 TCh Mintardjo W. 134 6 17 30/ 28/ 42 Aeka T.Hsu 132 2 18 31/ 31/ 38 Der Zweite Blitzkrieg - 9 Mike Nonemacher 132 259 19 33/ 36/ 31 mmfP v2 Karl Lewin 131 7 20 5/ 0/ 0 Pyramid v5.5 Michael Constant 14 1 The above ordering seems to be a good representation of what has been happening on the hill for the last couple of weeks. Michael Constant's "Pyramid" and Paul Kline's "Keystone" have both been fighting for the top position, with "Torch" being the only close competitor. Both "Pyramid" and "Keystone" are excellent examples of complex programs that push the 100 line limit, although they are radically different from each other. Also dramatic are the drop of Mike Nonemacher's "Der Zweite Blitzkrieg" and Michael Constant's "Sauron" (right off the hill), as both were putting up a good fight for the top position only a month ago. Although the hill is fairly old, the new programs seem to be making a big difference. The current ICWS '94 Draft hill on "Stormking": # %W/ %L/ %T Name Author Score Age 1 45/ 29/ 26 Sauron v3.6 Michael Constant 160 1 2 41/ 27/ 32 Killer instinct Anders Ivner 155 24 3 36/ 21/ 43 Twimpede+/8000-d1 Jay Han 150 14 4 44/ 38/ 17 Ntttgtstitd Simon Hovell 150 25 5 43/ 38/ 19 Request v2.0 Brant D. Thomsen 148 17 6 34/ 21/ 44 Lucky 3 Stefan Strack 147 12 7 35/ 23/ 42 NC II Wayne Sheppard 147 79 8 35/ 25/ 40 Sphinx v5.1 W. Mintardjo 145 82 9 43/ 41/ 17 Sylvester v1.0 Brant D. Thomsen 144 61 10 29/ 19/ 53 ttti nandor sieben 139 35 11 32/ 26/ 42 JustTakingALookSee J.Layland 138 78 12 31/ 24/ 45 Snake Wayne Sheppard 138 34 13 43/ 47/ 10 Rave 4.1 Stefan Strack 138 7 14 39/ 40/ 21 tiny J.Layland 138 59 15 29/ 20/ 51 ttti94 nandor sieben 137 30 16 39/ 42/ 19 Beholder's Eye v1.7 W. Mintardjo 137 91 17 38/ 42/ 19 Christopher Steven Morrell 135 23 18 39/ 43/ 18 SJ-4 J.Layland 134 28 19 37/ 43/ 20 Fast Food v2.1 Brant D. Thomsen 131 37 20 35/ 40/ 26 pepper P.Kline 129 6 ______________________________________________________________________________ The ICWS '94 Draft Experimental Hill: Core size: 55,440 instructions Max processes: 10,000 per program Duration: After 500,000 cycles, a tie is declared. Max entry length: 200 instructions The current ICWS '94 Experimental (Big) hill on "Pizza": # %W/ %L/ %T Name Author Score Age 1 49/ 32/ 19 Pyramid v5.3 Michael Constant 166 38 2 49/ 32/ 19 ivscan6b J.Layland 165 11 3 37/ 17/ 46 Aleph 1 Jay Han 158 9 4 46/ 34/ 20 Request-55440 Brant D. Thomsen 157 147 5 44/ 36/ 20 Aleph 0/1 Jay Han 153 3 6 42/ 37/ 21 Vanity IIx Stefan Strack 147 102 7 35/ 24/ 41 Variation G-1 Jay Han 146 111 8 41/ 36/ 24 Stimpy v2.0 Brant D. Thomsen 146 2 9 44/ 45/ 11 Squint Mike Nonemacher 143 85 10 40/ 39/ 20 Aleph 0 Jay Han 142 10 11 44/ 47/ 9 Rave B4.1 Stefan Strack 140 108 12 31/ 24/ 44 Der Zweite Blitzkrieg - 9 Mike Nonemacher 139 109 13 32/ 26/ 42 Splash 1 Jay Han 137 112 14 30/ 24/ 47 NotSoBigImps James Layland 136 7 15 36/ 38/ 26 Lump J.Layland 135 92 16 31/ 29/ 40 Lucky 13 Stefan Strack 133 153 17 40/ 49/ 11 Plasma v5 Wayne Sheppard 132 49 18 28/ 25/ 47 Blue Funk Steven Morrell 131 1 19 27/ 30/ 43 Tail of the Twister Mike Nonemacher 124 57 20 25/ 33/ 43 avp2 J.Layland 117 5 On this hill, just as on the standard hill, Michael Constant's quick-scanning vampire "Pyramid" is a string first-place contender. However, unlike last month, there is a program that is giving him some close competition: "ivscan6b", an updated version of James Layland's notable tournament entry. Jay Han's "Aleph" series, and Brant Thomsen's "Stimpy" are a couple of other new programs that seem to have taken a liking to the Big hill. Perhaps scanners will be the programs that dominate this hill in the future. The current ICWS '94 Experimental (Big) hill on "Stormking": # %W/ %L/ %T Name Author Score Age 1 48/ 12/ 40 Variation M-1 Jay Han 184 2 2 46/ 30/ 24 Request-55440 Brant D. Thomsen 162 54 3 40/ 20/ 40 Lucky 13 Stefan Strack 161 20 4 46/ 36/ 18 Raiden Richard van der Brug 157 3 5 45/ 35/ 19 Vanity IIx Stefan Strack 155 8 6 35/ 18/ 47 Bakers Dozen Wayne Sheppard 153 13 7 40/ 30/ 31 Sauron v2.4 Michael Constant 150 5 8 30/ 15/ 55 Imperfection v2.3 Michael Constant 146 48 9 36/ 31/ 33 Variation D-1 Jay Han 142 15 10 44/ 47/ 10 Rave B4.1 Stefan Strack 141 9 11 42/ 46/ 12 bigproba nandor sieben 138 12 12 41/ 46/ 14 Dagger v7.0 Michael Constant 136 14 13 40/ 48/ 11 The Count Jay Han 132 44 14 27/ 23/ 50 BigImp Alex MacAulay 132 95 15 30/ 29/ 41 jmpWetPaper-94x-a J.M.Pohjalainen 131 1 16 26/ 23/ 51 BigImps James Layland 129 114 17 31/ 35/ 34 Veeble Jr. T. H. Davies 126 16 18 28/ 37/ 34 Industrious Stefan Strack 119 4 19 29/ 40/ 31 Open Arms Stefan Strack 117 7 20 29/ 41/ 30 Test Stefan Strack 116 6 ______________________________________________________________________________ HINTS and HELPS: One of the problems that has been haunting corewar programmers through the years is the differences in behavior caused by in-register and in-memory evaluation of an instruction. Actually, it's usually not the evaluation itself that is the problem -- instead, it is the fact that few corewar programmers know what the difference is between them, or how these differences affect the behavior of programs. I'd like to help clarify this difference, and give some pointers to help you predict what your code will do under each type. If you think about it, you can probably guess exactly what "in-memory" and "in-register" are referring to. With in-memory evaluation, changes to the core are made directly to the memory storing the core. In-register evaluation, on the other hand, copies the current instruction and the instructions it points to into registers, and the information in the registers is then used to update the core. There are advantages to both types of evaluation. In-memory evaluation is much more intuitive. In other words, it is the way that beginners expect redcode programs to operate. In-register evaluation's primary advantage is that it is faster. Most of the '88 compliant corewar emulators, including the one used for the original KotH hill, are in-register. For those of you that are curious, the '94 draft standard explicitly states that in-register evaluation should be used. In fact, much of the reason a new standard is needed is make this clarification. Although most code will function exactly the same under either type of evaluation, there are a growing number of programs where in-register/in-memory conflicts are a very important consideration. One of these programs is Paul Kline's "Torch". For those of you who missed it, here is a copy of the source code: ;redcode-94 quiet ;name Torch ;author P.Kline ;strategy very rapid incendiary bombing, core-clear & gate ;macro step equ 73 count equ 1500 gate dat <-step+1,<-step for 21 dat 0,0 rof sp spl #0,<-step ; spl half of the incendiary in add #step+step,msm ; | msm mov sm,>tgt-(step*count) ; | these 3 execute in reverse order! msp mov sp,@msm ; | tgt djn.f in,>3157 ; gets bombed with spl to start clear clr mov gate,<-13 cp djn.f clr,>3 ; forward decrement while clearing for 32 dat 0,0 rof sm mov @0,>step ; mov half of the incendiary end sp This program has a bomb that looks like this: sm mov sp, >sp ... sp spl #0, Date: 07 Jun 1994 09:31:54 GMT That's an interesting concept. I'd be curious to see your proposal. For one thing, it would bring *REGISTERS* to Redcode, and possibly some more flexible addressing modes. From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Anybody interested in RISC corewar? Message-ID: <1994Jun7.171934.6599@news.vanderbilt.edu> Date: Tue, 7 Jun 1994 17:19:34 GMT In article <1994Jun6.123619.1@bcvms.bc.edu> connorbd@bcvms.bc.edu writes: >Would anybody be interested in a proposal for a RISC version of Redcode? I thought redcode is pretty RISCy as is, at least as far as number and complexity of instructions is concerned. You are not proposing to add hundreds of registers, are you? -Stefan (stst@vuse.vanderbilt.edu) From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: The '94 Warrior Date: 7 Jun 1994 19:59:14 GMT Message-ID: <2t2jii$66k@agate.berkeley.edu> In "The '94 Warrior", Brant Thomsen wrote: > The current ICWS '94 Draft hill on "Pizza": > 1 49/ 34/ 17 Pyramid v5.5 Michael Constant 163 54 > > The current ICWS '94 Experimental (Big) hill on "Pizza": > 1 49/ 32/ 19 Pyramid v5.3 Michael Constant 166 38 Now isn't that pretty? :-) > Also dramatic are the drop of Mike Nonemacher's "Der Zweite Blitzkrieg" and > Michael Constant's "Sauron" (right off the hill), as both were putting up a > good fight for the top position only a month ago. Sorry, thank you for playing, please try again. I killed Sauron when I submitted Pyramid v5.6 to the '94 pizza hill, because I didn't want to kill off Pyramid v5.5 but I also didn't want to knock off the last-place program because Pyramid gets a lot of cheap points off of it^Ubecause I didn't want to push it off unfairly (by having two copies of Pyramid on the hill at once). So, I killed Sauron so that my own program would be the only one to suffer when I had two copies of Pyramid on at once. I'll resubmit Sauron in a day or two, and I expect it to be right back where it was when I killed it (7th place or thereabouts). -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: wirt@cais2.cais.com (Mark Wirt) Subject: CoreWar Implementations Date: Tue, 7 Jun 1994 20:45:36 Message-ID: I recently downloaded the CoreWar for Windows (v1.0) implementation from the archive, in the expectation of trying my hand at the game. Unfortunately, while running the program my computer was plagued with general protection faults, and associated strange errors. It could be coincidental (caused by some other software), but it *seems* to be a compatibility problem (I'm running an AMI EISA BIOS, 16 MB RAM, and Windows 3.1). Q1.) Have anyone else experienced these problems, and Q2.) What's everyone's favorite DOS implementation? Thanks in advance. From: jjfloyd@vela.acs.oakland.edu (Jered Floyd) Subject: Arithmetic evaluation order? Date: 7 Jun 1994 21:28:20 GMT Message-ID: <2t2opk$isu@oak.oakland.edu> Hi! I'm almost done (i.e. about 2 hours of work left) on jMARS (a.k.a. Yet another MARS for DOS with a seperate assembler and graphical display), and I'm stuck on one point. Let's say I have: JMP 5+2*3-1 (That's after labels and EQUs have been parsed) Do I have to follow order of operations, or is it acceptable to evaluate left to right? Also, in the assembler code, ('88) the only valid arithmetic operators are +,-,*, and /, correct? Thanks alot! If I get a reply tonight, I will release jMARS tomorrow. Jered . -- Jered Floyd jjfloyd@vela.acs.oakland.edu Geek Code: GAT d? -p+ c++++ l+ u++ e*@ m++ s/-- n--- h++ f? g- w++ t+++ r++ PGP Public key, Geek Code, picture, and assorted humor available by finger. From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Arithmetic evaluation order? Message-ID: <1994Jun7.235305.16255@news.vanderbilt.edu> Date: Tue, 7 Jun 1994 23:53:05 GMT In article <2t2opk$isu@oak.oakland.edu> jjfloyd@vela.acs.oakland.edu (Jered Floyd) writes: >Do I have to follow order of operations, or is it acceptable to >evaluate left to right? > Proper precedence would be nice, but not absolutely necessary if you can handle parentheses. You are welcome to use the pMARS expression evaluator in eval.c which is pretty modular and should translate easily into Pascal. -Stefan (stst@vuse.vanderbilt.edu) From: jjfloyd@vela.acs.oakland.edu (Jered Floyd) Subject: REQUEST: Where's my mistake? Date: 8 Jun 1994 01:53:17 GMT Message-ID: <2t38ad$lmh@oak.oakland.edu> Allright, Something's not right in my interpretation of the beginning of the program... (It's the Valudation program.) start spl l1,count+1 jmz ARRGGH! Sorry about that, I've been programming for several hours, and my mind went numb for a minute. Don't bother responding to that last message. And (barring further bugs), jMARS will be released tomorrow. -- Jered Floyd jjfloyd@vela.acs.oakland.edu Geek Code: GAT d? -p+ c++++ l+ u++ e*@ m++ s/-- n--- h++ f? g- w++ t+++ r++ PGP Public key, Geek Code, picture, and assorted humor available by finger. From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Re: Anybody interested in RISC corewar? [More rambling] Message-ID: Date: 08 Jun 1994 14:28:03 GMT In article <1994Jun7.171934.6599@news.vanderbilt.edu> stst@vuse.vanderbilt.edu (Stefan Strack) writes: > From: stst@vuse.vanderbilt.edu (Stefan Strack) > Subject: Re: Anybody interested in RISC corewar? > Date: 07 Jun 1994 17:19:34 PST-8 > > In article <1994Jun6.123619.1@bcvms.bc.edu> connorbd@bcvms.bc.edu writes: > >Would anybody be interested in a proposal for a RISC version of Redcode? > > I thought redcode is pretty RISCy as is, at least as far as number and > complexity of instructions is concerned. You are not proposing to add > hundreds of registers, are you? > > -Stefan (stst@vuse.vanderbilt.edu) It depends on what you call RISCy. To me, a RISC machine is one that has: - in-memory instructions are only LOAD and STORE - all "operations" are in-register (it follows) - register-relative addressing modes only In that respect, since Redcode doesn't have registers at all, I can't consider it RISC. Now I can't say if a RISC Redcode would be interesting in terms of possibilities for new warriors, but the concept is. Why not? At least, I'd be definitely interested in adding at least one register to the current redcode (an accumulator). MOV #3, A ;LOAD Accumulator MOV A, -3 ;STORE MOV #0, 0(A) ;Store indexed Granted, the accumulator can be substituted by a fixed location in core. However, if we say that each process has its own accumulator, the potential becomes greater, as we can user the accumulator as a stack pointer for true multi-threading. The indexed addressing can also be replaced by indirect addressing, but not fully: with indexed mode you can get double indirection. -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science & Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: mreddy@uk.ac.glamorgan (Mike Reddy) Subject: MARS -> RISC -> Turing Machines? Message-ID: Date: Wed, 8 Jun 1994 16:17:52 GMT A little while ago we had a call for those interested in RISC-based core war games. Well the ultimate machine (sic) for corewar would be Turing Machines (defined by Alan Turing in 1936!). Anyone interested in developing a TM simulator? A Turing Machine (the simplest example) had a state register, a type of program counter - conceptualised by Turing as the physical position of the machine on a paper tape - and a memory/input/output device, which was the forementioned tape. The Universal Turing Machine had an infinite tape, but we could do without that. Now the Church-Turing hypothesis states that any and all computations are equivalent on different machines/representations, so it should be possible to set a number of TMs off on a tape of zeros (i.e. the blank core) and see which one won by causing the others to execute a finish command. Programming a TM involved giving it an "Instruction Table" which consisted of rules which dictated its actions and the movement of the machine (program counter). An example would be: State of TM Value on Tape New State of TM New Value on Tape Direction 1 0 2 1 L Where the State (1) and the value (0) caused the state and the value to increase and the machine to move left (i.e. to execute the previous instruction assuming that we read left to right (very Occidental, I know)). The initial concept allowed for the tape to carry zero (0) one (1) and a marker (X), but the machine could have any number of states (say 1-6). A corewar competition could be of the form that each machine had its own instruction table (rather like a production rule set really) which must include one command/state that could terminate the process, and a given array of tape that the TM wold initially address, which would be its input. Naturally, there could be some limit on the space on the tape and the size of the instruction table to handicap the TMs, but everything else is effectively similar to the standard (?) corewar competition. So what about it? Yours Mike Reddy -- P.S. I would have had a witty signature, but the Government put VAT on it! P.P.S. I live at mreddy@uk.ac.glamorgan OR mreddy@glamorgan.ac.uk if you are unfortunate enough to be outside the UK! From: mreddy@uk.ac.glamorgan (Mike Reddy) Subject: MARS -> RISC -> Turing Machines? Message-ID: Date: Wed, 8 Jun 1994 17:33:15 GMT NOTE: Repost! Apologies if two versions of this note appear! We recently had a call for RISC-based Core Wars to be investigated. How about the ultimate machine (sic); i.e. the Turing Machine? Anyone interested in implementing a TM simulator? TMs are the simplest computers in (or out?) of existence. Originally conceived by Alan Turing in 1936 (!) they are equivalent to any other computing system (Church-Turing Hypothesis) and therefore could be used for corewars. TM structure and operation goes something like this: Contents * An 'Instruction Table' which is a set of rules of behaviour * Some State Register, which defines part of the TM behaviour according to those rules * a sort of Program Counter, conceptualised by Turing as the physical location of the TM on a piece of tape (see later) Operation The TM is positioned on a (possibly infinite) paper tape which acts as the input/output/memory. The value on the tape (memory or core) is read; values of zero (0), one (1) and a marker (X) are allowed in the original system. This value and the internal value of the machine state register are used to look up some behaviour in the instruction set (or program). An example would be: TM State Tape Value New TM State New Tape Value PC Direction 2 0 4 1 R where PC is Program Counter (some representation of the movement of the TM itself) The above example would be a simple IMP (if other rules where added) in that reading a zero on the tape it would convert it into a 1 and move along one instruction. Any number of States where allowed and a complete Instruction Table would have three entries for each state (i.e. 0,1 or X) The core war competition would consist of a number of TMs with their individual Instruction Tables defined internally, and a certain section of Tape predefined in which they started. To make things playable it must be possible to terminate a TM if it meets some condition, so that TMs could defeat each other. I have not worked out all the details yet (these are left as an exercise for the reader... 8-) I have always wanted to say that!) So what do you think? Yours Mike Reddy -- P.S. I would have had a witty signature, but the Government put VAT on it! P.P.S. I live at mreddy@uk.ac.glamorgan OR mreddy@glamorgan.ac.uk if you are unlucky enough to live outside the UK! 8-) From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: CoreWar Implementations Date: 8 Jun 1994 20:16:53 GMT Message-ID: <2t58vl$l4l@agate.berkeley.edu> Mark Wirt wrote: > Q1.) Have anyone else experienced these problems [WinCore crashing]? I haven't had any problems with WinCore... I don't really like it though, because it doesn't support '94 programming and it doesn't use in-register evaluation (i.e. it's not koth-compatible) until you register it (which is quite expensive). > Q2.) What's everyone's favorite DOS implementation? It's called pMARS (Portable MARS) and you can get the DOS-compiled version by anon ftp to soda.berkeley.edu, as /pub/corewar/systems/pmars051.zip. This is, without question, the very best corewar simulator in existence. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: jjfloyd@vela.acs.oakland.edu (Jered Floyd) Subject: Re: Anybody interested in RISC corewar? [More rambling] Date: 9 Jun 1994 01:28:58 GMT Message-ID: <2t5r8q$76f@oak.oakland.edu> Sure, just as I get my ICWS '88 MARS working, you go and come up with something new. First it's ICWS '94, then it's RISC...It's a conspiracy! You're all out to make me lose my mind (or spend 20 hours a day programming...not counting work.) :-) -- Jered Floyd jjfloyd@vela.acs.oakland.edu Geek Code: GAT d? -p+ c++++ l+ u++ e*@ m++ s/-- n--- h++ f? g- w++ t+++ r++ PGP Public key, Geek Code, picture, and assorted humor available by finger. From: macaulay@ee.mu.OZ.AU (alexander william macaulay) Subject: Redcoder 2.1 Message-ID: <9416015.28857@mulga.cs.mu.OZ.AU> Date: Thu, 9 Jun 1994 05:25:49 GMT Redcoder 2.1 is now available at soda.berkeley.edu (and will also appear at major Mac ftp sites very soon). It is currently in the /pub/corewar/incoming directory but should eventually move to /pub/corewar/systems. Redcoder is a graphical CoreWar simulator and development environment for the Macintosh. It supports both the ICWS '88 and ICWS '94 (proposed) standards. Redcoder 2.1 adds a tournament manager (see the Tournament section in this document), has an improved "Declare Results" dialog and also fixes a few bugs in version 2.0. --- Alex MacAulay (macaulay@ecr.mu.oz.au). From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: Anybody interested in RISC corewar? [More rambling] Message-ID: Date: Thu, 9 Jun 1994 12:25:34 GMT In article , Jay "Thierry" Han wrote: > >At least, I'd be definitely interested in adding at least one >register to the current redcode (an accumulator). > >MOV #3, A ;LOAD Accumulator >MOV A, -3 ;STORE >MOV #0, 0(A) ;Store indexed > >Granted, the accumulator can be substituted by a fixed location in >core. However, if we say that each process has its own accumulator, >the potential becomes greater, as we can user the accumulator as a >stack pointer for true multi-threading. The indexed addressing can >also be replaced by indirect addressing, but not fully: with indexed >mode you can get double indirection. This I agree with... I wonder what this would mean to program intelligence? If you had one or more (I vote for 4!) accumalators, then you can hide some of the calculations that can be searched for in the CORE. I am assuming that the registers cannot be read by any other program currently running in the core. Would this be able to give larger programs a much needed slight advantage? Or would it give the smaller programs a much unneeded advantage? I am curious how vampire programs would be written with registers? Hmmm.... There is, of course, the other thing about multithreading that we can discuss too. Jay already touched upon that... Would each newly created child process have access to the same registers, or would they have access to their own set of registers? We could have two registers which are shared among all children and two registers which only belong to the current process... this would allow flexibility and also allow the multithreaded communication that could occur between children... In any the case, even if it doesn't make it to the proposed standard, I would like to see someone add it to a system so that we can play with it :-) (I am not volunteering, since all of my programming time is devoted to real work at the moment... *sigh*) :-) Scott -- ______ __ __ ________ /\ ___\ /\ \ __/\ \ /\ ____ \ Scott W. Adkins - sadkins@ohiou.edu \ \ \__/ \ \ \/\ \ \ \ \ \ \___\ \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \ \___ \ \ \ \ \ \ \ \ \ \ ____ \ Ohio University of Athens \/___\ \ \ \ \_\ \_\ \ \ \ \ \ \ \ Harvard on the Hocking! /\_____\ \ \_________\ \ \_\ \ \_\ \/_____/ \/_________/ \/_/ \/_/ Knowledge is the seed of understanding. From: mconst@OCF.Berkeley.EDU (Michael Constant) Subject: Re: Anybody interested in RISC corewar? [More rambling] Date: 9 Jun 1994 20:15:37 GMT Message-ID: <2t7t99$85o@agate.berkeley.edu> Jay "Thierry" Han wrote: >Granted, the accumulator can be substituted by a fixed location in >core. However, if we say that each process has its own accumulator, >the potential becomes greater, as we can user the accumulator as a >stack pointer for true multi-threading. Then why not use an idea I've been toying with for a while: allow read/write to absolute core locations. This would allow good inter-process communication and it would also work for anything else you might want to use registers for. There were some complaints the last time I proposed this, but it seemed to me that all of the objections people had were unfounded, so I'm proposing it again. If I completely misunderstood someone's argument, I would like to hear it again... -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: Dave Darling Subject: Re: Anybody interested in RISC corewar? Message-ID: <1994Jun9.212708.5859@riacs.edu> Date: Thu, 9 Jun 94 21:27:08 GMT In article Scott W. Adkins, sadkins@bigbird.cs.ohiou.edu writes: >In any the case, even if it doesn't make it to the proposed standard, I would >like to see someone add it to a system so that we can play with it :-) Ooooooh, yeaaah! Actually, this sounds like a better mod than the current "play with it" set (A-fields, looking at instructions, etc.). And I even voted for most of those. If this is another "vote"-capable issue, my vote is "yes". --DD Dave Darling, | HELP! I'm in TQM training, Cockpit Graphics Programmer | and I can't get up! GU d--@ -p+(p-) c+ !l(l--) u++(u--) e- m---@ s+/+ n+@ h+ f? g-(g+) w++ t++ r+@ y* From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 10 Jun 1994 02:13:14 GMT Message-ID: Archive-name: games/corewar-faq Last-modified: 1994/04/11 Version: 2.2.1 These are the Frequently Asked Questions (and answers) from the USENET newsgroup rec.games.corewar. This FAQ list is also available by anonymous FTP from rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.Z. TABLE OF CONTENTS Line ------------------------------------------------------------------------ 1. What is Core War? 69 2. Is it Core War or Core Wars? 82 3. Where can I find more information about Core War? 90 4. Core War has changed since Dewdney's articles. Where do I get 108 a copy of the current instruction set? 5. What is this ICWS'94? 126 6. What is the ICWS? 143 7. What is TCWN? 153 8. How do I join? 161 9. Are back issues of TCWNs available? 178 10. What is the EBS? 185 11. Where are the Core War archives? 201 12. Where can I find a Core War system for . . . ? 219 13. I do not have ftp. How do I get all of this great stuff? 268 14. I do not have access to Usenet. How do I post and receive news? 275 15. When is the next tournament? 293 16. What is KotH? How do I enter? 304 17. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 466 18. How does SLT (Skip if Less Than) work? 478 19. What does (expression or term of your choice) mean? 490 20. Other questions? 633 --------------------------------------------------------------------- Q 1: What is Core War? A 1: Core War is a game played by two or more programs (and vicariously by their authors) written in an assembly language called Redcode and run in a virtual computer called MARS (for Memory Array Redcode Simulator). The object of the game is to cause all of the opposing programs to terminate, leaving your program in sole posession of the machine. There are Core War systems available for most computer platforms. Redcode has been standardized by the ICWS, and is therefore transportable between all standard Core War systems. ---------------------------------------------------------------------- Q 2: Is it "Core War" or "Core Wars"? A 2: Both terms are used. Early references were to Core War. Later references seem to use Core Wars. I prefer "Core War" to refer to the game in general, "core wars" to refer to more than one specific battle. ---------------------------------------------------------------------- Q 3: Where can I find more information about Core War? A 3: Core War was first described in the "Core War Guidelines" of March, 1984 by D. G. Jones and A. K. Dewdney of the Department of Computer Science at The University of Western Ontario (Canada). Dewdney wrote several "Computer Recreations" articles in "Scientific American" which discussed Core War, starting with the May 1984 article. Those articles are contained in an anthology: Author: Dewdney, A. K. Title: The Armchair Universe: An Exploration of Computer Worlds Published: New York: W. H. Freeman (c) 1988 ISBN: 0-7167-1939-8 Library of Congress Call Number: QA76.6 .D517 1988 The Redcode language has changed somewhat since; see Q 4. --------------------------------------------------------------------- Q 4: Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? A 4: A draft of the official standard (ICWS'88) is available by anonymous FTP from the Core War archives (soda.berkeley.edu) as pub/corewar/documents/standards/redcode-icws-88.Z This document is formatted awkwardly and contains ambiguous statements. For a more approachable intro to Redcode, take a look at pub/corewar/documents/tutorial.1.Z tutorial.2.Z (See also Q11) Steven Morrell (morrell@math.utah.edu) is preparing a more pratically oriented Redcode tutorial that discusses different warrior classes with lots of example code. Mail him for a preliminary version. --------------------------------------------------------------------- Q 5: What is this ICWS'94? A 5: There is an ongoing discussion about future enhancements to the Redcode language. A proposed new standard, dubbed ICWS'94, is currently being evaluated. A major change is the addition of "instruction modifiers" that allow instructions to modify A-field, B-field or both. Also new is a post-increment indirect addressing mode and unrestricted opcode and addressing mode combination ("no illegal instructions"). ICWS'94 is backwards compatible; i.e. ICWS'88 warriors will run correctly on an ICWS'94 system. Take a look at the ICWS'94 draft for more information (soda.berkeley.edu pub/corewar/documents/icws94.0202.Z). You can try out the new standard by submitting warriors to the '94 hills of the KotH servers (see Q16). Two corewar systems currently support ICWS'94, pMARS (various platforms) and Redcoder (Mac), both available at soda (see Q12). --------------------------------------------------------------------- Q 6: What is the ICWS? A 6: About one year after Core War first appeared in Sci-Am, the "International Core War Society" (ICWS) was established. Since that time, the ICWS has been responsible for the creation and maintenance of Core War standards and the running of Core War tournaments. There have been six annual tournaments and two standards (ICWS'86 and ICWS'88). --------------------------------------------------------------------- Q 7: What is TCWN? A 7: Since March of 1987, "The Core War Newsletter" (TCWN) has been the official newsletter of the ICWS. It is published quarterly and recent issues are also available as Encapsulated PostScript on soda.berkeley.edu (see Q9). --------------------------------------------------------------------- Q 8: How do I join? A 8: For more information about joining the ICWS (which includes a subscription to TCWN), or to contribute an article, review, cartoon, letter, joke, rumor, etc. to TCWN, please contact: Jon Newman 13824 NE 87th Street Redmond, WA 98052-1959 email: jonn@microsoft.com (Note: Microsoft has NO affiliation with Core War. Jon Newman just happens to work there, and we want to keep it that way!) Current annual dues are $15.00 in US currency. ---------------------------------------------------------------------- Q 9: Are back issues of TCWN available? A 9: Recent issues can be found on soda.berkeley.edu (see Q11). Older issues (up to Winter 1991) are also available (see the next TCWN for details). --------------------------------------------------------------------- Q10: What is the EBS? A10: The Electronic Branch Section (EBS) of the ICWS is a group of Core War enthusiasts with access to electronic mail. There are no fees associated with being a member of the EBS, and members do reap some of the benefits of full ICWS membership without the expense. For instance, the ten best warriors submitted to the EBS tournament are entered into the annual ICWS tournament. All EBS business is conducted in the rec.games.corewar newsgroup. The current goal of the EBS is to be at the forefront of Core War by writing and implementing new standards and test suites in preparation for the tenth anniversary of Core War in May of 1994 (see Q 5). Its immediate business will be to set up a Charter and establish its officers. ---------------------------------------------------------------------- Q11: Where is the Core War archive? A11: Many documents such as the guidelines and the ICWS standards along with previous tournament Redcode entries and complete Core War systems are available via anonymous ftp from soda.berkeley.edu (128.32.149.19) in the /pub/corewar directories. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Jon Blow (blojo@soda.berkeley.edu) is the archive administrator. When uploading to /pub/corewar/incoming, ask Jon to move your upload to the appropriate directory and announce it on the net. Much of what is available on soda is also available on the German archive at iraun1.ira.uka.de (129.13.10.90) in the /pub/X11/corewars directory. This FAQ is automatically archived by news.answers. See the header for the current archive name and news.answers for how to get it. ---------------------------------------------------------------------- Q12: Where can I find a Core War system for . . . ? A12: Core War systems are available via anonymous ftp from soda.berkeley.edu in the pub/corewar/systems directory. Currently, there are UNIX, IBM PC-compatible, Macintosh, and Amiga Core War systems available there. CAUTION! There are many, many Core War systems available which are NOT ICWS'88 (or even ICWS'86) compatible available at various archive sites other than soda.berkeley.edu. Generally, the older the program - the less likely it will be ICWS compatible. Reviews of Core War systems would be greatly appreciated in the newsgroup and in the newsletter. Below is a not necessarily complete or up-to-date list of what's available at soda: MADgic41.lzh - corewar for the Amiga, v4.1 MAD4041.lzh - older version? MAD50B.lha - corewar for the Amiga, beta version 5.0 Redcoder-20.hqx - corewar for the Mac, supports ICWS'88 and '94 core-11.hqx - corewar for the Mac core-wars-simulator.hqx - same as core-11.hqx? corewar_unix_x11.tar.Z - corewar for UNIX/X-windows, ICWS'86 but not ICWS'88 compatible koth31.tar.Z - corewar for UNIX/X-windows. This program ran the former KotH server at intel.com koth.shar.Z - older version kothpc.zip - port of older version of KotH to the PC deluxe20c.tar.Z - corewar for UNIX (broken X-windows or curses) and PC mars.tar.Z - corewar for UNIX, likely not ICWS'88 compatible icons.zip - corewar icons for MS-Windows macrored.zip - a redcode macro-preprocessor (PC) c88v49.zip - PC corewar, textmode display mars88.zip - PC corewar, graphics mode display corwp302.zip - PC corewar, textmode display, slowish mercury2.zip - PC corewar written in assembly, fast! mtourn11.zip - tournament scheduler for mercury (req. 4DOS) pmars05s.zip - portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars05s.tar.Z - same as above pmars05.zip - 16-bit PC executables, graphics display version pmars05g.zip - 32-bit PC execs (djgpp, large core) macpmars02.sit.hqx - pMARS executable for Mac (port of version 0.2) ApMARS03.lha - pMARS executable for Amiga (port of version 0.3.1) wincore.zip - MS-Windows system, shareware ($35) ---------------------------------------------------------------------- Q13: I do not have ftp. How do I get all of this great stuff? A13: There is an ftp email server at ftpmail@decwrl.dec.com. Send email with a subject and body text of "help" (without the quotes) for more information on its usage. ---------------------------------------------------------------------- Q14: I do not have access to Usenet. How do I post and receive news? A14: To receive rec.games.corewar articles by email, join the COREWAR-L list run on the Stormking.Com ListProcessor. To join, send: SUB COREWAR-L FirstName LastName to: LISTPROC@STORMKING.COM You can send mail to corewar-l@stormking.com to post even if you are not a member of the list. Responsible for the listserver is Scott J. Ellentuch (tuc@stormking.com). Another server that allows you to post (but not receive) articles is available. Email your post to rec-games-corewar@cs.utexas.edu and it will be automatically posted for you. ---------------------------------------------------------------------- Q15: When is the next tournament? A15: The ICWS holds an annual tournament. Traditionally, the deadline for entering is the 15th of December. The EBS usually holds a preliminary tournament around the 15th of November and sends the top finishers on to the ICWS tournament. Informal double-elimination tournaments are held frequently among readers of the newsgroup; watch there for announcements or contact me. ---------------------------------------------------------------------- Q16: What is KotH? How do I enter? A16: King Of The Hill (KotH) is an ongoing Core War tournament available to anyone with email. You enter by submitting via email a Redcode program with special comment lines. You will receive a reply indicating how well your program did against the current top twenty programs "on the hill". Your program will play 100 battles against each of the 20 other programs currently on the Hill. You receive 3 points for each win and 1 point for each tie. (The existing programs do not replay each other, but their previous battles are recalled.) All scores are updated to reflect your battles and all 21 programs are ranked from high to low. If you are number 21 you are pushed off the Hill, if you are higher than 21 someone else is pushed off. The original KotH was developed and run by William Shubert at Intel, and discontinued after almost three years of service. Currently, KotHs based on Bill's UNIX scripts but offering a wider variety of hills are are running at two sites: "koth@stormking.com" is maintained by Scott J. Ellentuch (tuc@stormking.com) and "pizza@ecst.csuchico.edu" by Thomas H. Davies (sd@ecst.csuchico.edu). Both KotHs provide very similar services and are therefore covered together. The principal difference is that "pizza" has a much faster internet connection than "stormking". Entry rules for King of the Hill 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. If you wish to receive mail on every new entrant, use ";redcode verbose". Otherwise you will only receive mail if a challenger makes it onto the hill. Use ";redcode quiet" if you wish to receive mail only when you get shoved off the hill. (Also, see 5 below). Additionally, 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 daemon 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. There are currently six separate hills you can select by starting your program with ;redcode, ;redcode-x, ;redcode-icws, ;redcode-b, ;redcode-94, or ;redcode-94x. More information on these hills is listed below. 3) Mail this file to "koth@stormking.com" or "pizza@ecst.csuchico.edu". "Pizza" requires a subject of "koth" (use the -s flag on most mailers). 4) Within a few minutes (or the next day for "stormking") you should get mail back telling you whether your program assembled correctly or not. If it did assemble correctly, sit back and wait; if not, make the change required and re-submit. 5) In an hour or so (or the next day for "stormking") you should get more mail telling you how your program performed against the current top 20 programs. If no news arrives during that time, 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. SAMPLE ENTRY: ;redcode ;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 ; Programs start at the first line unless ; an "END start" pseudo-op appears to indicate ; the first logical instruction. Also, nothing ; after the END instruction will be assembled. Here are the Specs for the various hills: ICWS'88 Standard Hill Specs: (Accessed with ";redcode", available at "stormking" and "pizza") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '88 ICWS Annual Tournament Hill Specs: (Accessed with ";redcode-icws", available at "stormking" only) coresize: 8192 instructions max. processes: 8000 per program duration: After 100,000 cycles, a tie is declared. max. entry length: 300 minimum distance: 300 instruction set: ICWS '88 ICWS'88 Experimental (Small) Hill Specs: (Accessed with ";redcode-x", available at "pizza" only) coresize: 4096 max. processes: 32 duration: after 65,536 cycles, a tie is declared. max. entry length: 64 minimum distance: 64 instruction set: ICWS '88 ICWS'94 Draft Hill Specs: (Accessed with ";redcode-94", available at "stormking" and "pizza") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Beginner's Hill Specs: (Accessed with ";redcode-b", available at "pizza" only) coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Experimental (Big) Hill Specs: (Accessed with ";redcode-94x", available at "stormking" and "pizza") coresize: 55440 max. processes: 10000 duration: after 500,000 cycles, a tie is declared. max. entry length: 200 minimum distance: 200 instruction set: ICWS '94 Draft If you just want to get a status report without actually challenging the hills, send email with ";status" as the message body (and don't forget "Subject: koth" for "pizza"). If you send mail to "pizza" with "Subject: koth help" you will receive instructions that may be more up to date than those contained in this document. All hills run portable MARS (pMARS) version 0.5, a platform-independent corewar system available at soda (see Q12). The '94 and '94x hills allow three experimental opcodes currently not covered in the ICWS'94 draft document: SEQ - Skip if EQual (synonym for CMP) SNE - Skip if Not Equal NOP - (No OPeration) ---------------------------------------------------------------------- Q17: Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? A17: Core is initialized to DAT 0, 0. This is an "illegal" instruction under ICWS'88 rules and strictly compliant assemblers (such as KotH or pmars -8) will not let you write a DAT 0, 0 instruction - only DAT #0, #0. So this begs the question, how to compare something to see if it is empty core. The answer is, most likely the instruction before your first instruction and the instruction after your last instruction are both DAT 0, 0. You can use them, or any other likely unmodified instructions, for comparison. Note that under ICWS'94, DAT 0, 0 is a legal instruction. ---------------------------------------------------------------------- Q18: How does SLT (Skip if Less Than) work? A18: SLT gives some people trouble because of the way modular arithmetic works. It is important to note that all negative numbers are converted to positive numbers before a battles begins. Example: (-1) becomes (M - 1) where M is the memory size. Once you realize that all numbers are treated as positive, it is clear what is meant by "less than". It should also be clear that no number is less than zero. ---------------------------------------------------------------------- Q19: What does (expression or term of your choice) mean? A19: Here is a selected glossary of terms. If you have a definition and/or term you wish to see here, please send it to me. (References to an X-like program mean that the term X is derived from the specific program X and has become a generic term). Bootstrapping - Strategy of copying the active portion of the program away from the initial location, leaving a decoy behind and making the relocated program as small as possible. B-Scanners - Scanners which only recognize non-zero B-fields. example add #10,scan scan jmz example,10 C - Measure of speed, equal to one location per cycle. Speed of light. CMP-Scanner - A Scanner which uses a CMP instruction to look for opponents. example add step,scan scan cmp 10,30 jmp attack jmp example step dat #20,#20 Color - Property of bombs making them visible to scanners, causing them to attack useless locations, thus slowing them down. example dat #100 Core-Clear - code that sequentially overwrites core with DAT instructions; usually the last part of a program. Decoys - Bogus or unused instructions meant to slow down Scanners. Typically, DATs with non-zero B-fields. DJN-Stream (also DJN-Train) - Using a DJN command to rapidly decrement core locations. example . . . . . . djn example,<4000 Dwarf - the prototypical small bomber. Gate-busting - (also gate-crashing) technique to "interweave" a decrement-resistant imp-spiral (e.g. MOV 0, 2668) with a standard one to overrun imp-gates. Hybrids - warriors that combine two or more of the basic strategies, either in sequence (e.g. stone->paper) or in parallel (e.g. imp/stone). Imp - Program which only uses the MOV instruction. example MOV 0, 1 or example MOV 0, 2 MOV 0, 2 Imp-Gate - A location in core which is bombed or decremented continuously so that an Imp can not pass. Also used to describe the program-code which maintains the gate. example ... ... SPL 0, RISC -> Turing Machines? Message-ID: Date: 10 Jun 1994 10:55:36 GMT Sounds kinda interesting, but it would need a lot of work to have it all under control. First of all, as you say, what condition would signal the death of a program? That's a very tough one, and I, the reader :-), don't see a solution. It could be some special symbol that is writable but kills you when you read it, but then how many different strategies can you come up with? BTW, the example you mention is not an IMP, because it only advances on a 0. If you make it advance on a 1 too, it looks more like a core-clear. The problem is, I can't see *any* other strategy that would work on a TM! -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science & Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: connorbd@bcvms.bc.edu Subject: The basics of RedcodeRISC Date: 10 Jun 94 13:30:41 EDT Message-ID: <1994Jun10.133042.1@bcvms.bc.edu> Okay, I forgot the basic proposal at home, so I don't have it with me. Shame, really, because it shows a version of Dwarf hacked up as a RISC program. But as much as I can remember, here's the basics. Comments or suggestions, email me. I'll try to get the full proposal out next week. The MARS simulator is only one step in complexity above the standard, since it adds a stack or two to the process queue for each player. Programs are larger, with most of the overhead incurred in the math routines, which are done with signed numbers and push/pop/collapse stack operations. The instruction set is very basic, providing a bare minimum of operations in order to do things. Also, absolute addressing is allowed; see entry on _data_ for details. This is the basic set of instructions (* denotes not present in current proposal): syntax operation value,memory comp (=cmp) compares value to memory; if equal skips to instruction after next else continues to next instruction data (=dat) *memory arg is optional; if used puts the data at absolute address specified. (Note that absolute addresses should be preceded with a denoting character; my preference is >. Without this the argument is either considered a relative address or (with _data_) ignored.) move (=mov) moves value to address jump (=jmp) transfers program execution to given address; value is ignored spl splits processes off. Value represents number of processes; memory gives location to split to. Was named _fork_ in proposal. push pushes value onto a warrior's integer stack (as opposed to any others it might have). Using a memory argument does the same thing with an address on a different stack; this, however, may be questionably useful. pop pops the stack and puts the output in either a variable specified in value or an address specified by memory (as a data statement). cols collapses the stack, outputting the result to a variable specified in value. This 'collapse' operation basically amounts to addition of signed integers on the stack and replaces both addition and subtraction operations. sign changes the sign of a variable in value, but not a constant. Notes: Value can be anything you can stick in a variable. Address is noted (see _data_) with either a signed integer (relative) or an unsigned value preceded by a marker (absolute). All math is done with stack operations and signed integers. Pseudo-ops eq equals; not really necessary but it helps readability. main value denotes point to begin execution. Standard variables coresize size of execution space. Depends on rules of implementation. maxproc number of allowable active processes; exceeding this is illegal and results in a default to the other side. maxjump If implemented, this places a limit on the maximum jump a program can make. Makes things interesting. maxstack Maximum number of values on stack; an overflow will trigger an autocollapse. time How long will the match run? dist How far apart will the warriors start out? Not required. Basic MARS setup: Each player has a stack and a process queue. Both of these are to be displayed in the debugging display. As this is a proposal only, it's up to the implementor as to whether to make the stack vulnerable to enemy attack. The MARS interpreter, if possible, should be able to compile ICWS '88 or '94 warriors, but this is hardly necessary. All the same, it'd be kind of interesting... Well, that's the basic idea. It's actually a bit better than the proposal I had but we still don't have the RISC dwarf... I'll try to rewrithe the proposal and post it next week. Brian Connors Boston College "and all this from a newbie too" From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: pMARS v0.6.0 released Message-ID: <1994Jun10.225109.2459@news.vanderbilt.edu> Date: Fri, 10 Jun 1994 22:51:09 GMT Perfect timing - here the second MARS release notice for today. Now available at soda.berkeley.edu:/pub/corewar/incoming: pmars06s.zip - source code, zip'ed pmars06s.tar.Z - source code, tar'd and compressed pmars06.zip - DOS executables Coming soon: OS/2 PM and Mac versions of pMARS This version is not running at the pizza and stormking hills yet, so hold off submitting warriors with the new addressing modes until further notice. Enjoy, Stefan (stst@vuse.vanderbilt.edu) >____________________ >What's new in version 0.6.0 > >Bug fixes: > > o NOP is now legal with a single operand > > o cycle and process meters are refreshed when switching from text > to graphics display in pmarsv.exe > > o some pshell input fields were extended > > >New features, Simulator/Assembler: > > o added three experimental adressing modes: > * indirect using A-field > { predecrement indirect using A-field > } postincrement indirect using A-field > > These modes complement the @, < and > modes which use the B-field > as the indirection pointer. > > >Assembler: > > FOR/ROF and EQU substitution pass have been merged. This not only > means faster assembly, but also a richer FOR argument syntax: the FOR > argument can now be any expression containing arithmetic, comparison > and logical operators, predefined variables, line labels and EQU > expressions (as long as their definitions occur before the ROF). > A welcome side effect of this merger is that you no longer have to > include a ;macro line in your code to get FOR/ROF to work. > > If the FOR argument evaluates to 0, the FOR block is not expanded. > This allows for "conditional" assembly, e.g.: > > FOR CORESIZE == 8000 ;evaluates to 1 if true > some code > ROF > > FOR CORESIZE != 8000 > other code > ROF > > The new predefined variable CURLINE holds the current line number of > the generated assembly. Its main use is to write FOR/ROF blocks that > adapt to the code length: > > FOR MAXLENGTH-CURLINE ;fill the rest of the available space with decoy > dat 1,1 > ROF > > As announced previously on the net, pMARS now supports the ;assert > directive which makes sure that your warrior runs under compatible > settings for coresize, max. processes etc.. If the expression > following ;assert evaluates to 0, i.e. the "assertion fails", > assembly aborts with an error message. To encourage wide-spread use > of ;assert, pMARS complains if ;assert is missing. Some examples: > > ;assert CORESIZE == 8000 && MAXPROCESSES >= 1000 > ;assert (CORESIZE % 4) == 0 ; is multiple of 4 > > std EQU CORESIZE==8000 && MAXPROCESSES==8000 && MAXCYCLES==80000 .... > ;assert std && VERSION >= 060 > > To make updating all your warriors a little easier, we have included > UNIX scripts and DOS batch files that insert "generic" ;assert's (see > assert.doc). > > The extended expression syntax including assignment and use of single > char register variables a..z (you may know them from cdb macros) is > valid in instruction operand fields as well, but probably not very > useful except in cdb macros. Example: > > @calc x=-100~!!~@edit 3~djn -3, > (this is fragment of a macro that finds a DJN-stream offset which > triggers the cmp-scan as late as possible) > > >Display: > > The UNIX curses version finally has a split screen display for the > debugger. Sorry, no X-windows display yet. Any volunteers? > > >New program: > > "mopt", the multiple constant optimizer is now part of the package > (makes sense since mopt uses the pMARS expression evaluator). > > >New docs: > > "primer.cdb" gives a brief intro to the most commonly used debugger > commands for those whose attention span is too short to read the entire > "pmars.doc". > > "redcode.ref" is a quick reference to the redcode syntax supported > by pMARS. > > >New macros: > > ALT-G/S/C/T are versions of "go", "step", "continue" and "thread" that > use the 2-panel debugger display. > From: clgonsal@undergrad.math.uwaterloo.ca (Carl Laurence Gonsalves) Subject: Re: Anybody interested in RISC corewar? [More rambling] Message-ID: Date: Fri, 10 Jun 1994 23:38:59 GMT In article <2t7t99$85o@agate.berkeley.edu>, Michael Constant wrote: >Jay "Thierry" Han wrote: >>Granted, the accumulator can be substituted by a fixed location in >>core. However, if we say that each process has its own accumulator, >>the potential becomes greater, as we can user the accumulator as a >>stack pointer for true multi-threading. > >Then why not use an idea I've been toying with for a while: allow read/write >to absolute core locations. This would allow good inter-process communication >and it would also work for anything else you might want to use registers for. > >There were some complaints the last time I proposed this, but it seemed to >me that all of the objections people had were unfounded, so I'm proposing it >again. If I completely misunderstood someone's argument, I would like to >hear it again... I was one of the people a while back who complained about the idea of absolute addressing. I still don't think they're a good idea. They add asymmetry to the game. I can think of one exception though: If each warrior's "absolute addressing" was done, say, relative to that warrior's first instruction ever executed, then there wouldn't be any asymmetry. Each program would have it's own concept of "absolute zero", but this would be shared among all of its "threads". How does that sound? -- clgonsal@cayley.uwaterloo.ca - http://csclub.uwaterloo.ca/u/clgonsal/ Carl Laurence Gonsalves - 1B Computer Science, University of Waterloo From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Anybody interested in RISC corewar? [More rambling] Date: 11 Jun 1994 06:24:18 GMT Message-ID: <2tblai$3pb@agate.berkeley.edu> Carl Laurence Gonsalves wrote: >If each warrior's "absolute addressing" was done, say, relative to that >warrior's first instruction ever executed, then there wouldn't be any >asymmetry. Each program would have it's own concept of "absolute zero", >but this would be shared among all of its "threads". How does that >sound? That's fine with me. But how about changing your idea a little: I would prefer it if the addressing is done relative to the warrior's first instruction as loaded into core, rather than the first instruction executed. Is there anyone who absolutely despises the idea of absolute addressing? Otherwise I think that it would be quite a useful extension to the standard, because it would allow really good inter-process communication. P.S. Speaking of extensions to the standard, thank you to the pMARS team for implementing the latest '94 proposal (A-field indirection)! -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: kay@lucie.wupper.de (Kay Hamacher) Subject: Q: Neural Nets ? Date: 11 Jun 1994 08:02:16 GMT Message-ID: <2tbr28$fv@lucie.wupper.de> Hi! I am very interested in neural nets and want to ask users in the net, who would have fun in developing a corewar-like system for neural nets ? I think it may be possible to produce an enviroment in which some nets "fight" against each other. By using the typically algorithms for "learning" they should learn how to survive and perhaps elimante the competetives. Kay -- -------------------------------------------------------------------------- Kay Hamacher Phone : ++ 49 2332 80650 Milskotter Str. 19 Fax : ++ 49 2332 83518 58285 Gevelsberg InterNet: kay@lucie.wupper.de Federal Republic of Germany - European Union Selig sind die Vergesslichen: denn sie werden auch mit ihren Dummheiten "fertig". (Friedrich Nietzsche) From: pk6811s@acad.drake.edu Subject: Re: Anybody interested in RISC corewar? [More rambling] Date: 11 Jun 94 08:49:22 CST Message-ID: <1994Jun11.084922.1@acad.drake.edu> > > Is there anyone who absolutely despises the idea of absolute addressing? > Otherwise I think that it would be quite a useful extension to the standard, > because it would allow really good inter-process communication. Other than that I prefer Corewars development activities to be devoted to warrior development instead of emulator development...:-) Interprocess communication could be useful if you have a small number of processes, but how about replicators? You will have trouble syncing reads and writes without read-with-lock and write-unlock instructions. Paul Kline @c@ pk6811s@acad.drake.edu - ignorance exceeded only by inquisitance - From: devink@tartarus.uwa.edu.au (Devin Kilminster) Subject: Re: Anybody interested in RISC corewar? [More rambling] Date: 11 Jun 1994 08:50:13 GMT Message-ID: <2tbts5$oq2@styx.uwa.edu.au> Michael Constant (mconst@soda.berkeley.edu) wrote: : Is there anyone who absolutely despises the idea of absolute addressing? : Otherwise I think that it would be quite a useful extension to the standard, : because it would allow really good inter-process communication. One of the more interesting implications of absolute addressing is the ability to distinguish between the owners of processes. A fairly poor example (as there is no need to do it this way) is the gate: here: jmp (abosulte)here, <-1 an imp being stomped by this gate doesn't get killed but instead jumps to an (unfortunately) effectively random place in core. It'd be nice to figure out a way of finding out where as then another piece of code could be put there (say a pit?). Devin Kilminster. From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: pMARS v0.6.0 released Message-ID: <1994Jun11.192943.11091@news.vanderbilt.edu> Date: Sat, 11 Jun 1994 19:29:43 GMT pMARS v0.6.0 is now up and running at the pizza KotH. -Stefan (stst@vuse.vanderbilt.edu) From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Absolute addressing Message-ID: <1994Jun12.004423.15678@news.vanderbilt.edu> Date: Sun, 12 Jun 1994 00:44:23 GMT Well, I for one find that absolute addressing is an ugly concept and agree with Paul Kline that it's usefulness for interprocess communication is at best dubious. Also keep in mind that we're not talking about adding a single addressing mode but *seven*: absolute direct, absolute indirect using B-field, absolute predecrement indirect using B-field, ... , and absolute postincrement indirect using A-field. This is not to say that absolute addressing wouldn't go well with something completely new like that RISC corewar that somebody is proposing. -Stefan (stst@vuse.vanderbilt.edu) From: schoelle@cs.tu-berlin.de (Bernd Schoeller) Subject: FTP Site for Corewars in DE Date: 12 Jun 1994 12:58:08 GMT Message-ID: <2tf0p0$3i7@news.cs.tu-berlin.de> Hi ! Is there an FTP-Site for Corewars-Shells in Germany. I tried iraun1.ira.uka.de (as stated in the FAQ) but I did find only old programs. Ciao Bernd Subject: Q: Neural Nets ? From: john.goverts@almac.co.uk (John Goverts) Message-ID: <17.671.392@almac.co.uk> Date: Mon, 13 Jun 94 19:39:00 +0000 KH>Hi! KH>I am very interested in neural nets and want to ask users in the KH>net, who would have fun in developing a corewar-like system for KH>neural nets ? I think it may be possible to produce an enviroment in KH>which some nets "fight" KH>against each other. By using the typically algorithms for "learning" KH>they should learn how to survive and perhaps elimante the KH>competetives. Kay Definitely an interesting concept, but I wouldn't dare to pretend to know how to go about this. John Goverts, Rotterdam (johngo@hacktic.nl) --- * Orator V1.21 #38 * This is all a modem-induced hallucination. From: bharat@shadow.Eng.Sun.COM (Bharat Mediratta) Subject: Re: Anybody interested in RISC corewar? [Mor Date: 13 Jun 1994 20:39:29 GMT Message-ID: <2tig61$10i@engnews2.Eng.Sun.COM> In article 130694143722@130.252.106.44, roca_michael@tandem.com (Michael Roca) writes: >It's a shame, because interprocess communication would be very interesting. >What if each process had a "message area" or "register" which could be used >to send it messages? We would need (another) new addressing mode (my >apologies to the pMars developers), such as cmp !3,0 meaning "compare >process number 3's message area with the value 0". > >Can my objections be overcome? I view corewars slightly differently from most of the viewpoints that I've read about so far. The way I see the game is like this. You have two computers that share one core memory space. They are designed to interleave atomic instructions, so that they are never both executing an instruction at the same time. Each computer is programmed with one warrior, who's goal is to crash the other computer. This makes the concept of splitting much more straightforward. When a process splits, it is only splitting up resources on it's OWN computer. The other computer is still happily chugging away with it's single program (or it's multitude). Since each computer is threaded, a thread can die no problem. When the final thread is dead, the computer has nothing to execute and stops, thereby declaring a winner. Simple, eh? Now, it would be very simple to extend this concept a bit. Suppose each computer had a few global registers? Or just one global register? You could then store information in that register that would be readable/writeable by all of the threads on that computer. Heck, you could even simulate a stack in core to keep track of context switches (although you'd probably get demolished by an imp if you tried :). Of course, the simulator would have to be a bit more complex to handle this, but I think it would enrich the game and make KoTH a bit more unstable :) -Bharat --- Bharat Mediratta | Above opinions are mine and have bharat.mediratta@eng.sun.com | nothing to do with Sun Microsystems From: roca_michael@tandem.com (Michael Roca) Subject: Re: Anybody interested in RISC corewar? [More rambling] Message-ID: Date: Mon, 13 Jun 1994 22:37:22 GMT In article <2tbts5$oq2@styx.uwa.edu.au>, devink@tartarus.uwa.edu.au (Devin Kilminster) wrote: > here: jmp (abosulte)here, <-1 > > an imp being stomped by this gate doesn't get killed but instead jumps to > an (unfortunately) effectively random place in core. > This does raise a question. If you execute one of my instructions, is my "address 0" or yours used? I would think it should be yours (otherwise the emulator has to track who wrote to each memory location). I don't see how a vampire would work. jmp x,y would go to an effectivly random location (as mentioned above) and jmp @0,x would do its indirect addressing from the base 0 location, not the instruction being executed. I haven't given it much thought, but I also don't see how imps and some kinds of paper would work. It's a shame, because interprocess communication would be very interesting. What if each process had a "message area" or "register" which could be used to send it messages? We would need (another) new addressing mode (my apologies to the pMars developers), such as cmp !3,0 meaning "compare process number 3's message area with the value 0". Can my objections be overcome? Mike Roca Date: 14 Jun 1994 00:00:00 +0000 From: schommer@otaku.ruessel.sub.org (Michael Schommer) Message-ID: <5QsnQ_g26RB@otaku.ruessel.sub.org> Subject: Re: FTP Site for Corewars in DE schoelle@cs.tu-berlin.de schrieb am 12.06.94 zum Thema "FTP Site for Corewars in DE": +>Hi ! +> Is there an FTP-Site for Corewars-Shells in Germany. I tried +>iraun1.ira.uka.de (as stated in the FAQ) but I did find only old +>programs. If I remeber correctly, there is no other ftp site in .de that carries core war related files. I had to get everything from soda. Oh, maybe there was some stuff at the clausthal ftp server, but I'm not sure. Try gopher ! +> +>Ciao Bernd Salu, Michael -- Michael Schommer schommer@otaku.ruessel.sub.org Kaiserslautern, Germany m_schommer@jokl.zer PGP 2.3a Fingerprint: A6 F0 31 0E C1 57 12 02 - EB AA E5 E4 15 05 25 73 GCS/B/AT d++@ -p+ c++++ l+ u++ e+ m* s+++/++ n+ h-- f+ !g w++(+++) t r y+ ## CrossPoint v3.02 ## From: ukln@rzstud1.rz.uni-karlsruhe.de (David Furminieux) Subject: Re: FTP Site for Corewars in DE Date: 14 Jun 1994 00:48:54 GMT Message-ID: <2tiupm$9rr@nz12.rz.uni-karlsruhe.de> Bernd Schoeller (schoelle@cs.tu-berlin.de) wrote: : Hi ! : Is there an FTP-Site for Corewars-Shells in Germany. I tried : iraun1.ira.uka.de (as stated in the FAQ) but I did find only old : programs. : Ciao Bernd There is one , not so much stuff as on soda but anyway ftp.ira.uka.de:/pub/programming/corewar or something like that Dave & have a good night ******************************************************************************* * * * D. G. Furminieux ukln@rzstud1.rz.uni-karlsruhe.de * * ---------------- * * the one who reproduce is a human * * the one who create is a god * * * ******************************************************************************* From: ez003207@chip.ucdavis.edu (Rrrrrrryan) Subject: length 100??? Message-ID: Date: Tue, 14 Jun 1994 04:49:55 GMT This is to the people on the '94 draft hill: I submitted my best program to date to the '94 draft hill (Viewmaster 4.1 - a 2 pass core clear, 0.66c quickscanner..). It's been on the top of the beginner hill for a while (age 21), so I thought I'd give it a shot. Alas, I only made it to #20 for about an hour or so...The thing is, is that in all my testing, Viewmaster kicks ass most against large programs (this is intrinsic to quickscanners, right?) and of the 20 programs on the '94 draft hill, _15_ of them were 90 instructions or more! I thought I'd do at least ok then...So what went wrong? Is my scanning engine just too slow? Are all those programs really 100 instructions long??? Or are they super-efficient short programs padded with 50 point imp spirals??? Still trying, Ryan From: bdthomse@peruvian.cs.utah.edu (Brant Thomsen) Subject: Re: length 100??? Date: 14 Jun 1994 14:16:35 GMT Message-ID: <2tke43$9qr@magus.cs.utah.edu> In article ez003207@chip.ucdavis.edu (Rrrrrrryan) writes: >This is to the people on the '94 draft hill: > > I submitted my best program to date to the '94 draft hill (Viewmaster >4.1 - a 2 pass core clear, 0.66c quickscanner..). It's been on the top of >the beginner hill for a while (age 21), so I thought I'd give it a shot. >Alas, I only made it to #20 for about an hour or so...The thing is, is that >in all my testing, Viewmaster kicks ass most against large programs (this is >intrinsic to quickscanners, right?) and of the 20 programs on the '94 draft >hill, _15_ of them were 90 instructions or more! I thought I'd do at least ok >then...So what went wrong? Is my scanning engine just too slow? Are all >those programs really 100 instructions long??? Or are they super-efficient >short programs padded with 50 point imp spirals??? Many of those programs, such as the ones I have on the hill, take advantage of boot-strapping. This is where part of your code is moved to a different location before being executed. If you have a small program that can be moved with only a few instructions, then this can greatly improve your score. Much of the idea behind bootstrapping is to leave behind some kind of decoy that will attract the attention of any scanners and quick-scanners that you may be competing against. After all, any time they spend attacking your decoy is time they _won't_ spend attacking you. That is why my programs on the hill are all 100 instructions long -- to _increase_ their chances of being found. (By the way, with the addition of a-indirection, it is becoming more important than ever that you modify your bootstrapping code so that it doesn't leave any pointers to your real program after the boot-strapping has occurred. This may be why Insight is doing as well as it is.) Good luck with your efforts! -- Brant D. Thomsen Man will occasionally stumble over the truth, (bdthomse@peruvian.cs.utah.edu) but most times he will pick himself up University of Utah and carry on. - Winston Churchill From: ratzburg@omnifest.uwm.edu (Linda Ratzburg) Subject: Re: Q: Neural Nets ? Date: 14 Jun 1994 16:14:53 -0500 Message-ID: <2tl6kd$144@omnifest.uwm.edu> Sounds cool but I have one question: How? ### From: pk6811s@acad.drake.edu Subject: Re: length 100??? Date: 15 Jun 94 08:19:38 CST Message-ID: <1994Jun15.081938.1@acad.drake.edu> In article , ez003207@chip.ucdavis.edu (Rrrrrrryan) writes: >... > then...So what went wrong? Is my scanning engine just too slow? Are all > those programs really 100 instructions long??? Or are they super-efficient > short programs padded with 50 point imp spirals??? > I can vouch for Keystone and Torch. They both copy their active code away from the startup location, leaving a large decoy behind. Against a quick-scanning opponent I should have 10-20 cycles to get away, then while he attacks the decoy my program does its thing. 'booting' or 'bootstrapping' is a time-honored way of distracting scanners. Here's the source for Keystone so you know what you are up against: ;redcode-94 quiet ;name Keystone t33 ;kill Keystone ;author P.Kline ;strategy stone + anti-vamp ;macro spacing equ 2517 ; mod-1, approximates a mod-4 step for 29 dat #-(start*8),2667 rof start mov #-6,hideto+5582 ; avamp pointer mov #100,hideto+5582+78 mov hide4,inc-2269 mov -27 ; moved by stone onto hide3 hide6 djn.f #0,<-25 ; moved by stone onto cnt for gate hideto dat #7242-2073-8+527 hidefr dat #hide3+1 hptr2 dat #hide6+2512+527+1 hide7 djn.f 0,>-26 ; moved by stone onto hide3 hide8 djn.f #0,<-24 ; moved by stone onto cnt for gate for 37 dat #-(start*8),2667 rof end start Paul Kline @c@ pk6811s@acad.drake.edu - ignorance exceeded only by inquisitance - From: phy2ps@leeds.ac.uk (SKELTON P.) Subject: Evolution of battle programs Message-ID: Date: Wed, 15 Jun 1994 13:50:48 GMT This is an idea that came back to me after someone suggested using neural networks to train programs. The idea started whenI read an article in 'The New Scientist' about some guy who had written and evolution simulator on his computer. It consisted of a world - a linear section of memory rather like the core in corewar - which was populated by a bunch of organisms - which were basically programs. In his simulation, the programs could replicate themselves, though the simulator introduced random errors into the programs code, rather analogous to random mutation of genes in cells in replication, which is the basis of evolution. Naturally, the programs evolved to more efficient forms (because of competition for limited resources, namely processor time and available memory), while inefficient, unsucessful programs tended to die out. So here is my suggestion. Why not use a setup something like this to produce battle programs via evolution. You could use a setup where there were many programs in a very large core, fighting it out with each other. Each would also have to be able to replicate itself, with the controling program changing some of the instructions in the program each time. Most programs produced will be useless, but every now and again a more efficient program comes along. If the simulator is left running for long enough (and we could be talking in terms of a few days here), then eventually you should end up with a very sucessful program. Or that is the theory. Then you can just pick out the attack/ defense routines that work the best, and use them in your programs. It might not work quite so nicely of course. For a start, since battle programs tend to be rather agressive creatures at the best of times, they may just wipe each other out rather quickly, which would rather defeat the point of the exercise. Or they way go to the other extreme and become a collection of peacfully cohabiting pacifist programs (an electronic commune), in which case they aren't much use. I don't know what sort of results to expect from this, as I haven't had time to do it myself (what with exams and things), so i just thought that I'd mention it to see what other people thought, or to see if anyone has already tried it. Any (polite) comments welcome. Phill Skelton From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Re: length 100??? Message-ID: Date: 15 Jun 1994 15:12:01 GMT In article ez003207@chip.ucdavis.edu (Rrrrrrryan) writes: > From: ez003207@chip.ucdavis.edu (Rrrrrrryan) > Subject: length 100??? > Date: 14 Jun 1994 04:49:55 PST-8 > > This is to the people on the '94 draft hill: > > I submitted my best program to date to the '94 draft hill (Viewmaster > 4.1 - a 2 pass core clear, 0.66c quickscanner..). It's been on the top of > the beginner hill for a while (age 21), so I thought I'd give it a shot. > Alas, I only made it to #20 for about an hour or so...The thing is, is that > in all my testing, Viewmaster kicks ass most against large programs (this is > intrinsic to quickscanners, right?) and of the 20 programs on the '94 draft > hill, _15_ of them were 90 instructions or more! I thought I'd do at least ok > then...So what went wrong? Is my scanning engine just too slow? Are all > those programs really 100 instructions long??? Or are they super-efficient > short programs padded with 50 point imp spirals??? > > > Still trying, > > Ryan They usually are not-so-large programs padded with decoy, with bootstrapping. My feeling is that they usually have 20-40 useful instructions, the rest is bootstrapping/decoy. Once your quickscan has detected something, it's not enough to bomb the detected location: you have to bomb 100 locations around it as well (although not necessarily *all* of them; every 4 or 6 seems to do nicely). And even then, you might be bombing and empty decoy, so you need a decent follow-through, especially since you just spent 100+ cycles bombing in the air. If your quickscan doesn't find anything, you're in trouble: you just gave away 80+ cycles to your opponent's stone or vampire. That is not counting quickscanners, but the quickscan code is virtually a decoy after it's used, and it's used in the first 100 or so cycles. If you're not already dead, it means you're pretty much even. BTW, a 2/3c scan doesn't qualify as "quick"... The normal ADD/CMP/JMP loop is that fast. The best quickscans (Pyramid or Plasma) scan at 2c, which is the fastest possible using Redcode. The slower but more compact "Fscan", using indirect-A addressing, scans at 1c. -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science & Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: Dave Darling Subject: Re: Evolution of battle programs Message-ID: <1994Jun15.170650.26188@riacs.edu> Date: Wed, 15 Jun 94 17:06:50 GMT In article SKELTON P., phy2ps@leeds.ac.uk writes: >'The New Scientist' about some guy who had written and evolution simulator on >his computer. It consisted of a world - a linear section of memory rather like >the core in corewar - which was populated by a bunch of organisms - which were >basically programs. This sounds very much like Tom (?) Ray's TIERRA A-life program. A very in- teresting system. Each "organism" has its own virtual CPU, with registers, etc. You can't mess with someone else's CPU, or change their instructions (as of several versions back--I'm not current) but you could execute their instructions to copy yourself. Interesting to see parasites (viruses?) evolve that did that. > > It might not work quite so nicely of course. For a start, since battle >programs tend to be rather agressive creatures at the best of times, they may >just wipe each other out rather quickly, which would rather defeat the point >of the exercise. It would be *very* difficult to evolve anything but a paper. You *might* get a wonderful anti-paper paper, but it wouldn't be "designed" to cope with anything that wasn't a paper. It seems to be a pretty good tool to explore the idea of evolution, but probably wouldn't evolve a very good warrior. The approach that is going on right now seems to be a better way to actu- ally evolve a good warrior--take a random program, fight it against either other randoms, or against various "real" warriors, and then copy the most suc- cessful programs (some with changes). It still seems to take quite a long time. --DD Dave Darling, | HELP! I'm in TQM training, Cockpit Graphics Programmer | and I can't get up! GU d--@ -p+(p-) c+ !l(l--) u++(u--) e- m---@ s+/+ n+@ h+ f? g-(g+) w++ t++ r+@ y* From: lewin@netcom.com (Karl Lewin) Subject: Re: Evolution of battle programs Message-ID: Date: Wed, 15 Jun 1994 21:11:40 GMT The program that is described you describe sounds somewhat like TIERRA by Tom Ray. As far as evolutions with regards to corewar there is a paper about it that can be FTP'd from ftp.csua.berkeley.edu that is titled evolving.something or other. Also there are several people currently playing around with using GA's to develop warriors. I have dabbled with this type of thing and really ahvn't come up with anything very interesting yet although the latest run produced much more interesting warriors that the first, at least I think so :) Here is one of the better warriors to evolve lately (any comments/observations/etc?) ;redcode-94 ;name W0078V00 ;author RC94 Evolver v2 ;fitness score 106 ; vs Rave 4.1 Results: 6 19 0 ; vs Pyramid2 Results: 18 3 4 ; vs Blitz 94 Results: 2 11 12 ; vs Paradox2 Results: 0 13 12 ORG 3 DAT.B # -13, $ -6 DAT.F < -15, > -7 MOV.BA > -10, @ -13 MOV.BA > -9, < -9 SEQ.F < -15, @ 3 MUL.F @ -8, $ -9 DJN.X # 9, > 10 SPL.X # -2, > 1 SPL.X # -2, > 13 SPL.A < -2, > 13 SLT.I > 6, > 11 DAT.F # -4, # 12 MOD.X > -3, < -6 JMP.AB # 7, @ 15 SLT.I # -13, < 1 JMZ.F < 2, @ -9 NOP.F < 1, @ -13 SPL.X < -2, > -15 SPL.F > -15, < 8 MUL.F @ -8, $ -9 SPL.X < -2, > -15 SEQ.F < -15, @ 8 MUL.F @ -8, $ -9 DJN.X # 9, > 10 SPL.X # -2, > 13 MOV.F < 2, @ -9 SUB.B < 5, # -14 SPL.F < -15, @ 9 DAT.A > -2, < 10 JMZ.X @ 12, $ -15 SLT.I # 5, @ -8 DJN.AB $ 7, < -15 DAT.X $ 9, $ -3 MOD.X > -3, < -6 JMP.AB # 7, @ 15 SLT.I # -13, < 1 JMZ.F < 2, @ -9 NOP.F < 1, @ -13 DAT.BA $ 1, < 13 DAT.BA $ 4, $ 12 SLT.F < 13, > -6 SLT.I < 6, > 11 SLT.I # 5, @ -8 SPL.X < -2, > -15 SEQ.F < -15, @ 9 MUL.AB @ -8, $ -9 DJN.X # 9, > 10 SPL.X # -2, > 13 SPL.X # -2, > 13 JMZ.F < 2, @ -9 NOP.F < -2, @ -13 SPL.X < -2, > -15 SPL.F > -15, < 8 SUB.B < 5, # 15 MOD.X > -12, < 2 SLT.I # -13, < 1 JMZ.F < 2, @ -9 NOP.F < 1, @ -13 SPL.X < -2, > -15 MOV.BA > -10, @ -13 SEQ.A # -12, >-3998 MOV.X # -5, @ 6 MUL.A > -10, @ 2950 JMN.X < -7, @ -10 DAT.I > -2, @ 5 DAT.BA > -7, < 10 SLT.I > 6, > 11 SPL.X > -12, $ 2 DAT.BA < -15, > -7 JMP.BA > -10, @ -13 ADD.AB < -12, >-3998 SEQ.BA $ -4, @ -9 SEQ.A < 11, >-3998 SEQ.BA $ -4, # -9 DIV.BA @ 5, @ 4 SPL.B > -12, $ 2 NOP.AB # 12, # -4 DJN.AB $ 7, < -15 MOV.X # -5, @ 10 SUB.B @ 5, # 15 SUB.BA > -7, # -4 NOP.BA $ 5, $ 4 SPL.I > -12, < 2 NOP.AB > 12, # -4 SPL.X > -12, < 2 DAT.BA $ 1, < 13 DJN.X # 9, > 10 SPL.X # -2, > 13 SLT.I < 13, @ -6 SLT.I > 6, > 11 ADD.F # -4, # 12 SPL.X < -2, > -15 DJN.X # 9, > 10 SPL.X # -2, > 13 SLT.F < 13, @ -6 MOV.BA > -9, < -9 SEQ.F < -15, @ 3 SPL.A # -12, > 11 DAT.I # -4, $ 7881 SPL.A # -12, > 7 -- ==================================== Karl Lewin lewin@netcom.com ==================================== From: al663@FreeNet.Carleton.CA (Chris Sibbitt) Subject: Help!!! Program types.... Message-ID: Date: Wed, 15 Jun 1994 21:48:56 GMT Well, my first entry to koth rcked up something like 17.68 points... obviously not very effective.... But I did notice a patern... most of the successfull progs. on the hill were vamp, anti-vamp programs... I may be mistaken, but I think that was it... Anyways, my problem is this.. What are the types of programs? What strategies do they use. I've seen references to Vampires, Papers, Imps, Dwarfs, Gates, Gatebreakers, and probably others that I can't remember. If anyone has a file explaining these strategies and how to create them, or even a good explanation of each, I'd love for you to send it to me... at my above address as I have no FTP access.... Thanx alot. -Chris (I will figure out the redcode thing) -- | Name: Chris Sibbitt (a.k.a. Wanderer) |Burble............GAK! |����� | Address: al663@freenet.carleton.ca | So? Sue me! |����� +----------------------------------------+-----------------------------+����� GU(cs/m) d(?) (-)p(+) c++@ l u(+) e* m--- s+ !n(---) h(--) f+@ !g w+@ t+ r x? From: pk6811s@acad.drake.edu Subject: Re: Evolution of battle programs Date: 15 Jun 94 22:56:50 CST Message-ID: <1994Jun15.225650.1@acad.drake.edu> In article <1994Jun15.234934.21897@llyene.jpl.nasa.gov>, jlayland@kilroy.jpl.nasa.gov (James Layland) writes: > In article , Karl Lewin wrote: >>Here is one of the better warriors to evolve lately (any >>comments/observations/etc?) >> >>;redcode-94 >>;name W0078V00 > ... > > > Unfortunately, this is a return to the one-line DJN programs. Begining with > the 4th cycle, the program spends all its time executing the last line > above: DJN.X #9, >10 > > I believe that DJN.X is equivalent to DJN.F. > > There is a big leap from here to creating even a 3-line bomber, and an even > bigger one to creating the sort of multiple-strategy warriors which can rise > to the top of the Hill. > Uh, I suppose I should admit that W0078V00 trounced Torch :-( Paul Kline @c@ pk6811s@acad.drake.edu - ignorance exceeded only by inquisitance - From: jlayland@kilroy.jpl.nasa.gov (James Layland) Subject: Re: Evolution of battle programs Message-ID: <1994Jun15.234934.21897@llyene.jpl.nasa.gov> Date: Wed, 15 Jun 1994 23:49:34 GMT In article , Karl Lewin wrote: >Here is one of the better warriors to evolve lately (any >comments/observations/etc?) > >;redcode-94 >;name W0078V00 >;author RC94 Evolver v2 >;fitness score 106 >; vs Rave 4.1 Results: 6 19 0 >; vs Pyramid2 Results: 18 3 4 >; vs Blitz 94 Results: 2 11 12 >; vs Paradox2 Results: 0 13 12 >ORG 3 >DAT.B # -13, $ -6 >DAT.F < -15, > -7 >MOV.BA > -10, @ -13 >MOV.BA > -9, < -9 >SEQ.F < -15, @ 3 >MUL.F @ -8, $ -9 >DJN.X # 9, > 10 ... Unfortunately, this is a return to the one-line DJN programs. Begining with the 4th cycle, the program spends all its time executing the last line above: DJN.X #9, >10 I believe that DJN.X is equivalent to DJN.F. There is a big leap from here to creating even a 3-line bomber, and an even bigger one to creating the sort of multiple-strategy warriors which can rise to the top of the Hill. Good luck. -- James Layland jlayland@grissom.jpl.nasa.gov From: lewin@netcom.com (Karl Lewin) Subject: Re: Evolution of battle programs Message-ID: Date: Thu, 16 Jun 1994 03:37:59 GMT I posted a warrior from the most recent run of my I-thought-it-was-working-better-but-apparently-not corewar evolver earlier today and have since found out it is still converging on a one line DJN again (thanks to Stefan and James L. for the analysis) Back to the drawing board I guess Karl If anyone wants the source for the system it is written in VX-REXX for OS/2 but should be readable if you have knowledge of almost any programming language. -- ==================================== Karl Lewin lewin@netcom.com ==================================== From: mreddy@uk.ac.glamorgan (Mike Reddy) Subject: Re: Evolution of battle programs Message-ID: Date: Thu, 16 Jun 1994 11:32:56 GMT In article SKELTON P., phy2ps@leeds.ac.uk > writes: >'The New Scientist' about some guy who had written and evolution >simulator on >his computer. It consisted of a world - a linear section of memory > rather like >the core in corewar - which was populated by a bunch of organisms - > which were >basically programs. Yes, definitely Tierra, which can be obtained for Dos and Unix. Well worth a look, if you are interested. Also discussed in Stephen Levy's excellent book "Artificial Life" In article <1994Jun15.170650.26188@riacs.edu>, Dave Darling wrote: > It would be *very* difficult to evolve anything but a paper. You *might* > get a wonderful anti-paper paper, but it wouldn't be "designed" to cope > with > anything that wasn't a paper. It seems to be a pretty good tool to > explore > the idea of evolution, but probably wouldn't evolve a very good warrior. Not sure I agree with this - it does not seem to be supported by the work that has been done to date. In fact, one of my students is to do a project on a genetic algorithm/programming approach to developing warriors, but at the bit level rather than instruction level (which, I believe, all previous attempts have concentrated on). We therefore expect to get a lot of rubbish along with (hopefully) a few good programs. In summary, the idea has definitely been discussed here before. I recommend the original poster to look at the archives of this news group and email the relevant parties - of which I count myself as one. Yours Mike Reddy -- P.S. I would have had a witty signature, but the Government put VAT on it! P.P.S. I live at mreddy@uk.ac.glamorgan OR mreddy@glamorgan.ac.uk if you are unlucky enough to live outside the UK! 8-) From: Walter.Harms@arbi.informatik.uni-oldenburg.de (Walter Harms) Subject: Re: Evolution of battle programs Date: Thu, 16 Jun 1994 12:17:46 GMT Message-ID: <1994Jun16.121927.1319@arbi.Informatik.Uni-Oldenburg.DE> you need some clever algorithem to cross and mutate because prg1 X prg2 != any prg; most times junk walter-- #################################################################### "Life starts at '030, fun starts at '040, impotence starts at '86" keyboard not connected -- press F1 to continue <><><><><><>alles nur gestohlen, alles nur geraubt ..<><><><><><><><> From: mslevine@acsu.buffalo.edu (Ming S Levine) Subject: Help for A Neophyte Message-ID: Date: Thu, 16 Jun 1994 13:35:47 GMT I am a newcomer to corewars (the concept). I've never played it, but it sounds fascinating. What would be the best software for it to run on either a Mac or a PC? Is there any prerequisite knowledge for playing? -- \|||||||/ (^ ^) (0 0) Different is good ----oOO---(!)---OOo---- --Arby's From: kay@lucie.wupper.de (Kay Hamacher) Subject: Re: Q: Neural Nets ? Date: 16 Jun 1994 17:34:27 GMT Message-ID: <2tq2f3$5q@lucie.wupper.de> As I have no concrete Vision, I have asked the net ;-) -- -------------------------------------------------------------------------- Kay Hamacher Phone : ++ 49 2332 80650 Milskotter Str. 19 Fax : ++ 49 2332 83518 58285 Gevelsberg InterNet: kay@lucie.wupper.de Federal Republic of Germany - European Union Man trauert der Vergangenheit nach, fuerchtet die Zukunft und vergisst dabei die Gegenwart ! Denn wer weiss schon, dass die Gegenwart die Geschichte der Zukunft ist ? From: kay@lucie.wupper.de (Kay Hamacher) Subject: Re: Evolution of battle programs Date: 16 Jun 1994 17:48:12 GMT Message-ID: <2tq38s$5q@lucie.wupper.de> In article , phy2ps@leeds.ac.uk (SKELTON P.) writes: |> This is an idea that came back to me after someone suggested using |> neural networks to train programs. Yes, that was me ! |> his computer. It consisted of a world - a linear section of memory rather like |> the core in corewar - which was populated by a bunch of organisms - which were |> basically programs. In his simulation, the programs could replicate |> themselves, though the simulator introduced random errors into the programs |> code, rather analogous to random mutation of genes in cells in replication, |> which is the basis of evolution. Naturally, the programs evolved to more |> efficient forms (because of competition for limited resources, namely |> processor time and available memory), while inefficient, unsucessful programs |> tended to die out. Yes, that seems to be Tierra. A simulator (I think for SunOS and/or DOS ?) which implements a virtuell parallel-computer. Each processor computes the life of an individuum. This evolution is nice, but the improvement of fitness is done by evolution and not by the mind of the programmer. So there is no real competition between humans ! I had in mind to create a simulated world, which can be exachange messages with self-programmed neural nets (uups, it seems a little object-oriented !) about the status of the world. The nets compete against each other by learning what was right or what was false. There must be a clearly defined Interface between the nets and the simulator to exchange messages, but I think that is not the problem. The problem will be a defintion of "false". There must be quality-function for decisions of the nets ! Corewar-like behaviour (dead or alive) is here not the solution. I think there must be a "Health"-Status of each net, which can be consultate if a decision was "good" or "bad". So if one net attacks an other net it will not kill it (unless it has learned how to do so), but "hurt" it, so that the attacked net can learn how to "protect" or "flie". So by trying this, You may be able to determine whether a neural net structure is able to "survive" in hard competition to an other structure. So I still ask : has someone the time and the fun to develope such software (with me) ? -- -------------------------------------------------------------------------- Kay Hamacher Phone : ++ 49 2332 80650 Milskotter Str. 19 Fax : ++ 49 2332 83518 58285 Gevelsberg InterNet: kay@lucie.wupper.de Federal Republic of Germany - European Union Man trauert der Vergangenheit nach, fuerchtet die Zukunft und vergisst dabei die Gegenwart ! Denn wer weiss schon, dass die Gegenwart die Geschichte der Zukunft ist ? From: jlayland@kilroy.jpl.nasa.gov (James Layland) Subject: One-line DJN vs. '94 Hill Message-ID: <1994Jun16.185211.3565@llyene.jpl.nasa.gov> Date: Thu, 16 Jun 1994 18:52:11 GMT After seeing Karl Lewin's post, I submitted a one-line warrior to the hill: djn.f #55, <-55 ;numbers chosen for no good reason In case anyone but me was curious, here are the results. Clearly, the DJN can not kill anything which has a SPL/JMP/DJN #xx instruction. It is a perfect gate, so can not be killed by an imp. It is small enough that it is likely to survive many bombing runs which are not followed by a core clear. Scanners are obvious candidates to succumb to this, and the DJN wins roughly 50% against the 3 scanners on the hill. However, it also does fairly well against 5 other warriors, including a couple gate-busting spirals, a quickscan/stone, a vampire, and (as Paul mentioned) Torch. (I don't have code for Torch, but I assume it can not be self-splitting and maintain reliable timing to use incendiary bombs-- SPL-JMP bombers have the same problem.) Cannonade, Sauron, and Aleph 0 use an extra-extra stone with a SPL -1 instead of a SPL #x, so they can be killed by the DJN.F. Perhaps Aeka has the same problem? I am not sure why Stimpy (A/B field SPL-JMP scanner from ;strategy) fares so much better than the conventional CMP-scanners. One possibility would be if the JMP in the main loop could be decremented once and still point to executable code (i.e. bombing routine is before scanner instead of after). I am not sure if I learned much from this, other than perhaps realizing the vulnerability of extra-extra stones to '94 DJN streams. Too bad, I always liked having easily predictable execution order in a self-splitting program. If anyone is interested, here is a complete list of scores. Rave 4.1 56-44-0 (rave wins 56, DJN wins 44, 0 ties) Dragon Spear 53-47-0 Iron Gate 1.5 48-52-0 Sauron v6.0 37-49-14 Aeka 48-52-0 Cannonade 61-39-0 Torch t3 43-37-10 Christopher 28-37-35 Stimpy v2.0 78-22-0 Aleph 0 49-13-38 test 43-4-53 NC 94 27-0-73 Blue Funk 23-0-77 B-Panama IX 74-0-26 Keystone t33 41-0-59 Request v2.0 30-0-70 Pyramid v5.5 88-0-12 mmfP v2 96-0-4 Insight v1.0 100-0-0 Lucky 3 100-0-0 -- James Layland jlayland@grissom.jpl.nasa.gov From: jlayland@kilroy.jpl.nasa.gov (James Layland) Subject: Re: One-line DJN vs. '94 Hill Message-ID: <1994Jun16.204152.5124@llyene.jpl.nasa.gov> Date: Thu, 16 Jun 1994 20:41:52 GMT Following up my own article... In article <1994Jun16.185211.3565@llyene.jpl.nasa.gov>, James Layland wrote: >I am not sure if I learned much from this, other than perhaps realizing >the vulnerability of extra-extra stones to '94 DJN streams. Too bad, On second thought, this is not likely to be a big factor against a real warrior program. The "advantage" of a stone using SPL #x vs. SPL -1 is that the former can withstand being continually decremented by a DJN.F, while the latter will eventually be killed. In either case, however, the result after one pass by a DJN stream is an impotent program, which can easily be killed by a coreclear. The SPL #x will pick up extra ties only when the enemy coreclear has been destroyed. While this is nice, it is hardly likely to be a major design criterion. Actually, it may be better for the stone to die as soon as it becomes useless because of decrementing. If the warrior has other components which are still functional, the cycles spent in an incapacitated bombing loop could be better spent elsewhere. One other comment-- in standard bombing loop architectures, after a single pass by a DJN, a loop with a SPL #x begins accumulating cycles faster, while a loop using SPL -1 stops accumulating cycles after a single DJN pass (and dies on the second). Of course the SPL -1 loop accumulates cycles much faster before being decremented, so I'm not sure what to conclude from all this... -- James Layland jlayland@grissom.jpl.nasa.gov From: pk6811s@acad.drake.edu Subject: Re: One-line DJN vs. '94 Hill Date: 16 Jun 94 23:04:05 CST Message-ID: <1994Jun16.230405.1@acad.drake.edu> In article <> jlayland@kilroy.jpl.nasa.gov (James Layland) writes: > After seeing Karl Lewin's post, I submitted a one-line warrior to the hill: > djn.f #55, <-55 ;numbers chosen for no good reason > > In case anyone but me was curious, here are the results. Clearly, the > DJN can not kill anything which has a SPL/JMP/DJN #xx instruction. It > is a perfect gate, so can not be killed by an imp. It is small enough ^^^^^^^^^^^^^^^^^^^^^^^^^^^ If I read your table correctly, it looks like Cannonade's gate-busting technique worked though :-) > that it is likely to survive many bombing runs which are not followed > by a core clear. Scanners are obvious candidates to succumb to this, > and the DJN wins roughly 50% against the 3 scanners on the hill. > However, it also does fairly well against 5 other warriors, including > a couple gate-busting spirals, a quickscan/stone, a vampire, and (as > Paul mentioned) Torch. (I don't have code for Torch, but I assume it > can not be self-splitting and maintain reliable timing to use incendiary ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Actually Torch DOES self-split AND maintains reliable timing. I discovered that the instructions execute in reverse order. See listing below. Thanks for running this test. Gives one much to think about.... ;redcode-94 verbose ;name Torch t3 ;kill Torch ;author P.Kline ;strategy very rapid incendiary bombing, core-clear & gate ;strategy plus decoy & boot ;macro step equ 73 count equ 1500 boot1 equ 2150 boot2 equ 3508 start jmn.f copy2,@copy1 copy1 mov -step+1,<-step copy2 mov -step ; spl half of the incendiary in add #step+step,msm ; in,msm,msp execute in reverse order msm mov sm,>tgt-(step*count) msp mov sp,@msm ; bomb alternately with spl & mov tgt djn.f in,>3157 ; bombed with spl to start clear clr mov gate,<-13 cp djn.f clr,>3 copyf dat #0 for 31 mov.i #sp,2667 rof sm mov @0,>step ; mov half of the incendiary for 9 mov.i #sp,2667 rof end start Paul Kline @c@ pk6811s@acad.drake.edu - ignorance exceeded only by inquisitance - From: jjfloyd@vela.acs.oakland.edu (Jered Floyd) Subject: Re: Evolution of battle programs Date: 17 Jun 1994 02:04:06 GMT Message-ID: <2tr0am$dgd@oak.oakland.edu> I have been, and will finish as soon as I settle in with my new job, a GA evolver for corewars which I expect to perform nicely. -- Jered Floyd jjfloyd@vela.acs.oakland.edu Geek Code: GAT d? -p+ c++++ l+ u++ e*@ m++ s/-- n--- h++ f? g- w++ t+++ r++ PGP Public key, Geek Code, picture, and assorted humor available by finger. From: rrognlie@netcom.com (Richard Rognlie) Subject: KotH Behaviour Message-ID: Date: Fri, 17 Jun 1994 12:49:47 GMT Greetings! I have been watching (but not participating) the corewar forum for a while with an eye toward a similar (but quite different) project. I am wondering how the King of the Hill standings are figured. Is it a start at the bottom, and challenge your way up the ladder, and your position is where you lose? Or is it challenge everyone in the pool, and your standing is based on your win-loss records vs. theirs? My project will be a robot simulator in which you will program a virtual robot in GNU C++ (with the ability to scan, shoot, move and determine current status) then then 2+ robots will be placed in the arena to fight it out. Thanks in advance, Richard Rognlie -- /\/\/\ | Richard Rognlie / Sr. Computer Analyst / PRC Inc. / McLean, VA / \ \ \ | E-Mail: rrognlie@netcom.com *or* rognlie_richard@prc.com \ / / / | Phone: (Home) (703) 361-4764 (Office) (703) 556-2458 \/\/\/ | (Fax) (703) 556-1174 From: ehope@juno.gac.edu (Eric A Hope) Subject: Re: Help for A Neophyte Date: 17 Jun 1994 18:13:47 GMT Message-ID: <2tsp4rINNql2@news.gac.edu> mslevine@acsu.buffalo.edu (Ming S Levine) writes: >I am a newcomer to corewars (the concept). I've never played it, but it >sounds fascinating. What would be the best software for it to run on either >a Mac or a PC? Is there any prerequisite knowledge for playing? >-- > \|||||||/ > (^ ^) > (0 0) Different is good >----oOO---(!)---OOo---- --Arby's I understand that Redcoder-20 for the Mac is considered good. For the PC you might try pmars05s which is what I use. As for pre-requisite knowledge, past programming experiance helps a good deal, but isn't required. The only thing you really need is a willingness to experiment. Eric Hope ehope@nic.gac.edu Proud holder of the 20th spot on the beginners' hill for all of three days! (I'll take what I can get!) From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: KotH Behaviour, C-Robots Date: 17 Jun 1994 18:28:56 GMT Message-ID: <2tsq19$8jt@agate.berkeley.edu> Richard Rognlie wrote: >I am wondering how the King of the Hill standings are figured. Is it >a start at the bottom, and challenge your way up the ladder, and your >position is where you lose? Or is it challenge everyone in the pool, >and your standing is based on your win-loss records vs. theirs? Option #2. You fight against everyone and your overall record determines your score. When a new program gets onto the hill, then your record against the previous worst program (which has just been pushed off the hill) is discarded, and replaced by your record against the new program. >My project will be a robot simulator in which you will program a virtual >robot in GNU C++ (with the ability to scan, shoot, move and determine >current status) then then 2+ robots will be placed in the arena to >fight it out. Have you seen C-Robots? It's almost the same idea... you might want to check it out. I'm too lazy to run archie myself but it's available for ftp at several sites. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: emp305@sashimi.wwa.com (Jeffrey S. Hady) Subject: How do I start? Date: 17 Jun 1994 18:42:26 -0500 Message-ID: <2ttcd2$fil@sashimi.wwa.com> What is required to play corewar? How do I start? Are there any reference books available? Thanks in advance! Jeffrey Hady From: bharat@shadow.Eng.Sun.COM (Bharat Mediratta) Subject: Re: KotH Behaviour, C-Robots Date: 17 Jun 1994 21:03:25 GMT Message-ID: <2tt32t$rfr@engnews2.Eng.Sun.COM> In article 8jt@agate.berkeley.edu, mconst@soda.berkeley.edu (Michael Constant) writes: >Richard Rognlie wrote: >>My project will be a robot simulator in which you will program a virtual >>robot in GNU C++ (with the ability to scan, shoot, move and determine >>current status) then then 2+ robots will be placed in the arena to >>fight it out. > >Have you seen C-Robots? It's almost the same idea... you might want to >check it out. I'm too lazy to run archie myself but it's available for >ftp at several sites. I have written a Unix variant of C-Robots that uses shared memory and the unix scheduler to have up to 4 robots duke it out in real time. I just need an ftp site to upload the binaries to. Interested? -Bharat --- Bharat Mediratta | Above opinions are mine and have bharat.mediratta@eng.sun.com | nothing to do with Sun Microsystems From: rlsnell@phoenix.oulu.fi (Ritvaliisa Snellman) Subject: Re: Evolution of battle programs Date: 18 Jun 1994 03:41:48 GMT Message-ID: <2ttqds$gto@ousrvr.oulu.fi> Mike Reddy (mreddy@uk.ac.glamorgan) wrote: : In article SKELTON P., phy2ps@leeds.ac.uk : > writes: : >'The New Scientist' about some guy who had written and evolution : >simulator on : >his computer. It consisted of a world - a linear section of memory : > rather like : >the core in corewar - which was populated by a bunch of organisms - : > which were : >basically programs. : Yes, definitely Tierra, which can be obtained for Dos and Unix. Well worth : a look, if you are interested. Also discussed in Stephen Levy's excellent : book "Artificial Life" Is Tierra freely distributable ? If it is, where could i get it ? -Poke Snellman From: bdthomse@peruvian.cs.utah.edu (Brant Thomsen) Subject: Stimpy source Date: 18 Jun 1994 04:43:50 GMT Message-ID: <2ttu26$fbt@magus.cs.utah.edu> The following is the code for Stimpy. The ;strategy line is somewhat misleading, as this is not a true scanner. Rather, it bombs the core with SPL 0 instructions, and drops a JMP -1 instruction immediately after the SPL 0 if either of the fields in that location are non-zero. Basically, it's my attempt at a SPL/JMP bomber that doesn't take four cycles to drop each bomb. The SPL/DAT coreclear was added with version two. It isn't as clean as I would like, as there end up being three SPL 0 statements preceding the DAT statement for the final imp-gate after the core-clear. Still, since the processes tend to collect in the last SPL statement, the final gate retains most of its effectiveness -- especially against the small imp-spirals that tend to remain after a SPL/DAT core-clear has been executed. ;redcode-94 ;name Stimpy v2.0 ;author Brant D. Thomsen ;strategy SPL/JMP A/B field scanner w/ SPL/DAT core-clear. ;strategy Submitted: @date@ ;macro step equ 2365 init equ 1 + step dat.A #1, #1 dat.A #1, <1 dat.A #1, @1 . . [Huge decoy deleted] . dat.I @1, 1 dat.I @1, >1 dat.I 1, 1 start mov.I db, db - point - step - 1 ; The bootstrapping distance is chosen ; such that this instruction is overwritten ; by the first bomb. ; (In case of tracing.) add #ptr - db, start mov.I ptr, @start sub #ptr - jump - 1, start for 8 mov.I point point jmz.F -2, init ; Hit here to end jmn.A top, -1 split spl #0, <-ptr mov.I @begin, For the first time in several months, corewar has dropped from the "Net PC Games Top 100" list posted weekly on comp.sys.ibm.pc.games.announce. If you spend any time at all playing corewar, help to put corewar back on the list by sending mail to "jojo@hacktic.nl" with message body 5 Core Wars Intern. Core Wars Society [1227] The "5" is the number of points you assign and reflects the amount of time you spend playing a game. The total number of points per vote cannot exceed 20, and you can have a maximum of 5 for a single game. Check out the list on csipga for details. People who vote get the top 100 list by email; one vote is good for 4 weeks after which you are reminded to renew your vote. Goal: let's get corewar into the top 10! -Stefan (stst@vuse.vanderbilt.edu) From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Help for A Neophyte Message-ID: <1994Jun20.070047.12124@news.vanderbilt.edu> Date: Mon, 20 Jun 1994 07:00:47 GMT In article <2tsp4rINNql2@news.gac.edu> ehope@juno.gac.edu (Eric A Hope) writes: >mslevine@acsu.buffalo.edu (Ming S Levine) writes: > >>sounds fascinating. What would be the best software for it to run on either >>a Mac or a PC? > >I understand that Redcoder-20 for the Mac is considered good. >For the PC you might try pmars05s which is what I use. Let me expand on this: if you plan on programming in ICWS'88, your choices are Core! and Redcoder for the Mac, and at least five very good simulators for the PC (all at soda.berkeley.edu:/pub/corewar/ systems). For ICWS'94 as it is currently proposed in pub/corewar/documents/ icws94.0202, you have can use either Redcoder (Mac) or pMARS (PC, UNIX,..). However, if you want to compete on the -94 and -94x hills with the NOP, SNE and A-field indirect addressing extensions, you're pretty much stuck with pMARS, since the latest Redcoder still uses the assembler from pMARS v0.4. -Stefan (stst@vuse.vanderbilt.edu) From: bdthomse@peruvian.cs.utah.edu (Brant Thomsen) Subject: The '94 Warrior Date: 21 Jun 1994 07:31:57 GMT Message-ID: <2u651d$a9n@magus.cs.utah.edu> __ __| | ) _ \ | | \ \ / _) | __ \ _ \ / ( | | | \ \ \ / _` | __| __| | _ \ __| | | | | __/ \__ |___ __| \ \ \ / ( | | | | ( | | _| _| |_|\___| _/ _| \_/\_/ \__,_|_| _| _|\___/ _| June 21, 1994 Issue #9 ______________________________________________________________________________ This newsletter covers the current status of the ICWS '94 Draft hills, and also attempts to keep up with the latest ideas in how the new standard will affect corewars in general. I hope you enjoy it! If you are unfamiliar with the '94 draft standard, you can learn more about it by reading the FAQ for this newsgroup. In addition, the program pMARS includes a highly recommended tutorial on the new standard. Feel free to send me e-mail if you have any difficulty finding either of them, if you need to have a corewar item mailed to you, or if you have any other questions. The FAQ is available through anonymous FTP to rtfm.mit.edu, as /pub/usenet/news.answers/games/corewar-faq.Z ______________________________________________________________________________ CHANGES and CORRECTIONS: A new version of pMARS has been released. The latest version of pMARS now has A-field indirection, and encourages the use of the ";assert" command to make sure that the hill you are running your program on is adequate. You can get it through anonymous FTP to soda.berkeley.edu. I also owe Michael Constant an apology. Sauron was removed (killed) by it's owner, rather than being pushed off of the '94 draft hill -- as I stated in the last issue of _The_'94_Warrior_. ______________________________________________________________________________ The ICWS '94 Draft Hill: Core size: 8000 instructions Max processes: 8000 per program Duration: After 80,000 cycles, a tie is declared. Max entry length: 100 instructions The current ICWS '94 Draft hill on "Pizza": # %W/ %L/ %T Name Author Score Age 1 45/ 34/ 21 Pyramid v5.5 Michael Constant 155 89 2 45/ 36/ 18 Keystone t33 P.Kline 154 111 3 40/ 27/ 33 Torch t5 P.Kline 154 4 4 36/ 23/ 40 Sasami T.Hsu 150 24 5 38/ 34/ 27 Stimpy v2.0 Brant D. Thomsen 143 40 6 39/ 37/ 23 Christopher Steven Morrell 141 232 7 30/ 19/ 51 Aeka T.Hsu 141 1 8 31/ 22/ 47 Cannonade P.Kline 141 169 9 39/ 38/ 23 Request v2.0 Brant D. Thomsen 141 342 10 30/ 19/ 51 Blue Funk Steven Morrell 140 311 11 30/ 20/ 51 Insight v1.0 Brant D. Thomsen 139 31 12 41/ 44/ 14 Iron Gate 1.5 Wayne Sheppard 138 288 13 30/ 22/ 48 B-Panama IX Steven Morrell 138 39 14 42/ 47/ 11 Rave 4.1 Stefan Strack 137 276 15 39/ 41/ 20 Sauron v6.0 Michael Constant 137 35 16 35/ 32/ 33 mmfP v2 Karl Lewin 137 42 17 32/ 28/ 41 Lucky 3 Stefan Strack 136 304 18 40/ 44/ 16 Dragon Spear c w blue 136 344 19 30/ 24/ 46 NC 94 Wayne Sheppard 136 324 20 38/ 42/ 20 Aleph 0+ Jay Han 135 21 The top three programs are still Pyramid, Keystone, and Torch. However, there is a new entry that seems to be giving them some stiff competition. Sasami, by T. Hsu, was submitted to the hill a few days ago, and has been clinging to fourth place ever since. The rest of the hill, as far as I can tell, is total chaos. I have a feeling that the next couple of weeks will be really interesting -- especially as more programs are submitted that take advantage of the latest pMARS additions. The current ICWS '94 Draft hill on "Stormking": # %W/ %L/ %T Name Author Score Age 1 45/ 29/ 26 Sauron v3.6 Michael Constant 160 1 2 41/ 27/ 32 Killer instinct Anders Ivner 155 24 3 36/ 21/ 43 Twimpede+/8000-d1 Jay Han 150 14 4 44/ 38/ 17 Ntttgtstitd Simon Hovell 150 25 5 43/ 38/ 19 Request v2.0 Brant D. Thomsen 148 17 6 34/ 21/ 44 Lucky 3 Stefan Strack 147 12 7 35/ 23/ 42 NC II Wayne Sheppard 147 79 8 35/ 25/ 40 Sphinx v5.1 W. Mintardjo 145 82 9 43/ 41/ 17 Sylvester v1.0 Brant D. Thomsen 144 61 10 29/ 19/ 53 ttti nandor sieben 139 35 11 32/ 26/ 42 JustTakingALookSee J.Layland 138 78 12 31/ 24/ 45 Snake Wayne Sheppard 138 34 13 43/ 47/ 10 Rave 4.1 Stefan Strack 138 7 14 39/ 40/ 21 tiny J.Layland 138 59 15 29/ 20/ 51 ttti94 nandor sieben 137 30 16 39/ 42/ 19 Beholder's Eye v1.7 W. Mintardjo 137 91 17 38/ 42/ 19 Christopher Steven Morrell 135 23 18 39/ 43/ 18 SJ-4 J.Layland 134 28 19 37/ 43/ 20 Fast Food v2.1 Brant D. Thomsen 131 37 20 35/ 40/ 26 pepper P.Kline 129 6 ______________________________________________________________________________ The ICWS '94 Draft Experimental Hill: Core size: 55,440 instructions Max processes: 10,000 per program Duration: After 500,000 cycles, a tie is declared. Max entry length: 200 instructions The current ICWS '94 Experimental (Big) hill on "Pizza": # %W/ %L/ %T Name Author Score Age 1 50/ 34/ 16 ivscan6b J.Layland 165 17 2 49/ 33/ 18 Request-55440 Brant D. Thomsen 164 153 3 49/ 35/ 17 Pyramid v5.3 Michael Constant 163 44 4 37/ 18/ 46 Aleph 1 Jay Han 156 15 5 42/ 34/ 24 Stimpy v2.0 Brant D. Thomsen 151 8 6 36/ 27/ 37 Variation G-1 Jay Han 145 117 7 41/ 38/ 21 Aleph 0 Jay Han 145 16 8 42/ 41/ 17 Fscan Jay Han 142 1 9 32/ 25/ 43 NotSoBigImps James Layland 140 13 10 38/ 37/ 25 Lump J.Layland 139 98 11 39/ 39/ 22 Vanity IIx Stefan Strack 138 108 12 43/ 47/ 10 Rave B4.1 Stefan Strack 138 114 13 32/ 27/ 41 Der Zweite Blitzkrieg - 9 Mike Nonemacher 138 115 14 31/ 25/ 43 Blue Funk Steven Morrell 137 7 15 42/ 46/ 12 Squint Mike Nonemacher 137 91 16 33/ 31/ 35 Lucky 13 Stefan Strack 135 159 17 42/ 48/ 10 Plasma v5 Wayne Sheppard 135 55 18 31/ 32/ 37 Sasami / 55440 T.Hsu 131 3 19 30/ 30/ 39 Splash 1 Jay Han 130 118 20 7/ 2/ 0 Fscan Jay Han 21 2 Not too much is happening on the big hill at the moment. I've noticed that the intensity tends to switch between the '94 draft and the '94 experimental hills. Then again, perhaps it's just summer break. The current ICWS '94 Experimental (Big) hill on "Stormking": # %W/ %L/ %T Name Author Score Age 1 48/ 12/ 40 Variation M-1 Jay Han 184 2 2 46/ 30/ 24 Request-55440 Brant D. Thomsen 162 54 3 40/ 20/ 40 Lucky 13 Stefan Strack 161 20 4 46/ 36/ 18 Raiden Richard van der Brug 157 3 5 45/ 35/ 19 Vanity IIx Stefan Strack 155 8 6 35/ 18/ 47 Bakers Dozen Wayne Sheppard 153 13 7 40/ 30/ 31 Sauron v2.4 Michael Constant 150 5 8 30/ 15/ 55 Imperfection v2.3 Michael Constant 146 48 9 36/ 31/ 33 Variation D-1 Jay Han 142 15 10 44/ 47/ 10 Rave B4.1 Stefan Strack 141 9 11 42/ 46/ 12 bigproba nandor sieben 138 12 12 41/ 46/ 14 Dagger v7.0 Michael Constant 136 14 13 40/ 48/ 11 The Count Jay Han 132 44 14 27/ 23/ 50 BigImp Alex MacAulay 132 95 15 30/ 29/ 41 jmpWetPaper-94x-a J.M.Pohjalainen 131 1 16 26/ 23/ 51 BigImps James Layland 129 114 17 31/ 35/ 34 Veeble Jr. T. H. Davies 126 16 18 28/ 37/ 34 Industrious Stefan Strack 119 4 19 29/ 40/ 31 Open Arms Stefan Strack 117 7 20 29/ 41/ 30 Test Stefan Strack 116 6 ______________________________________________________________________________ HINTS and HELPS: For this issue's hint, I'd like to make some suggestions about what new abilities the A-field indirection in the latest pMARS release makes possible. (I tried to come up with examples for each of these points, but couldn't find any that I was really pleased with.) Probably the most obvious benefit is the enhanced ability to store information in the A-field of instructions. With the increasing use of SPL #a, JMP #a, and MOV.I #a instructions, the are an increasing number of instructions in a program that can have their A-field used to store information. Take a look at your old programs and see if there isn't another DAT that you can eliminate, or if you can now implement a SPL/DAT core-clear with that code. Another feature that is made possible by the latest enhancements to pMARS is that anti-vampiric code is now much easier to write. It is no longer necessary to extract the A-field value from an instruction, as you can now simply use the value in that location as a pointer instead. (Actually, I'm not that excited about having better anti-vampiric programs, since I've grown fond of Request over the last few months.) I tried to take advantage of this ability when I submitted the program Insight to the hill, but it did much worse against vampires -- and better against several other programs -- than I expected. Along these same lines, I have the feeling that the latest changes to pMARS will result in more intelligent programs. For instance, much more information can be found in boot-strapping code. Instead of just being able to trace where MOV statements point to, the SPL and JMP statements will always be traceable as well. I wouldn't be surprised if there is soon a warrior on the hill that uses a quick-scanner to find bootstrapping code, then tries to exploit any information in that code. Now, more than ever, I think it will become important to spend a couple of extra instructions covering up your trail after you boot-strap. I have no doubt that there will be some interesting changes to the hill when using these new addressing modes becomes more common. I have already found myself writing programs differently to account for their effects. ______________________________________________________________________________ Looking to the Future: I'd like to (again) encourage everyone to experiment around with the latest additions to the pMARS language. Remember that A-field indirection, and the NOP and SNE instructions, have not been added to the draft of the '94 language. It will be your input that will be used to decide, later on, whether or not they will be. If you have any comments or questions about the '94 hills or the '94 draft standard that you think might be of general interest, please let me know. Also, if there are any particular topics you would like to see covered in future editions of _The_'94_Warrior_, please send me e-mail on that as well. Good luck, and happy computing! -- Brant D. Thomsen Man will occasionally stumble over the truth, (bdthomse@peruvian.cs.utah.edu) but most times he will pick himself up University of Utah and carry on. - Winston Churchill From: pk6811s@acad.drake.edu Subject: Re: The '94 Warrior (tracing boot code) Date: 21 Jun 94 08:37:41 CST Message-ID: <1994Jun21.083741.1@acad.drake.edu> In The '94 Warrior Brandt says: > exploit any information in that code. Now, more than ever, I think it will > become important to spend a couple of extra instructions covering up your > trail after you boot-strap. Eclipse II used a b-scan to find startup code, then bombed 'through' each instruction it found, hoping to catch boot pointers. It was pretty good at catching imps (using a spiral attack) and a few other programs. One thing I found in tracing startup instructions. You have to be careful about small pointers that cause you to bomb other startup instructions. You might end up destroying the pointers you were looking for. This also leads to a defensive strategy: put a- and b- references in your decoy to your own pointer instructions. Then when the scanner attacks through those references he will destroy your pointers for you. Put references both before and after the pointers. I don't know why, but I got the impression that Insight was doing some kind of trace like this, so I messed around over the weekend with Torch (also to make it a little more djn-proof :-). Here's the latest: ;redcode-94 verbose ;name Torch t5 ;kill Torch ;author P.Kline ;strategy very rapid incendiary bombing, core-clear & gate ;strategy plus decoy & boot & djn resistance ;macro step equ 73 count equ 1800 boot1 equ 2150 boot2 equ 3508 for 5 mov.i #sp-300,2667 rof smptr dat #1,#sm+boot1 ; a-ref to gtptr gtptr dat #-1,#gate+boot1 ; a-ref to smptr start jmn.f c2,@copy1 ; don't boot onto opponent's code mov smptr d2 mov gate,>gtptr copy1 jmp @0,cp+boot1 dat 0,0 dat copy1,copy1 ; a- and b-refs to copy1 gate dat >-step+1,<-step c2 mov -step ; spl half of the incendiary in add #step+step,@msp ; '@msp' for djn-resistance msm mov sm,>tgt-(step*count) msp mov sp,@msm ; bomb alternately with spl & mov tgt djn.f in,>3157 ; bombed with spl to start clear clr mov gate,<-13 cp djn.f clr,>3 copyf dat #0 for 30 mov.i #sp-300,2667 rof dat #copy1,#copy1 ; a- and b-refs to copy1 sm mov @0,>step ; mov half of the incendiary end start Paul Kline @c@ pk6811s@acad.drake.edu - ignorance exceeded only by inquisitance - From: pk6811s@acad.drake.edu Subject: Fixed start positions :-( Date: 21 Jun 94 13:19:25 CST Message-ID: <1994Jun21.131925.1@acad.drake.edu> One of the current rules on KotH is that start positions remain the same when a program is re-submitted. I would like to raise some discussion about this. In theory the rule allows one to make minor changes in the program to test their impact without the randomizing effect of changing starts. In practise this may only be true for a few situations and actually may never be true. The real effect of this rule is to freeze your opponents in place, while you are free to move around in your 100-location slot, adjust your boot distance, fiddle with your step increments, etc. This in itself is undesirable because it gives challengers an 'unnatural' advantage. It is also disruptive to testing. Here's why. As Stefan pointed out earlier, 100 battles is a very small sample of the 7900 possible, and you can expect swings of 10 or more wins/losses if changing starts are allowed. Here are three possible situations between you and your opponent: A - first set of start positions favors neither program B - first set of start positions favors your program C - first set of start positions favors your opponent If B is true, then almost any change you make to your program will probably move you to A or C, with the result that you perceive a negative result. If C is true, then almost any change you make will move you to A or B and you will perceive a positive result. Nearly any change in the program affects my 'relative' start location. Adding and removing lines has the same affect as changing my boot distance. My latest tests with Torch showed that a move of a single line can create a swing of as many as 20 wins against individual opponents, even when it is an unused decoy line. I know that against 20 opponents the swings average out, but it makes it more difficult to guess what results are due to 'strategy' change and what are inadvertantly caused by 'relocation' change. I recommend we go back to random start locations for every submission. Paul Kline @c@ pk6811s@acad.drake.edu - ignorance exceeded only by inquisitance - From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Fixed start positions :-( Date: 22 Jun 1994 01:37:49 GMT Message-ID: <2u84ld$ruj@agate.berkeley.edu> Paul Kline wrote: > It [using fixed start locations for koth] is also disruptive to testing. > Here's why. As Stefan pointed out earlier, 100 battles is a very small > sample of the 7900 [actually 15800] possible, and you can expect swings > of 10 or more wins/losses if changing starts are allowed. Here are three > possible situations between you and your opponent: > > A - first set of start positions favors neither program > B - first set of start positions favors your program > C - first set of start positions favors your opponent > > If B is true, then almost any change you make to your program will probably > move you to A or C, with the result that you perceive a negative result. > If C is true, then almost any change you make will move you to A or B and > you will perceive a positive result. But this argument applies with greater force to eliminating randomization! It works exactly the same way. With random start locations, when you submit a program, there are three equally likely possibilities (we can adjust the definition of "about" in choice A in order to make them equally likely): A - you did about as well as you should have B - you got lucky and did better than you should have C - you got unlucky and did worse than you should have By how well you "should have" done I mean how well you would have done if all possible battles had been run. Now, if you start at B and then make a trivial change to your program and resubmit it, chances are 2/3 that you will now move to either A or C, and the result is that you will perceive a significant decrease in score. The same applies for starting at A or C. (If you start at A then you will be likely to perceive a significant *change* in score, although I can't say whether it will be for better or for worse.) A trivial change will not be any more likely to significantly change your score under fixed positioning than under random positioning -- after all, the trivial change itself is random. In fact, under random positioning, you are likely to get a significantly different score even if you *don't* make the trivial change! And this allows people to keep resubmitting their program in the hopes of getting a even luckier placement than last time -- which (I assume) we don't really want people to do. So your argument doesn't show that random positioning is better, it just points out one of the problems with using a small sample in the first place. Unfortunately, short of donating hardware to the people running the koth servers :-) , there's nothing we can do about the sample size. And fixed positioning *does* have a seperate advantage: when you're not making changes to your program that involve positioning, then the differences in score from one submission to the next will be more meaningful than with random positioning. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: morrell@jeeves.math.utah.edu (Steven C. Morrell) Subject: Optima numbers occuring in pairs Date: Wed, 22 Jun 1994 03:55:11 GMT Message-ID: The optima numbers don't always come in pairs, as someone pointed out a couple of months ago, but I have found something stunning: If you think of them as mod-1 numbers in a coresize/n array and multiply them together, look what happens!: 3359*3039= 10208001 = 1 (mod 8000) (3094/2)*(2234/2)= 1727999 = -1 (mod 4000) (3364/4)*(3044/4)= 640001 = 1 (mod 2000) (3315/5)*(2365/5)= 313599 = -1 (mod 1600) (2936/8)*(2376/8)= 108999 = -1 (mod 1000) (2930/10)*(2430/10)= 71199 = -1 (mod 800) So my guess is that every optima number that doesn't have a pair is actually a square root of 1. Neato, eh? Does anybody know why this happens? Steven Morrell morrell@math.utah.edu From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Re: The '94 Warrior Message-ID: Date: 22 Jun 1994 10:30:00 GMT In article <2u651d$a9n@magus.cs.utah.edu> bdthomse@peruvian.cs.utah.edu (Brant Thomsen) writes: [...] Thanks Brant for giving us _The_'94_Warrior_! > HINTS and HELPS: > > For this issue's hint, I'd like to make some suggestions about what new > abilities the A-field indirection in the latest pMARS release makes possible. > (I tried to come up with examples for each of these points, but couldn't find > any that I was really pleased with.) I had posted several weeks ago two specific things where indirect-A would be good for. 1. Fscan. As you can see, it's not doing spectacularly well, but it works. The idea is to use a tight scanning loop and DAT pointers to scanning locations, like this: SNE.I *table, @table DJN.F -1, -1 ... table DAT 200, 400 You need some code to detect the end of the table, then to copy over the pointer to the bombing code, etc. This Fscan is faster (1c) than normal scan (ADD/CMP/JMP, 2/3c) but slower than Quickscans (2c). On the upside, it's even more compact than Plasma-style quickscan (2 location/instruction, vs. 4 locations every 3). 2. Two-pass core-clear in four lines: SPL #-1, <-3 MOV.I *2, <2 DAT <-4, -1 DAT -3, -3 This piece of code does a SPL pass, then a DAT pass, then becomes a perfect gate. I believe it's possible to do an alternating SPL/DAT coreclear in 3 instructions, or do a once-SPL perpetual-DAT corescan in 3 instructions also. I tried to make the above in 3 instructions, with no luck. -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science & Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: sdd2252@tamsun.tamu.edu (Stacy David Doss) Subject: Neural Net ? Date: 22 Jun 1994 13:48:17 -0500 Message-ID: <2ua11h$830@tamsun.tamu.edu> Someone had posted a RFC on implimenting a Neural Network solution for Core Wars. I'm open to discussion on this subject if the origional poster will contact me via EMail. +----------------+--------------------------------------------------+ | Stacy Doss | Instant Human: Just Add Coffee... | | sdoss@tamu.edu | UNIX... A manly sort of operating system! | | Gig'em Aggies | It's not a bug ... it's a undocumented feature! | +----------------+--------------------------------------------------+ From: scarfman@wam.umd.edu (Jonathan Smith) Subject: Masses of Neophytes Date: 22 Jun 1994 19:05:44 GMT Message-ID: <2ua228$86s@cville-srv.wam.umd.edu> In the last several days I've seen several posts asking startup questions re corewar (myself included). How about one of you veterans starting a mailing list to hold our hands and walk us through the startup ideas....how to get info, what to do with it, etc. -Jonathan ps. I've looked for the book mentioned in the faq but the Armchair Universe doesn't seem to be around anymore. Any advice on where else to look next? Thanks -- ---------------------------------------------------- scarfman@wam.umd.edu is excited that he is listed in the internet white pages directory! ---------------------------------------------------- Date: Thu, 23 Jun 1994 23:36:35 MST From: Message-ID: <94174.233636AHNAS@ASUACAD.BITNET> Subject: Re: Fixed start positions :-( Paul's post shows us that the fixed position 'solution' is far from perfect. But why is it worse than the random starting position. The problems are problems at random starting position too. A small advantage for the challangers is not a problem I think. It keeps the hill changing which is interesting. Nandor. From: connorbd@bcvms.bc.edu Subject: Date: 24 Jun 94 12:50:33 EDT Message-ID: <1994Jun24.125033.1@bcvms.bc.edu> Well, as far as my original post on the subject goes (don't make me repost it; it's at soda under the name RedcodeRISC), I'd like to hear a few thoughts on that. While you're at it, here's a few more thoughts: Addenda to post on RedcodeRISC--a few more ideas ------------------------------------------------------------------------------ There are a few more concepts I fleshed out after posting the original material to rec.games.corewar. These make RedcodeRISC a bit RISCier. Comments? scalarity: This would be set as a variable on the system itself. RISC chips are often superscalar in design; maybe it would be interesting to see how a game runs with, say, four instructions per cycle. some new pseudoops: gr-greater than lt-less than neq-not equal to a simple model for interprocess communications: A special register can hold one instruction or data unit. This register is given the name ipc and is treated as a variable. There is one instruction attached: do reps,address executes instructions at address the number of times reps states. If no parameters is given, it executes the contents of ipc once. Comments? email to connorbd@bcvms.bc.edu or post. Thanks. This will be available at soda.berkeley.edu as RedcodeRISCaddenda. Brian Connors Boston College "This is a .sig trojan horse. Copy it into your .sig and watch people laugh at you." Date: Fri, 24 Jun 1994 17:57:03 MST From: Message-ID: <94175.175703AHNAS@ASUACAD.BITNET> Subject: Re: Optima numbers occuring in pairs This is very interesting. Did you test this theory with actual pairless optima numbers? Nandor. From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 25 Jun 1994 19:26:00 GMT Message-ID: Archive-name: games/corewar-faq Last-modified: 1994/04/11 Version: 2.2.1 These are the Frequently Asked Questions (and answers) from the USENET newsgroup rec.games.corewar. This FAQ list is also available by anonymous FTP from rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.Z. TABLE OF CONTENTS Line ------------------------------------------------------------------------ 1. What is Core War? 69 2. Is it Core War or Core Wars? 82 3. Where can I find more information about Core War? 90 4. Core War has changed since Dewdney's articles. Where do I get 108 a copy of the current instruction set? 5. What is this ICWS'94? 126 6. What is the ICWS? 143 7. What is TCWN? 153 8. How do I join? 161 9. Are back issues of TCWNs available? 178 10. What is the EBS? 185 11. Where are the Core War archives? 201 12. Where can I find a Core War system for . . . ? 219 13. I do not have ftp. How do I get all of this great stuff? 268 14. I do not have access to Usenet. How do I post and receive news? 275 15. When is the next tournament? 293 16. What is KotH? How do I enter? 304 17. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 466 18. How does SLT (Skip if Less Than) work? 478 19. What does (expression or term of your choice) mean? 490 20. Other questions? 633 --------------------------------------------------------------------- Q 1: What is Core War? A 1: Core War is a game played by two or more programs (and vicariously by their authors) written in an assembly language called Redcode and run in a virtual computer called MARS (for Memory Array Redcode Simulator). The object of the game is to cause all of the opposing programs to terminate, leaving your program in sole posession of the machine. There are Core War systems available for most computer platforms. Redcode has been standardized by the ICWS, and is therefore transportable between all standard Core War systems. ---------------------------------------------------------------------- Q 2: Is it "Core War" or "Core Wars"? A 2: Both terms are used. Early references were to Core War. Later references seem to use Core Wars. I prefer "Core War" to refer to the game in general, "core wars" to refer to more than one specific battle. ---------------------------------------------------------------------- Q 3: Where can I find more information about Core War? A 3: Core War was first described in the "Core War Guidelines" of March, 1984 by D. G. Jones and A. K. Dewdney of the Department of Computer Science at The University of Western Ontario (Canada). Dewdney wrote several "Computer Recreations" articles in "Scientific American" which discussed Core War, starting with the May 1984 article. Those articles are contained in an anthology: Author: Dewdney, A. K. Title: The Armchair Universe: An Exploration of Computer Worlds Published: New York: W. H. Freeman (c) 1988 ISBN: 0-7167-1939-8 Library of Congress Call Number: QA76.6 .D517 1988 The Redcode language has changed somewhat since; see Q 4. --------------------------------------------------------------------- Q 4: Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? A 4: A draft of the official standard (ICWS'88) is available by anonymous FTP from the Core War archives (soda.berkeley.edu) as pub/corewar/documents/standards/redcode-icws-88.Z This document is formatted awkwardly and contains ambiguous statements. For a more approachable intro to Redcode, take a look at pub/corewar/documents/tutorial.1.Z tutorial.2.Z (See also Q11) Steven Morrell (morrell@math.utah.edu) is preparing a more pratically oriented Redcode tutorial that discusses different warrior classes with lots of example code. Mail him for a preliminary version. --------------------------------------------------------------------- Q 5: What is this ICWS'94? A 5: There is an ongoing discussion about future enhancements to the Redcode language. A proposed new standard, dubbed ICWS'94, is currently being evaluated. A major change is the addition of "instruction modifiers" that allow instructions to modify A-field, B-field or both. Also new is a post-increment indirect addressing mode and unrestricted opcode and addressing mode combination ("no illegal instructions"). ICWS'94 is backwards compatible; i.e. ICWS'88 warriors will run correctly on an ICWS'94 system. Take a look at the ICWS'94 draft for more information (soda.berkeley.edu pub/corewar/documents/icws94.0202.Z). You can try out the new standard by submitting warriors to the '94 hills of the KotH servers (see Q16). Two corewar systems currently support ICWS'94, pMARS (various platforms) and Redcoder (Mac), both available at soda (see Q12). --------------------------------------------------------------------- Q 6: What is the ICWS? A 6: About one year after Core War first appeared in Sci-Am, the "International Core War Society" (ICWS) was established. Since that time, the ICWS has been responsible for the creation and maintenance of Core War standards and the running of Core War tournaments. There have been six annual tournaments and two standards (ICWS'86 and ICWS'88). --------------------------------------------------------------------- Q 7: What is TCWN? A 7: Since March of 1987, "The Core War Newsletter" (TCWN) has been the official newsletter of the ICWS. It is published quarterly and recent issues are also available as Encapsulated PostScript on soda.berkeley.edu (see Q9). --------------------------------------------------------------------- Q 8: How do I join? A 8: For more information about joining the ICWS (which includes a subscription to TCWN), or to contribute an article, review, cartoon, letter, joke, rumor, etc. to TCWN, please contact: Jon Newman 13824 NE 87th Street Redmond, WA 98052-1959 email: jonn@microsoft.com (Note: Microsoft has NO affiliation with Core War. Jon Newman just happens to work there, and we want to keep it that way!) Current annual dues are $15.00 in US currency. ---------------------------------------------------------------------- Q 9: Are back issues of TCWN available? A 9: Recent issues can be found on soda.berkeley.edu (see Q11). Older issues (up to Winter 1991) are also available (see the next TCWN for details). --------------------------------------------------------------------- Q10: What is the EBS? A10: The Electronic Branch Section (EBS) of the ICWS is a group of Core War enthusiasts with access to electronic mail. There are no fees associated with being a member of the EBS, and members do reap some of the benefits of full ICWS membership without the expense. For instance, the ten best warriors submitted to the EBS tournament are entered into the annual ICWS tournament. All EBS business is conducted in the rec.games.corewar newsgroup. The current goal of the EBS is to be at the forefront of Core War by writing and implementing new standards and test suites in preparation for the tenth anniversary of Core War in May of 1994 (see Q 5). Its immediate business will be to set up a Charter and establish its officers. ---------------------------------------------------------------------- Q11: Where is the Core War archive? A11: Many documents such as the guidelines and the ICWS standards along with previous tournament Redcode entries and complete Core War systems are available via anonymous ftp from soda.berkeley.edu (128.32.149.19) in the /pub/corewar directories. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Jon Blow (blojo@soda.berkeley.edu) is the archive administrator. When uploading to /pub/corewar/incoming, ask Jon to move your upload to the appropriate directory and announce it on the net. Much of what is available on soda is also available on the German archive at iraun1.ira.uka.de (129.13.10.90) in the /pub/X11/corewars directory. This FAQ is automatically archived by news.answers. See the header for the current archive name and news.answers for how to get it. ---------------------------------------------------------------------- Q12: Where can I find a Core War system for . . . ? A12: Core War systems are available via anonymous ftp from soda.berkeley.edu in the pub/corewar/systems directory. Currently, there are UNIX, IBM PC-compatible, Macintosh, and Amiga Core War systems available there. CAUTION! There are many, many Core War systems available which are NOT ICWS'88 (or even ICWS'86) compatible available at various archive sites other than soda.berkeley.edu. Generally, the older the program - the less likely it will be ICWS compatible. Reviews of Core War systems would be greatly appreciated in the newsgroup and in the newsletter. Below is a not necessarily complete or up-to-date list of what's available at soda: MADgic41.lzh - corewar for the Amiga, v4.1 MAD4041.lzh - older version? MAD50B.lha - corewar for the Amiga, beta version 5.0 Redcoder-20.hqx - corewar for the Mac, supports ICWS'88 and '94 core-11.hqx - corewar for the Mac core-wars-simulator.hqx - same as core-11.hqx? corewar_unix_x11.tar.Z - corewar for UNIX/X-windows, ICWS'86 but not ICWS'88 compatible koth31.tar.Z - corewar for UNIX/X-windows. This program ran the former KotH server at intel.com koth.shar.Z - older version kothpc.zip - port of older version of KotH to the PC deluxe20c.tar.Z - corewar for UNIX (broken X-windows or curses) and PC mars.tar.Z - corewar for UNIX, likely not ICWS'88 compatible icons.zip - corewar icons for MS-Windows macrored.zip - a redcode macro-preprocessor (PC) c88v49.zip - PC corewar, textmode display mars88.zip - PC corewar, graphics mode display corwp302.zip - PC corewar, textmode display, slowish mercury2.zip - PC corewar written in assembly, fast! mtourn11.zip - tournament scheduler for mercury (req. 4DOS) pmars05s.zip - portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars05s.tar.Z - same as above pmars05.zip - 16-bit PC executables, graphics display version pmars05g.zip - 32-bit PC execs (djgpp, large core) macpmars02.sit.hqx - pMARS executable for Mac (port of version 0.2) ApMARS03.lha - pMARS executable for Amiga (port of version 0.3.1) wincore.zip - MS-Windows system, shareware ($35) ---------------------------------------------------------------------- Q13: I do not have ftp. How do I get all of this great stuff? A13: There is an ftp email server at ftpmail@decwrl.dec.com. Send email with a subject and body text of "help" (without the quotes) for more information on its usage. ---------------------------------------------------------------------- Q14: I do not have access to Usenet. How do I post and receive news? A14: To receive rec.games.corewar articles by email, join the COREWAR-L list run on the Stormking.Com ListProcessor. To join, send: SUB COREWAR-L FirstName LastName to: LISTPROC@STORMKING.COM You can send mail to corewar-l@stormking.com to post even if you are not a member of the list. Responsible for the listserver is Scott J. Ellentuch (tuc@stormking.com). Another server that allows you to post (but not receive) articles is available. Email your post to rec-games-corewar@cs.utexas.edu and it will be automatically posted for you. ---------------------------------------------------------------------- Q15: When is the next tournament? A15: The ICWS holds an annual tournament. Traditionally, the deadline for entering is the 15th of December. The EBS usually holds a preliminary tournament around the 15th of November and sends the top finishers on to the ICWS tournament. Informal double-elimination tournaments are held frequently among readers of the newsgroup; watch there for announcements or contact me. ---------------------------------------------------------------------- Q16: What is KotH? How do I enter? A16: King Of The Hill (KotH) is an ongoing Core War tournament available to anyone with email. You enter by submitting via email a Redcode program with special comment lines. You will receive a reply indicating how well your program did against the current top twenty programs "on the hill". Your program will play 100 battles against each of the 20 other programs currently on the Hill. You receive 3 points for each win and 1 point for each tie. (The existing programs do not replay each other, but their previous battles are recalled.) All scores are updated to reflect your battles and all 21 programs are ranked from high to low. If you are number 21 you are pushed off the Hill, if you are higher than 21 someone else is pushed off. The original KotH was developed and run by William Shubert at Intel, and discontinued after almost three years of service. Currently, KotHs based on Bill's UNIX scripts but offering a wider variety of hills are are running at two sites: "koth@stormking.com" is maintained by Scott J. Ellentuch (tuc@stormking.com) and "pizza@ecst.csuchico.edu" by Thomas H. Davies (sd@ecst.csuchico.edu). Both KotHs provide very similar services and are therefore covered together. The principal difference is that "pizza" has a much faster internet connection than "stormking". Entry rules for King of the Hill 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. If you wish to receive mail on every new entrant, use ";redcode verbose". Otherwise you will only receive mail if a challenger makes it onto the hill. Use ";redcode quiet" if you wish to receive mail only when you get shoved off the hill. (Also, see 5 below). Additionally, 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 daemon 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. There are currently six separate hills you can select by starting your program with ;redcode, ;redcode-x, ;redcode-icws, ;redcode-b, ;redcode-94, or ;redcode-94x. More information on these hills is listed below. 3) Mail this file to "koth@stormking.com" or "pizza@ecst.csuchico.edu". "Pizza" requires a subject of "koth" (use the -s flag on most mailers). 4) Within a few minutes (or the next day for "stormking") you should get mail back telling you whether your program assembled correctly or not. If it did assemble correctly, sit back and wait; if not, make the change required and re-submit. 5) In an hour or so (or the next day for "stormking") you should get more mail telling you how your program performed against the current top 20 programs. If no news arrives during that time, 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. SAMPLE ENTRY: ;redcode ;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 ; Programs start at the first line unless ; an "END start" pseudo-op appears to indicate ; the first logical instruction. Also, nothing ; after the END instruction will be assembled. Here are the Specs for the various hills: ICWS'88 Standard Hill Specs: (Accessed with ";redcode", available at "stormking" and "pizza") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '88 ICWS Annual Tournament Hill Specs: (Accessed with ";redcode-icws", available at "stormking" only) coresize: 8192 instructions max. processes: 8000 per program duration: After 100,000 cycles, a tie is declared. max. entry length: 300 minimum distance: 300 instruction set: ICWS '88 ICWS'88 Experimental (Small) Hill Specs: (Accessed with ";redcode-x", available at "pizza" only) coresize: 4096 max. processes: 32 duration: after 65,536 cycles, a tie is declared. max. entry length: 64 minimum distance: 64 instruction set: ICWS '88 ICWS'94 Draft Hill Specs: (Accessed with ";redcode-94", available at "stormking" and "pizza") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Beginner's Hill Specs: (Accessed with ";redcode-b", available at "pizza" only) coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Experimental (Big) Hill Specs: (Accessed with ";redcode-94x", available at "stormking" and "pizza") coresize: 55440 max. processes: 10000 duration: after 500,000 cycles, a tie is declared. max. entry length: 200 minimum distance: 200 instruction set: ICWS '94 Draft If you just want to get a status report without actually challenging the hills, send email with ";status" as the message body (and don't forget "Subject: koth" for "pizza"). If you send mail to "pizza" with "Subject: koth help" you will receive instructions that may be more up to date than those contained in this document. All hills run portable MARS (pMARS) version 0.5, a platform-independent corewar system available at soda (see Q12). The '94 and '94x hills allow three experimental opcodes currently not covered in the ICWS'94 draft document: SEQ - Skip if EQual (synonym for CMP) SNE - Skip if Not Equal NOP - (No OPeration) ---------------------------------------------------------------------- Q17: Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? A17: Core is initialized to DAT 0, 0. This is an "illegal" instruction under ICWS'88 rules and strictly compliant assemblers (such as KotH or pmars -8) will not let you write a DAT 0, 0 instruction - only DAT #0, #0. So this begs the question, how to compare something to see if it is empty core. The answer is, most likely the instruction before your first instruction and the instruction after your last instruction are both DAT 0, 0. You can use them, or any other likely unmodified instructions, for comparison. Note that under ICWS'94, DAT 0, 0 is a legal instruction. ---------------------------------------------------------------------- Q18: How does SLT (Skip if Less Than) work? A18: SLT gives some people trouble because of the way modular arithmetic works. It is important to note that all negative numbers are converted to positive numbers before a battles begins. Example: (-1) becomes (M - 1) where M is the memory size. Once you realize that all numbers are treated as positive, it is clear what is meant by "less than". It should also be clear that no number is less than zero. ---------------------------------------------------------------------- Q19: What does (expression or term of your choice) mean? A19: Here is a selected glossary of terms. If you have a definition and/or term you wish to see here, please send it to me. (References to an X-like program mean that the term X is derived from the specific program X and has become a generic term). Bootstrapping - Strategy of copying the active portion of the program away from the initial location, leaving a decoy behind and making the relocated program as small as possible. B-Scanners - Scanners which only recognize non-zero B-fields. example add #10,scan scan jmz example,10 C - Measure of speed, equal to one location per cycle. Speed of light. CMP-Scanner - A Scanner which uses a CMP instruction to look for opponents. example add step,scan scan cmp 10,30 jmp attack jmp example step dat #20,#20 Color - Property of bombs making them visible to scanners, causing them to attack useless locations, thus slowing them down. example dat #100 Core-Clear - code that sequentially overwrites core with DAT instructions; usually the last part of a program. Decoys - Bogus or unused instructions meant to slow down Scanners. Typically, DATs with non-zero B-fields. DJN-Stream (also DJN-Train) - Using a DJN command to rapidly decrement core locations. example . . . . . . djn example,<4000 Dwarf - the prototypical small bomber. Gate-busting - (also gate-crashing) technique to "interweave" a decrement-resistant imp-spiral (e.g. MOV 0, 2668) with a standard one to overrun imp-gates. Hybrids - warriors that combine two or more of the basic strategies, either in sequence (e.g. stone->paper) or in parallel (e.g. imp/stone). Imp - Program which only uses the MOV instruction. example MOV 0, 1 or example MOV 0, 2 MOV 0, 2 Imp-Gate - A location in core which is bombed or decremented continuously so that an Imp can not pass. Also used to describe the program-code which maintains the gate. example ... ... SPL 0, Date: Sun, 26 Jun 1994 23:23:38 GMT This is an idea for a new predefined variable: RANDOM - has a "random" value between 0 and coresize-1 inclusively. RANDOM is assigned a value once for every warrior assembly, *not* every time it is referenced in the warrior source. This is mostly for efficiency; if you need several random values, you need to derive them yourself from RANDOM. Use: If you don't like the fixed KotH start locations, you can introduce some randomness yourself, e.g. by varying your relative start location: FOR RANDOM % 10 ;null spacer, length 0 to 9 dat 0,0 ROF start ... Or you can use RANDOM to effectively randomize the distance of your boot-strap, making it immune to a "known boot-distance" attack. You could even use it to randomly select bomb constants and entire code sections (bracketed by FOR/ROF). E.g.: select EQU RANDOM % 2 dist EQU select*37 + !select*51 ; either 37 or 51 FOR select some code ROF FOR !select other code ROF Does this sound useful to have? -Stefan (stst@vuse.vanderbilt.edu) From: walker@yallara.cs.rmit.OZ.AU (Fantom) Subject: Unable to get a response from pizza Date: 27 Jun 1994 07:28:05 GMT Message-ID: <2ulv25$9m2@goanna.cs.rmit.oz.au> Previously I have had no trouble, but today I've had no luck. Mailing with "koth help" and "pizza help" or "help" as the subject gives me no problems at all. However, if I post (with subject "koth") either a ;status or a warrior I get no response at all. Any known problems with the site, or is it just me? Fantom From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: RANDOM predefined variable Message-ID: Date: Mon, 27 Jun 1994 12:29:07 GMT In article <1994Jun26.232338.2304@news.vanderbilt.edu>, Stefan Strack wrote: > >RANDOM - has a "random" value between 0 and coresize-1 inclusively. [ stuff deleted... ] >You could even use it to randomly select bomb constants and entire >code sections (bracketed by FOR/ROF). E.g.: > >select EQU RANDOM % 2 >dist EQU select*37 + !select*51 ; either 37 or 51 >FOR select >some code >ROF >FOR !select >other code >ROF > >Does this sound useful to have? This sounds *scary* :-) But I definitely like it :-) Useful? Yes, quite... but lots of stuff are useful... I vote yes on this one. Scott -- ______ __ __ ________ /\ ___\ /\ \ __/\ \ /\ ____ \ Scott W. Adkins - sadkins@ohiou.edu \ \ \__/ \ \ \/\ \ \ \ \ \ \___\ \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \ \___ \ \ \ \ \ \ \ \ \ \ ____ \ Ohio University of Athens \/___\ \ \ \ \_\ \_\ \ \ \ \ \ \ \ Harvard on the Hocking! /\_____\ \ \_________\ \ \_\ \ \_\ \/_____/ \/_________/ \/_/ \/_/ Knowledge is the seed of understanding. From: roca_michael@tandem.com (Michael Roca) Subject: Re: RANDOM predefined variable Message-ID: Date: Mon, 27 Jun 1994 16:29:05 GMT In article <1994Jun26.232338.2304@news.vanderbilt.edu> stst@vuse.vanderbilt.edu (Stefan Strack) writes: >From: stst@vuse.vanderbilt.edu (Stefan Strack) >Subject: RANDOM predefined variable >Date: Sun, 26 Jun 1994 23:23:38 GMT >This is an idea for a new predefined variable: >RANDOM - has a "random" value between 0 and coresize-1 inclusively. >RANDOM is assigned a value once for every warrior assembly, *not* >every time it is referenced in the warrior source. This is mostly >for efficiency; if you need several random values, you need to derive >them yourself from RANDOM. I was under the impession that Koth only assembled each submitted warrior once. If that's the case your opponent couldn't tell the difference between you using RANDOM and you picking a random number yourself. Or are the warriors reassembled each time? From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: RANDOM predefined variable Message-ID: <1994Jun27.164005.22172@news.vanderbilt.edu> Date: Mon, 27 Jun 1994 16:40:05 GMT In article roca_michael@tandem.com (Michael Roca) writes: >I was under the impession that Koth only assembled each submitted warrior once. >If that's the case your opponent couldn't tell the difference between you using >RANDOM and you picking a random number yourself. > Each submitted warrior is assembled 22 times, once for each warrior on the hill and twice against itself. A given opponent wouldn't be able to tell whether a challenger used RANDOM, because the value would be the same for all 100 rounds. Again, I see the best use for RANDOM in things like randomizing the boot distance, immediate A-field values (so they don't fall prey to a specialized scan), and hypothetically, self-identification. -Stefan (stst@vuse.vanderbilt.edu) From: morrell@uglab10.math.utah.edu (Steven C. Morrell) Subject: Blue Funk, Blue Funk 3, and in-register vs. in-memory Date: Mon, 27 Jun 1994 18:26:24 GMT Message-ID: The following post contains the source code and the story behind Blue Funk and Blue Funk 3, which happens to be in first place on the '94 hill right now. It illustrates some of the subtleties of in-memory/ in-register addressing. As I was working on chapter two ("Stones") of my tutorial, I extracted a lot of stones from various warriors and ran them on Jon Neuman's Core! MARS for the macintosh. The most elegant of these was P.Kline's Emerald, which bombed the entire core before self-destructing. Upon closer investigation, I noticed something fishy -- after a mod 5 bombing run, the bombing instruction turned into MOV <0,2. Now under in-memory evaluation, which Core! incorrectly uses, this instruction decrements the 2, and then moves the next instruction onto itself (essentially a NOP.) Under in-register evaluation, the 2 is decremented and the source pointer is 1, but since things are in-register, the destination pointer is 2, messing up the stone. I watched the Emerald stone play out on William Shubert's KOTH, and sure enough, it only bombed 40% of the core before ruining itself. But, says I, we now have post-increment in the '94 draft, so I can use a MOV >0,n instruction and things will work out perfectly. (Well, almost perfectly.) Thus was the stone made for Blue Funk. I took a cue from Wayne Sheppard's Night Crawler and got the stone bombing early before I launched the imp-ring. Not a good strategy against quickscanners, but in practice it works pretty well. And here is Blue Funk: ;redcode-94 verbose ;name Blue Funk ;author Steven Morrell ;strategy Stone like Emerald without the in-memory/in-register problem ;strategy Imp added for fun ;macro step equ 3044 for 81 dat -step,step-1 ADD emerald,stone cnt DJN.f stone,boot mov emerald+1,>boot mov emerald+2,>boot mov emerald+3,>boot spl i spl i31 i12 spl imp2 imp1 jmp >0,imp i31 spl imp1 imp3 jmp >0,imp+5334 i spl i12 spl imp3 imp2 jmp >0,imp+2667 imp mov.i #3044,2667 end boot That brings me up to the middle of last week, when I finally downloaded Alex MacAulay's Redcoder, and got a visual perspective on my warriors. Much to my horror, I found that Blue Funk was only bombing half of core, and without a core-clear anywhere to back it up. What happened was that the MOV statement turned into MOV >0,-1 at the end of the first run and MOV >0,0 at the end of the second run and MOV >0,0 at the end of the third and all consequent runs. When a MOV >0,0 executes correctly, it loads MOV >0,0 into a register, increments the memory, and then stores MOV >0,0 into the same memory. The net effect is no decrement! So after another bug fix, here is Blue Funk 3, which bombs the entire core one and a half times before the stone component kills itself. ;redcode-94 verbose ;name Blue Funk 3 ;author Steven Morrell ;strategy Fixed another in-memory/in-register bug ;macro step equ 3044 for 78 dat -step,step+1 ADD emerald,stone cnt DJN.f stone,out mov emerald+1,>out mov emerald+2,>out mov emerald+3,>out spl i spl i31 i12 spl imp2 imp1 jmp >0,imp i31 spl imp1 imp3 jmp >0,imp+5334 i spl i12 spl imp3 imp2 jmp >0,imp+2667 imp mov.i #3044,2667 end boot --- Steven Morrell morrell@math.utah.edu From: morrell@jeeves.math.utah.edu (Steven C. Morrell) Subject: Re: Unable to get a response from pizza Date: Tue, 28 Jun 1994 19:22:46 GMT Message-ID: In article <2ulv25$9m2@goanna.cs.rmit.oz.au> walker@yallara.cs.rmit.OZ.AU (Fantom) writes: However, if I post (with subject "koth") either a ;status or a warrior I get no response at all. Fantom I tried submitting a warrior where I had accidentally omitted the ;redcode label and got no response from the pizza server. I resubmitted it about 5 times before I figured out what was wrong. So, to submit a warrior, you need both a subject header of koth and one of ;redcode, ;redcode-94, etc. in your code. To check up on the hill, use "koth status" as the subject. Steven Morrell morrell@math.utah.edu From: morrell@jeeves.math.utah.edu (Steven C. Morrell) Subject: Re: Optima numbers occuring in pairs Date: Wed, 29 Jun 1994 04:44:00 GMT Message-ID: In article <94175.175703AHNAS@ASUACAD.BITNET> writes: This is very interesting. Did you test this theory with actual pairless optima numbers? Nandor. I only got it to work with a coresize of 8. However, for each optima pair on coresize 55440, I got 1 or -1 as an answer, so I think something's wrong with whatever optima program Brant used when he posted the optima numbers in _The '94 Warrior_ a couple of months ago. I haven't tried Corestep yet, so I don't know if it works there or not. What worries me is if these optima numbers are really pairless, why is the score for their multiplicative inverses different? This isn't the pattern I see for all of the optima number pairs. The particular numbers I am suspicious of are mod 2, 4, 6, and 9 in coresize 55440. If these numbers are wrong, it might explain why I can't get a mod-4 bomber to do well on the big hill. (Of course, there may be other reasons :( Steven Morrell morrell@math.utah.edu From: morrell@jeeves.math.utah.edu (Steven C. Morrell) Subject: The Pizza Server IS Down Date: Wed, 29 Jun 1994 05:39:34 GMT Message-ID: Whoops! I just sent a valid (I think) program in and got no response. Nothing has come out of it since last Friday. From: an791@FreeNet.Carleton.CA (David Moorhouse) Subject: Re: The Pizza Server IS Down Message-ID: Date: Thu, 30 Jun 1994 03:44:37 GMT In a previous article, morrell@jeeves.math.utah.edu (Steven C. Morrell) says: >Whoops! I just sent a valid (I think) program in and got no response. >Nothing has come out of it since last Friday. Really? I just got a report yesterday. It works fine for me. -- an791@freenet.carleton.ca | David Moorhouse | <<.sig under construction!!>> AKA: Gollum, Smeagol, Dave.| Burble.........GAK! | From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Re: Optima numbers occuring in pairs Message-ID: Date: 30 Jun 1994 13:46:05 GMT Here's some thoughts about what we call "optima" numbers. What I'm looking for is some input on what kind of "formula" is "best" for finding "optimal" numbers. Lots of "s. First off, the definition of "optimal" varies. It depends on what kind of result you look for. There are two antagonistic goals: 1) catch opponents early, 2) eventually catch everything. Requirement 1 means that we want, say a pattern that is guaranteed to hit any 100-size opponent in minimal time (i.e. ~80 bombs). Requirement 2 means that we want it to be mod-2 or mod-4 or any small mod-number. The perfect pattern would be dichotomic: bomb at mod-4000, then mod-2000, then mod-1000, 500, 250, 125, etc. narrowing it down without hitting previous bombs. This, I believe, ensures the earliest discovery of the opponent. But even with DIV, it's not easy to implement, and would be too slow (or would it?). The "optima" formula (the one I call "classic") uses the distance to the closest earlier bomb as a measure of how good a given bomb is. The "corestep" formula (which I call "alternate") uses the distance to the middle between the two nearest earlier bombs. Basically, these formulae try to make sure that the bombs are evenly distributed, that is, closest possible to the perfect pattern defined above. Another approach that I've introduced with Corestep v3 was to target specific opponent sizes. With corestep, you can say for example: corestep -cf 29 -df 100 -b 20 which will display the 20 best steps for finding a 100-size opponent, and display also their find-20 score. That way, you can get a stepsize that is near-perfect for 100-size, and good against 20-size. I believe that these deterministic find-numbers are better than any "formula". Many of the formula-generated stepsizes are really pretty bad (e.g. they bomb near-mod-400 then fill in the 400-gaps in parallel). The problem with the formulae is that they don't integrate the notion that early bombs (say, the first 20) shouldn't count, whereas the next 50 are crucial (they'll hit 100-size opponents), and then the following 1000 not so important, but the last 1000 are, because they determine the final mod-number. You *could* put weighs and stuff, but finding out what set of weights is "best" is itself a question as hard to answer. I hope all this rambling wasn't too boring. The point is that what we regard as "optima" numbers depend widely on the warrior it's incorporated into. Depending on what kind of code you have besides your stone/vampire/scanner/whatever, and how that stone/etc. is started/terminated, the behaviour you want varies. Anyway, this is probably going to be my last post in a month or so. I'm leaving the US back to France! See you all later! And don't mess up my warriors while I'm gone! :-) -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science & Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: lewin@netcom.com (Karl Lewin) Subject: Re: The Pizza Server IS Down Message-ID: Date: Thu, 30 Jun 1994 17:36:36 GMT Steven C. Morrell (morrell@jeeves.math.utah.edu) wrote: : Whoops! I just sent a valid (I think) program in and got no response. : Nothing has come out of it since last Friday. Same here, I haven't gotten any updates/responses since at least last friday. Karl -- ==================================== Karl Lewin lewin@netcom.com ====================================