Re: Patterns and Behavior

[Mousheng Xu <xu@xxxxxxxxxx>]

At 04:23 PM 3/12/99 -0600, rbrown@xxxxxxxxxxxxxxxxx wrote:
>Mousheng Xu wrote:
>
>>         Hey, that's a good catch. :) "Ko" is the Janpanese way to say
"Jie".
>
>Ah, I thought that might be it.  A vacant point, but one you aren't
permitted to
>play on, at this time.  I must ask another question, does "jie" mean
eternity?
>That is, is it the same han zi (kanji) as "ko"?

	The same. "jie" actually means "rob" or "bad fortune". :) In "jie" mode,
two sides are fighting for the tiny piece of meat over and over, somewhat
like in a robbery. Maybe that's how it got its name.

	Oh, well, it's very independant thinking not to use patterns, I really
appreciate it a lot.

>My earlier comments were meant to be general in nature; I don't think I am
able
>to answer Mousheng's specific questions.  But if Silly Number means what I
think
>it does, you'd better get some more disk drives, if you are going to use
that!

	Suppose the configuration of a 10x10 board is represented by a number, you
need only 100 * (2bit/8bit) = 25 bytes for it. Even for a 100 k pattern
base, you need only 25 * 100 k bytes = 2 M bytes. Even if you put
additional associative information to a pattern, if might be still in the
order of several M bytes, not a big deal.

>
>There is a phase of pattern recognition called "feature extraction" during
which
>useless or redundant information is discarded from an observation,
_before_ that
>observation is encoded into a pattern.  Again, this is a rephrasing of
that very
>difficult question, "what information do I want to store in my patterns?"

	Thanks for the idea. I will try that during pattern matching.

>as data by having the program observe professional games.  (The encoding
of the
>patterns that result from the observations, i.e. the database format, is a
state
>secret.)  Based on that data, the program emulates behaviors it has seen
before.

	OK. That's a good idea, especially because I thought about it before. :)
But I lack certain ways to 1) divide the go problem into multiple factors;
2) a way to achieve the learning. For the first problem, as you said, you
could use Go knowledge to give a heuristic and reasonably good solution.
The second problem is harder. If you could nicely solve the two problems,
your program would be very promising. Any interest in collaboration, say,
in 6-12 month? :)

>The tricky part is getting a machine to be able to tell the difference.
>

	Agree. But do you mean it's hard to define the problems for a machine?

	Your discussion is very enlightening, thanks a lot.

-- Mousheng Xu