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

[Vincent Diepeveen <diep@xxxxxxxxx>]

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.

>From own experience i know how hard it is to have no knowledge. For example
10x10 international checkers is a very hard game to play well in with a
program (yes that was amazing for me too). I play very poor draughts.

My advisor is Marcel Monteba, a draughtsplayer who plays in the highest
league and has in his own team for example 1 ex world champion. 

He is capable of really explaining the knowledge well.

That's however not sufficient. The real problem is that perhaps this
pattern is ok, but the program will avoid such a pattern by making 1 move
different and then the pattern doesn't apply and problems happen.

So from own experience i know that when you don't have the knowledge, that
there is only extra problems to program it.

Of course it's nice to list things like creativity and similar vague
formulated things.

There are of course limitations to the strength you need in order to
program knowledge.

>From knowledge viewpoint, Kasparov doesn't know 100x more than i do.

He just plays better. 

If i get time and can make moves on the board, i sure can understand every
move he plays in a game and why it was so good.

So there is no knowledge 'gap'.

However the typical chessprogrammer at the moment has no clue about the
difference between a bishop and a knight.

That really is showing. A program like junior just plays into systems where
no positional knowledge is needed. It just attacks like crazy and tries to
win in that way, thanks to a very good openings book made by GM. It does
have a few things in evaluation which cause it to win game after game. So
they definitely have done some effort there. Because they are so book
dependant they just play 1 computer tournament a year at most.

Shredder is another clear case of a programmer who has learned past few
years a lot of new chessknowledge. No clue where he learned it from. I have
my suspicions there however. Fact is he learned a lot new chessknowledge
and has put it in his eval. When it loses it loses typically because of
knowledge it doesn't have as the programmer has no clue about that type of
knowledge.

Third of world is my own program, which is pathetically outsearched by
other chessprograms usually.

Yet just a few bugfixes have managed to get it from outside world top into
world top 3 already.

The proof in computerchess is just too obvious that better chessknowledge
wins the game in the end. 

This where in contradiction to go, tactics really dominate chess a lot more.

So that in the end good go knowledge is most important is trivial.

Yet it's without doubt the case that in order to implement it bugfree you
need to be hell of a programmer in the first case.

A few years ago at several tournaments the first time programs showed up
they always forfeited. Instead of playing 40 moves in 2 hours, they thought
they had to play 39 moves in 2 hours :)

Such type of bugs.

I understand that Mark Boon will not be able to imagine such major bugs in
software, yet that type of bugs is what the average software has...

At 17:16 29-11-2004 +0100, Frank de Groot wrote:
From: "Mark Boon" <tesujisoftware@xxxxxxxxxxxxxxxxx>
>Subject: RE: [computer-go] Pattern matching - example play
>
>
>
>> To make a good Go program I'd rank the following in order of importance:
>>
>> 1) Lots of spare time
>> 2) Lots of motivation and determination (in other words, be a nerd!)
>> 3) An inventive mind.
>> 4) A high rank in the game.
>> 5) Strong programming skills.
>
>I would rank it, in order of importance:
>
>1) An inventive mind
>2) Strong programming skills
>3) Lots of motivation and determination (in other words, be a nerd!)
>4) Lots of spare time
>5) A high rank in the game.
>
>
>I have a contrary opinion on attaining strong programming skills, I think it
>needs a greater talent than the talent needed to become a Shodan Go player,
>and I also think it takes much more investment in time to become a really
>good programmer (20 years is a good estimate). There are kids that are
>Shodan but there are no kids that are highly professional software engineers
>that have sustained rates of a patentable invention per year. With all due
>respect, you can't compare a game with the most complex engineering
>profession on earth.
>
>My (1) is by far the most important point for Go programming, as current Go
>programs stink, therefore a lot of (1) is required.
>I am pretty sure that a main reason Go programs stink is lack of (2) as
>well.
>
>(5) I consider to be almost of no significance whatsoever, based on my
>earlier expalnation on how I see people try to put their own knowledge into
>Go programs instead of adopting a scientific, systematic approach and put
>the knowledge of tens of thousands of pro games in to their games.  A pro
>can't voice his thoughts on Go programming, but his games speak for him.
>
>_______________________________________________
>computer-go mailing list
>computer-go@xxxxxxxxxxxxxxxxx
>http://www.computer-go.org/mailman/listinfo/computer-go/
>
>
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/