The rule of thumb I try to follow is to connect when possible; try to
disconnect enemy groups - but don't bother with cuts if the separated groups
are alive; don't let yourself be cut off if you can't make two eyes.
These rules seem to make good sense; they're not just "human style" for the
sake of style, but are rooted in the fundamentals of the game. I don't know how
to capture the subtlety of the "connect or cut when it makes a difference to
the outcome" in the playouts, but this should make a difference, since it tends
to favor more efficient play. It's all about making the most for your one play,
before your opponent gets his turn.
I was playing against a 7 or 8 dan (AGA rating ) player last night, and he
reminded me of a terrible truth: we take turns placing stones. So frustrating
that I don't get a "two stone tesuji" to solve my problems. ;)
Terry McIntyre <[EMAIL PROTECTED]>
They mean to govern well; but they mean to govern. They promise to be kind
masters; but they mean to be masters. -- Daniel Webster
----- Original Message ----
From: Jason House <[EMAIL PROTECTED]>
To: computer-go <[email protected]>
Sent: Thursday, December 13, 2007 3:30:27 PM
Subject: Re: [computer-go] MC-UCT and tactical information
On Dec 13, 2007 5:33 PM, <[EMAIL PROTECTED]> wrote:
> -----Original Message-----
> From: Jason House <[EMAIL PROTECTED]>
> To: computer-go <[email protected]>
> Sent: Thu, 13 Dec 2007 3:20 pm
> Subject: Re: [computer-go] MC-UCT and tactical information
> On Dec 13, 2007 2:17 PM, <[EMAIL PROTECTED]> wrote:
I'd like to start a more specific discussion about ways to combine tactical
information with MC-UCT. Here's the scenario.
It's the bot's turn and, prior to starting any playouts, it runs a tactical
analyzer (for want of a better name) that labels each string as unconditionally
alive, unconditionally dead, conditionally alive, uncertain, or too strong to
bother testing. For each conditionally alive string, it finds the move(s) to
kill/rescue it. Each possible move, has a critical score indicating the net
number of stones whose life/death status would be changed for the better if the
bot moved there. Moves with a non-zero critical score are "critical moves."
> As worded, I don't know if I agree with that formalization of what
> information will be useful.
> It's in the right ballpark for the discussion, but will likely shift a bit
> with any final design.
Right. It's not meant to be comprehensive. By... um coincidence, that's
the information my bot has access to. I'm soliciting ideas on what other
information should be included as well as how to use it. It's also a hint at
the minimum level of detail I'm hoping for.
...
"Change for the better" seems to imply only a one-sided analysis. I would
imagine any analysis would have to include both sides. There's also important
concepts that can some into play like the number of moves that can be ignored
(or must be ignored) before something happens. This can be critical info for
ko fights and semeai.
I've done some dabbling (thought experiments) with how I'd like to cache
search results and I'm not yet happy with any of them. Not taking into account
miai and such logic could lead to excessive storage bloat. I'd love to enter a
discussion talking just about how to store cached L&D search results.
When I go down this road, I'd probably initially focus on maintaining
connections in playouts and then extend it to maintaining life. There's some
tricky parts about when severing a connection or giving up a group is ok. Deep
in a random game, it may be ok to conservatively protect stuff, giving a sort
of quiescence search.
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping_______________________________________________
computer-go mailing list
[email protected]
http://www.computer-go.org/mailman/listinfo/computer-go/
