[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



At 21:41 29-11-2004 +0100, Frank de Groot wrote:
From: "Don Dailey" <drd@xxxxxxxxxxxxxxxxx>
>Subject: Re: [computer-go] Pattern matching - example play
>
>
>> However Frank,  it seems to  me that it  should be better  to directly
>> apply  actual  knowledge as  opposed  to  trying  to obtain  knowledge
>> indirectly.
>
>I have always said that this is exactly what I propose.
>I said, harvesting knowledge from games, and harvesting knowledge from Go
>teaching books.
>
>For ex. There are wonderfully detailed descriptions of algorithms on how to
>statically detect whether something is alive or dead in case of a
>Semeai-kind of thing when B moves vs. when W moves (the details escaped me
>but I remembered that it was very cool and that I wanted to implement it
>straight from the book).



>There are books written that teach how to count liberties and there are
>"inner eyes" and "outer eyes" (or whatever, my point is that detailed
>algorithms have been explained in Go teaching books).
>
>So, why do I need to be a strong Go player?

In chess literature there were only 3 types of bishops.
a) a good bishop
b) a bad bishop
c) a financhetto bishop

Recently in some new literature a new bishop has been notified
a so called
d) position bishop

The inventor of that definition has been me.

Yet in my chessprogram i have at least 50 types of bishops. 4 bishops won't
do simply. 

Now in go with respect to eyes, you can have way more type of eyes than you
can have types of bishops. And the literature just uses the word 'eye' i bet.

Yet your evaluation function needs to understand what type of eye it is and
just the word 'eye' won't do in your evaluation function. You need clear
distinctions between what type of eye it is. 

The more accurately knowledge you use there to identify the type of eye,
the better the program will evaluate.

>I *know* that I need to do reading. The problem is managing the tree. And
>that is done with Go knowledge.
>But that can be learned form Go software publications, Go teaching
>publications, statical analysis, genetic evaluation of self-play, whatever.
>
>Why do I need to be a strong player myself?
>I really don't see it.
>If I would, I would start to learn to play Go.
>I like the game but I simply see no use for it, to learn to play the game.
>Even more perverse, I don't see any use for a pro player, none whatsoever.
>
>Like Vincent said they talk in a way thaat is utterly useless to make a Go
>program.
>"It would be nice if you could somehow <insert vaguest meta-philosophical
>ungraspable concept here>".
>
>
>> this, there are  many more.  Most of the  knowledge expressed in games
>> is buried  far beneath  the surface, extracting  the real  reasons for
>> moves is  extremely non-trivial  and is really  what you would  want a
>> program to understand.
>
>
>I still don't see it.
>There are only limited concepts.
>
>Influence, Territory, connectivity, Ajji, Moyo, Running room, eye space,
>Sente, Ko's, etc. etc.
>It's not that there are an infinite number of concepts.
>All these concepts are explained in books and can be programmed to be
>extracted from game records.
>
>
>_______________________________________________
>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/