Re: computer-go: Data Mining and Rulebase for GO

[David Fotland <fotland@xxxxxxxxxxxxxxx>]

Please compare the number of positions in the number of good game
records you can get (perhaps 100,000), to 3^360 and describe
what fraction of the game space can be learned by your system....

Please guys, do a little arithmetic before you propose these
schemes.

David Fotland

At 06:29 PM 11/9/00 -0800, you wrote:
>Hi, there,
>
>I would like to ask if some one already did the following and what are the
>results:
>1. Represent each point on GO board as 0 (blank), 1 (white), or 2 (black),
>thus the board can be expressed as a large number (>=0, and <= 3^360).
>2. Rotate, mirror, and flip the board to get other 8 or 16 large numbers
>from  symmetric configurations.
>3. Pick the board configuration that has the smallest number as
>representative. This will eliminate duplicated board configuration due to
>symmetric. Also, this will make
>4. Category game end results as -1 (loss), 0 (tie), or 1 (win) for each
>playable position. Treat each playable position as a sub-system, so there
>are 361 sub-systems.
>5. Rule- or ANN-learning for each sub-system from existing game records.
>6. Apply learnt results by first mapping the board configuration to have the
>smallest large number, then use the mapped board configuration to check the
>361 sub-system to find where should be the position to play.
>
>If ANN is used to learn and the results are good enough, then, we would have
>had a static mathematical evaluate function. If Rule is used, then we would
>have had a better understanding of playing GO.
>
>The above approach should not require a large programming resources.
>
>Weimin Xiao
>
>----- Original Message -----
>From: "Rong Zeng" <rodneyzeng@xxxxxxxxxxxxxxxxx>
>To: <computer-go@xxxxxxxxxxxxxxxxx>
>Sent: Wednesday, November 08, 2000 5:53 PM
>Subject: Re: Re: computer-go: minimax and go
>
>
>Hi, everyone:
>
>Here I'd like to talk some of my idea about the mathematical modeling of Go
>game.
>
>I have read some articles in Chinese about this problem and have some
>experience with the popular game programs. Most of them adopted the
>force-field theory when considering the influence of stones. But this theory
>has some basic shortcomings when two sides fight closely together and made
>programs confused. This is not a perfect theory about Go modeling.
>
>I think Go game is some geometry. Two sides play discretly but would build
>up continuous boundaries; stones groups would be disconnected or connected
>to each other in various ways; the shapes of any stones group would effcet
>its surviving and its easiness to build up eyes. One must consider force
>field and geometry together to make a good model.
>
>There are bulk of questions in the dynamic precess of playing go. But
>there's still basic problem of static modeling when we make a program. This
>is relatively simple and we can make it precisely and close to exact way of
>human's thinking when we play. The goal of static modeling is to hash the
>trees greatly and make selective points as few as possible, like human do.
>
>I think the OOP technique can be used here and build up an engine on which
>the dynamic processes can be built. It's a geometry with force-field. And
>this static model engine would not take much time as most of the CPU time is
>spent on searching. According to my understanding of those excellent game
>engines nowdays such as STARCRAFT of Blizzard and some of EA SPORTS,  I
>think a such kind of engine is not a big problem to them.
>
>I don't agree that advanced AI techniques are the most important factors in
>Go game programming. As we all know AI techniques applied very well to
>Chess. So it's the Go game itself that becomes the bottleneck. If we cannot
>make a good model for it, little progress will we make.
>
>Welcome any opinions to my idea above.
>
>Regards,
> Rong Zeng
> rodneyzeng@xxxxxxxxxxxxxxxxx
>
>
>