I could be drawing wrong inferences from incomplete information, but as
Darren pointed out, this paper does leave the impression Alpha Zero is not
as strong as the real AlphaGo Zero, in which case it would be clearer to
say so explicitly. Of course the chess and shogi results are impressive
regardl
his might take a
> year or more on your hardware.
>
> I feel like maybe a lot of this is sour grapes; let's please again
> acknowledge that the hobbyists aren't there yet without trying to tear down
> the accomplishments of others.
>
> s.
>
> On Nov 27,
I imagine implementation determines whether transferred knowledge is
helpful. It's like asking whether forgetting is a problem -- it often is,
but evidently not for AlphaGo Zero.
One crude way to encourage stability is to include an explicit or implicit
age parameter that forces the program to per
On Tue, Dec 8, 2009 at 5:49 PM, Petr Baudis wrote:
> Hi!
>
> In most papers I've read, three-valued Zobrist hashes are used - per
> intersection, values for "empty", "black" and "white" coloring [1].
> I'm not clear on why is the "empty" value needed, however, shouldn't
> only "black", "white" v
On Fri, Oct 30, 2009 at 12:50 PM, Brian Sheppard wrote:
>>> Parallelization *cannot* provide super-linear speed-up.
>>
>>I don't see that at all.
>
> This is standard computer science stuff, true of all parallel programs and
> not just Go players. No parallel program can be better than N times a s
Am I remembering correctly (maybe not) that Mogo communicates between
nodes three times per second? That isn't a lot of communication
opportunities if each turn lasts a few seconds. Olivier, have you
tested parallel Mogo's ability to scale with core count at blitz
speeds? I might imagine, for examp
Not sure this helps, but...
I found send-two receive-one, as in your example, to be the most
common non-simple ko cycle in my program. The program was heavy, so
forbidding "send two" added little to the total cost. Specifically,
the rule forbade playing on an isolated empty intersection that
neigh
On Mon, Apr 6, 2009 at 11:32 AM, Jason House
wrote:
> I disagree with your comment about AyaMC's move 28 in round 4. The move
> looks to me like it primarilly aims to build a large framework along the
> bottom/center. All basic fights seem to favor white..
>
> I'm only KGS 3k, so take my comments
On Tue, Feb 17, 2009 at 4:39 PM, wrote:
> I've been looking into CGT lately and I stumbled on some articles about
> approximating strategies for determining the sum of subgames (Thermostrat,
> MixedStrat, HotStrat etc.)
> It is not clear to me why approximating strategies are needed. What is the
An amateur 5D also beat Mogo with 3 handicap. I would love to see more
serious games between top programs and roughly evenly matched human
opponents.
On Sun, Feb 15, 2009 at 8:08 AM, "Ingo Althöfer" <3-hirn-ver...@gmx.de> wrote:
> Hello,
>
> During the last week (February 10 - 13, 2009)
> there w
On Thu, Oct 9, 2008 at 10:25 AM, Jason House
<[EMAIL PROTECTED]> wrote:
> You are incorrect that the following heuristics in random games lead to
> finite game length:
> * no eye filling
> * no suicide
> * no simple ko violations
>
> Consider two eyeless chains with 3 ko's connecting them... Two ta
On Wed, Oct 8, 2008 at 3:46 PM, Don Dailey <[EMAIL PROTECTED]> wrote:
> Is there any way to prove that with best play the game cannot end in
> seki?
It seems like most reasonable sequences in Chinese rules 4x4 go end in
a whole-board seki. I would expect that for 19x19 go, some avenues of
best pla
When you measure win rates against players with a given rating, you
measure both how well player strength predicts probability of winning,
and how accurately the ratings reflect player strength. Sometimes the
ratings are quite inaccurate. This causes win rates to regress towards
50%. If you can inc
I don't have much useful to say, but I did notice that the gcc-gdc
version accepted as current by Cygwin Update is ancient:
gdc is /usr/bin/gdc
@eboesch ~: gdc --version
gdc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.
Sometimes the us
On Mon, Jun 16, 2008 at 2:00 PM, Nick Wedd <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>,
> John Fan <[EMAIL PROTECTED]> writes
>>
>> After I review the game, it is hard to say ManyFaces made a mistake at
>> move 60 or around, since the white group at the lower left corner has a
>> fl
> 4 X X X X X . X . X 4
> 3 . O O O O X X O . 3
> 2 O O O . O O X . . 2
> 1 . X X X O X X . . 1
>A B C D E F G H J
>
> /Gunnar
>
>
> Eric Boesch wrote:
> > Black doesn't need the lower-right corner as territory after killing
> > the lower
Black doesn't need the lower-right corner as territory after killing
the lower left. After B B1 W C2 B C1 W H3 B G3, w gains about 7
points in the lower right but has already lost like 31 in the lower
left, and black wins by 15. Either I'm missing something obvious, or
you overlooked that the lowe
On Jan 23, 2008 7:39 PM, Jason House <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-01-23 at 18:57 -0500, Eric Boesch wrote:
> > I am curious if any of those of you who have heavy-playout programs
> > would find a benefit from the following modification:
> >
> > >
On Jan 23, 2008 3:11 AM, Hiroshi Yamashita <[EMAIL PROTECTED]> wrote:
> 2. Change UCT exploration parameter
> exp_param = sqrt(2.0);
> uct = exp_param * sqrt( log(sum of all children playout) /
> (number of child playout) );
> uct_value = (child winning rate) + uct;
>
On Jan 22, 2008 1:43 AM, Petri Pitkanen <[EMAIL PROTECTED]> wrote:
> Even top MC programs fail to see that a group with 3 liberties with
> no eyes is dead.
A 3-liberty group with no eyes has a 100% chance to die during
playouts unless a surrounding group dies first. 100% chance to die is
as good
In chess, playing the game out to the bitter end can be defensible,
but in go, it isn't. The meaning of the "end of the game" in go is
fluid, but it's not "when it's no longer possible to play a move". In
absolute time limit games, when significant per-move lag exists (which
is true in all human ma
I wrote:
> If (but not only if) ((a XOR c) AND (b XOR d)) == 0 then a collision
> is guaranteed. The probability of this is closer to 2^-32 than to
> 2^-64.
Before anybody else feels the need to correct me here -- to be more
precise, the probability of collision is at least
E(0.5**binomial_variabl
Taking the min of the 8 rotated and reflected values is safe enough.
Yes, the probability density will be eight times higher at the low
end, so you're left with 61 bits and change worth of collision
protection instead of 64. If that's not enough, then you can use a
bigger hash size, as has been men
For what it's worth, "Hall of Fame" can mean anything from the
Baseball Hall of Fame (serious business) to the Mullet Hall of Fame (a
total joke). To me this looks like a pretty clear misunderstanding.
Don and Hideki have both contributed usefully to the mailing list, and
it would be too bad if thi
On 12/11/07, Mark Boon <[EMAIL PROTECTED]> wrote:
> Question: how do MC programs perform with a long ladder on the board?
>
> My understandig of MC is limited but thinking about it, a crucial
> long ladder would automatically make the chances of any playout
> winning 50-50, regardless of the actual
Make sure that you use the -19 argument when starting 19x19 Mogo, and
restart GoGui (in order to restart Mogo indirectly) after you change
the settings. Somewhat confusingly, Mogo does not automatically play
19x19 style just because it receives a request for 19x19 board. Poor
ladder handling and "s
On Nov 27, 2007 8:29 PM, Don Dailey <[EMAIL PROTECTED]> wrote:
> Ian Osgood wrote:
> > Checking the participants, I see that MoGo and CrazyStone were
> > specifically invited. Also playing is a version of GNU Go
> > (presumably), as well as veterans Aya and Katsunari, and two dozen
> > others.
> >
On Nov 24, 2007 10:38 AM, <[EMAIL PROTECTED]> wrote:
> * For liberty values, I use the following equation:
> values[i] = 25000 + (16 * (i+1)) + ((i+1) * (i+1));
> Some bits are constant, some are linear, and some
> are quadratic, which guarantees that the sum of
> up to 4 values
On 11/16/07, John Tromp <[EMAIL PROTECTED]> wrote:
> On Nov 16, 2007 10:05 AM, Chris Fant <[EMAIL PROTECTED]> wrote:
> > > > Neat. Was the 15-bit version for 81 values or 361? At the risk of
> > > > putting my foot in my mouth, I don't think there exist 361 15-bit
> > > > numbers that satisfy minim
On 11/15/07, Chris Fant <[EMAIL PROTECTED]> wrote:
> On Nov 15, 2007 3:20 PM, Eric Boesch <[EMAIL PROTECTED]> wrote:
> > On 11/14/07, Chris Fant <[EMAIL PROTECTED]> wrote:
> > > Based on more recent emails, this may not be useful anymore, but I
> > > h
it. It could use
more thorough tests and more comments, and the class name is lame, but
hopefully it works.
#ifndef _IsOneSum_hpp
#define _IsOneSum_hpp
#include
#include
// Based on ideas of John Tromp, Jason House, and me (Eric Boesch).
class IsOneSum {
public:
/** @param codeCnt: all inputs
Encode each number by swapping base 2 with base 5, without changing
the digits. So binary 11011 (27) is represented as base-5 11011 (756).
This allows you to sum up to 4 such numbers without experiencing
overflow from one digit to the next (since 4 1's adds up to just 4).
Essentially, you are perfo
got
this right -- I'm sort of hurrying to correct it before anybody wasted
too much time trying to decode it. (Sorry, Jason :)
On 11/14/07, Eric Boesch <[EMAIL PROTECTED]> wrote:
> Encode each number by swapping base 2 with base 5, without changing
> the digits. So binary 11011 (27)
On 11/12/07, Petr Baudis <[EMAIL PROTECTED]> wrote:
> Does any frequently playing real-world bot use libEGO? It seems still
> order of magnitude faster, but it looks like that is because it
> simplifies some things too much. For example, its board::merge_chains()
> does not seem to take account for
On 10/17/07, Stefan Mertin <[EMAIL PROTECTED]> wrote:
> Hi, all!
>
> here are the FIRST RESULTS
> of my new 9x9 Computer Go Tournament
> (Osnabrueck, 2007-10-15):
Cool! But Mogo and the other top MC bots are now so dominant at 9x9
that a tournament in which none of them participate is of limited
r
On 10/15/07, Erik S. Steinmetz <[EMAIL PROTECTED]> wrote:
> Greetings all,
>
> I have been looking through the literature (many thanks to Markus's
> wonderful online bibliography) on existing strategies in the opening
> game, and have not found too many articles on the specifics outside
> of a few
On 10/11/07, Ian Osgood <[EMAIL PROTECTED]> wrote:
> I thought Steenvreter only played 9x9 Go. The 19x19 ICGA tournament
> winners were MoGo, CrazyStone, and GnuGo in that order.
How did I mess that up? Thanks for the correction.
___
computer-go mailing
On 10/11/07, David Fotland <[EMAIL PROTECTED]> wrote:
> But the only way to settle this is to do some experiments. I could
> certainly be wrong. If we have a mogo-many faces match on 19x19 cgos, and
> we also have them play for ratings against people on kgs, it would settle
> it.
Mogobot1 and mo
On 10/9/07, Andrés Domínguez <[EMAIL PROTECTED]> wrote:
> 2007/10/9, Eric Boesch <[EMAIL PROTECTED]>:
> > Naive null move is unhelpful because throughout much of a go game,
> > almost every move is better than passing,
>
> I think this is not the point of null mo
On 10/8/07, Tapani Raiko <[EMAIL PROTECTED]> wrote:
> > May sound unpolite. But Deep Blue reached a very
> > important step in IA. They will be known for ever.
> > But, from a research point of view, they didn't much
> > really. It was mainly a technological/technical
> > achivement.
> >
> Maybe th
On 7/28/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > So even though you the playout agent has only 50% probability of
> > playing correctly, the probability that after 2 plys the position is
> > still won is 75%!
>
> going toward a limit of 66.6% as the number of plies increases
That is a
On 6/10/07, Peter Drake <[EMAIL PROTECTED]> wrote:
On Jun 10, 2007, at 7:00 AM, Eric Boesch wrote:
[..snipped...]
> It is also easy to imagine why MC programmers in games with {1, -1}
> payoff sets would discover that the choose-best-average-payoff
> heuristic is not as good as
The UCT heuristic of trying every child of a node once before trying
any child twice is reasonable when the payoff distribution is unknown.
Why try the lever that paid $5 a second time if there might be another
lever that pays $1,000,000? But when the set of possible payoffs is
known to be {1, -1}
On 2/7/07, David Doshay <[EMAIL PROTECTED]> wrote:
On 7, Feb 2007, at 1:35 PM, Don Dailey wrote:
> Although suicide can occasionally be the best move in some
> rule-sets, I think it weakens your program to include it,
At best you are going to get a ko threat, so it requires a pretty
sophisti
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
45 matches
Mail list logo
