On Thu, Sep 10, 2009 at 09:18:40AM -0400, Jason House wrote:
Somewhat... One could generate a random number (r) and combine it
with the move mask (m) as follows:
black moves = m r
white moves = m ~r
This has the drawback that the number of black and white moves may
not be equal. It can
Petr,
wow, I didn't expect to see so much experimentation being performed!
It's great that you have taken the time to implement this approach,
because this now shows people both alternatives for implementing a
playout algorithm on the GPU.
I strongly suspect the low performance in the
This is very interesting. Here is a crazy idea, maybe it the same as
Marks but I want to take it to its extreme.
Since AMAF values are so helpful, perhaps one can let go of the idea
of sequential play following the rules of go, and basically play moves
in parallel on all empty
Hi!
On Thu, Sep 10, 2009 at 12:26:06PM +0100, Christian Nentwich wrote:
I strongly suspect the low performance in the per-intersection case
is down to two reasons - please let me know what you think:
- A big proportion of moves place one stone on an empty
intersection. In this case 80 of
On Thu, Sep 10, 2009 at 01:54:49PM +0200, Magnus Persson wrote:
This is very interesting. Here is a crazy idea, maybe it the same as
Marks but I want to take it to its extreme.
Since AMAF values are so helpful, perhaps one can let go of the idea
of sequential play following the rules of go,
Quoting Petr Baudis pa...@ucw.cz:
On Thu, Sep 10, 2009 at 01:54:49PM +0200, Magnus Persson wrote:
This is very interesting. Here is a crazy idea, maybe it the same as
Marks but I want to take it to its extreme.
Since AMAF values are so helpful, perhaps one can let go of the idea
of sequential
Sorry for my empty reply to Petr, I misclicked
When a block is identified you could also sum up what the original
strength of the original stones covered by the block and use that as a
heuristic for what should be captured first.
Also to avoid filling all liberties. One can avoid that with
On Thu, Sep 10, 2009 at 08:29:31AM -0400, Jason House wrote:
I've thought of something similar in the past, but with a twist:
pre-compute a subset of moves that could be safely played in
parallel. Even if you can only play 285 moves in parallel on an
empty 19x19, it could still be a huge speed
maybe some divide conquer algorithm?
Am 10.09.2009 um 14:43 schrieb Petr Baudis:
On Thu, Sep 10, 2009 at 08:29:31AM -0400, Jason House wrote:
I've thought of something similar in the past, but with a twist:
pre-compute a subset of moves that could be safely played in
parallel. Even if you
Since AMAF values are so helpful, perhaps one can let go of the idea of
sequential play following the rules of go, and basically play moves in
parallel on all empty intersection. Compute new state (do captures) and
repeat a fixed number of times and evaluate.
two thoughts:
i) how do you
Somewhat... One could generate a random number (r) and combine it with
the move mask (m) as follows:
black moves = m r
white moves = m ~r
This has the drawback that the number of black and white moves may not
be equal. It can be modified to give an equal number of moves such as
requiring
Quoting steve uurtamo uurt...@gmail.com:
Since AMAF values are so helpful, perhaps one can let go of the idea of
sequential play following the rules of go, and basically play moves in
parallel on all empty intersection. Compute new state (do captures) and
repeat a fixed number of times and
12 matches
Mail list logo
