It would be nice to have a reference implementation.
I can do that on Java (yes Its not C but its reference
implementation and for free, I would do a lot of
JUnits in exchange).
What do you think ?
--- £ukasz Lew <[EMAIL PROTECTED]> escribió:
> Hi,
>
> There are some issues that are not so we
On Sat, Mar 03, 2007 at 04:10:16PM -0500, Don Dailey wrote:
> And you CAN compare GTP directly to UCI because both are designed for
> the same purpose and both are simple text based protocols and the
> similarities are much greater than the differences.
GTP has many purposes. One of them is to sit
In my view, the most important features of GTP are its ability to mediate
for tournements. It lowers the bar for building a program. Anything that
changes that is bad news. However, there are some problems with the current
protocol such as its inability to handle rules. I feel it is a step in
Hello Peter, Hello Don, Hello all,
It is true that I have been mainly working to improve the level of MoGo in
19x19. It turned out in my experiments, that improving its level in 9x9 with
very little simulations was significant for the level in 19x19, so it is one
reason why the limited version of
On Mon, Mar 05, 2007 at 10:52:23AM +0100, Sylvain Gelly wrote:
> I still strongly believe in the future of MC even in 19x19.
I would also like to try my hand at 19x19. Wouldn't it almost be time
for a playground server, like cgos, but on a larger board. Of course
there would have to be more time (
Just an small thought
GTP could implement "async" commands. Adding commands
like:
CHAT
ABORT
etc.
Its up to the engine to read them as soon as possible,
or wait to read/process them after processing a
get_move command.
I think just adding a couple of new commands that some
engines could impleme
Don,
Perhaps I'm completelly wrong, but pondering is up to
the engine, the controller, nobody outside the engine
will know / have to know if the engine is pondering.
I think in the threads we are confusing the fact that
the engine and the gtp line controller could be in two
different process thre
I think you are mostly correct. But, the problem is that GTP was designed
to block on the genmove command. This is a problem because genmove is
usually not quick to return. Therefore, there is no way with the current
scheme to be able to issue commands while an engine is thinking. It would
req
Actually gen_move blocks because every engine uses the
same thread for both the engine and the comm link.
you can have a couple of sub commands for get_move
like: get_complete_percent, get_current_best_move,
chat, etc.
If the engine doesn't support "realtime" gtp, they
will be answer after the ge
On Mon, Mar 05, 2007 at 09:50:30AM -0300, Eduardo Sabbatella wrote:
> Actually gen_move blocks because every engine uses the
> same thread for both the engine and the comm link.
Yes. That is not a bug, it is a feature, when using GTP for debugging,
automatic tests, or something else that is based
On Mon, 2007-03-05 at 10:10 +0100, Heikki Levanto wrote:
> On Sat, Mar 03, 2007 at 04:10:16PM -0500, Don Dailey wrote:
> > And you CAN compare GTP directly to UCI because both are designed for
> > the same purpose and both are simple text based protocols and the
> > similarities are much greater th
Sylvain,
What you say is no surpise to me about the constraints. I knew that if
you improved things, you would eventually have to improve or reduce
the constraints.
The simple question I always ask about a feature is whether the idea
is infinitely scalable. Some idea are very good in the shor
Also sometimes it scales but not lineal, thats an
issue to. A big one.
Like raw MC, you can get a very good move with less
than 70k simulations, to get a really good move
perhaps you need 400 billons.
I remember there is a paper about this with a 'oracle'
MC engine and they used it to compare to d
I agree with you. My idea is to not have a specific aync
command, but to have anycronous versions of commands. The
engine is free to accept or reject them. Having an async
command doesn't do anything if you haven't implemented the
useful needed extensions.Of course it could change the
mean
We got consensus :-)
Yes some messages are async, some are synqued. If an
async message/reply is received in the wrong time, it
could be ignored as they use to be information only
values, no state change of the game.
cool :-)
--- Don Dailey <[EMAIL PROTECTED]> escribió:
> I agree with you. My
just a thought...
prefix all async commands with "async_" so that it is clear. Also, that way
there can be a version of the command that is async and one that blocks and
an engine can support one or both. This could be useful for commands that
query on state (or estimated score or whatever). A
On Mon, 2007-03-05 at 09:32 -0300, Eduardo Sabbatella wrote:
> Don,
>
> Perhaps I'm completelly wrong, but pondering is up to
> the engine, the controller, nobody outside the engine
> will know / have to know if the engine is pondering.
My program Lazarus ponders on CGOS, without any help
from th
Yes, it's possible to do all of this with GTP as is and
the addition of a few commands that stay blocking, nothing
but pure GTP extensions and no asyncronous communication.
I already mentioned this as polling. Instead of genmove,
you send inc_genmove, which is designed to return very
quickly an
I do not think that genmove should work that way. It makes more sense for
you to have a genmove command and an async_endsearch command or
somethinglike that. The program is allowed to keep searching as long as it
doesn't receive that command. genmove doesn't need to have an async mode
really.
I don't think it should work that way either. I was just suggesting
that it's
possible to do everything required without any anynchronous changes to
GTP,
but I certainly don't recommend this method.
- Don
On Mon, 2007-03-05 at 10:07 -0600, Nick Apperson wrote:
> I do not think that genmove shou
On Mon, 2007-03-05 at 11:58 -0300, Eduardo Sabbatella wrote:
> Also sometimes it scales but not lineal, thats an
> issue to. A big one.
>
> Like raw MC, you can get a very good move with less
> than 70k simulations, to get a really good move
> perhaps you need 400 billons.
> I remember there is a
Congratulations to MoGo for winning both divisions, with a total of 12
wins and no losses, despite the fast time limits and large boards! I
must confess I did not expect this. It is a most impressive result.
My report is at http://www.weddslist.com/kgs/past/24/index.html. I fear
it probably
Maybe this would make a good Go card:
http://gizmodo.com/gadgets/peripherals/nvidia-ships-128core-graphics-cards-for-highend-film-editors-graphics-pros-apple-excited-241478.php
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer
Don Dailey wrote:
On Mon, 2007-03-05 at 10:10 +0100, Heikki Levanto wrote:
On Sat, Mar 03, 2007 at 04:10:16PM -0500, Don Dailey wrote:
And you CAN compare GTP directly to UCI because both are designed for
the same purpose and both are simple text based protocols and the
similarities are much gr
On Mon, 2007-03-05 at 20:00 -0600, Matt Gokey wrote:
> I'm entering this discussion a bit late, but what about the following
> idea?
>
> Perhaps we could start from scratch and create the protocol we want
> with
> no compromises based perhaps on an async event message model - a
> model
> everyon
25 matches
Mail list logo
