OpenEuphoria

Re: Contest 2 Announcement:

• Posted by Patrick Barnes <mrtrick at gmail.com> Nov 29, 2004
• 556 views

On Mon, 29 Nov 2004 05:14:31 -0800, Andy Serpa <guest at rapideuphoria.com>
wrote:
> The time-limit itself I'm not concerned about, but let's say I have a program
> that "thinks" and I want to use my available time, whatever it is.  Using a local
> clock for 2 seconds * the # opponents I could implement, but not without breaking
> the rules (I would need to use .dll functions) because the timer in Euphoria is
> at a very low resolution (whole integer seconds) and not very suitable.  Or let's
> just say I have a slower machine on average my answers take 3 seconds to come up
> with.  I suspect that on your machine they will be fast enough, but maybe they
> won't?  How will I know?

Hey, I'm open to suggestions for an alternative time-limit metric... A
pity it's not really possible to count number of code lines executed.

> I don't see why it would be faster just because you can start them all at the
> same time.  The real time is taken up by the bots themselves:
> 
> for i = 1 to num_bots do
>    -- send start msg to bot # i
>    -- wait up to 2 seconds for response
> end for

Yes, ok. I'll make things sequential.


> > 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.
> >
> 
> Ok.  I have not studied how you are doing the IPC.  With certain kinds of
> event loops >there would be nothing preventing my program from sending my moves
> and then >immediately start thinking about new ones while simultaneously checking
> for new >messages from the main program.

Well, the only way to check for new messages blocks. There is no way
to start up another process... (You can only submit one file each
entry, and you can't spawn another instance to do multi-process
collaboration because the command-line is used already.)


> > 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.
> >
> 
> Again, depends on your IPC.  If you were to use pipes to each program, it
> could send an updated answer continously until the time runs out.  That's how
> chess engines work.

True, except I wasn't able to get pipes working, so I used a different
system. (Look at the sources, I *did* put plenty of comments in)

-- 
MrTrick