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.
Quoting steve uurtamo :
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 though
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
requirin
> 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 d
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 c
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 sp
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
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 boost.
Consider the following basic pattern for a 19x19 b
Quoting Petr Baudis :
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 followi
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
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 o
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 intersection.
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 per-in
I have written a quick CUDA implementation of the per-intersection
GPGPU apprach; Christian's e-mail finally made me polish it up to
a somewhat presentable form.
In this implementation, each GPU thread maintains a single
intersection.
The implementation uses 9x9 board (10x11 internally); ex
14 matches
Mail list logo
