Part II - 40 scans using only sne/seq pairs!
First question - is it worth it to add more scans. Obviously you are
going to get bigger and make yourself easier to find. So are big
qscans better than small qscans?
Say you and your opponent have 8 sne/seq/jmp qscans that total 24
lines and scan 32 locations. If you add another sne/seq/jmp quad you
gain 4 more chances of finding your opponent. That is an increase of
4/32=.125, while his chance of finding you increases 3/24=.125. Looks
like a wash. Hold on though, your opponent also has a 15-line stone-
imp boot. You also increased your chance of finding that code by .125
with no increased risk to yourself. So it looks like you should use
the biggest qscan you can manage. The tradeoff will be when you are
still scanning after he has booted the stone-imp, then his qscan-and-
boot are just a huge decoy for you to waste time on.
Here is a new version of the previous general form that scans 40
locations using only sne/seq:
tA dat tE ,qA
tB dat 1 ,qB
tC dat tF ,qC
tD dat tJ ,qD
sne qPtr+qA*qM ,qPtr+qA*qM+Dist ; mutate tB
seq <tA ,qPtr+(qA-1)*qM+Dist
djn.a decode ,{tB
sne qPtr+qB*qM ,qPtr+qB*qM+Dist
seq <tB ,qPtr+(qB-1)*qM+Dist
jmp decode ,{tB
sne qPtr+qC*qM ,qPtr+qC*qM+Dist
seq <tC ,qPtr+(qC-1)*qM+Dist
tE jmp decode ,qE
sne qPtr+qD*qM ,qPtr+qD*qM+Dist
seq <tD ,qPtr+(qD-1)*qM+Dist
jmp decode ,}tB
sne qPtr+qE*qM ,qPtr+qE*qM+Dist ; mutate decode
seq <tE ,qPtr+(qE-1)*qM+Dist
jmp decode ,{decode
sne qPtr+qF*qM ,qPtr+qF*qM+Dist
seq <tF ,qPtr+(qF-1)*qM+Dist
jJ jmp decode ,}decode
sne qPtr+qG*qM ,qPtr+qG*qM+Dist ; mutate pH
seq <tG ,qPtr+(qG-1)*qM+Dist
jmp decode-1 ,{pH
sne qPtr+qH*qM ,qPtr+qH*qM+Dist
pH seq <tH ,qPtr+(qH-1)*qM+Dist
tF jmp decode-1 ,qF
sne qPtr+qI*qM ,qPtr+qI*qM+Dist
seq <tI ,qPtr+(qI-1)*qM+Dist
jmp decode-1 ,}pH
sne qPtr+qJ*qM ,qPtr+qJ*qM+Dist ; mutate decode
twice
seq <tJ ,qPtr+(qJ-1)*qM+Dist
jmp jJ ,}decode ; double-
jmp to decode
tJ jmp launch ,qJ
mov.a #pH-decode ,decode ; new decode
option
decode mul.b *tB ,qPtr
sne null ,@qPtr
add.a #Dist ,qPtr
mov bomb ,@qPtr
qPtr mov bomb ,@qM
add.ab #Incr ,qPtr
djn -3 ,#10
...
launch
tG spl 1 ,qG ; hiding qG-qI in other code
tH spl 1 ,qH
tI spl 1 ,qI
...
Even though this form requires five new lines, tA-tD and the mov
before decode, it is more dense than q4.5 scans. And there is an
advantage in that four of those lines are dat's and won't be
executed. If they get bombed it might not be fatal. In some programs
it might be possible to bury them out of sight. Also, there is no
special restriction on Dist so we can reject scan-pairs that are < 100
apart.
The same math as before defines qA-qJ: qX = (tX-qPtr)*qMod + 1
Now our parameters defining qA-qJ are:
tA = location of tA (determines tB-tD
tG = location of tG (determines tH&tI)
tE = location of tE (determines tF&tJ)
Dist = distance between pairs of scans
qMod = some value where (qM-1)*qMod = 1 mod 8000
From the above, I constructed a program using a 14-line paper launch
with tA fixed at zero. I let Dist vary from 100 to 4000 by 20. The
code blocks imply a constraint on the distances between tA tG & tE,
but all told there are about 180,000 combinations for each qM/qMod
pair. And there are 3201 of those pairs, so that gives .... um let me
see ... 570 million combinations. Hooraw!
The next thing you will all appreciate
Right now the only
programming language I have access to is Redcode using CoreWin. Oh
for a c compiler.. My challenge is to generate 570 million lists of
40 values and select only those lists whose minimum distance between
values is >= 100. But CoreWin has a 2G maxcycles limit per round. My
first version was able to process one qM/qMod pair in about 5
minutes. Times 3200 that is 16000 minutes, which is, like, weeks!
After a few more rewrites I can now process the entire set of 540
million lists in about 10 hours, using p-space to store the working
parameters between rounds.
When finished, I have a list of about 300 qM's in p-space that I can
reprocess one at a time to see the actual parameters. Or I can
introduce more constraints and rerun just these qM's.
This may be the first useful application of Redcode ever
The next challenge would be to reduce tA-tD. I leave that as an
exercise for the reader
P. Kline
FAQ
Search
Profile
Private Messages
Log in/Register/Password
