2007/5/27, Peter Drake <[EMAIL PROTECTED]>:
3197 occurrences of
...
w?.
BB.
(7 transformations. Another full triangle.)
This is called "Turn".
http://senseis.xmp.net/?Turn
This is a standard Go term, originating from qu3(Chinese),
magari(Japanese), guburim(Korean).
--
Seo Sanghyeon
_
As I get into the home stretch of rewriting the core of my bot, I want
to add a monte carlo player. I've realized that picking a random move
to play is non-trivial since it's such a key element in playout speed.
An array of legal positions has easy lookup, but may not be easy to
maintain...
I've spent a lot of time struggling with this; it can have a huge
impact on performance. The key thing to remember is to keep the
common case fast.
Orego currently maintains a list (technically a stretchable array,
analogous to the java.util.ArrayList class) of vacant points. I
shuffle th
Hi,
I've tested many approaches, and the one I implemented is clearly the best.
The bias that Peter Drake talks about is negligible and doesn't have a
noticeable impact
on playout results.
(and uniformity of playout isn't something to fight for in MC Go)
Jason, can You tell me why You don't want
i'd need to write a C interface for it, then try to maintain compatibility
through new releases. (AKA i'd effectively end up rewriting it). it might
seem like less of a burden for me to just write my code in C++, but
i guess i'm just a caveman who is stuck in his old ways and would rather
reinven
Yeah, I suffer from this, too. (There's also the fact that using
someone else's code would disqualify you from the formal division of
the KGS tournaments.)
Here's a heroic tale of not-invented-here syndrome for your amusement:
http://worsethanfailure.com/Articles/slammerSCR.aspx
Peter Drake
Here is what I do, don't know if it's best
Basically you want a list of empty points, since most of them are legal.
When I apply a move to the board I then do any needed legality
testing.
At the beginning I start with a list of ALL points on the board. When
a non-empty point is encounter
I'm a language caveman too then. I really avoid C++ even though I
learned the basics long ago. I really hate it. It's not like I'm
an old dog that can't learn new tricks - I have experimented and
explored many computer languages and I am versatile in many.
It's one of those languages th
On Sun, 2007-05-27 at 13:21 -0400, Jason House wrote:
> As I get into the home stretch of rewriting the core of my bot, I want
> to add a monte carlo player. I've realized that picking a random move
> to play is non-trivial since it's such a key element in playout speed.
>
> An array of
?ukasz Lew wrote:
Jason, can You tell me why You don't want to use libego instead?
Actually this is open question to all comp-go readers.
Is libego too complicated? Do You have problems with compilation?
Or You are not comfortable with the GNU license? Any other reason?
I probably have a lot o
Don Dailey wrote:
Lukasz Lew does something far more sophisticated and very fast using the
concept of pseudo liberties which you might want to look into.
Both pseudo liberties as well as disjoint set chain tracking. Curiously
enough, they're both things I independently came up with when I
I struggled with unto a lot, too. In the current version of Orego,
there is no undo, just a way to copy a board relatively quickly. This
falls under "keep the common case fast" again: you only "undo" once
per playout, so it's faster to make a copy.
(For the "real" board, where actual games
> Jason, can You tell me why You don't want to use libego instead?
> Actually this is open question to all comp-go readers.
>
> Is libego too complicated? Do You have problems with compilation?
> Or You are not comfortable with the GNU license? Any other reason?
I've been studying and experimenti
Darren Cook wrote:
Jason House also mentioned "hard coding to a set board size", I think
libego can be used at least up to 19x19, just by changing the
"board_size" setting in board.cpp (it also supports hexagonal boards).
Or did you mean being able to make one binary for all board sizes? I
feel t
On Sun, 2007-05-27 at 19:31 -0400, [EMAIL PROTECTED] wrote:
> If I had it to do over again, knowing what I know now, I would not spend a
>
> lot of time optimizing random games. These optimizations don't make much
>
> difference for heavy playouts and heavy playouts are better.
>
> - Dave Hil
I remember that conversation and the negative response. But to be fair
to the ones who were negative, you presented this as an evaluation
feature that could be calculated quickly, not as a pure performance
optimization. The negative response was in response to the suggestion
that it might be us
Don Dailey wrote:
I remember that conversation and the negative response. But to be fair
to the ones who were negative, you presented this as an evaluation
feature that could be calculated quickly, not as a pure performance
optimization. The negative response was in response to the suggestion
17 matches
Mail list logo
