2. Mogo (and CrazyStone) are using lots of intelligence in their
playouts, and that is the cause of the nakade weakness. They are good
players, but they have preconceptions. They consider the moves required
to discover the difference between a nakade and
dead-stones-in-a-definitely-alive-group as
>> Any estimate of winning probability is only as good as the estimates of
>> whether particular games are actually won or lost.
>>
>> Evidently, even strong programs fail to recognize the impact of nakade,
>
> MC programs don't even have any concept of nakade. Nevertheless, the
> best of them ar
Joshua Shriver wrote:
> I've been looking into GPGPU for several years now, there was even some buzz
> in the comp-chess stream but the downsides seemed to be to much. Think the
> big problem is the latency on the PCI/AGP bus. Though that might not be as
> much an issue now with PCI-x, etc.
Thanks
I've been looking into GPGPU for several years now, there was even some buzz
in the comp-chess stream but the downsides seemed to be to much. Think the
big problem is the latency on the PCI/AGP bus. Though that might not be as
much an issue now with PCI-x, etc.
For more info I'd refer you to this
An interesting article on using GPUs for general purpose computation:
http://www.linux-mag.com/microsites.php?site=business-class-hpc&sid=build&p=4543
In (current mainstream) computer go there are two main CPU-bound
algorithms: playouts (random, or incorporating logic or patterns) and
tactical sea
In message <[EMAIL PROTECTED]>, terry mcintyre
<[EMAIL PROTECTED]> writes
I am hardly fit to clean the dust from Pro 9-dan Go Seigen's goban, so
I'll just rest my argument
What _is_ your argument?
Nick
with the chapter headings from his book,
Winning a Won Game:
Chapter 1 Three Golden Rules
Hi Terry,
How to convert these maxims to robust code? Use monte carlo with
win/loss scoring as we do now.These maxims fit the monte carlo
scoring model perfectly.
- Don
terry mcintyre wrote:
> I am hardly fit to clean the dust from Pro 9-dan Go Seigen's goban, so
> I'll just rest my argu
I propose a far more powerful and correct set of rules:
1. Play the move that gives you the best chance of winning.
Unfortunately, that it not very helpful for humans. Luckily it is
helpful for a UCT engine or a similar best first + MC engine.
On Dec 6, 2007 6:29 PM, terry mcintyre <[EMAIL PR
Le jeudi 6 décembre 2007, Don Dailey a écrit :
>
> Lavergne Thomas wrote:
> > If some bot can be setup to play on kgs for enough time to get a solid
> > rank and then put on cgos to get an elo rating with the same
> > configuration we could find a formula to convert elo to kgs ranks.
> > For sure,
I am hardly fit to clean the dust from Pro 9-dan Go Seigen's goban, so I'll
just rest my argument with the chapter headings from his book, Winning a Won
Game:
Chapter 1 Three Golden Rules
Avoid uncertainties when you have the lead
Seize the opportunity when it is presented
Attack the oppon
> -Original Message-
> From: Jason House <[EMAIL PROTECTED]>
> To: computer-go
> Sent: Thu, 6 Dec 2007 4:44 pm
> Subject: Re: [computer-go] Re: evaluating monte carlo results
> On Dec 6, 2007 4:22 PM, <[EMAIL PROTECTED]> wrote:
> >
> > My program is riddled with code to try and make u
You example is perfect for explaining the strengths of Monte Carlo.
And I think your analysis is wrong. A Monte Carlo program will choose
the group that maximizes it win expectancies. If it see's all groups
as 85% then it would clearly go for the biggest group since that has a
bearing on the
I organized the go congress computer go tournaments for many years.
Ask the AGA congress organizers for prize money. The congress has a big
pool of prize money. Several years I convinced the organizers to put up
$500 to $1000 in prize money. Usually the congress budget isn't set until
right bef
You can't "play to win" if you don't actually know whether you are winning or
losing.
Analyze any lost game, and the loser will admit "I didn't see that coming" -
they were playing
an imaginary game, not the one actually on the board. Some are honest enough to
admit: "I was hallucinating ther
Here's a more likely scenario: Approaching endgame, there
are 10 "resolved" fights that remain to be played out. The
program estimates is won 5 of them and lost 5 of them,
each with 85% confidence. The sizes of the groups is
such that any single switch from won to lost will swing
the game. The
On Dec 6, 2007 4:22 PM, <[EMAIL PROTECTED]> wrote:
>
> My program is riddled with code to try and make use of this. (It's always
> bothered me that UCT relies on the standard deviation of (often) multi-modal
> distributions.) It hasn't made my engine any stronger but it has helped me
> understand
terry mcintyre wrote:
> Any estimate of winning probability is only as good as the estimates
> of whether particular games are actually won or lost.
So what? This is about the sophistication of the approach you are
using. Monte Carlo programs use the sophisticated approach of viewing
the game g
Go ahead and do it then and produce this super-bot. I know that the
programmers of the top engines have tried many things that have
weakened the engine. This could just as easily be one of those as it
could be one that improves it. Maybe even easier. Only way to tell
is to try it out (with bug-
My program is riddled with code to try and make use of this. (It's always
bothered me that UCT relies on the standard deviation of (often) multi-modal
distributions.) It hasn't made my engine any stronger but it has helped me
understand some things better.
-Original Message-
From: Dav
From: Nick Wedd <[EMAIL PROTECTED]>
>>which will alter the score not by one point, but by ten or twenty.
>>Their estimate of winning probability is totally wrong. Good players
>>winnow out losing moves and stick with good moves - the basic premise
>>of minimax searching. Losing a big group will
Christoph Birk wrote:
On Tue, 4 Dec 2007, Christoph Birk wrote:
On Tue, 4 Dec 2007, Don Dailey wrote:
It would be awkward at best. I could build a client to do this, but
the human would have to be willing to sit and play games at the moment
they were scheduled.
You are right ... it's very
On Tue, 4 Dec 2007, Christoph Birk wrote:
On Tue, 4 Dec 2007, Don Dailey wrote:
It would be awkward at best. I could build a client to do this, but
the human would have to be willing to sit and play games at the moment
they were scheduled.
You are right ... it's very awkward. I lost one gam
In message <[EMAIL PROTECTED]>, terry mcintyre
<[EMAIL PROTECTED]> writes
Any estimate of winning probability is only as good as the estimates of
whether particular games are actually won or lost.
Evidently, even strong programs fail to recognize the impact of nakade,
MC programs don't even ha
At 11:39 AM 12/6/2007, terry mcintyre wrote:
>Any estimate of winning probability is only as good as the estimates of
>whether particular games are actually won or lost.
I propose that monte carlo programs should produce a distribution of
quantitative outcomes rather than just a simple %win. It'
On Thu, 2007-12-06 at 14:21 -0500, Don Dailey wrote:
> > However, the estimated probability of winning may be way off. It is
> > well known that Mogo, and perhaps some other programs, fail to
> > recognize common nakade placements, which leads to fundamental
> > estimation errors. An algorithm wit
Any estimate of winning probability is only as good as the estimates of whether
particular games are actually won or lost.
Evidently, even strong programs fail to recognize the impact of nakade, which
will alter the score not by one point, but by ten or twenty. Their estimate of
winning probab
From: terry mcintyre <[EMAIL PROTECTED]>
For a large number of playouts, the estimated scores should converge as the
game progresses. This is particularly true if the random distributions strongly
favor moves where each opponent monotonically increases the score - keeping
one's groups alive, k
I suggest to make the bots play on kgs but on 9x9 versus human, so we
could known approximatively the level of theses bots against human.
We can also know the relative strenght of these bots against other bots
on cgos in the same conditions (i.e. board size, timing, rules...) so we
could estimate t
terry mcintyre wrote:
> I understand that Monte Carlo algorthms are driven by the "winning
> probability", and a 0.5 win looks as good - or maybe even better -
> than a 100-point win.
>
It doesn't view 0.5 as "better"
> However, the estimated probability of winning may be way off. It is
> well
Lavergne Thomas wrote:
> If some bot can be setup to play on kgs for enough time to get a solid
> rank and then put on cgos to get an elo rating with the same
> configuration we could find a formula to convert elo to kgs ranks.
> For sure, this is not perfect but I think is good enought.
>
Her
All right thanks, so whos turn it is don't matter, it is part of my hashcode
implementation.
I completely forget that fact and only looked position and think only that
black has not got that position before. But thats easy to fix thanks.
t. harri
- Original Message -
From: "Nick Wedd"
I understand that Monte Carlo algorthms are driven by the "winning
probability", and a 0.5 win looks as good - or maybe even better - than a
100-point win.
However, the estimated probability of winning may be way off. It is well known
that Mogo, and perhaps some other programs, fail to recogniz
On Thu, 2007-12-06 at 15:07 +0100, Edward de Grijs wrote:
>
>
> To check things even more, I tried to communicate using C with
> popen():
> > FILE *ptr;
> > if ((ptr = popen("mogo --9 --nbTotalSimulations 3000 > mogoout",
> "w")) != NULL)
> > {
> > fprintf(ptr, "boardsize 9\n");
> > fprintf(ptr
There is also the fact that some amateurs plays a lot of 9x9 game and
get a better feeling about it, so when they meet a stronger opponent but
who don't have played a lot of game on 9x9 they can crush it.
Tom
On Tue, Dec 04, 2007 at 11:32:45AM +, Jacques Basaldúa wrote:
> Christoph Birk wrote
If some bot can be setup to play on kgs for enough time to get a solid
rank and then put on cgos to get an elo rating with the same
configuration we could find a formula to convert elo to kgs ranks.
For sure, this is not perfect but I think is good enought.
Tom
On Tue, Dec 04, 2007 at 05:30:15PM
I'll dig into the scoring algorithms used by GoGui; my guess is that it counted
handicap stones differently than Mogo.
Regarding nakade: I had a friend with a shodan ranking play a 9x9 game, no
handicap, against Mogo, which Mogo lost due to a nakade in the corner. Mogo
apparently believed it ha
>As any incomplete search, it can blunder, but why more than any other
>incomplete search?
Not worse, just not a magic bullet.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Yes! You are write. I haven't mentioned this. It's a good idea to swap
them all in the form that black has the move-right. Thank you!
I'll fix that. But not today ;)
If you find any inconsistencies in the data please let me know!
By the way: I forgot to cut the file at the end. You should only u
Jason House wrote:
This may serve as a good test of if there is enough data to assign
values to the patterns.
I did not mention this in my paper, but you can rather easily estimate
uncertainty margins around Elo values. This involves computing the
second-order derivative of the probability
On Dec 6, 2007 10:13 AM, Álvaro Begué <[EMAIL PROTECTED]> wrote:
>
>
> On Dec 6, 2007 10:06 AM, Jason House <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > On Dec 6, 2007 7:13 AM, Álvaro Begué <[EMAIL PROTECTED]> wrote:
> >
> > > 88|0|17.033168
> > > 88|1|12.263955
> > >
> > > and
> > >
> > > 164|0|17.38
On Dec 6, 2007 10:06 AM, Jason House <[EMAIL PROTECTED]> wrote:
>
>
> On Dec 6, 2007 7:13 AM, Álvaro Begué <[EMAIL PROTECTED]> wrote:
>
> > 88|0|17.033168
> > 88|1|12.263955
> >
> > and
> >
> > 164|0|17.388714
> > 164|1|25.862695
> >
> > Are identical except for swapping the roles of white and bla
On Dec 6, 2007 7:13 AM, Álvaro Begué <[EMAIL PROTECTED]> wrote:
> 88|0|17.033168
> 88|1|12.263955
>
> and
>
> 164|0|17.388714
> 164|1|25.862695
>
> Are identical except for swapping the roles of white and black
Curiously, the gamma values in your example are way different
17.033168 vs 25.862595
Edward de Grijs: <[EMAIL PROTECTED]>:
>
>
>Thanks Hideki, Chris and Jacques for your replies.
>
>> Hideki wrote:
>> Then, you can make a very simple program that passes a file to stdout
>> first and passes stdin to stdout after the end-of-file of the file.
>> And use it as "a.out file | mogo ".
>I
Oh, I didn't notice at first that the player-to-move was encoded
seperatly from the pattern shape.
On Dec 6, 2007 9:53 AM, Álvaro Begué <[EMAIL PROTECTED]> wrote:
>
>
>
> On Dec 6, 2007 9:31 AM, Chris Fant <[EMAIL PROTECTED]> wrote:
> > But then you lose information on player-to-move, right?
>
> N
On Dec 6, 2007 9:31 AM, Chris Fant <[EMAIL PROTECTED]> wrote:
> But then you lose information on player-to-move, right?
No. What I am saying is that it is as urgent for black to play on
. . .
. . X
X O .
as it is for white to play in
. . .
. . O
O X .
Precisely one way of implementing what I
But then you lose information on player-to-move, right?
On Dec 6, 2007 7:18 AM, Álvaro Begué <[EMAIL PROTECTED]> wrote:
> Oh, I see you have applied the symmetries, but not the swapping of roles.
> Still, this should probably be done and cut the number of gamma values in
> half.
>
> Álvaro.
>
>
>
Thanks Hideki, Chris and Jacques for your replies.
> Hideki wrote:
> Then, you can make a very simple program that passes a file to stdout
> first and passes stdin to stdout after the end-of-file of the file.
> And use it as "a.out file | mogo ".
Is this not the way a "tail -f" works?
This is t
On Wed, Dec 05, 2007 at 10:16:20PM -0800, Sylvain Gelly wrote:
> >
> > You should be using area scoring only and if you are playing handicap
> > games then either YOU or MOGO is not counting them the same. Or
> > perhaps Mogo has a bug in the handicap code.
> >
>
> MoGo uses KGS handicap count
In message <[EMAIL PROTECTED]>, Harri Salakoski
<[EMAIL PROTECTED]> writes
Hi is last black move A4 really illegal in cgos rules?
Just ensure before start change things. It seemed weird.
White D9 shouls change board situation and white kills two stones
before A4 is getting then
one stone back f
Oh, I see you have applied the symmetries, but not the swapping of roles.
Still, this should probably be done and cut the number of gamma values in
half.
Álvaro.
On Dec 6, 2007 7:13 AM, Álvaro Begué <[EMAIL PROTECTED]> wrote:
> Thanks for the file! This should be very helpful when I try to repr
Thanks for the file! This should be very helpful when I try to reproduce
results.
It looks like you are not taking advantage of symmetries. For instance,
88|0|17.033168
88|1|12.263955
and
164|0|17.388714
164|1|25.862695
Are identical except for swapping the roles of white and black (88 == 1120
Dave Dyer wrote:
In cases where the good moves are the "obvious" ones,
you've found them anyway.
Ok. Here I agree.
In other cases, you prune them away.
You are not really pruning, just postponing. Of course
you may overlook moves of genius, who doesn't? But
if your probabilities are co
Edward de Grijs wrote:
Can someone help me with this problem, for which I cannot
find a solution: I am trying to run MoGo in an automatic
way, using the cygwin toolkit.
I guess you are trying to do this in Windows and using
the Windows binary. If this is the case, you don't need
any library.
Lars wrote:
> Anyone of you have similar or other experiences with the algorithm?
I use at runtime the same Bradley-Terry formulas Remí introduces
in his paper. That is a huge advance compared to "naif urgency"
scores because it gives a measure of how hard it was to "win"
for a move candidate. B
While you can find the gamma-values of non-shape patterns in the paper
of Remi, I can give you the list of shape-pattern gamma-values.
The source-code is mixed with my engine-code, which i don't like to
publish. But the algorithm is more or less easy to implement..
I'll try to attach the file to
55 matches
Mail list logo
