[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: computer-go: extracting date to beat 9d from chess and draughtsscene
At 09:31 PM 11/15/99 +0000, you wrote:
>i agree. for one thing, the stones don't move. but you would think that
>this should give you an advantage. i am not an ai expert, but it seems like
It gives the human an advantage; humans get confused easily when things
keep moving around. So go is easier than chess for humans.
maybe not. in chess, if you capture a big piece early, its usually a real
good move and you know it.
in go, if you capture 1 stone early in the game i might be that "30 point
ponuki" or it might just be 2 points.
Maybe current
chess programs and current go programs are equally strong but we just don't
realize it ;-).
no way, the average go player can beat all programs, only masters can beat
chess programs.
>unless the stones get captured, whatever information about them the program
>can figure out just accumulates. seems like you could get fairly smart
>about this?
Yes. But it's difficult.
doesn't seem that difficult (but i know much more go than ai). where did
all those so-called knowledge engineers go to anayway?
At the stone level, nothing changes, except the last stone played (and
captures).
this can be a big difference. the shape might be much more alive or have 3
more liberties which could be real important.
At the chain liberty level, all the chains adjacent to the last stone
played change, but the rest of the board is unaffected.
if two weak groups connect and become strong, this has a great affect on
the rest of the board.
At the tactical reading level, a few groups nearby might change, or they
might not. The tactical status of a group on the other side of the board
might change if the move is a ladder breaker.
At the group strength level, it gets more complex.
yes, i seen to be arguing both ways, i must be confused. ot1h, it seems
more complicated than your examples, otoh, it just doesn;t seem like it
would be that difficult to keep stats on the groups or maybe some kind of
condensed histories of nodes searched. if the last stone was at a critical
fork in some previous search maybe you could find that and incrementally
keep this kind of info? maybe you could keep some of these critical places
(where the evaluator returned very different results?). i wonder if anyone
has tried this?
thanks
Ray (will hack java for food) http://home.pacbell.net/rtayek/
hate spam? http://www.blighty.com/products/spade/