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. But I
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.
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
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 ==
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
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
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 counting (add 1
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 arguments.
Is this not the way a tail -f works?
This is
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.
On Dec
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?
No. What I
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 arguments.
Is this
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
and
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.388714
164|1|25.862695
Are
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
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/
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.
Here
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 recognize
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 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
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,
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
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 with more
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's
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 have
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
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
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 lead to a
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
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 there.
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
-Original Message-
From: Jason House [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
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
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
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, this is
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
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
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 are stronger
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
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
39 matches
Mail list logo
