Re: [computer-go] KO in Hashtable-UCT?

2007-05-23 Thread Eduardo Sabbatella
In my experience adding a captured stoned limit per game biases the results. strongly. The limit was a constant number. Perhaps it could be good to define it as a function of current move number. In UCT-Suzie I stop also when one side has a big material advantage (captured much more

Re: [computer-go] KO in Hashtable-UCT?

2007-05-23 Thread Heikki Levanto
On Wed, May 23, 2007 at 06:47:58AM -0300, Eduardo Sabbatella wrote: In my experience adding a captured stoned limit per game biases the results. strongly. In which direction? The limit was a constant number. Perhaps it could be good to define it as a function of current move number. I

Re: [computer-go] KO in Hashtable-UCT?

2007-05-23 Thread Eduardo Sabbatella
game biases the results. strongly. In which direction? I was comparing my engine with GNUGO 3.6 level 1. It looses more frequently. I don't make any tests for the first 20 moves. Thereafter, I resign if - I have no stones left on board - I have less than half the number of stones my

[computer-go] CGOS up and running.

2007-05-23 Thread Don Dailey
CGOS is back up, both 9x9 and 19x19. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] KO in Hashtable-UCT?

2007-05-23 Thread dhillismail
-Original Message- From: Eduardo Sabbatella [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Wed, 23 May 2007 8:20 am Subject: Re: [computer-go] KO in Hashtable-UCT? game biases the results. strongly. In which direction? I was comparing my engine with GNUGO 3.6

Re: [computer-go] Go and UCT: article in June 2007 SciAm

2007-05-23 Thread Chris Fant
Favorite line: If the index equals the win rate of the move, the algorithm quickly focuses on the most promising path. On 5/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I just received the June issue of Scientific American and found a 1.5 page article on Computer Go and UCT. I've

[computer-go] My bad intuitions about Monte Carlo Go

2007-05-23 Thread Peter Drake
In previous versions of Orego, I have added one node per playout. I just changed that to add a child to a node only if that node has at least A runs, where A is the area of the board (e.g., 81). This seems to make the program stronger, if only because it allows me to get in more runs.

Re: [computer-go] KO in Hashtable-UCT?

2007-05-23 Thread Darren Cook
Heikki Levanto wrote: I don't make any tests for the first 20 moves. Thereafter, I resign if - I have no stones left on board - I have less than half the number of stones my opponent has I also pass if my opponent has no stones left on board. Eduardo Sabbatella wrote: My cut logic was:

Re: [computer-go] KO in Hashtable-UCT?

2007-05-23 Thread Darren Cook
What is the most extreme example of being behind (either by X stones, or by some percentage, such as Heikki's 50% above) where the losing player can make a comeback and win the game (assume perfect play by both players from that point)? I realized this is quite trivial: a board position where

Re: [computer-go] Go and UCT: article in June 2007 SciAm

2007-05-23 Thread Darren Cook
I just received the June issue of Scientific American and found a 1.5 page article on Computer Go and UCT. Just so I'm ready next time a computer go question comes up at a pub quiz, it says the Monte Carlo method was First incorporated into Go Programs in the 1970s. I'd have guessed 30 years