Rémi Coulom wrote:
In Crazy Stone (maybe that is the case of MoGo, too), nakade is such a
big problem because the program avoids playing self-atari in playouts.
Crazy Stone will play the self-ataris anyway, but with a low
probability, so they are played at the end of the playout only. In case
I got a smile out of that.
_ Dave Hillis
-Original Message-
From: Don Dailey <[EMAIL PROTECTED]>
To: computer-go
Sent: Thu, 13 Dec 2007 8:52 pm
Subject: Re: [computer-go] low-hanging fruit - yose
[EMAIL PROTECTED] wrote:
>
> Impasse: noun,
> 1. There is no argument
[EMAIL PROTECTED] wrote:
>
> Impasse: noun,
> 1. There is no argument so elegant and compelling that it will prove
> the negative that making UCT greedier could not possibly lead to more
> won games.
I could hardly fail to disagree with you less.
___
Impasse: noun,
1. There is no argument so elegant and compelling that it will prove the
negative that making UCT greedier could not possibly lead to more won games.
2. Everyone who has tried it one way, will have tried some variations. It's not
as if it takes a?lot of code. No one has reported i
Mark Boon wrote:
>Let me therefore change the discussion a bit to see if this will make
>things more clear. Consider a chess-playing program with an
>unorthodox search method. When playing a human after while it
>announces check-mate in thirty-four moves. Yet the human can clearly
>see it's check-m
Hi Begué and Don,
I did this in my earlier version of ggmc. The real code was:
reward = 0.5 * (1 + tanhf(K * (score - komi)));
# tanhf() is a float, not double, version of hyperbolic tangent
function.
# I use tanh() as exp() may cause overflow.
# You can see the code from http://www.gggo.jp/ as
Nice idea and worth a try.I predict that this will weaken the
program no matter what value you use, but that there may indeed be a
reasonable compromise that gives you the "better" behavior with only a
very small decline in strength.
I think this bother people so much that they would be will
At the end of a playout there is probably some code that says samoething
like
reward = (score > komi) ? 1.0 : 0.0;
You can just replace it with
reward = 1 / (1 + exp(- K * (score - komi)));
A huge value of K will reproduce the old behaviour, a tiny value will result
in a program that tries to
On Dec 13, 2007 3:33 PM, Chris Fant <[EMAIL PROTECTED]> wrote:
> Seems like the final solution to this would need to build out the
> search tree to the end of the game, finding a winning line. And then
> search again with a different evaluation function (one based on
> points). If the second sear
Seems like the final solution to this would need to build out the
search tree to the end of the game, finding a winning line. And then
search again with a different evaluation function (one based on
points). If the second search cannot find a line that wins bigger
than the first search did, just
Hi Mark,
It wasn't my intention to sound argumentative about this, I apologize
for this.
Yes, I agree that the shorter mate sequence should be chosen and also
that if all else is equal, the bigger win should be the course to follow.
There is a misconception that MC favors winning by the smalle
Don,
This has taken me some time to formulate an answer. Mainly because
you are making so many assumption about what I understand or imagine
and what not. It makes for a confused discussion and I didn't feel
like getting into arguments like "no, that's not what I meant etc."
Let me theref
This is an artifact of using mercy rule.
You can change it in config.cpp
use_mercy_rule = true
Should I make it default?
Thanks,
Lukasz
On Dec 10, 2007 11:41 PM, Heikki Levanto <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 10, 2007 at 04:08:48PM -0500, Don Dailey wrote:
> > Would you rather be 95% co
Quoting Gunnar Farnebäck <[EMAIL PROTECTED]>:
10k100k 1M
GNU Go CVS 0.079 0.387 0.475
This position seems to fit he extra knowledge of Valkyria well, but
not perfectly
500 1k 10k100k
Valkyria 0.76 0.760.64
On Dec 12, 2007 7:44 PM, Álvaro Begué <[EMAIL PROTECTED]> wrote:
> Maybe I did something wrong, but dimwit aces this one:
>
> 10k 100k1M
>
> dimwit-0.48r 1.000 1.000 1.000
>
> This is the output at the end of those searches:
>
> score=1 thr=5
Maybe I did something wrong, but dimwit aces this one:
10k 100k1M
dimwit-0.48r 1.000 1.000 1.000
This is the output at the end of those searches:
score=1 thr=5 moves=20393 PV=(10001) B8(9407) D6(369) H9(361) J9(9) D4(4) D3
score=0.8 thr=
Hi Gunnar,
Gunnar Farnebäck: <[EMAIL PROTECTED]>:
>Heikki Levanto wrote:
> > On Mon, Dec 10, 2007 at 04:08:48PM -0500, Don Dailey wrote:
> >> Would you rather be 95% confident of a win or 90% confident?There is
> >> only 1 correct answer to that question.
> >
> > Yes, if you can offer me relia
On Mon, 10 Dec 2007, Heikki Levanto wrote:
Compare these two positions:
playout_benchmark 1
= Initial board:
komi 7.5
A B C D E F G H J
9 . . . . . O O O O 9
8 O O O O O O O O O 8
7 O O O O O O O O O 7
6 O O O O O O O O O 6
5 # # # # # # # # # 5
4 O O O # # # # # # 4
3 O O O O . # # # # 3
Heikki Levanto wrote:
> On Mon, Dec 10, 2007 at 04:08:48PM -0500, Don Dailey wrote:
>> Would you rather be 95% confident of a win or 90% confident?There is
>> only 1 correct answer to that question.
>
> Yes, if you can offer me reliable confidence numbers. We all (should)
know
> that MC eval
Vlad Dumitrescu wrote:
> Hi,
>
> Thank you all who answered my question. I think I understand better
> what each of you talks about. I still have the feeling that at some
> level different people think about different things when referring to
> some notion, but it's probably just me.
>
> On Dec 1
On Dec 11, 2007 3:34 AM, terry mcintyre <[EMAIL PROTECTED]> wrote:
> But what about doing a top-level analysis of the board just before starting
> playouts, offering some hints
> to the more interesting moves? During the middle game, and especially during
> the endgame, top-level
> analysis can pro
Hi,
Thank you all who answered my question. I think I understand better
what each of you talks about. I still have the feeling that at some
level different people think about different things when referring to
some notion, but it's probably just me.
On Dec 10, 2007 11:26 PM, Don Dailey <[EMAIL PR
From: Chris Fant <[EMAIL PROTECTED]>
> Such guidance has to be fairly subtle, however; it often must take
the form
> of "if he plays here, do this, if there, do that."
> Doesn't the search tree provide such functionality?
It does indeed - but there are often forced sequences which can be pred
> Such guidance has to be fairly subtle, however; it often must take the form
> of "if he plays here, do this, if there, do that."
Doesn't the search tree provide such functionality?
___
computer-go mailing list
computer-go@computer-go.org
http://www.co
- Original Message
From: Darren Cook <[EMAIL PROTECTED]>
> Am I confused in my understanding that a weakness of MC evaluation is
> that due to its random play it will miss sequences where there is
only
> one winning move at each play? ...
> This was exactly the topic I tackled in this
> Am I confused in my understanding that a weakness of MC evaluation is
> that due to its random play it will miss sequences where there is only
> one winning move at each play? ...
This was exactly the topic I tackled in this article:
http://dcook.org/compgo/article_the_problem_with_random_playou
Heikki Levanto wrote:
> On Mon, Dec 10, 2007 at 04:08:48PM -0500, Don Dailey wrote:
>
>> Would you rather be 95% confident of a win or 90% confident?There is
>> only 1 correct answer to that question.
>>
>
> Yes, if you can offer me reliable confidence numbers. We all (should) know
>
On Mon, Dec 10, 2007 at 04:08:48PM -0500, Don Dailey wrote:
> Would you rather be 95% confident of a win or 90% confident?There is
> only 1 correct answer to that question.
Yes, if you can offer me reliable confidence numbers. We all (should) know
that MC evaluations suffer from systematic pro
Vlad Dumitrescu wrote:
> Hi Don,
>
> On Dec 10, 2007 9:08 PM, Don Dailey <[EMAIL PROTECTED]> wrote:
>
>> /snipped a lot of interesting stuff/
>> However MC play-outs is not horizon limited like this. It's stupid to
>> make it greedy because it may notice that winning the big group leads to
>
Vlad Dumitrescu wrote:
Hi Don,
On Dec 10, 2007 9:08 PM, Don Dailey <[EMAIL PROTECTED]> wrote:
/snipped a lot of interesting stuff/
However MC play-outs is not horizon limited like this. It's stupid to
make it greedy because it may notice that winning the big group leads to
a loss every tim
On Dec 10, 2007 5:00 PM, Vlad Dumitrescu <[EMAIL PROTECTED]> wrote:
> Am I confused in my understanding that a weakness of MC evaluation is
> that due to its random play it will miss sequences where there is only
> one winning move at each play? This is the way I am interpreting the
> "nakade prob
Hi Don,
On Dec 10, 2007 9:08 PM, Don Dailey <[EMAIL PROTECTED]> wrote:
> /snipped a lot of interesting stuff/
> However MC play-outs is not horizon limited like this. It's stupid to
> make it greedy because it may notice that winning the big group leads to
> a loss every time and that some other
Mark Boon wrote:
>
> On 6-dec-07, at 19:29, Don Dailey wrote:
>>
>> Here is an example of why this works so well and why your greedy
>> approach is so wrong:
>>
>>Consider a position where there are 2 groups left that are being
>> fought over. One of these groups is very large and the other
On 6-dec-07, at 19:29, Don Dailey wrote:
Here is an example of why this works so well and why your greedy
approach is so wrong:
Consider a position where there are 2 groups left that are being
fought over. One of these groups is very large and the other is quite
small.The computer must
Aboute the "Nakade problem":
1) There is in principle no problem to correctly handle nakade in
MC/UCT programs. It just a question of making the playouts do it.
2) But doing this requires some smart programming. I think all the
strong progams has been designed by the "What can I do in less th
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
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
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-
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
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
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
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
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
47 matches
Mail list logo
