Re: Contest 2 Announcement:
On Sun, 28 Nov 2004 07:41:51 -0800, Andy Serpa <guest at rapideuphoria.com>
wrote:
> Rules suggestion:
>
> You must submit your orders within 2*n seconds of the "turn" beginning,
> correct? I see a couple of potential problems with this:
>
> A) Your machine is your machine, running at its own speed. The rest of have
> to guess if our moves will take too long on your machine.
True, but I have a fairly fast machine (2.4Ghz, 512mb ram, corporate
machine - nothing cluttering it up )
Can you think of a better metric? My concern is that matches can take
a long time, an entire tournament even longer.
> B) A resource-intensive, number crunching program or something with heavy-disk
> access will likely inhibit another program if they are running in parallel, even
> though in theory they should get equal slices. On Windows, they simply won't.
> There are a number of factors that can affect this, who started up first, is one
> program accessing the disk alot, etc.
That's true... any data file that a program uses is restricted to a
small size though. (Perhaps I should implement file access routines in
eubots.ew to enforce this?)
> I would propose two changes to your evaluation routine:
>
> 1) Do not run the programs in parallel. Ask for and receive the orders for
> each program in turn, and once you've collected all the orders, evaluate them as
> normal. In other words, simulate parallel, but don't do actual parallel. This
> will not slow things down, but it will guarantee that each program gets 100%
> resources. (It would also be easier to code the engine, I would think.)
Actually, it's easier like it is, because the complexity is handled by
the windows API. 
You're right, it would be *fairer* to do things sequentially, I'm just
concerned about the time. Interleaving the processes makes it a lost
quicker, because I can start *all* of the processes, and wait on *all*
of them to finish. (See the waitForMultipleObjects function in
kernel32.dll, it's wonderful). If it was individual, each would need
their own timeout, and turns would take a lot longer to process.
>There also needs to be rule addition: NO "THINKING" outside your
allotted time. If I were to use a chess-program like algorithm, it
could just go on calculating potential orders 100% of the time, taking
up resources, etc. It should be enforced that the program isn't
allowed to do anything except sit there between calls from the main
engine for get_orders().
I may be wrong, but I don't believe that's possible. No top-level
statements are permitted, and the get_orders() function *has* to
return. The only way the MSG_GETMOVE can be received by the bot is if
it's waiting inside eubots.ew.
> 2) Instead of forcing the program to return in an allotted time (which we have
> to guess, although we could maintain a local clock in the program I suppose),
> allow each program to update a variable that contains a set of "current orders"
> and the system will simply take whatever the current value of this variable is at
> the end of the alloted time. This will allow for "anytime" algorithms that just
> keep updating an answer the longer they have to think about it. If the program
> has a "definite" answer, it can submit as soon as its ready, of course.
That is an interesting idea... The way that it works currently is that
if the program is late in returning orders for turn N, its orders are
used in turn N+1, by which time they may not be useful.
> These changes would likely slow down the evaluation because people might want
> to use all of their time each turn, but it would allow for more complex and
> interesting strategies. It would also allow the program to do evaluation itself
> iteratively by examining possibilities instead of trying to hand-code every
> nuance of the strategy. This would also potentially mean that certain bots would
> get stronger the faster the machine the tournament is run on. You may or may not
> like this implication. You could also ban these sort of endless loop algorithms
> altogether, I suppose, but one way or another I think you need to deal with the
> possibilities...
Well, at some stage it has to relinquish control, or it won't be able
to wait on the signal for new orders. I will absolutely not allow a
timeout or non-blocking call to wait for a new orders signal.
Otherwise...
procedure run_match(sequence initial_orders, sequence initial_metrics)
while 1 do
start_time = time()
*figure out orders*
temp = sendOrdersAndWaitForUpdate(orders)
arena = temp[1]
metrics = temp[2]
end while
end procedure
Like this? I don't see how it's any different from the current
functional implementation. The only difference being that the local
variables stay... and that is academic, because you can have global
variables if you want...
What do others think? Would you prefer a setup like this?
(I'm not going to allow both functionl and this, I think that'd be a
large headache.)
--
MrTrick
|
Not Categorized, Please Help
|
|
