I am slowly getting my little bot to do very light playouts. I came to think
about detecting ko. Is it even necessary in a simple playout? During the
earlier stages of the game, the playouts have no idea of wanting to
recapture the ko, of ko threats, or anything else. Only in the endgame can
we ru
It has been discussed already on this list. The common approach is to not
even bother to try detect ko in playouts. In case of infinite game (very
rare but happens) you can just put a threshold on the number of moves and
igore the result. Of course you have to detect ko in the tree search part
Ivan Dubois wrote:
> It has been discussed already on this list. The common approach is to not
> even bother to try detect ko in playouts. In case of infinite game (very
> rare but happens) you can just put a threshold on the number of moves and
> igore the result. Of course you have to detect ko i
what happens with the following?
rank the moves as normal, ignoring ko.
choose the highest ranked legal move at the end.
(i.e. only check for ko-legality when choosing the
final move)
s.
On Mon, Jun 15, 2009 at 4:45 PM, Heikki Levanto wrote:
> I am slowly getting my little bot to do very light
Permutating through liberties in a semiai seems especially painful from a
human perspective.
And doing so in multiple fights, without separating them somehow, is
ofcourse much more painful still.
Maybe someone will find a way of destilling the concept of leading or
trailing a semiai out of the M
I've been working on the new server and I'm almost at the point where
I can think about time controls - and since this is primarily for
developers, I would like to get your thoughts.
First, a brief explanation of how the time control works. When the
client starts up it will inform the server of
I don't like venues, because it spreads out the programs so there are fewer
available opponents. I think we want to encourage as many programs as
possible in the same pool to keep the ratings accurate and have a lot of
different ratings populated. So the fewer venue choices, the more programs
at
>I don't like venues, because it spreads out the programs
>so there are fewer available opponents.
I agree with David. Have one time control per board size.
I like the 5-minute controls for 9x9. You can take your program
down for extensive offline testing and still get 100 games per day.
That is
> I agree with David. Have one time control per board size.
>
> I like the 5-minute controls for 9x9. You can take your program
> down for extensive offline testing and still get 100 games per day.
> That is far more data than you can analyze. Still, the speed is
> fast enough for ratings to stabi
Given all the negative reaction to nested time control, I have to say
I like it. The pool won't be diluted as long as there's an obvious
main venue.
Sent from my iPhone
On Jun 15, 2009, at 7:20 PM, Don Dailey wrote:
I've been working on the new server and I'm almost at the point where
I c
2009/6/15 David Fotland
> I don’t like venues, because it spreads out the programs so there are
> fewer available opponents. I think we want to encourage as many programs as
> possible in the same pool to keep the ratings accurate and have a lot of
> different ratings populated. So the fewer v
On Mon, Jun 15, 2009 at 9:43 PM, Jason House wrote:
> Given all the negative reaction to nested time control, I have to say I
> like it. The pool won't be diluted as long as there's an obvious main venue.
A good compromise might be to have only 2 venues, one such as David
suggested and another
>The argument for longer time controls is that it encourages the
>development of new algorithms. New algorithms are usually slower. It
>might take 10 man hours to quickly code up a new idea. Sure we can
>optimize it to run 10 times quicker, but that takes another 90 man
>hours. We want to see how w
>Or they may not implement a proper time control algorithm and thus
>would not be able to adapt to 2 different time controls without being
>reinitialized with different parameters.
Programs with fixed trials appear to be common. There is no reason to
believe that they will complete faster games.
On Mon, Jun 15, 2009 at 4:02 PM, Brian Sheppard wrote:
>
> One thing I would *really* like to know is how to make something
> 10 times quicker using only 90 man hours. :-)
>
In my experience, the first ten times faster takes about the same time
extra as programming the original idea. It's the next
I'll express my opinion here, but keep in mind that my engine (cogito)
has only played 44 games as of now on CGOS. I have a few problems with
separate time controls.
--It dilutes the rating pool. If there is only one time control,
everyone can play everyone. If there are separate time controls, th
I'm for keeping the number of pools small, to keep their sizes large.
Peter Drake
http://www.lclark.edu/~drake/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
On Mon, Jun 15, 2009 at 11:18 PM, Zach Wegner wrote:
> I'll express my opinion here, but keep in mind that my engine (cogito)
> has only played 44 games as of now on CGOS. I have a few problems with
> separate time controls.
>
> --It dilutes the rating pool. If there is only one time control,
> e
If more than one venue is mandatory I probably won't be able to join, since
I want to spend my limited programming time making the engine stronger, not
programming multiple time controls. Please allow me to play with just a
singe time limit without changing my cgos interface code.
David
Fr
19 matches
Mail list logo
