Re: [computer-go] Pattern matching - example play

["Frank de Groot" <frank@xxxxxxxxxxxxx>]

----- Original Message ----- 
From: "Heikki Levanto" <heikki@xxxxxxxxxxxxxxxxx>
Subject: Re: [computer-go] Pattern matching - example play


> Searching all those positions is not a hard problem. Evaluating the
> resulting positions is hard.


Is it really that hard or is the main problem that it takes too much time?

A main difference between Chess and Go is that in chess, you work with a
single piece and its relation to other pieces or squares but in Go, you work
with groups that grow and merge and have a whole lot more administration to
take care of.

I think we should focus a lot on efficient representation/move generation.
Efficient representation in the sense that finding an eye shape or other
properties of a group is extremely fast, because pruning the tree is perhaps
more important than the fastest move generation.

I would like to see publications that thoroughly deal with such mundane
tasks rather than yet another attempt to work with "symbolized knowledge" or
yet another Neural Network. But there isn't much glory in that for
researchers, and I would think that commercial developers keep these things
secret.

Bitboards, for ex. A major slowdown is counting the # of liberties after
chains have grown/merged/captured.
Pentiums still don't have a population count instruction, needed after a
"shake". So I am working on a method to delta-update this stuff.
I think such work is worth 100 hours of time or more. Such relatively simple
inventions are worth thousands of USD.
They can mean enormous speedups, which can mean the difference of Go program
#5 or #1 (strength-wise).


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