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
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).
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 liberties (ladder
A recurrent concept popping up in discussions on how to improve
playouts is balance. So I would like to try to share my philosophy
behind the playouts of Valkyria and how I define balance and how it
relates to the evaluation of go positions.
*Background
In an old school program the
don,
But I also discovered that there seems to be no benefit whatsoever in
removing them from the play-outs.I have no real explanation for
this. But it does tell me that the play-outs are very different in
nature from the tree - you cannot just use the same algorithms for
Hi Magnus,
Your post makes a great deal of sense. I agree with all the points you
have stated. I don't think you have ever made an illogical post like
most of us have (including myself) and they are always well thought out
and worded.
I have a response to this comment:
Still I think
Quoting Don Dailey [EMAIL PROTECTED]:
I have a response to this comment:
Still I think predicting the best moves is very important in the
tree part, but this may be much less important in the playouts, and
perhaps even detrimental as some people have experienced.
A class of bad
steve uurtamo wrote:
don,
But I also discovered that there seems to be no benefit whatsoever in
removing them from the play-outs.I have no real explanation for
this. But it does tell me that the play-outs are very different in
nature from the tree - you cannot just use the
I think there was some confusion in Don's post on ``out of atari'' in
play-outs.
For one thing, I do not agree with the maximal information argument.
Testing ``out of atari'' moves is not good because they might be good,
or might be bad, but merely because they might be good. By contrast, you
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 found
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
Jonas Kahn wrote:
I think there was some confusion in Don's post on ``out of atari'' in
play-outs.
For one thing, I do not agree with the maximal information argument.
This is more a theory than an argument. Maybe I didn't express it very
well either.
It's a pretty solid principle in
Don,
I'd strongly agree. You must know whether ladders work
or not, whether a nakade play works or not, whether
various monkey jumps and hanes and so forth succeed or
not. In and of themselves, few moves are objectively
good or bad in any sense - one has to try them and see
what happens.
Some
terry mcintyre wrote:
Don,
I'd strongly agree. You must know whether ladders work
or not, whether a nakade play works or not, whether
various monkey jumps and hanes and so forth succeed or
not. In and of themselves, few moves are objectively
good or bad in any sense - one has to try them
14 matches
Mail list logo
