Alternatively, I wonder if there is some theoretical
way to work it out?
What is the most extreme example of being behind
(either by X stones, or
by some percentage, such as Heikki's 50% above)
I think the bias comes as MCGO needs to finish the
game up to the last stone/point... Killing a
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
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
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
-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
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:
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
On Sat, 2007-05-19 at 12:32 +0200, chrilly wrote:
In the play-outs, I'm pretty sure infinite play-outs due to not using
superko are possible - even with the randomness.But I have a limit
on the length of the play-out games because when you use heavy play-outs
the games can
The first option is what we do, too.
Peter Drake
http://www.lclark.edu/~drake/
On May 19, 2007, at 5:30 AM, Don Dailey wrote:
On Sat, 2007-05-19 at 12:32 +0200, chrilly wrote:
In the play-outs, I'm pretty sure infinite play-outs due to not
using
superko are possible - even with the
I have serious problems with KO. UCT-Suzie plays generally strong, but
makes
terrible blunders in KO-positions. So far I do not even understand the
problem. Could you describe it more detailed?
I had also some serious SuperKO problems. UCT-Suzie was very clever to
find SuperKOs. We do not
On 5/18/07, Chrilly [EMAIL PROTECTED] wrote:
When going down a variation the Hash and other Board-State Information like
e.g. the KO-Point are stored on a stack. Starting from the current Top of
Stack the detection goes down and search for the same hash-key and Ko-Point.
Its the Repeated
Non-capturing moves can create repetition (but there will of course be
captures elsewhere in the cycle).
So far the SuperKOs I have found where a round-trip of KOs.
Fortunately, there are other simple
criteria. E.g., you can stop whenever a move is played on an
intersection for the first
On 5/18/07, chrilly [EMAIL PROTECTED] wrote:
Non-capturing moves can create repetition (but there will of course be
captures elsewhere in the cycle).
So far the SuperKOs I have found where a round-trip of KOs.
Maybe the others are just hiding from you ;-)
Fortunately, there are other
It took me a long time to get around my mental block and accept the
advice of everyone here, but your intuition is correct: superko is so
rare, and so expensive to detect, that you should NOT check for it on
every move.
Orego's current approach is:
During search, just maintain a single ko
On 5/18/07, Peter Drake [EMAIL PROTECTED] wrote:
It took me a long time to get around my mental block and accept the advice
of everyone here, but your intuition is correct: superko is so rare, and so
expensive to detect, that you should NOT check for it on every move.
In dimwit, we check for
After search, when actually making a move:
1) Make a copy of the board
2) Compute the Zobrist hash of the current position from scratch
3) Check for superko violations (against a stack of previous Zobrist hashes
for positions in the real game,)
4) If there is a violation, go back to the copy and
Yes, that sounds reasonable too.
In thinking about optimization, the rule as always is keep the
common case fast. The cases in UCT Go, in decreasing order of
commonness, are:
1) Play a move in an MC playout
2) Play a UCT tree move
3) Start (or finish) a playout
4) Make (or accept) a move
True...
My experience has been that (largely) ignoring the extremely rare
case of superko is a better use of the finite resources we have.
Have others found the same thing?
Peter Drake
http://www.lclark.edu/~drake/
On May 18, 2007, at 9:19 AM, Chris Fant wrote:
After search, when
Peter Drake said:
It took me a long time to get around my mental block and accept the
advice of everyone here, but your intuition is correct: superko is so
rare, and so expensive to detect, that you should NOT check for it on
every move.
Depending on how a program works, you may well need to
I don't think you can ignore superko in the UCT search - you will lose
games. You will also lose games even if you only check the move you
will actually play in the game.
But in the play-outs, it has almost no value whatsoever, even if it
was free. (It probably has SOME value, but
John's post is almost identical to mine! Sorry about that. I could
have just said ditto for Lazarus.
- Don
On Fri, 2007-05-18 at 12:15 -0400, John Tromp wrote:
On 5/18/07, Peter Drake [EMAIL PROTECTED] wrote:
It took me a long time to get around my mental block and accept the advice
of
Lazarus does full superko in the UCT search - but the play-out only look
at
simple KO.
In the play-outs, I'm pretty sure infinite play-outs due to not using
superko are possible - even with the randomness.But I have a limit
on the length of the play-out games because when you use heavy
But then you have an engine which does not converge to perfect play
given infinite resources.
I assume that you're joking, given: a) a current lack of infinite resources,
and b) a current lack of convergence of any kind.
No, but I can rephrase for those spooked by the concept of infinity:
I have now also finished a first version of UCT-Suzie (in parallel the Peter
Woitke works on the Alpha-Beta Version). UCT-Suzie uses a hashtable, mainly
because I found the programming of the tree too complicated. The Monte-Carlo
part uses some simple patterns according the MoGo article.
On 5/17/07, Chrilly [EMAIL PROTECTED] wrote:
I have now also finished a first version of UCT-Suzie (in parallel the Peter
Woitke works on the Alpha-Beta Version). UCT-Suzie uses a hashtable, mainly
because I found the programming of the tree too complicated. The Monte-Carlo
part uses some simple
25 matches
Mail list logo
