Quoting Heikki Levanto [EMAIL PROTECTED]:
On Wed, Feb 07, 2007 at 04:42:01PM -0500, Don Dailey wrote:
In truth the only thing that matters is to increase your winning
percentage - not your score. There seems to be no point in tampering
with this.
I guess I must accept the wisdom of those
Quoting Don Dailey [EMAIL PROTECTED]:
Doing 8 searches is time-consuming, but I really prefer a book
that has a LOT of variety.
This is also one reason I now hand edit my book. Every time I correct a
bad move
there are often several ways of playing that I cannot tell which is better or
Thanks, Peter! I have a question or two regarding the opening book, based on a
collection of 3000 9x9 games provided by Nici Schraudolph. Who played the games
in this collecton - pros, strong amateurs, or go programs?
Second, were any statistics on the number of game moves in book versus
Magnus Persson wrote:
This is not a problem for scalability for MC/UCT. It just
means that a program ..
You are right. I didn't mean it is not scalable, of course
it is. What I mean is complexity is not, as one could
expect, about ~boardsize^4. (The square of legal moves
times the square of
The average score can contain a very large proportion of losees if it is
compensated by bigger wins.
yes, it is easy to see how this might cripple the play of an MC player.
that 90% territory win that requires 3 opponent blunders is tempting enough
to ignore the fact that all other
I think there are 15 first moves in 9x9 go if you factor out the
symetries.
UCT isn't good at evauating all the moves, it will pick one of them and
spend most of it's time on it.But you could search each 1 at a time.
The UCT programs are memory bound, so you could search each of these 15
I thought that the memory boundedness was completely fixed by not
expanding a UCT node until it has been visited X number of times.
Just increase X until you are no longer memory bound. I don't recall
anyone reporting a loss in playing strength by doing this.
On 2/8/07, Don Dailey [EMAIL
Quoting Don Dailey [EMAIL PROTECTED]:
I think there are 15 first moves in 9x9 go if you factor out the
symetries.
UCT isn't good at evauating all the moves, it will pick one of them and
spend most of it's time on it.But you could search each 1 at a time.
The UCT programs are memory bound,
On Thu, 2007-02-08 at 08:59 -0500, Chris Fant wrote:
I thought that the memory boundedness was completely fixed by not
expanding a UCT node until it has been visited X number of times.
Just increase X until you are no longer memory bound. I don't recall
anyone reporting a loss in playing
When I added code to by bot to prohibit single-stone suicide in the MC
playouts, I saw about a 200 ELO point gain plus an increase in pps due
to the shorter games. I did not need to limit game length to 2x board
area.
When I added code to also prohibit multi-stone suicides in the MC
playouts, I
Quoting Chris Fant [EMAIL PROTECTED]:
I understand that allowing multi-stone suicide seems like a bad idea,
but because it makes board repetition much more unlikely, it seems
like a good idea.
I do not understand how you get a problem of board repetition, and how
multi-stone suicde help with
Sounds like a bug. The randomness of the moves should make infinite loops
fairly rare (though not impossible) and your average game length should be
close to 100 moves.
It's a good idea to step through playout games one move at a time. Also to
run a lot of games, stopping to
Hello,
Is there any known (by theory or tests) function of how much a increase
in the strength of the simulation policy increases the strength of the
MC/UCT Program as a whole?
I think that is a very interesting question.
In our work on MoGo we found that there could be a decrease of the
This makes no sense to me. Most of us are working on how to improve
the quality of the quasi random simulations and you are considering
to allow the worst moves.
Your eye rule probably keeps this from getting completely out of
control, but I would say allowing any suicide should greatly
On 2/7/07, David Doshay [EMAIL PROTECTED] wrote:
On 7, Feb 2007, at 1:35 PM, Don Dailey wrote:
Although suicide can occasionally be the best move in some
rule-sets, I think it weakens your program to include it,
At best you are going to get a ko threat, so it requires a pretty
In our work on MoGo we found that there could be a decrease of the
strength of the MC/UCT program while using a stronger simulation
policy. It is why in MoGo it is more the sequence idea, than the
strength idea. Our best simulation policy is quite weak compared to
others we tested.
Could you
Could you elaborate on the sequence idea? Or point me to somewhere
where you have already done so?
Sure. We already describe it in our research report that you can find there:
http://hal.inria.fr/inria-00117266
or there if you prefers the web interface in english but with a longer URL :-)
Last one, I promise :) If your eye rule doesn't allow the defender to fill
in behind the ko stone (the one in atari), that can set up infinite loop triple
kos.
- Dave Hillis
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Thu, 8 Feb 2007 12:19
On 2/8/07, steve uurtamo [EMAIL PROTECTED] wrote:
i wonder if this kind of greediness might, however, be useful for selecting,
say, the first move or two in a 9x9 game. the thinking here is that since the
endgame is essentially noise at this point, you might as well be greedy
before tactics
One simple explaination could be that a random player shamelessly tries all
moves (very bad ones but also very nice tesuji) whereas the stronger player
is restricted by its knowledge and will always miss some kind of moves.
Here we are not speeking about the pruning in the tree, but the
This sounds backwards.
If multi-stone suicides ARE allowed then it opens up board areas
that can then be replayed. This could lead to infinitely long games.
Cheers,
David
On 8, Feb 2007, at 7:45 AM, Chris Fant wrote:
When I added code to also prohibit multi-stone suicides in the MC
On Thu, 8 Feb 2007, Chris Fant wrote:
When I added code to also prohibit multi-stone suicides in the MC
playouts, I saw the appearance of infinitely long games due to
unrestricted board repetition. So I then had to add the 2x board area
limit. But I also saw a significant drop in strength and
It seems i was ambiguous: I was speaking of the simulation player too.
What i meant is a random simulation player is not biased, whereas a better
simulation player is biased by its knowledge, and thus can give wrong
evaluation of a position.
I think we have to start defining what the bias. For
Actually this is all I ever wanted! Now if only I could convince the whole
Computer Go community to use it, but that seems unlikely :)
-Original Message-
From: Joshua Shriver [EMAIL PROTECTED]
To: Dmitry Kamenetsky [EMAIL PROTECTED], computer-go
computer-go@computer-go.org
Date: Wed, 7
Now that's low traffic! One post in May of 2006, and since then, nada. No
spambots, no griefers. :)
Terry McIntyre
-Original Message-
From: Joshua Shriver [EMAIL PROTECTED]
To: Dmitry Kamenetsky [EMAIL PROTECTED], computer-go
computer-go@computer-go.org
Date: Wed, 7 Feb 2007 09:35:54
On Thu, 2007-02-08 at 15:55 -0500, Don Dailey wrote:
The children of one parent almost certainly will have different 64 bit
keys than the children of the other parent.
Not if the parents collide.
(apart from symmetry/canonical considerations):
if H(A)==H(B),
then after applying move 'm'
--
I think that the bias Alain meant is the choice of moves that control
the
branching factor. If I understand correctly, this can happen differently
in two places in MoGo: once in the branching below a node in the UCT
tree, and either the same or differently in the random playouts.
In some ways
We had this same problem and wasted a huge amount of time and
energy on trying to determine the right canonical key. I felt both
proud and stupid when I realized: it really does not make any
difference which is the canonical key, so we just declare the first
one that we find to be the canonical.
tranforms as the cannonical key. In most cases 8 positions will
IIRC, choosing the smallest may cause some unwanted effects. Not sure...
It's not quite as good as using 64 bits free and clear because there is
compression towards the lower bits.
i must be missing something here -- the
On Fri, 2007-02-09 at 01:35 +0300, Dmitry Kamenetsky wrote:
Actually this is all I ever wanted! Now if only I could convince the
whole Computer Go community to use it, but that seems unlikely :)
Smiley aside, wouldn't it be more constructive to do as somebody else
suggested, and use the email
Okay, I found the bug. There was actually two. I won't bore you with
the details. Sorry for wasting everyone's time.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
On Thu, 2007-02-08 at 15:58 -0800, steve uurtamo wrote:
tranforms as the cannonical key. In most cases 8 positions will
IIRC, choosing the smallest may cause some unwanted effects. Not sure...
It's not quite as good as using 64 bits free and clear because there is
compression
light is always a good adagium, see David Fotlands hilarious
compression of a joseki library into 12 bits/move, IIRC ;-)
More like 10 bits per move to store the joseki DAG, moves, pointers, and
good/bad/trick flags. I would never do anything like that now, but back
then the entire go
On Thu, 2007-02-08 at 15:36 -0800, David Doshay wrote:
We had this same problem and wasted a huge amount of time and
energy on trying to determine the right canonical key. I felt both
proud and stupid when I realized: it really does not make any
difference which is the canonical key, so we
It depends. (though travel light is always a good adagium,
see David Fotlands hilarious compression of a joseki library
into 12 bits/move, IIRC ;-)
this reminds me of an old-school optimized piece of scrabble-playing
code. there was a routine that would take an ascii list of words and
create
On Thu, 2007-02-08 at 15:58 -0800, steve uurtamo wrote:
tranforms as the cannonical key. In most cases 8 positions will
IIRC, choosing the smallest may cause some unwanted effects. Not sure...
It's not quite as good as using 64 bits free and clear because there is
compression
On Thu, 2007-02-08 at 18:43 -0800, steve uurtamo wrote:
It depends. (though travel light is always a good adagium,
see David Fotlands hilarious compression of a joseki library
into 12 bits/move, IIRC ;-)
this reminds me of an old-school optimized piece of scrabble-playing
code. there
I was only joking. Ofcourse I will do as you suggested. I just didn't realize
that it was possible to use the email list as a feed.
Thank you everyone for your constructive feedback and suggestions. Consider
this topic closed.
-Original Message-
From: Jeff Nowakowski [EMAIL PROTECTED]
On 8, Feb 2007, at 6:42 PM, Don Dailey wrote:
On Thu, 2007-02-08 at 15:36 -0800, David Doshay wrote:
We had this same problem and wasted a huge amount of time and
energy on trying to determine the right canonical key. I felt both
proud and stupid when I realized: it really does not make any
39 matches
Mail list logo
