On Sep 24, 2009, at 8:45 PM, terry mcintyre wrote:
Indeed it is. How may a program reason about the order of moves? At
higher levels of play, the order of moves is often crucial.
I plan to try the following:
Store win and run counts for each move in the context of the two
previous moves. This would accumulate results for "forced" move
sequences, such as edge-of-board hanes. In terms of the GRAVE model I
discussed earlier, this says two boards are similar if they have the
same last two moves (regardless of what happened elsewhere on the
board).
Two moves, rather than one, are necessary to chain together sequences
of moves. Otherwise, consider this:
.#O.
.#Od
.cab
If # moves at a, then b is the correct response, followed by c, then
d. However, if # plays directly at c, O should not respond at d.
Obligatory acronym: SAVE (Sequence RAVE).
My guess is that this will not work as well as RAVE. It just might
work to combine this information (which in a sense remembers local
searches) with the RAVE information (which finds "globally" good
moves). Combining pure AMAF might help, too, as it would solve the
"missing sibling information" problem I mentioned earlier.
Peter Drake
http://www.lclark.edu/~drake/
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
