Also, there was a recent thread on the mailing list: 50, 576 pro/dan
games without repetitions nor easily detectable problems, started by
Jacques Basaldúa, who has put together a collection of games:
http://www.dybot.com/masters/masters.zip
If I recall correctly, the format of this file is
Okay. Don's later post does indicate that he intends to compensate
for the stones. So, in the interest of being 100% clear: is this
compensation included in the komi value that is sent to the client?
Weston
On 12/29/06, Weston Markham [EMAIL PROTECTED] wrote:
Am I correct in inferring
Personally, I use the terminology in much the same way as Heikki. I
use the word mistake to describe (for example) a move that loses a
large group, but does not change the game from a win to a loss. It
makes sense to me to generally apply mistake to any move that loses
points relative to the
On a slightly (but not much) more serious note:
The proposal that elicited (for better or for worse) Alain's
size-of-the-universe comment was not for a complete table of all
possible board states, but rather a table of winning moves. I expect
that most positions will have multiple winning
On 1/24/07, Weston Markham [EMAIL PROTECTED] wrote:
282 possible moves
Um. Dunno where I got that number from. (I meant 362, I think.)
Weston
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo
I have an idea in the back of my mind that is an extreme version of
this: Divide the board into 361 separate local searches, then use
information from these to guide a global search. The local searches
would be done on the full board, but would only search for strategies
that will capture or
The version in the Open division was the standard development
version. The one in the Open division, MonteGNU
Should one of those Opens be Formal?
Weston
On 2/5/07, Nick Wedd [EMAIL PROTECTED] wrote:
I have put a short report on the event at
http://www.weddslist.com/kgs/past/23/index.html
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, 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
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
On 2/8/07, steve uurtamo [EMAIL PROTECTED] wrote:
i wonder if this kind of greediness might, however, be useful for selecting,
say, the first move or two in a 9x9 game. the thinking here is that since the
endgame is essentially noise at this point, you might as well be greedy
before tactics
thought that I would mention it.
Weston
On 2/8/07, Chris Fant [EMAIL PROTECTED] wrote:
On 2/8/07, Weston Markham [EMAIL PROTECTED] wrote:
I believe that I have had some success with an approach like this,
actually. I believe that I initially only tally games that are won by
a certain margin
I think that you are essentially correct. However, this is only going
to affect a small number of games where two different moves are
exactly tied for the best winning percentage, after many playouts.
Even if the underlying probabilities are exactly the same, you can't
really expect this to
On 2/9/07, Weston Markham [EMAIL PROTECTED] wrote:
I don't seem to have any numbers on this anymore, but I should be able
to try some experiments this weekend. I do have some code that does
what I describe below. It is also using an all moves as first
heuristic. According to my notes, I made
Somewhere online, I played a game on a torus, against someone's Java
applet that has this option. I seem to recall playing a normal game
at either 9x9 or 13x13, and then a game on the same-sized torus. I
recall the first game as being somewhat challenging to me, (a
beginner) and the second game
That board needs to have the inside edge be connected to its outside
edge, in order to represent a torus.
Weston
On 2/20/07, Antonin Lucas [EMAIL PROTECTED] wrote:
No need for those difficulties, you can play along this board :
http://www.youdzone.com/go.html
On 2/21/07, Weston Markham
(oops. Other people have already pointed this out, in an
appropriately re-named thread.)
On 2/21/07, Weston Markham [EMAIL PROTECTED] wrote:
That board needs to have the inside edge be connected to its outside
edge, in order to represent a torus.
Weston
On 3/7/07, Paul Pogonyshev [EMAIL PROTECTED] wrote:
Don Dailey wrote:
On Wed, 2007-03-07 at 22:53 +0100, Gunnar Farneback wrote:
* To abort the asynchronous genmove, the controller should send the
(synchronous) command abort_async_genmove. If the engine has not
returned the
On 3/7/07, Paul Pogonyshev [EMAIL PROTECTED] wrote:
Gunnar Farneback wrote:
Example 3: Like example 2, but abort command comes too late.
...
Maybe it should then read
?2 not in progress
It also makes sense to forbid an async_genmove (or simple genmove for
that matter) until the previous
On 3/8/07, Don Dailey [EMAIL PROTECTED] wrote:
On Thu, 2007-03-08 at 12:27 -0500, Weston Markham wrote:
I think I am confused.
I may be confused as well. I see that Paul has responded as well, but
just in case this doesn't clear up on it's own:
So what you might get is this:
1
It appears to me that at least 91 is possible:
.xx.x.xx.
xx.xxx.xx
.xx.x.xx.
xx.xxx.xx
.xx.x.xx.
xx.xxx.xx
.xx.x.xx.
xx.xxx.xx
.xxx.xxx.
Weston
On 3/29/07, Jason House [EMAIL PROTECTED] wrote:
After some trial and error, I got 90
* * * *
*
* * * *
* * * ***
* * *
*** * * *
*
A pseudo-liberty is a pairing of a stone in the group and an adjacent,
empty intersection.
On 3/29/07, Jim O'Flaherty, Jr. [EMAIL PROTECTED] wrote:
What's a pseudo-liberty? And how can there be more of them than there are
empty intersections (81) on the board?
- Original Message
On 3/29/07, John Tromp [EMAIL PROTECTED] wrote:
On 3/29/07, Weston Markham [EMAIL PROTECTED] wrote:
It appears to me that at least 91 is possible:
Nice! If you use O's instead like
.OO.O.OO.
OO.OOO.OO
.OO.O.OO.
OO.OOO.OO
.OO.O.OO.
OO.OOO.OO
.OO.O.OO.
OO.OOO.OO
.OOO.OOO.
it looks pretty
On 3/29/07, John Tromp [EMAIL PROTECTED] wrote:
On 3/29/07, Weston Markham [EMAIL PROTECTED] wrote:
On 3/29/07, John Tromp [EMAIL PROTECTED] wrote:
On 3/29/07, Weston Markham [EMAIL PROTECTED] wrote:
It appears to me that at least 91 is possible:
Nice! If you use O's instead like
On 4/7/07, Jacques Basaldúa [EMAIL PROTECTED] wrote:
Assuming two simplifying hypotheses:
1. The playouts are uniformly random.
2. Both players have the same number of legal moves (or any
unbalanced numbers compensate in the long term).
I did not understand your post either. Is #2 the same
The second explanation was no clearer to me. I'll try to criticize in
more detail:
1. Uniform playouts, as used in practice, are not really uniform over
all legal go moves. Generally, pass moves are excluded until
necessary, and moves that fill eyelike points are excluded. So, I
assume that
On 4/8/07, Don Dailey [EMAIL PROTECTED] wrote:
These programs, in theory, will play perfect GO given
enough time.
... and space. I doubt that your current programs would be capable of
storing a large enough game tree to actually converge to the
alpha-beta value. So in practice, it really
(I typed the following up earlier today, before other people cast some
doubts about what infinite scalability means. Perhaps it is
helpful.)
I think that Alain was specifically referring to a property of UCT,
whereby given that a winning line of play exists, the probability that
the algorithm
I know that other people have mentioned this sort of thing already,
but the result of level 8 being better than level 10 matches my own
experience with slightly older versions of gnugo. As I recall, 8 was
the best, 9 a little worse, and 10 worse again. Increasing the level
seems to improve play
On 3/6/08, Christoph Birk [EMAIL PROTECTED] wrote:
On Thu, 6 Mar 2008, Don Dailey wrote:
advantageous to give away stones that not. Despite what many people
believe, MC programs don't normally believe it's better to win small
and they are not hell-bent on giving away stones in order to
On Tue, May 13, 2008 at 7:08 PM, Gunnar Farnebäck [EMAIL PROTECTED] wrote:
And I agree, don't even think of doing this with floating point
numbers.
This is a bit tangential to computer go. But you have piqued my curiosity
Offhand, that sounds rather extreme to me. Perhaps I haven't
In the context of Monte Carlo, a win or loss by a large margin is
quite likely (at least in any close game) to be due to large blunders.
(For example, allowing a large, safe group of stones to be captured.)
Given this, it does not make sense to weight it more strongly than
any other win or loss.
On Thu, Oct 23, 2008 at 1:00 PM, Mark Boon [EMAIL PROTECTED] wrote:
This is still something I don't understand. Are there others who implemented
the same thing and got 111 moves per game on average? I tried to look
through some posts on this list but didn't see any other numbers published.
111
On Sun, Oct 26, 2008 at 4:22 PM, Don Dailey [EMAIL PROTECTED] wrote:
I imagine that it approaches some hypothetical
level in an asymptotic way.
For most board positions, it is reasonable to expect that there exists
a single move for which the asymptotic Monte Carlo value is higher
than the
On Mon, Nov 17, 2008 at 2:30 PM, Don Dailey [EMAIL PROTECTED] wrote:
On Mon, 2008-11-17 at 16:04 -0200, Mark Boon wrote:
On another note, as an experiment I have a bot running on CGOS that
is the ref-bot but instead of using a fixed number of simulations I
use a fixed amount of time that
On Mon, Nov 17, 2008 at 11:13 PM, Michael Williams
[EMAIL PROTECTED] wrote:
No one ever alleged that pure AMAF or pure MC was infinitely scalable.
My point is that in many cases, they doesn't even keep all of their
benefits, after some number of trials have been run. So, running 10k
playouts
On Tue, Nov 18, 2008 at 12:02 PM, Michael Williams
[EMAIL PROTECTED] wrote:
It doesn't make any sense to me from a theoretical perspective. Do you have
empirical evidence?
I used to have data on this, from a program that I think was very
nearly identical to Don's reference spec. When I get a
...@cox.net wrote:
On Tue, 2008-11-18 at 14:17 -0500, Weston Markham wrote:
On Tue, Nov 18, 2008 at 12:02 PM, Michael Williams
michaelwilliam...@gmail.com wrote:
It doesn't make any sense to me from a theoretical perspective. Do you
have
empirical evidence?
I used to have data
On Mon, Dec 15, 2008 at 5:47 PM, Don Dailey drdai...@cox.net wrote:
Is Jrefgo the pure version that does not use tricks like the futures
map? If you use things like that, all bets are off - I can't be sure
this is not negatively scalable.
I don't know, although I was under the impression
On Tue, Dec 16, 2008 at 7:34 PM, Weston Markham
weston.mark...@gmail.com wrote:
And I believe that current
Monte Carlo methods only really manage to avoid the very worst of the
bad moves, regardless of how many playouts they run.
Um, perhaps I should qualify that as pure Monte Carlo, meaning
On Wed, Dec 17, 2008 at 12:34 AM, Weston Markham
weston.mark...@gmail.com wrote:
I don't know, although I was under the impression that I had
downloaded the pure version. I found a reference to the source here
on the list, and downloaded and compiled that. When I get back home,
how would I
On Wed, Dec 17, 2008 at 12:51 AM, Darren Cook dar...@dcook.org wrote:
I'd also like to second Mark Boon's statement that Gnugo is not an
expert judge, especially not after only 10 moves. One experiment I did,
a couple of years ago, was scoring lots of terminal or almost-terminal
9x9 positions
On Wed, Dec 17, 2008 at 1:32 AM, Mark Boon tesujisoftw...@gmail.com wrote:
By the way, what does scratch100k.sh look like?
../gogui-1.1.3/bin/gogui-twogtp -auto -black java -jar jrefgo.jar 10 -game
s 1 -komi 0.5 -maxmoves 10 -referee gnugo --mode gtp --score aftermath --ch
inese-rules
On Wed, Dec 17, 2008 at 2:07 AM, Mark Boon tesujisoftw...@gmail.com wrote:
Thanks. I just realized that you set the komi to 0.5. That doesn't
sound like a good idea. I wanted to make sure you had the same for the
100k version. Were your earlier experiments also with 0.5 komi? MC
programs are
On Tue, Dec 16, 2008 at 7:34 PM, Weston Markham
weston.mark...@gmail.com wrote:
Incidentally, when I get home, I'll post the line of play that follows
those moves with the highest (asymptotic) Monte Carlo values,
according to jrefgo. I have about 18 moves calculated with high
accuracy.
Here
On Wed, Dec 17, 2008 at 2:38 AM, Don Dailey dailey@gmail.com wrote:
Is it the java version? I believe there is only one version of that and
it's the pure reference bot. I did make modification to a C version
but I think I kept that private.
Yes, it is the Java version.
On Mon, Dec 15, 2008 at 11:10 PM, Mark Boon tesujisoftw...@gmail.com wrote:
It would have been much more persuasive if you had simply run a 5K
playout bot against a 100K bot and see which wins more.
In 200 games, 100k beat 5k a total of 127 times. So that's about a
63.5% win rate.
On Fri, Jun 5, 2009 at 5:59 PM, Christoph Birk b...@ociw.edu wrote:
Handicap games are for humans ... they get frustrated losing
over and over. Computers have no problems with that.
2009/6/5 terry mcintyre terrymcint...@yahoo.com:
The purpose of a handicap games is to allow a 50% chance of
I'm curious to find out what is meant by lazy. If, as I am led to
believe by your report, Monte Carlo strategies applied to Double Step
Races are lazy, yet they converge to perfect play, then I'm not sure
why we are meant to worry. I certainly understand that the strategies
can converge faster
49 matches
Mail list logo
