Mark Boon wrote:
I'm fairly new on the subject of Monte Carlo and am in the process of
catching up on reading, so I hope you guys have some patience with me
while I get into this and ask a lot of questions. I got side-tracked
away from computer-Go programming for quite a while for various
On 18-jan-08, at 12:47, Don Dailey wrote:
I recently read an interesting blog on this, where it was claimed
that
early optimization SHOULD be done when performance is actually a
consideration (and sometimes it isn't.) The idea is that if ignore
performance consideration early, you
So I wouldn't be surprised at all if at some point you'll see a
marriage of the best ideas of traditional Go programs and Monte-
Carlo / UCT. In fact, this is most likely already happening as these
Monte-Carlo programs use algorithms / ideas from the traditional
programs for tactics,
I'm fairly new on the subject of Monte Carlo and am in the process of
catching up on reading, so I hope you guys have some patience with me
while I get into this and ask a lot of questions. I got side-tracked
away from computer-Go programming for quite a while for various
reasons but have
On 18-jan-08, at 12:01, Gian-Carlo Pascutto wrote:
But the speed of the random playout becoms less and less important
with heavy playouts.
This I don't understand at all. The improvement curve for being
faster isn't different with heavy than with light playouts.
I see I didn't word this
So I wouldn't be surprised at all if at some point you'll see a
marriage of the best ideas of traditional Go programs and Monte-Carlo /
UCT. In fact, this is most likely already happening as these
Monte-Carlo programs use algorithms / ideas from the traditional
programs for tactics,
Mark Boon wrote:
On 18-jan-08, at 12:01, Gian-Carlo Pascutto wrote:
But the speed of the random playout becoms less and less
important with heavy playouts.
This I don't understand at all. The improvement curve for being
faster isn't different with heavy than with light playouts.
I see I