Dmitry Kamenetsky wrote:
I have been reading this list for nearly a year now and it is very discouraging
to receive so much criticism for my first post.
The yahoo groups was merely an example to show how easy it is to get a forum
started. I also agree that yahoo appends too much spam to its
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 7, 2007, at 5:20 , Dmitry Kamenetsky wrote:
I hope I have given some good reasons for having a forum. Since so
many people here are against losing the list, why not the following:
we keep the list, but give members the option of using a
As I have spent a lot of time trying to guess what could be done for
Quasi-Monte-Carlo
or other standard forms of Monte-Carlo-improvements in computer-go, I
write below
my (humble and pessimistic :-) ) opinion about that.
Let's formalize Monte-Carlo.
Consider P a distribution of probability.
Dmitry Kamenetsky [EMAIL PROTECTED] writes:
The forums that I really like are the TopCoder forums
(http://forums.topcoder.com/). I like them for these reasons:
And really everything of these reason are features of good E-Mail
clients (except the +/- voting). So with the right client you get
Hi,
So this is all about flexibility -- nearly all web forum software are
really jails with no easy alternative access, but with mailing lists
you have plenty of alternatives (including your own web server with
your forum software into which you can inject all these mails).
I agree. Setting
I could see a case where it is possible to reduce a variance of a single
variable even in the 0-1 case. Let us say that black has about 5% chances of
winning. If we could (exactly) double the chances of black winning by
changing the nonuniform sampling somehow (say, enforce bad moves by
On Wed, Feb 07, 2007 at 12:06:40PM +0200, Tapani Raiko wrote:
Let my try again using the handicap example. Let's say MC player is given
a huge handicap. In the simulations, it is winning all of its games, so
there is no information helping to select the next move.
This situation happens in
Matt Gokey wrote:
But what are some of the reasons MC is not even better?
1-Since MC engines don't deal with tactics directly, they're not likely
going to play tactical sequences well for low liberty strings, securing
eye space, cutting and connecting, ko fights, or ladders, etc.
2-Also because
I have been reading this list for nearly a year now and it is very
discouraging to
receive so much criticism for my first post.
it means that you've touched upon an important issue to the readers of the
list. this, in and of itself, means that you are getting valuable information
from
the
Jacques Basaldúa wrote:
Very good analysis and I would like to contribute a 4th reason:
As Luke Gustafson pointed out, we have to contemplate the simulation
as a _stochastic process_. We want to determine the conditional
probability of a win given a particular move is made. And that depends
on
Two qick comments:
Quoting Matt Gokey [EMAIL PROTECTED]:
Jacques Basaldúa wrote:
Very good analysis and I would like to contribute a 4th reason:
against scalability of global search MC/UCT. If the simulation is
500 moves long (Chinese rules with recaptures, etc.) the observed
variance at an
I've had a computer go forum running for a while but has low traffic.
http://www.olympuschess.com/phpBB2
-josh
On 2/4/07, Dmitry Kamenetsky [EMAIL PROTECTED] wrote:
Hello everyone,
Why can't we use proper forums instead of this outdated list? Forums are easier
to keep track of and search for
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Wed, 7 Feb 2007 5:34 AM
Subject: [computer-go] MC approach (was: Monte Carlo (MC) vs Quasi-Monte Carlo
(QMC))
On Wed, Feb 07, 2007 at 12:06:40PM +0200, Tapani Raiko wrote:
Let my try again using the
I should have mentioned that I have only tested on 9x9. For larger boards,
I don't know.
- Dave Hillis
`
Intuitively, it seems like this should work. You only give the winning
margin a small weight, or only use it to break ties, or only apply it after the
game
If I recall correctly, someone spoke of constraining the opening moves to the
3rd,4th,and 5th lines in the absence of nearby stones, or something to that
effect. What was the impact of this experiment? I notice the recent discussion
of the need for a lot of thinking time to find good opening
What sort of sampling was used for the playouts? For this variable (
incorporating some information about the score vs only the win-loss variable ),
does it make a difference whether playouts are totally random or incorporate
varying degrees of similitude to good play?
From: [EMAIL PROTECTED]
terry mcintyre wrote:
If I recall correctly, someone spoke of constraining the opening moves
to the 3rd,4th,and 5th lines in the absence of nearby stones, or
something to that effect. What was the impact of this experiment?
For what it's worth, I tried a number of experiments along these
The tests that involved factoring in the margin of victory while the game
was still in play, used pure random playouts (or relatively close to it.)
Later, I did some tests with esthetics as a goal in itself, and for these, I
used what I call a heavy playout. I doubt that the playout type
Don Dailey wrote:
On Wed, 2007-02-07 at 11:34 +0100, Heikki Levanto wrote:
All this could be avoided by a simple rule: Instead of using +1 and -1
as the results, use +1000 and -1000, and add the final score to this.
Heikki,
I've tried ideas such as this in the past and it's quite
Magnus Persson wrote:
Quoting Matt Gokey [EMAIL PROTECTED]:
(snip)
Good point. This leads to another thought that I have been wondering
about. That is I question whether using more time to search more
simulations in the opening is the best approach. For the opening,
selecting
If it only did one playout you would be right, but imagine the following
cases:
case 1: White wins by .5 x 100, Black wins by .5 x 100
case 2: White wins by 100.5 x 91, Black wins by .5 x 109
the method that takes into account score would prefer the second case even
though it has a lower
On Wed, 2007-02-07 at 14:10 -0600, Matt Gokey wrote:
I was wondering if anyone was combining an opening library with MC/UCT
by running a large number of the simulations and storing the results.
This seems like a pretty natural extension to save simulation time in
the opening.
This is not
On Wed, 2007-02-07 at 16:17 -0500, Don Dailey wrote:
I have a hash funciton that creates a 64 bit cannonical hash of
the position. The same hash is produced after a rotation for
example. A book entry is a record with 3 fields, a priority
value (how many times the deep search selected this
That drives me nuts! Minimax search would eliminate bad lines of play whenever
a refutation is found. A good opponent would not play badly, and the quantity
of possible bad moves should not affect the evaluation of good moves - but that
seems to be what MC does, averaging out all moves
You should never play suicide, whether multiple or single stone
in the play-out portion of the search - ESPECIALLY when it's not
legal anyway in the rule-set you are using.
Although suicide can occasionally be the best move in some
rule-sets, I think it weakens your program to include it,
even
On Wed, 2007-02-07 at 14:08 -0600, Matt Gokey wrote:
Don, do you have any theories or information about why this is the
case?
Not really. In truth the only thing that matters is to increase your
winning percentage - not your score. There seems to be no point in
tampering with this.
- Don
Hello,
David Doshay wrote:
On 3, Feb 2007, at 2:51 AM, Sylvain Gelly wrote:
the speed of the best simulation policy in MoGo is 0.6 * the speed
of the uniform random one.
I think that this is very good. You give up less than a factor of 2
from uniform random and you probably get better than
Okay, thanks for the feedback. I mentioned that I was allowing
multi-stone suicide a couple days ago but no one said anything. It
seems little more complicated to check for than single-stone suicide
when only tracking pseudo-liberties. But I will get it in there and
see what kind of
It's a *weighted* average of all moves. UCT tree search doesn't explore
bad moves as often as good ones, so they don't contribute as much to the
estimation of the worth of a node.
- Dave Hillis
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent:
The only think I can suggest which perhaps hasn't been tried is to
only consider the score in the evaluation if NONE of the playouts
resulted in a loss.
On 2/7/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
It's a *weighted* average of all moves. UCT tree search doesn't explore
bad moves
By the way, the paper was rejected on first submission, largely
because we were just testing Orego against itself. We're now testing
Orego against GNU Go and have a revised version:
https://webdisk.lclark.edu/xythoswfs/webui/_xy-2352013_1-t_Gct7yJ5s%22
(Markus, could you change the link and
Quoting Matt Gokey [EMAIL PROTECTED]:
Magnus Persson wrote:
Quoting Matt Gokey [EMAIL PROTECTED]:
I was wondering if anyone was combining an opening library with MC/UCT
by running a large number of the simulations and storing the results.
This seems like a pretty natural extension to save
Unfortunately, it's just not that simple, because it depends far more
on _how_ the playout is improved, rather than, say, the ELO numbers
that measure that improvement. For example, programs exist that are
good (in part) because they entirely disregard some lines of play.
They may be correct to
On 2/7/07, steve uurtamo [EMAIL PROTECTED] wrote:
And of course don't forget about this no_variable_in_for thing...
i'll have to read up on what you're describing.
The following pseudocode block
for (int i = 0; i 10; ++i) {
... code ...
}
// i's lifetime ends after the for loop does
is
On Wed, Feb 07, 2007 at 04:42:01PM -0500, Don Dailey wrote:
In truth the only thing that matters is to increase your winning
percentage - not your score. There seems to be no point in tampering
with this.
I guess I must accept the wisdom of those who have tried these things.
Still, it hurts
On Wed, 2007-02-07 at 16:28 -0500, Don Dailey wrote:
On Wed, 2007-02-07 at 16:17 -0500, Don Dailey wrote:
I have a hash funciton that creates a 64 bit cannonical hash of
the position. The same hash is produced after a rotation for
Most people do incremental hashing, which is cheaper even
On Thu, 2007-02-08 at 00:46 +0100, Heikki Levanto wrote:
On Wed, Feb 07, 2007 at 04:42:01PM -0500, Don Dailey wrote:
In truth the only thing that matters is to increase your winning
percentage - not your score. There seems to be no point in tampering
with this.
I guess I must accept
On 2/7/07, Unknown [EMAIL PROTECTED] wrote:
to binary search the file on the parent position key,
collect all of these records together (making sure there is a
legal move which leads to the cannonical response key) and then
You are not clear here.
Is there only a one-move-step between key
On Thu, 2007-02-08 at 01:00 +0100, Unknown wrote:
On Wed, 2007-02-07 at 16:28 -0500, Don Dailey wrote:
On Wed, 2007-02-07 at 16:17 -0500, Don Dailey wrote:
I have a hash funciton that creates a 64 bit cannonical hash of
the position. The same hash is produced after a rotation for
But of course, it's not the size of the win that counts, it is rather
the confidence that it really is a win. In random playouts that
continue from a position from a close game, the ones that result in a
large victory are generally only ones where the opponent made a severe
blunder. (Put
After looking at your message I'm not sure you understand how
I set this up.
On Thu, 2007-02-08 at 01:00 +0100, Unknown wrote:
to binary search the file on the parent position key,
collect all of these records together (making sure there is a
legal move which leads to the cannonical
Matt Gokey: [EMAIL PROTECTED]:
Weston Markham wrote:
But of course, it's not the size of the win that counts, it is rather
the confidence that it really is a win.
Yes, and my reasoning was that a larger average win implied a higher
confidence since there is more room for error. That intuition
42 matches
Mail list logo
