On Mon, 2007-07-09 at 21:12 -0700, David Doshay wrote: > I also think that it is not a bad thing to have our knowledge set > "start conflicting" with itself. That is the nature of life and the > nature of Go. It is well known in learning theory that a child builds > models of the world until they have too many inconsistencies, > and then spends some time pretty confused and less adept than > when just a little younger, but then reformulates something in > their heads and then abruptly become more adept. I do not see > that our programs should be different.
But there is a mechanism for doing so in the human brain. I am not opposed in any way to self learning or even human assisted learning that is self-correcting in this way. But that's not how it works in our programs. The real issue to me is that knowledge engineering, the way it's done in computer go program is just an ugly hack. What really irks me is that in most peoples minds, that is considered the "elegant" approach - hard coding tons of fixed "knowledge" into the program. Nothing could be farther from the truth, this is a dirty shortcut, a hack. There is nothing elegant whatsoever about having a huge database of patterns that tell the program what and what not to do - then calling it "smart." The reason UCT/MC is elegant is that it has a built in mechanism to discover truth for itself. It may not be the best way and perhaps there is something better but at least it is a try. In a lot of ways it mimics the human thinking process. The MC play-outs is a crude substitute for human experience (the experience is gained on the fly) and UCT tree is a substitute for reasoning about characteristics of the position, what does and doesn't work. If someone were to create a strong program that was free of all domain specific knowledge, it would be an incredibly elegant piece of art. If someone were to create an equally strong program full of pattern based rules and regulations it would be a vulgar beast - a brute force monster. If you can imagine a program with a self-learning mechanism, one that could take knowledge provided by you and I and make some sense of it - actually understand it and modify it when appropriate, then you would have something beautiful - but that's not the way things currently work with the heavily knowledge engineered programs. It's the difference between giving a man a fish or teaching him to fish to use a well known analogy. A pattern based program is like supplying a man with lots of fish, a UCT program is like teaching a man to fish for himself. I would like to say I'm not opposed to having knowledge explicitly coded into the software - I'm speaking mostly philosophically. The analogy is learning from a teacher and if your teacher is smarter than you it is foolish to reject his advice. If you are dying of hunger you should take the fish. Sometimes we acknowledge the role of advisers and take their advice even if we don't understand it. However, if possible, it's better if you understand for yourself. Have you ever driven up to a stop-light that was stuck on red? How long will you wait there? At some point you will break the rules because you know something is wrong with the rules in this case. This is not the way in knowledge engineered programs - they would wait forever at the light. - Don _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
