Redcoder's Frenzy 23: The Powers of Ten Round

[chip]

Archived from groups: rec.games.corewar (More info?)

...............................­..............................­.......

.. .
.. _____ _ _ .
.. | __ \ | | | | .
.. | |__) |___ __| | ___ ___ __| | ___ _ __ ___ .
.. | _ // _ \/ _` |/ __/ _ \ / _` |/ _ \ '__/ __| .
.. | | \ \ __/ (_| | (_| (_) | (_| | __/ | \__ \ .
.. |_| \_\___|\__,_|\___\___/ \__,_|\___|_| |___/ .
.. .
.. ______ .
.. | ____| .
.. | |__ _ __ ___ _ __ _____ _ .
.. | __| '__/ _ \ '_ \|_ / | | | .
.. | | | | | __/ | | |/ /| |_| | .
.. |_| |_| \___|_| |_/___|\__, | .
.. __/ | .
.. |___/ .
.. .
.. ___ ___ .
.. |__ \_ \ .
.. / / / / .
.. / / \ \ .
.. /___|\__/ .
.. .
...............................­..............................­.......



..............................
. .
. The Powers of Ten Round .
. .
..............................


It's time for the next round of the Redcoder's Frenzy!


This is the 23rd round of the ongoing corewar tournament. Detailed
information is available on Fizmo's Corewar Info Page:

http://www.corewar.info/tournament/cwt.htm


The Powers of Ten Round homepage is:

http://www.corewar.info/tournament/23.htm


...............................­..............................­.......

.. _ .
.. _ _ _ _| |___ ___ .
.. | '_| || | / -_|_-< .
.. |_| \_,_|_\___/__/ .
.. .
...............................­..............................­.......



Time to free yourselves from the confines of tiny coresizes, and
explore the open spaces of a truly huge core!


Core size = 1,000,000
Max cycles = 10,000,000
Read limit = 1,000,000
Write limit = 50,000
Max processes = 10
Max length = 1000
Min distance = 10,000
P-space size = 100,000
Number of rounds = 100


P-space is allowed, but PIN is not (no handshaking). The battles are
fought Round Robin with no self fights. Two entries are allowed per
author. Three points for a win, one point for a tie.

Please note the write limit. You'll need to use either CoreWin 2.2
(http://www.geocities.com/corewin2/) or Joonas' R/W limit patch for
pmars
(http://www.cs.helsinki.fi/u/jpihlaja/cw/pmars-0.9.2-patches_20040721.tar.gz)


Hints:

- There is no read limit, so scanners can see all of core. But they'll
have to send out proxies to attack anything they find. Here's where
p-space can come in handy: sharing information and instructions with
your far-flung processes.

- With only 1/20th of the core reachable by any process, and only 10
processes, imp spirals are impossible, because the head can't wrap
around to the tail. It also means that no set of static processes can
bomb all of core. Mobility will be needed.

- There's plenty of room and plenty of time, so don't feel rushed.
There's no danger of being hit by a qscan in the first 20 cycles!
Perhaps this is the time to dust off some of the more complex
strategies (cooperating processes, self-repair programs) that never
seem to succeed on the standard hills.


...............................­..............................­.......

.. _ _ _ _ .
.. __| |___ __ _ __| | (_)_ _ ___ .
.. / _` / -_) _` / _` | | | ' \/ -_) .
.. \__,_\___\__,_\__,_|_|_|_||_\_­__| .
.. .
...............................­..............................­.......



23:59 (GMT) May 31, 2005


------------------------------­------------------------------­--
Please send your entries to Chip
(chipw[at]mdli.com)
------------------------------­------------------------------­--


Good luck, and may the core be with you!

 

[Guest]

Archived from groups: rec.games.corewar (More info?)

Chip wrote:
>
...............................­..............................­.......
>
> . .
> . _____ _ _ .
> . | __ \ | | | | .
> . | |__) |___ __| | ___ ___ __| | ___ _ __ ___ .
> . | _ // _ \/ _` |/ __/ _ \ / _` |/ _ \ '__/ __| .
> . | | \ \ __/ (_| | (_| (_) | (_| | __/ | \__ \ .
> . |_| \_\___|\__,_|\___\___/ \__,_|\___|_| |___/ .
> . .
> . ______ .
> . | ____| .
> . | |__ _ __ ___ _ __ _____ _ .
> . | __| '__/ _ \ '_ \|_ / | | | .
> . | | | | | __/ | | |/ /| |_| | .
> . |_| |_| \___|_| |_/___|\__, | .
> . __/ | .
> . |___/ .
> . .
> . ___ ___ .
> . |__ \_ \ .
> . / / / / .
> . / / \ \ .
> . /___|\__/ .
> . .
>
...............................­..............................­.......
>
>
>
> ..............................
> . .
> . The Powers of Ten Round .
> . .
> ..............................
>
>
> It's time for the next round of the Redcoder's Frenzy!
>
>
> This is the 23rd round of the ongoing corewar tournament. Detailed
> information is available on Fizmo's Corewar Info Page:
>
> http://www.corewar.info/tournament/cwt.htm
>
>
> The Powers of Ten Round homepage is:
>
> http://www.corewar.info/tournament/23.htm
>
>
>
...............................­..............................­.......
>
> . _ .
> . _ _ _ _| |___ ___ .
> . | '_| || | / -_|_-< .
> . |_| \_,_|_\___/__/ .
> . .
>
...............................­..............................­.......
>
>
>
> Time to free yourselves from the confines of tiny coresizes, and
> explore the open spaces of a truly huge core!
>
>
> Core size = 1,000,000
> Max cycles = 10,000,000
> Read limit = 1,000,000
> Write limit = 50,000
> Max processes = 10
> Max length = 1000
> Min distance = 10,000
> P-space size = 100,000
> Number of rounds = 100
>
>
> P-space is allowed, but PIN is not (no handshaking). The battles are
> fought Round Robin with no self fights. Two entries are allowed per
> author. Three points for a win, one point for a tie.
>
> Please note the write limit. You'll need to use either CoreWin 2.2
> (http://www.geocities.com/corewin2/) or Joonas' R/W limit patch for
> pmars
>
(http://www.cs.helsinki.fi/u/jpihlaja/cw/pmars-0.9.2-patches_20040721.tar.gz)
>
>
> Hints:
>
> - There is no read limit, so scanners can see all of core. But
they'll
> have to send out proxies to attack anything they find. Here's where
> p-space can come in handy: sharing information and instructions with
> your far-flung processes.
>
> - With only 1/20th of the core reachable by any process, and only 10
> processes, imp spirals are impossible, because the head can't wrap
> around to the tail. It also means that no set of static processes can
> bomb all of core. Mobility will be needed.
>
> - There's plenty of room and plenty of time, so don't feel rushed.
> There's no danger of being hit by a qscan in the first 20 cycles!
> Perhaps this is the time to dust off some of the more complex
> strategies (cooperating processes, self-repair programs) that never
> seem to succeed on the standard hills.
>
>
>
...............................­..............................­.......
>
> . _ _ _ _ .
> . __| |___ __ _ __| | (_)_ _ ___ .
> . / _` / -_) _` / _` | | | ' \/ -_) .
> . \__,_\___\__,_\__,_|_|_|_||_\_­__| .
> . .
>
...............................­..............................­.......
>
>
>
> 23:59 (GMT) May 31, 2005
>
>
> ------------------------------­------------------------------­--
> Please send your entries to Chip
> (chipw[at]mdli.com)
> ------------------------------­------------------------------­--
>
>
> Good luck, and may the core be with you!

 

[Guest]

Archived from groups: rec.games.corewar (More info?)

I seem to have a problem with CoreWin storing the large PSpace value.
Is anyone else having this problem??

 

[Guest]

Archived from groups: rec.games.corewar (More info?)

Hi.
Definitely an intersting round.
Large coresize, write limit, and lp -> it will be very difficult for
evolvers to make something competitive this time. Mobility is, of
course, necessary in order to be able to attack throughout the core,
but you can always sit and wait for your opponent to come to you
(static warriors can be much more complex). Of course, there is always
the option of combining these two approaches.
.... Testing will be difficult, because there is no possibility of
making a benchmark. We'll only be able to test our own potential
entries against each other.
heh. but that's what makes this so interesting .

 

[Guest]

Archived from groups: rec.games.corewar (More info?)

"Nenad Tomasev" <tomasev@nspoint.net> wrote in message news:<1114764197.554666.118080@f14g2000cwb.googlegroups.com>...
> Hi.
> Definitely an intersting round.
> Large coresize, write limit, and lp -> it will be very difficult for
> evolvers to make something competitive this time. Mobility is, of
> course, necessary in order to be able to attack throughout the core,
> but you can always sit and wait for your opponent to come to you
> (static warriors can be much more complex). Of course, there is always
> the option of combining these two approaches.
> ... Testing will be difficult, because there is no possibility of
> making a benchmark. We'll only be able to test our own potential
> entries against each other.
> heh. but that's what makes this so interesting .

Certainly, a realy interesting round.
Though, a serious problem for those, (surely only me), who have a
paleolithic PC.
100 rounds are maybe not enough for complex p-brains, but with 10^7
cycles we could become grandpas waiting the results with a large
number of rounds.
Am i hearing the sound of mP^3's...?

Personal note: I have to steal a nice machine from somewhere. Should i
go to Alberta to visit Bvowk?

 

[chip]

Archived from groups: rec.games.corewar (More info?)

I think I see what you mean. It seems that CoreWin has a bug in the way
it retrieves both the p-space size and the R/W limits from the
configuration file: if you load settings that have absolute numbers for
these (instead of fractions of coresize), the numbers fail to override
the default fractional values, so the p-space size remains at 1/16th of
coresize (62500 for this round). More importantly, the write limit will
fail to get set!

I'll fix this bug for version 2.3. For now, though, please use this
workaround: After you start CoreWin and load your settings for RF23,
manually type in the values for write limit and p-space size. They'll
look the same, but the act of typing forces the system to recognize
them as new values, and they'll get properly set. To doublecheck, open
a p-space view window to check p-space size, and run mov 0, 50001,
which should behave as a normal imp.

Sorry about the inconvenience.

- Chip

 

[Guest]

Archived from groups: rec.games.corewar (More info?)

Hi,

pMARS has some trouble displaying cores as large as this round
requires. I've hacked sdldisp.c to squash the core vertically to
limit the maximum core arena window height to 400 pixels (so that
you can still see the cdb panel when debugging.) You can
download the sources with read/write limit patches applied
already at:

http://www.helsinki.fi/~jpihlaja/pmars-0.9.2-6-rw.tar.gz

Cheers,

Joonas

 

[Guest]

Archived from groups: rec.games.corewar (More info?)

There's a five-slot ;redcode-rf23 hill up on
http://sal.math.ualberta.ca

Be prepared for *long* waits when the hill becomes saturated with
paper. So please do try real hard to kick all paper off ASAP.

Cheers,

Joonas

 

[chip]

Archived from groups: rec.games.corewar (More info?)

There have been a few questions about the RF23 round, so I've put
together a brief FAQ.

Q: Why isn't my warrior working the same under CoreWin and pmars?
A: As I noted in a previous post, CoreWin has a bug in the way it reads
settings from a .cfg file. Each time you start CoreWin, you need to
type numbers into the write limit and p-space size boxes in order for
those parameters to be set properly. If in doubt, run MOV 0,50001; it
should behave as a normal imp.

Q: How do read/write limits work?
A: This is a long one, but here goes:
Every address in Redcode is either a read address or a write address.
Basically, a write address is any address at which the core contents
are (or could be) changed, and everything else is a read address. For
instance, in a MOV $X,$Y instruction, X is a read address but Y is a
write address. All compares, jumps, and SPL use read addresses, because
nothing is changed in core. The address that's decremented by a DJN is
a write address. Each of the indirect addressing modes involves two
addresses, which may be classified differently: in a SUB >X,}Y
instruction, both of the intermediate addresses (X and Y) are write
addresses, because they're being incremented; the final addresses
(X+[X.B] and Y+[Y.A]) are read and write addresses, respectively.

Under R/W limits, each write address is calculated modulo the write
limit (WL), so that the address is "folded" into the range -WL/2+1 to
+WL/2. Similarly, each read address is folded modulo the read limit.
Under RF23 rules, the read limit is the same as the coresize, and since
all addresses are calculated modulo the coresize anyway, the extra
folding has no effect; any address in core can be "read". But the write
limit is 50000, so every write address will be folded into the range
-24999 to +25000, relative to the current instruction. This is true
even for indirect addressing; MOV bomb,@ptr will bomb the same section
of core no matter how far away ptr is.

Note that p-space addresses are not subject to R/W limits. STP
#42,#90000 will store a value in p-space location 90000 under RF23
rules. (P-space addresses are folded modulo the p-space size, but
that's a different story.)

If anyone has other questions they'd like to ask, please let me know,
and I'll try to address them (no pun intended).