Isaac Deutsch wrote:
> I'm about to implement this. Since I have multiple features
> (patterns, is in atari, is adjacent to last play, etc.), the weight
> is the product of the weight of all matching features.
>
> I'm thinking about having a table of weights, storing the sum of
> each row and the total (like Rémi suggested). I want to do this
> incrementally, so if I find a new feature match in a position, I can
> multiply its weight by the feature's weight. If I remove a feature,
> I can divide.
>
> My question/problem: How do I deal with features that have a weight
> of zero? I'm sure there are certain 3x3 patterns that have the
> weight zero, such as
>
> ###
> #*.
> #..
>
> with * to be played. It's clear that when this pattern matches, the
> total weight is set to zero. How do I find the resulting weight when
> removing this pattern, though? Since I can't divide by zero, I would
> have to reconstruct the weight by checking all features, which would
> be relatively slow. Is there a way this can be avoided, such as
> setting all weights to a very low value instead of zero?

Cache what features you have, then recomputing the weight will be fast.

GNU Go incrementally keeps track of the following features:

Black suicide (true/false)
White suicide (true/false)
Black self-atari (true/false)
White self-atari (true/false)
Number of stones captured by black move (0, 1, 2, 3+)
Number of stones captured by white move (0, 1, 2, 3+)
Color to the southeast (empty, white, black, off board)
Color to the northeast (empty, white, black, off board)
Color to the northwest (empty, white, black, off board)
Color to the southwest (empty, white, black, off board)
Color to the east (empty, white, black, off board)
Color to the north (empty, white, black, off board)
Color to the west (empty, white, black, off board)
Color to the south (empty, white, black, off board)

This information is stored in 24 bits of an integer. The 16 bits
related to the local 3x3 pattern are mapped by table lookup to the
1107 rotation/mirroring invariant patterns. The remaining 8 bits are
mapped to the following features:

Opponent suicide (1 bit)
Our self-atari (1 bit)
Opponent self-atari (1 bit)
Our captures (2 bits)
Opponent captures (2 bits)

by simple bit transposition depending on color to play. Additionally
nearness to the previous move is added as a feature giving 1107*256
combinations, which are finally mapped to pattern weight by table
lookup.

/Gunnar
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Reply via email to