Redcoders Frenzy 12: The Limited Distance Round ***Announcement****
Fizmo
. .
. _____ _ _ .
. | __ \ | | | | .
. | |__) |___ __| | ___ ___ __| | ___ _ __ ___ .
. | _ // _ \/ _` |/ __/ _ \ / _` |/ _ \ '__/ __| .
. | | \ \ __/ (_| | (_| (_) | (_| | __/ | \__ \ .
. |_| \_\___|\__,_|\___\___/ \__,_|\___|_| |___/ .
. .
. ______ .
. | ____| .
. | |__ _ __ ___ _ __ _____ _ .
. | __| '__/ _ \ '_ \|_ / | | | .
. | | | | | __/ | | |/ /| |_| | .
. |_| |_| \___|_| |_/___|\__, | .
. __/ | .
. |___/ .
...................................................................
The ongoing corewar tournament
__ ___
/_ |__ \
| | ) |
| | / /
| |/ /_
|_|____|
..............................
. .
. The Limited Distance Round .
. .
..............................
This is the 12th round of the ongoing corewar tournament. Detailed
information are available on Fizmo's Ultimate Corewar Page:
http://de.geocities.com/fizmo_master/cwt.htm
...................................................................
. _ .
. _ _ _ _| |___ ___ .
. | '_| || | / -_|_-< .
. |_| \_,_|_\___/__/ .
. .
...................................................................
Coresize: 8000
Max. processes: 800
Max. cycles: 100000
Max. length: 100
Min. distance: 800
Read limit: 800
Write limit: 800
Rounds: 200
Points per win: 3
Points per tie: 1
Points per loss: 0
Round Robin without Self-Fights.
Two Entry's are allowed.
You need for this round CoreWin 2.0
^^^^^^^^^^^
The homepage of this round, including some more informations and
the link to CoreWin 2.0 is:
http://de.geocities.com/fizmo_master/12.htm
Some hints will be added soon.
...................................................................
. _ _ _ _ .
. __| |___ __ _ __| | (_)_ _ ___ .
. / _` / -_) _` / _` | | | ' \/ -_) .
. \__,_\___\__,_\__,_|_|_|_||_\___| .
. .
...................................................................
August 10th, 2003
--------------------------------------------------------------
Please notify: You have to send your entries to me
--------------------------------------------------------------
Good luck, may be the core with you!
Dave Hillis
> . .
> . The Limited Distance Round .
> . .
> ..............................
>
RE: read/write limits, Redcoders Frenzy, and Corewin
I am hacking up exhaust so I can evolve some entries for the next round
of the contest. (I hope to make it available after it's wrung out.) I came
across some things that may be of general interest.
I find this sort of analysis to be highly error prone so please
correct or clarify if needed. (Blessedly, read and write limits are
identical for this round so I can ignore some issues.)
The rules for round 12 of the Redcoders Frenzy, specify that you must
have Corewin. They do not mention the ICWS 94 draft so it is Corewin that
defines how read/write (and jmp/spl) limits are to be implemented for this
contest.
The (very usefull) example warriors on the Frenzy site were written for
a MARS where a write command (i.e. MOV) pointing outside the write limits
would not change memory anywhere. In Corewin, the address would be
"folded" (i.e. wrapped) so that a memory location within the limits would
be written into. The ICWS 94 draft also includes address folding and
includes an example function to illustrate how it is to work. But this
funtion does not always produce the same behavior as Corewin. It produces
a different result for one specific relative address. Also, in Corewin,
JMPs and SPLs are folded as well.
It is worth remembering that the ICWS 94 draft is actually a draft. The
read/write limits were never completely nailed down. If I regarded Corewin
as having a "bug," I wouldn't be posting about it to the group. I think
it's a "feature."
The function below is intended to illustrate how both Corewin and ICWS
94 fold addresses.
Dave hillis
// 7/19/03 added to Exhaust by Dave Hillis
// A modified version of the folding function from the ICWS 94 draft.
// It wraps addresses to point within the "core within a core"
// imposed by read/write limits.
// pointer is an unsigned number relative to the center
// (executing command). result is an unsigned number relative to the
// center (executing command).
//
/* There is one support function used to limit the range of */
/* reading from Core and writing to Core relative to the */
/* current instruction. Behaviour is as expected (a small */
/* core within Core) only if the limits are factors of the */
/* size of Core. */
static u32_t Fold(
u32_t pointer, /* The pointer to fold into the desired range. */
u32_t limit, /* The range limit. */
u32_t M /* The size of Core. */
)
{
u32_t result;
// ~~~~~~~~~~~~~~~~~~~~~~~~~~
// corewin deviates from the ICWS standard in that a command may
// write to the address at (current line - (limit/2)).
// But not by folding!?
// Adresses reachable by folding (wrapping) are
//
// - (limit/2) < addresses reachable <= (limit/2)
//
// Assuming limit is an even integer that evenly divides
// coresize. That is the same range as for the ICWS 94
// draft standard. However,
// the function included in the 94 draft would NOT allow
// access to the
// address at (current line - (limit/2)) at all.
//
if (pointer > M) {pointer %= M;}
if (pointer == M - (limit/2))
{
return(pointer);
}
// end of special case for Corewin compatibility
// ~~~~~~~~~~~~~~~~~~~~~~~~~~
result = pointer % limit;
if ( result > (limit/2) ) {
result += M - limit;
};
return(result);
}
Chip Wendell
is a feature that bears some discussion.
The '94 draft specifies that _all_ effective address calculations are
folded by the R/W limits, including jumps, splits, decrements, etc.
(JMPs and SPLs use the read limit; incs/decs use the write limit.) The
stated goal is a "core within Core" kind of behavior. However, this
behavior is guaranteed only when the read or write limit (L) is a
factor of the core size (M); for other cases, the behavior is not
defined.
The example folding function in the draft uses an algorithm that works
well when M % L = 0. When M % L <> 0, however, addresses in the range
-L/2 to -1 are shifted by some amount, breaking any warrior that uses
offsets in that range. Even a simple JMP -1 won't work as expected. It
seemed like an unnecessarily harsh way to handle non-standard core
size/limit combinations.
I decided to modify the folding function slightly, so that all "local"
addresses, from -L/2 to +L/2, remain unchanged, regardless of the
relation between the limits and core size. Here's what the folding
function in CoreWin looks like (using Dave's notation):
if (pointer >= M - (limit/2)) {
return(pointer);
}
result = pointer % limit;
if (result > (limit/2)) {
result += M - limit;
}
return(result);
I intended this modified function to give identical results to the
draft algorithm for the usual cases when M % L = 0. However, I should
have used ">" on the first line, not ">=". That results in the
anomalous behavior at address M - L/2 that Dave found.
The short-term question is, what should be done for the Limited
Distance Round? I can eliminate the bug and release a patched version
of CoreWin quickly. Or I can wait until the next scheduled release to
include the fix, and people can use the current version for the
tournament.
The other issue is the change I made to the draft folding algorithm,
to preserve local addresses. I didn't really intend to "set the
standard" for everybody; I just wanted to be able to experiment with
odd core sizes without my warriors breaking! I suppose we ought to
have some kind of discussion about which algorithm to use. If the
consensus is to stick with the draft algorithm, I'll switch CoreWin
back to that. Bear in mind that the current CoreWin algorithm (once
it's fixed) gives identical results to the draft one when the R/W
limits are factors of the core size, so there's no fear that warriors
will start breaking if we make a change later.
Fizmo
R/W Limit in CoreWin. I found the same things the last days, too. Also
that for a R/W limit of 800 in the battle parameter the 'core in the
core' contains just 799 instructions.
Therefore I've updated the homepage of the Limited Distance Round at:
http://de.geocities.com/fizmo_master/12.htm
and my new Corewar Info Page at:
http://www.corewar.info/tournament/12.htm
deleting the aberrant link. I'll add soon a small hint which will
discuss a bit the possible strategies.
>
> The short-term question is, what should be done for the Limited
> Distance Round? I can eliminate the bug and release a patched version
> of CoreWin quickly. Or I can wait until the next scheduled release to
> include the fix, and people can use the current version for the
> tournament.
I think we should let it as it is for Round 12 and maybe fixing it in
a future release. Rounds with non standard settings/limitations/etc.
have a great appealing for most of the player, including myselfe ;-)
> The other issue is the change I made to the draft folding algorithm,
> to preserve local addresses. I didn't really intend to "set the
> standard" for everybody; I just wanted to be able to experiment with
> odd core sizes without my warriors breaking! I suppose we ought to
> have some kind of discussion about which algorithm to use. If the
> consensus is to stick with the draft algorithm, I'll switch CoreWin
> back to that. Bear in mind that the current CoreWin algorithm (once
> it's fixed) gives identical results to the draft one when the R/W
> limits are factors of the core size, so there's no fear that warriors
> will start breaking if we make a change later.
My personal opinion is that the algorithm you are using are well
deliberated. I don't see any reason why to go a step back.
Fizmo
R/W Limit in CoreWin. I found the same things the last days, too. Also
that for a R/W limit of 800 in the battle parameter the 'core in the
core' contains just 799 instructions.
Therefore I've updated the homepage of the Limited Distance Round at:
http://de.geocities.com/fizmo_master/12.htm
and my new Corewar Info Page at:
http://www.corewar.info/tournament/12.htm
deleting the aberrant link. I'll add soon a small hint which will
discuss a bit the possible strategies.
>
> The short-term question is, what should be done for the Limited
> Distance Round? I can eliminate the bug and release a patched version
> of CoreWin quickly. Or I can wait until the next scheduled release to
> include the fix, and people can use the current version for the
> tournament.
I think we should let it as it is for Round 12 and maybe fixing it in
a future release. Rounds with non standard settings/limitations/etc.
have a great appealing for most of the player, including myselfe ;-)
> The other issue is the change I made to the draft folding algorithm,
> to preserve local addresses. I didn't really intend to "set the
> standard" for everybody; I just wanted to be able to experiment with
> odd core sizes without my warriors breaking! I suppose we ought to
> have some kind of discussion about which algorithm to use. If the
> consensus is to stick with the draft algorithm, I'll switch CoreWin
> back to that. Bear in mind that the current CoreWin algorithm (once
> it's fixed) gives identical results to the draft one when the R/W
> limits are factors of the core size, so there's no fear that warriors
> will start breaking if we make a change later.
My personal opinion is that the algorithm you are using are well
Joshua Hudson
>From: ch...@mdli.com (Chip Wendell)
>I decided to modify the folding function slightly, so that all "local"
>addresses, from -L/2 to +L/2, remain unchanged, regardless of the
>relation between the limits and core size. Here's what the folding
>function in CoreWin looks like (using Dave's notation):
>
> if (pointer >= M - (limit/2)) {
> return(pointer);
> }
> result = pointer % limit;
> if (result > (limit/2)) {
> result += M - limit;
> }
> return(result);
>
>I intended this modified function to give identical results to the
>draft algorithm for the usual cases when M % L = 0. However, I should
>have used ">" on the first line, not ">=". That results in the
>anomalous behavior at address M - L/2 that Dave found.
>
My opinion: This method should be considered the standard, however
M - L/2 needs further discussion. Breaking JMP -1 is not an option!
_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus
Dave Hillis
> > ..............................
> > . .
> > . The Limited Distance Round .
> > . .
> > ..............................
> >
>
> RE: read/write limits, Redcoders Frenzy, and Corewin
>
> I am hacking up exhaust so I can evolve some entries for the next round
> of the contest. (I hope to make it available after it's wrung out.)
I have a modified version of exhaust for the contest, some code
to save one from having to run some tie-battles, a small collection of
circa-1992 X-hill warriors, and a version of my evolver program
Redrace that seems to produce respectable warriors (although Shotgun
and Sonic Boom rip them all to shreds).
Would anyone like any of these? I mean't to offer earlier.
Dave Hillis
Sascha Zapf
Send the Link to Fizmo, he can put them onto the Rules/Hints Site.
Sascha
------------------
Powered by NetMail
Fizmo
The ongoing corewar tournament
Detailed information are available on the new The Corewar Info Page:
http://www.corewar.info/tournament/cwt.htm
I've added also a small hint for a better understanding of the rules:
http://www.corewar.info/tournament/12.htm
...................................................................
. _ _ _ _ .
. __| |___ __ _ __| | (_)_ _ ___ .
. / _` / -_) _` / _` | | | ' \/ -_) .
. \__,_\___\__,_\__,_|_|_|_||_\___| .
. .
...................................................................
NEW NEW: August 17, 2003