> 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"... Killin
> 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 wh
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
>-Original Message-
>From: Eduardo Sabbatella <[EMAIL PROTECTED]>
>To: computer-go
>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 co
> > 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 sto
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
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 stone
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 rando
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 o
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 occasionally last for hundreds of moves.
How do you evaluate a game
On Fri, 2007-05-18 at 20:55 -0400, Chris Fant wrote:
> > my thinking is that in a situation like this, hardware advances aren't
> > yet the main limiting factor. and since the strength of 19x19 programs
> > of any variety are still many hundreds of ELO away from strong play, big
> > algorithmic ch
I don't understand why people always make a big issue out of this. I'm
sure that Chris Fant realizes we "lack infinite resources" but it's
important to understand the scalability properties of such things.
So when Chris Fant said, "given infinite resources" it's not crazy talk.
It's essential
my thinking is that in a situation like this, hardware advances aren't
yet the main limiting factor. and since the strength of 19x19 programs
of any variety are still many hundreds of ELO away from strong play, big
algorithmic changes (and not how those algorithms scale in the
distant hardware fu
> > 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
> 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:
>> 4) If there is a violation, go back to the copy and try the next best move
>
> 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"
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 miniscul
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
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 play
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
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 actual
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
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 t
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
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, 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 ot
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 tim
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 Posit
>
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 ch
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 simpl
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. Progres
31 matches
Mail list logo