RE: [computer-go] Pattern Matcher

[Vincent Diepeveen <diep@xxxxxxxxx>]

You wonder how big the speedup will be.

My first question is: "how many patterns, 8 million auto generated patterns?"
My second question is: "to what do you want to compare it too, hand written
C code?"
The third question is: "what does a pattern actually do?"
Like does every pattern that occurs in a given board position X give a
'bonus' for a move 'x' to be tried first and the move x with the highes
score is the move we go try first?

Or does each pattern have its own values?

Of course it has been proven already that when pattern amount keeps
growing, that auto tuners do not know how to assign score to patterns when
compared to the superiority of certain programmers there (not necessarily
good players).

Those elements are very important.

At 16:34 8-11-2004 -0200, Mark Boon wrote:
>
>
>> -----Original Message-----
>> From: computer-go-bounces@xxxxxxxxxxxxxxxxx
>> [mailto:computer-go-bounces@xxxxxxxxxxxxxxxxx]On Behalf Of Vincent
>> Diepeveen
>> Sent: Monday, November 08, 2004 15:06
>> To: computer-go; computer-go
>> Subject: Re: [computer-go] Pattern Matcher
>>
>>
>> In theory it is possible to let your automatic recognized patterns auto
>> generate to C code. With evolutionary tree software you can build
>> from that
>> a tree then which can hard code itself into C and just compile like an add
>> on C file. It can get evaluated then in a logarithmic way.
>>
>
>My pattern-matcher does exactly that (be it in a not very sophisticated way
>I think), create an optimized decision-tree. GNU Go generates C codes from
>it's patterns. I questioned if generated C-code could get the same kind of
>optimization as my decision-tree, but didn't get a very good answer on it. I
>suppose in theory you could generate C-code (or Java code in my case) to
>hard-code the decision-tree. My question is though: would that really
>provide such a big speedup? Now the actual matching code that reads the tree
>is tiny, so it will fit in the primary cache. The decision-tree will easily
>fit in the L2 cache (I think, I'm not sure even). The generated C-code would
>at best be similar in size as the decision-tree I think.
>
>I would be really interested if it would give a significant speedup. In Java
>it's probably even more practical than in C, as it has the built-in
>capability of doing run-time compilation of the code and load the compiled
>class run-time to replace the existing one.
>
>But it's rather a lot of work to try to make,so I would like to know before
>attempting something like this. Do you have any experience in this?
>
>_______________________________________________
>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/