Le 08/04/2009 à 07:28, Petri Pitkanen a écrit :
This is nice idea and this is to a degree what GnuGo regression test
does.
afaik, gnugo testsuite (based on a previous one) is not totally suitable
for MC programs, as some position are dead lost / clear win but shows
gg misbehavior.
Some
David Fotland wrote:
Yes, I walk both chains looking for duplicates. This is quite fast if done
efficiently, since group merging is rare enough. I found keeping the
liberty arrays to be slower since they are big, so there is more copy
overhead in the UCT tree, and they are not cache
On Wed, Apr 8, 2009 at 01:13, Darren Cook dar...@dcook.org wrote:
Linked lists have a terrible cache behaviour: every pointer (or index)
dereference has a nearly 100% chance of causing a cache miss.
...
It's quite easy and efficient to put all lists (cyclic, linked in one
direction) of
Do you have some code demonstrating the above idea? It sounds
interesting, but I cannot grasp what the data and algorithm look like.
4*19*19*4 is around 5.5 kB
On 9x9 it will be less than 1.5 kB
Are you still interested?
My own method is a large pre-allocated pool of Chain objects, which
On Tue, Apr 7, 2009 at 23:52, Claus Reinke claus.rei...@talk21.com wrote:
Last time I looked more closely at what my MC bot (simple, no tree)
was doing, I noticed that it has a tendency to try the impossible moves
(suicides) first, discarding them as impossible for every genmove.
Looking at
I think most of test are designed by people who is stronger than best
computer go program. So if MC program fail to pass a test, it is most likely
MC is wrong. MC program is strong in some aspect, but week in other aspect.
And the test suit is too focus on special aspect. We might split the test
On Wed, Apr 8, 2009 at 09:12, Darren Cook dar...@dcook.org wrote:
Do you have some code demonstrating the above idea? It sounds
interesting, but I cannot grasp what the data and algorithm look like.
4*19*19*4 is around 5.5 kB
On 9x9 it will be less than 1.5 kB
Are you still interested?
My
2009/4/8 Zhiheng Zheng zhiheng.zh...@gmail.com:
I think most of test are designed by people who is stronger than best
computer go program. So if MC program fail to pass a test, it is most likely
MC is wrong. MC program is strong in some aspect, but week in other aspect.
And the test suit is
I'm just digging through tons of posts I didn't have time to read.
This one is particularly interesting for me.
Thanks for sharing this idea.
I don't have slow tactical reader, but it helps me to understand why
heavy playouts work while
direct optimization of strength of the playout doesn't help.
End game is another issue. MC programs only aim on winning, so they
endgame is nor perfect in sense human would define it, but perfect
enough to win if the game is winnable.
You can modify komi to get the human expert and MC program in agreement.
This suggests how you could automate a set of
lot more memory. If your idea actually works and is just as quick then
of course I'm interested.
...
For a reference you can take a look for a libego implementation:
Ah, so you already use this idea in libego? That is all I need to know,
because, unless something has changed, libego does
...
For a reference you can take a look for a libego implementation:
Ah, so you already use this idea in libego?
libego uses this idea only for list of stones in chain.
list of liberties are not implemented.
but I guess I will implement it sometime soon.
That is all I need to know,
Hi Lukasz,
I think I understand the way it is done for storing the stones; I do it
exactly the same way.
For the liberties: Does the index of the direction (NWSE) state where the
chain is in respect to the liberty? So if you place a single stone on the
board at position, you add 4 liberties and
On Wed, Apr 8, 2009 at 10:46, Darren Cook dar...@dcook.org wrote:
End game is another issue. MC programs only aim on winning, so they
endgame is nor perfect in sense human would define it, but perfect
enough to win if the game is winnable.
You can modify komi to get the human expert and MC
On Apr 8, 2009, at 3:15 AM, Łukasz Lew lukasz@gmail.com wrote:
On Tue, Apr 7, 2009 at 23:52, Claus Reinke claus.rei...@talk21.com
wrote:
Last time I looked more closely at what my MC bot (simple, no tree)
was doing, I noticed that it has a tendency to try the impossible
moves
On Wed, Apr 8, 2009 at 13:10, Isaac Deutsch i...@gmx.ch wrote:
Hi Lukasz,
I think I understand the way it is done for storing the stones; I do it
exactly the same way.
For the liberties: Does the index of the direction (NWSE) state where the
chain is in respect to the liberty? So if you
On Wed, Apr 8, 2009 at 14:41, Jason House jason.james.ho...@gmail.com wrote:
On Apr 8, 2009, at 3:15 AM, Łukasz Lew lukasz@gmail.com wrote:
On Tue, Apr 7, 2009 at 23:52, Claus Reinke claus.rei...@talk21.com
wrote:
Last time I looked more closely at what my MC bot (simple, no tree)
was
Łukasz Lew wrote:
...
For a reference you can take a look for a libego implementation:
Ah, so you already use this idea in libego?
libego uses this idea only for list of stones in chain.
list of liberties are not implemented.
but I guess I will implement it sometime soon.
You can find
Yep.
I'm thinking about implementing it in libego with heavy playouts for
demonstration.
Maybe It will get libego some attention. :)
Thanks for your answers. I'm impressed with the speed of your library.
I use zobrist hashing as well. But the random base is separated from
board and
On Wed, Apr 8, 2009 at 2:07 PM, Isaac Deutsch i...@gmx.ch wrote:
What I don't understand is: How do you know from just a single xor hash
if you have played a certain position/color before? Don't you somehow have
to store for each possible hash (which is 2 bytes in my example) if it has
been
Like any hash function, multiple board positions can hash to the same
value. The idea is that the probability of encountering two board
positions in the same game that have the same hash value is so low,
that if you get a duplicate hash value you are practically guaranteed
that it's a
On Wed, Apr 8, 2009 at 10:46 AM, Darren Cook dar...@dcook.org wrote:
End game is another issue. MC programs only aim on winning, so they
endgame is nor perfect in sense human would define it, but perfect
enough to win if the game is winnable.
You can modify komi to get the human expert and MC
Ah, that's what you mean. :)
Actually I don't care too much about superko. I just care about the
move the genmove returns.
It would be better If I check at least some part of MCTS tree.
I just replay the game to check whether there is a hash collision. (I
use 64 bits)
If I would wan't fast
2009/4/8 Gunnar Farnebäck gun...@lysator.liu.se:
Łukasz Lew wrote:
...
For a reference you can take a look for a libego implementation:
Ah, so you already use this idea in libego?
libego uses this idea only for list of stones in chain.
list of liberties are not implemented.
but I guess I
Łukasz Lew wrote:
2009/4/8 Gunnar Farnebäck gun...@lysator.liu.se:
Łukasz Lew wrote:
...
For a reference you can take a look for a libego implementation:
Ah, so you already use this idea in libego?
libego uses this idea only for list of stones in chain.
list of liberties are not
Lukasz,
My performance test suite did 7 ways of tracking liberties:
* dense linked lists, (where 4 * number of positions are allocated)
* sparse linked lists, (where 256 * number of positions are allocated)
* arrays of liberties, (256 * number of positions are allocated)
* trivial
26 matches
Mail list logo
