On Wed, Apr 02, 2008 at 02:13:45PM +0100, Jacques Basaldúa wrote:
> Jonas Kahn wrote:
>
> > I guess you have checked that with your rules for getting probability
> > distributions out of gammas, the mean of the probability of your move 1
> > was that that you observed (about 40 %) ?
>
> If I unders
Jonas Kahn wrote:
> I guess you have checked that with your rules for getting probability
> distributions out of gammas, the mean of the probability of your move 1
> was that that you observed (about 40 %) ?
If I understand your post, there may be a misunderstanding by my fault.
Here gamma is no
On Tue, 2008-04-01 at 15:18 -0400, Joshua Shriver wrote:
> Do you have a link to those papers?
There is still one listed on the computer go bibliograpy:
http://www.cs.ualberta.ca/~games/go/compgo_biblio/
The links don't seem to work, so I set up a copy here:
http://nngs.ziar.net/cgml/gotxt/kojim
Do you have a link to those papers?
-Josh
> My go-programming efforts are very much concentrated on patterns.
> (maybe I have been influenced by the Kojima-papers)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mail
Hi Jacques
>
> No. for a reason I don't understand, I get something like:
>
> Distribution fit expected 0.1 found 0.153164
> Distribution fit expected 0.2 found 0.298602
> Distribution fit expected 0.3 found 0.433074
> Distribution fit expected 0.4 found 0.551575
> Distribution fit expected 0.5 fo
On Mon, Mar 31, 2008 at 03:12:39PM -0700, Christoph Birk wrote:
>
> On Mar 31, 2008, at 1:05 PM, Don Dailey wrote:
>>
>>
>> Christoph Birk wrote:
>>>
>>> On Mar 31, 2008, at 10:48 AM, Mark Boon wrote:
I don't know about this. I'm pretty sure MoGo checks if the stone can
make at least two
Hi Lukasz
In Rémi's paper about Bradly Terry models he found a way to give a
comparable gamma score to things that were different, for instance:
capturing a stone v.s. a given 3x3 pattern.
His model is much more general, but has less patterns (not at all
around 200K patterns of my system). Additi
On 31-mrt-08, at 20:28, Don Dailey wrote:
You could be
blind-siding the program.
I think this is the crux of the matter. Not just in MC but in Go
programming in general. If you add 'strong' knowledge you can create
blind-spots. For example, I guess a ko rarely gets played during
playout
Christoph Birk wrote:
>
> On Mar 31, 2008, at 1:05 PM, Don Dailey wrote:
>>
>>
>> Christoph Birk wrote:
>>>
>>> On Mar 31, 2008, at 10:48 AM, Mark Boon wrote:
I don't know about this. I'm pretty sure MoGo checks if the stone can
make at least two liberties (ladder problem) in which case
On Mar 31, 2008, at 1:05 PM, Don Dailey wrote:
Christoph Birk wrote:
On Mar 31, 2008, at 10:48 AM, Mark Boon wrote:
I don't know about this. I'm pretty sure MoGo checks if the stone
can
make at least two liberties (ladder problem) in which case it can
still be horrible but very seldomly w
Christoph Birk wrote:
>
> On Mar 31, 2008, at 10:48 AM, Mark Boon wrote:
>> I don't know about this. I'm pretty sure MoGo checks if the stone can
>> make at least two liberties (ladder problem) in which case it can
>> still be horrible but very seldomly worse than random.
>
> I would expect playi
On Mar 31, 2008, at 10:48 AM, Mark Boon wrote:
I don't know about this. I'm pretty sure MoGo checks if the stone
can make at least two liberties (ladder problem) in which case it
can still be horrible but very seldomly worse than random.
I would expect playing a "not-working" ladder to be w
>
>>
>> Heavier playouts have been shown to be far superior, but just placing
>> stronger moves in the playouts does not seem to be the right
>> formula. My guess is that if you place arbitrary knowledge into the
>> playouts, you create terrible imbalances. Perhaps the secret (I'm
>> enter
On 31-mrt-08, at 12:36, Don Dailey wrote:
Are these fixed patterns or wildcard patterns? I'm interested in
wildcard patterns too and how to automatically generate them.
A wildcard pattern is exactly the same as a decision tree (it can be
represented perfectly by a decision tree.)There
I think Don Dailey makes a good point about creating a
line of search which can quickly prove or refute a
line of play.
I've been using life-and-death problems to improve my
own level of play, and sometimes "vital move" patterns
quickly lead to proper solutions - but sometimes they
fail, and one m
Mark Boon wrote:
> I did an experiment that looks rather similar. I generated patterns
> and only kept the ones that had a minimum amount of 'urgency' and a
> minimum number of occurrences. But I noticed two things when using
> these patterns in a MC playout:
>
> 1) There are many important moves
I did an experiment that looks rather similar. I generated patterns
and only kept the ones that had a minimum amount of 'urgency' and a
minimum number of occurrences. But I noticed two things when using
these patterns in a MC playout:
1) There are many important moves missing. Apparently th
Mark Boon wrote:
>There are 16 4-distance points, so if you spill ino that by one
> point you get 315 or a little over 14 million patterns. Multiplied
> by 3 for every don't-care point within less than 4 distance. Ouch.
True, but the number of patterns is learned automatically. When I
first lea
On 29-mrt-08, at 14:13, terry mcintyre wrote:
Considering how inexpensive memory is, and how
branches cause processor pipelines to stall, it seems
to make sense to convert "don't care" patterns into
however many fixed patterns would be equivalent. If
there are three "don't care elements", which
--- Mark Boon <[EMAIL PROTECTED]> wrote:
>
> On 29-mrt-08, at 10:47, Jacques Basaldúa wrote:
>
> > I don't use don't care. I mask code in 2 bits:
> void, own,
> > opponent, out_of_board. This produces bigger
> database size,
> > because the only way to introduce "don't care" is
> to repeat the
On 29-mrt-08, at 10:47, Jacques Basaldúa wrote:
I don't use don't care. I mask code in 2 bits: void, own,
opponent, out_of_board. This produces bigger database size,
because the only way to introduce "don't care" is to repeat the
pattern.
OK, so we were comparing apples and oranges. I know th
Mark Boon wrote:
> I suppose there's no reason why it has to be assembler,
> you could just as well generate C-code.
I don't think so. But I don't write that much asm as it may appear.
I see what the compiler writes when I debug and write critical
parts only. And automatically generated code.
On 28-mrt-08, at 09:43, Jacques Basaldúa wrote:
The first source code was just an example to see what kind of code
is generated. The second is useful, if you understand asm you
should understand it.
Well, the only serious assembler I ever wrote was on a 6502 :-) And
that was a very long t
terry mcintyre wrote:
It is possible to get some remarkably high correlation
between the moves played by pros and a predictor - yet
still not have a good program. Why?
We have a random variable, the place at which a player
plays, and some variables that we can compute. The
distribution of the
Mark Boon wrote:
Sorry, without a bit more explanation, the assembler code is very
hard to understand. What exactly does it do?
The first source code was just an example to see what kind of code
is generated. The second is useful, if you understand asm you should
understand it. The board has
On undefined, Don Dailey <[EMAIL PROTECTED]> wrote:
>
> In some of my pattern learning experiments, I discovered that only a
> very small subset of possible patterns occur on the real board, and yet
> for a game tree searcher it would be pretty important to understand
> those patterns that ar
--- Don Dailey <[EMAIL PROTECTED]> wrote:
> terry mcintyre wrote:
> > I've been thinking a bit about the collection of
> > patterns from games, whether of professionals or
> of
> > programs.
> >
> > It is possible to get some remarkably high
> correlation
> > between the moves played by pros and
Actually, a better way to put this:
King and Pawn positions are generally understand so well by Grandmasters
that they know what the outcome of the game will be once it appears on
the board.
Therefore, at least 1 player is actively trying to avoid this ending,
because the game is essentially ove
terry mcintyre wrote:
> I've been thinking a bit about the collection of
> patterns from games, whether of professionals or of
> programs.
>
> It is possible to get some remarkably high correlation
> between the moves played by pros and a predictor - yet
> still not have a good program. Why?
>
On Thu, Mar 27, 2008 at 12:14:06PM -0700, terry mcintyre wrote:
> Suppose a group can be defended - four liberties in a
> row, for example. If the opponent plays inside those
> four liberties, you play to divide the area into two
> eyes - unless the situation is such that the group has
> a second e
I've been thinking a bit about the collection of
patterns from games, whether of professionals or of
programs.
It is possible to get some remarkably high correlation
between the moves played by pros and a predictor - yet
still not have a good program. Why?
One possible answer is that many moves a
Jacques,
Yes, I do an incremental update so the board-size should be almost
irrelevant. I'm not sure why I see any difference between 9x9 and
19x19 but it may have to do with the fact that the edge cuts a lot of
pattern seach short.
On 27-mrt-08, at 10:13, Santiago Basaldúa wrote:
Mark
Mark Boon wrote:
> Thanks for the pointer Don, that might be worth looking into at some
> point.
>
> When you say 'amazing accuracy despite this speed and simplicity' I
> still have to ask: "how fast?". I think 10usec is actually pretty
> fast. But when talking about using it during MC playouts f
"Santiago" wrote:
... Oops, wrong name ...
(Santiago is my official name, because I was born in a dictatorship that
did not allow foreign names. After that, I was too lazy to change it.
Jacques, like my French grandfather, is my real name.)
Jacques.
Mark Boon wrote:
What I have now takes 10-15 microseconds on a 2Ghz Intel computer to
find all the patterns on a board (on average for 9x9, for 19x19 it's
more like 15-20 usec)
From your difference between 9x9 and 19x19 I assume that you are updating
the patterns of the cells after a ston
Mark Boon wrote:
Lately I have been putting some effort into pattern-matching. Although I
have made progress, the result was not as good as what I had hoped for
by about an order of magnitude. This makes me wonder what is currently
actually the state of the art of pattern matching in Go.
Of c
My computer-go player is a single pattern system. It linearises
patterns and stores them in a very large suffix tree. At each node in
the tree counts are kept of the number of times the node has been
played or not played.
http://code.google.com/p/jgogears/
It's currently at the stage where it pla
The speed is based on how many attributes in the item you wish to
classify as well as how many classes. The complexity of classifying
something is O(kn) where k is number of classes and n the number of
attributes.
If your "patterns" are more than just the trivial [black, white, empty,
edge] t
On Wed, 2008-03-26 at 15:08 -0300, Mark Boon wrote:
> Lately I have been putting some effort into pattern-matching.
> Although I have made progress, the result was not as good as what I
> had hoped for by about an order of magnitude. This makes me wonder
> what is currently actually the state
Thanks for the pointer Don, that might be worth looking into at some
point.
When you say 'amazing accuracy despite this speed and simplicity' I
still have to ask: "how fast?". I think 10usec is actually pretty
fast. But when talking about using it during MC playouts for example,
it's stil
Mark,
I am doing some experimentation with something similar to patterns, but
based on Naive Bayes classifiers. The idea is to use Naive Bayes
classifiers to generalize patterns. The classifiers would still be
focused on some constrained area of the board, such as the 5x5 matrix or
someth
Our pattern matching work is just now starting to run.
We will post details when we have done more testing.
Cheers,
David
On 26, Mar 2008, at 11:08 AM, Mark Boon wrote:
Lately I have been putting some effort into pattern-matching.
Although I have made progress, the result was not as good as
42 matches
Mail list logo
