Rene,
you're absolutely right, it's completely fishy! But don't worry, you're
work is not in vain :) I noticed this morning, when I read your mail,
that I had included the 9x9 results in my original mail instead of
19x19! Indeed, for 19x19 the results are even worse. Here's a complete
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
Interesting stuff. I don't have the skills nor the time to make such
experiments myself, but here is a simple idea:
When using a bitmap representation of the board, it is quite possible to find
all eye-like points with a constant number of bit-shifting operations. That
should reduce the number
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
I always see this message when booting up CGOS. However, my program
supports time_left and I also state this in list_commands. Time
control would be much better if I got feedback from the server. How
can I use it? Is there a special command I'm missing?
Thanks,
Isaac
I think it needs *time_settings*
On Thu, Sep 10, 2009 at 12:37 PM, Isaac Deutsch i...@gmx.ch wrote:
I always see this message when booting up CGOS. However, my program
supports time_left and I also state this in list_commands. Time control
would be much better if I got feedback from the
thanks, it works!
Am 10.09.2009 um 18:49 schrieb Go Fast:
I think it needs time_settings
On Thu, Sep 10, 2009 at 12:37 PM, Isaac Deutsch i...@gmx.ch wrote:
I always see this message when booting up CGOS. However, my program
supports time_left and I also state this in list_commands. Time
16 matches
Mail list logo
