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

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

From: "Vincent Diepeveen" <diep@xxxxxxxxxxxxxxxxx>
Subject: Re: [computer-go] Pattern matching - example play


> Well for sure programming skill comes first, because if you have a major
> bug in your software wherever, either eval or search, then you lose
> immediately a game because of that.
>
> However, i fail to see how you can program knowledge without having that
> knowledge yourself first.


None of the Go programmers have ever given any arguments as to why you can't
extract Go knowledge from game records, and be better than "manual" Go
knowledge. I have given a working example for "shape" and theoretical
examples for effieicntly terminating search branches for L&D based on
harvested knowlegde, and a good explanation on how "connectivity" knowledge
could be harvested as well.

What are your arguments?
Keep on repeating that "if you don't have Go knowledge you can't program it
either" is not the point.
The point is that it is possible to EXTRACT this knowlege automatically and
BETTER.
At least that is my hunch.

Any reasons why this would not be the case (spare me the religious
convictions).
Of course only mean, by "no Go knowledge", no Go *playing* knowledge.

I *do* think it is important to read a lot about stuff, like statical
evaluation of Semeai etc. etc.
But apart from knowing the Go literature and using that to extract Go
knowledge or build algorithms, why would you need to be a good Go player?
You might say: "To judge where it makes a mistake and to tune certain parts"
but why is that impossible to judge much better and scientifically by
letting it predict pro moves and analize where it goes wrong? If you can
build separate modules and tests them using a scientific method and then
assemble those modules, why would you need to be a Go player for that?

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