Article 749 of rec.games.corewar:
Newsgroups: rec.games.corewar
From: rjc@hal.gnu.ai.mit.edu (Ray)
Subject: Re: Binary Subdivision bombing
Message-ID: <1992Apr18.082557.824@mintaka.lcs.mit.edu>
Sender: news@mintaka.lcs.mit.edu
Organization: /etc/organization
References: <1992Apr12.233751.8607@mintaka.lcs.mit.edu> <57559@cup.portal.com>
Date: Sat, 18 Apr 1992 08:25:57 GMT
Lines: 121

    Well I did a single process bomber about 3 days ago and it lost
miserably on the hill. It's just too big a target (although
much smaller than yours) compared to dwarf optima and their ilk.

-----------------------------------
;redcode verbose
;name Binrary Tree 2.0 (beta)
;author Ray Cromwell
;strategy Greatly enhanced version of my Binary Tree program
;strategy thousands of times faster!

bomb	spl	0,#42
offset	dat	#0,#0
temp	dat	#0,#0
	dat	#0,#0
num	dat	#16,#16
start	mov	<ptr,dest	;fetch next vlaue from offset table
	jmn	ploop,ptr	;if 0, turn into a dwarf bombing with dats
	mov	bomb-1,<bomb-1
	jmp	-1,<bomb-1
ploop	mov	dest,offset	;dest is the destination which is offsetted
	add	offset,offset   ;offset is the value added to dest each loop
				;which is 2*dest
				;this gets rid of the "bomb some loc twice"
				;by making each bombing run out of phase
				;by 1/2 the dist between two previous bombs
	slt	#62,num		;check to prevent us from bombing ourselve
	jmp	2,0		
	sub	#2,num
	mov	num,temp	;temp=number of bombs to lay out
	add	temp,num	;num=num*2, for next iteration
bloop	mov	bomb,@dest
	add	offset,dest
	djn	bloop,temp	;bomb code

	jmp	start,<4000	;impstomp/decoy jump back to begining
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0           ;move the table away from the main code
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
	dat	#0,#0
ptr	dat	#tbl+1,#tbl+1
	dat	#2,#2
	dat	#4,#4
	dat	#8,#8
	dat	#16,#16
	dat	#31,#31
	dat	#62,#62
	dat	#125,#125
tbl	dat	#250,#250
dest	dat	#0,#0
	end	start

---------------------------------

  On the first iteration, it lays out 16 bombs spaced 500 apart starting
at 250. On the next iteration it lays out 32 bombs spaced 250 apart
starting at 125. Then 64 bombs(actually 62) spaced 124 apart starting
at 62 (it bombs 62 instead of 64 because it would to bomb itself)
On the last loop it bombs 1924 locations spaced 4 apart starting at an offset
of 2.

  So it ends up bombing almost every other location in the core (except
a small area nar the program itself, and a single column)

  It still loses badly. I think because the table footprint is too big.
I thought of starting the table at dat #125,#125. That way it would bomb
with an offset of 250 between bombs starting out. I could also
stop the table at dat #4,#4 but this only shaves 2 words off the program
size.

  Clearly it does better against larger programs. It won't hit programs of
size 4-8 until the 7th iteration.

   I could make the bombing more uniform by making the table values larger
divisions of the core. (for instance, bomb 16 locations spaced 1500 apart
instead of 500. )