Re: [computer-go] Reference Montecarlo TreeDecision Bot.

I am not good at term definition, but I would say RAVE is the algorithm extending AMAF in MCTS, including how to accumulate the counts at each node (trivial extension even though implementation can be tricky), how to combine with UCT (or other move choice), and how to integrate with priors (based

Re: [computer-go] Rave coefficient

On Tue, Jun 30, 2009 at 12:47 AM, Peter Drake wrote: > A while back, Sylvain Gelly posted this code: > > ChooseMove(node, board) { >  bias = 0.015  // I put a random number here, to be tuned >  b = bias * bias / 0.25 >  best_value = -1 >  best_move = PASSMOVE >  for

Re: [computer-go] MoGo and passing

Obviously I should read better the emails before answering. Olivier rightly answered for all versions. Sorry, Sylvain On Tue, Jun 30, 2009 at 7:59 PM, Sylvain Gelly wrote: > Hi, > > Olivier answered for the new version. > On the downloadable version, I don't remember exactl

Re: [computer-go] MoGo and passing

Hi, Olivier answered for the new version. On the downloadable version, I don't remember exactly (almost 2 years back now...), but I think Mogo will still pass if all the other moves are clearly loosing. So it should "understand" somehow Seki situations. If that is correct, the sentence is not comp

Re: [computer-go] Incorporating a prior estimate

2009/5/1 Brian Sheppard : > In reading Sylvain Gelly's thesis, it seemed that incorporating a prior > estimate of winning percentage is > very important to the practical strength of Mogo. > > E.g., with 1 trials, Mogo achieved 2110 rating on CGOS, whereas my > program attempts to > reproduce ex

Re: [computer-go] Fast ways to evaluate program strength.

On Wed, Apr 8, 2009 at 10:46 AM, Darren Cook wrote: >> End game is another issue. MC programs only aim on winning, so they >> endgame is nor perfect in sense human would define it, but perfect >> enough to win if the game is winnable. > > You can modify komi to get the human expert and MC program

Re: [computer-go] Transpositions in Monte-carlo tree search

Hi Mattew, I cannot answer for the current version of Mogo but I can for the one 1.5 years ago. Maybe it still holds. We had a transposition table as it was designed like that from the beginning. However the prior value of the node, was initialized when the node was created and indeed was dependin

Re: [computer-go] How to "properly" implement RAVE?

On Sun, Feb 8, 2009 at 1:42 PM, Petr Baudis wrote: > On Sat, Jan 17, 2009 at 08:29:32PM +0100, Sylvain Gelly wrote: > > A small point: in "PlayoutOutTree", just after "if > > (!played.AlreadyPlayed(move)) {", there should have a > "played.Play(move)&q

Re: [computer-go] How to "properly" implement RAVE?

Hi Issac, You should be more in the range of +200-300 ELO, at least with pattern based playouts. Sylvain 2009/2/1 Isaac Deutsch > By the way, I got about 75 ELO points (1650->1720) with light playouts out > of RAVE. Do you think this is in the expected range? It's not really similar > to the 20

Re: [computer-go] How to "properly" implement RAVE?

On Fri, Jan 30, 2009 at 9:29 AM, Magnus Persson wrote: > Quoting Sylvain Gelly : > > On Wed, Jan 28, 2009 at 10:01 PM, Isaac Deutsch wrote: >> >> And a final question: You calculate the (beta) coefficient as >>> c = rc / (rc+c+rc*c*BIAS); >>> which l

Re: [computer-go] How to "properly" implement RAVE?

On Wed, Jan 28, 2009 at 10:01 PM, Isaac Deutsch wrote: > Hi again ;) > > I found some time to actually implement this stuff. And, this has raised > some small questions. In this part of the code: > > for (j = index; j < moves_played_in_tree.size(); j += 2) { > //stuff > } > for (j = 0

Re: [computer-go] How to "properly" implement RAVE?

2009/1/21 Olivier Teytaud > > Of course you can do put much more clever prior if you are a player and >> know the subtleties of the game. >> > > E.g. patterns extracted from databases - but it's not enough, carefully > tune the coefficients for "empty triangles" (important!) and various other > i

Re: [computer-go] How to "properly" implement RAVE?

Hi, I did not mention here the prior initialization that is done in each node. When you create a node, you can look at all possible move and if a pattern matches (the exact same as in the playout) you initialize rw and rc to 14. If the move saves a capture (same as in the playout), same initializa

Re: [computer-go] RAVE and memory allocation considerations

Hi, You should really look into never deallocate memory (by calling delete/free) but keeping it in some memory pool. I did that for the main objects that you deal with: nodes and "small vectors" (the one you create on the fly to keep the moves that have been played in the playout). It really speeds

Re: [computer-go] How to "properly" implement RAVE?

Good catch :)Indeed it makes no sense with the "*", sorry... Sylvain 2009/1/17 Magnus Persson > I think I found a bug in ChooseMove > > Quoting Sylvain Gelly : > > coefficient = 1 - rc * (rc + c + rc * c * b) >> > > I think this has to be > >

Re: [computer-go] How to "properly" implement RAVE?

Hi Issac, You are welcome, and I am happy there is finally a clearer of implementing RAVE out there. I believe I should have done it much earlier, sorry for that, but "better late than never", no? :) Best, Sylvain 2009/1/17 Isaac Deutsch > > Hi, > > > > Sorry for the slow reply. > > Hi > > I'd

Re: [computer-go] How to "properly" implement RAVE?

and > ishi-no-shita. When I have a little spare time I'll check to see if this > actually makes a difference in playing strength. If there's any noticeable > difference I'll try to modify the code in my reference implementation to > reflect the 'correct' method

Re: [computer-go] How to "properly" implement RAVE?

tor moves_played_out_tree bool black_wins = PlayoutOutTree(&board, &already_played, &moves_played_out_tree) Backup(black_wins, nodes_seen_in_tree, moves_played_in_tree, moves_played_out_tree, &already_played) }

Re: [computer-go] How to "properly" implement RAVE?

Hi, Sorry for the slow reply. After those discussions, I figured out that pseudo code was the fastest clear and not ambiguous way to describe how to precisely implement the algorithm. I needed to find some time to write it. Note that I did not write only the backup phase because to clearly describ

Re: [computer-go] How to "properly" implement RAVE?

2009/1/10 Isaac Deutsch > Hi Sylvain, > > I think it's starting to make sense now. :-) > > > > Sorry to be unclear. I wish we have a white board where we could discuss > > and > > that would sorted out in a few minutes :). > > Several results turn up in a google search ;p > http://www.google.com/

Re: [computer-go] How to "properly" implement RAVE?

Hi Isaac, 2009/1/9 Isaac Deutsch > Hi Sylvain, > > Thanks for your quick answer. > > > > in a nutshell RAVE is basically AMAF adapted for Monte Carlo Tree Search. > > The original paper describing it is > > http://www.machinelearning.org/proceedings/icml2007/papers/387.pdf and a > > paper for "b

Re: [computer-go] How to "properly" implement RAVE?

Hi Isaac, in a nutshell RAVE is basically AMAF adapted for Monte Carlo Tree Search. The original paper describing it is http://www.machinelearning.org/proceedings/icml2007/papers/387.pdf and a paper for "broader audience" can be found here: http://www.lri.fr/~gelly/paper/MoGoNectar.pdf (the picture

Re: [computer-go] Monte-Carlo Tree Search reference bot

What I did (was a "long" time ago, I don't know if it is still used in Mogo), is to compute the m best moves every so often and most of the time just do the max over those m moves. m was on the order of 5, and "every so often" was an increasing function like sqrt or log (I don't remember). That spe

Re: [computer-go] What was the specific design of the Mogo version which beat the pro...

C++ on linux (with a port on windows using cygwin libraries for the binary release) Sylvain 2008/8/13 steve uurtamo <[EMAIL PROTECTED]> > > And what language/platform is Mogo written in; C/C++, Java, Assembly, > PHP, > > etc.? > > This made coffee spray out of my nose (PHP). > > I think that C i

Re: [computer-go] Correction in AGA eJournal...

> the mistaken comment (9 stones in a year, computer superiority real soon) > is getting repeated a huge number of times. > As one of my computer science teacher said: "if your editor has the copy/paste feature, throw it away". It obviously applies to programming and apparently to publication as

Re: [computer-go] What Do You Need Most?

> > You can download for free an "old" version of MoGo (which reached 2k on KGS >> on a 4 CPU machine) at: >> >> >> >http://www.lri.fr/~gelly/MoGo_Download.htm >>

Re: [computer-go] What Do You Need Most?

2008/7/28 Ray Tayek <[EMAIL PROTECTED]> > At 07:53 PM 7/27/2008, you wrote: > >> The traditional programs are around 10 kyu, but the new ones are 2 to 4 >> kyu, >> at least on KGS. I've seen some handicap games against dan players that >> are >> consistent with these ratings. >> > > wow. that's i

Re: [computer-go] Representation of state-action pairs

MoGo has a notion of "internal" node in the tree (as most of the UCT programs I think) and the state-action pairs are only kept for those. Sylvain 2008/7/2 Jason Galbraith <[EMAIL PROTECTED]>: > I've been looking at RAVE (Rapid Action Value Estimate), which MoGo uses. The > score of states durin

Re: [computer-go] batch size and impact on strength

> > This seems to be the case and I still do not really on some level >> understand why. Since with the chinese go rules the board should be >> effectively stateless (exempting ko information) all the information be >> contained in the the current position. Why additional information is needed >> i

Re: [computer-go] MoGo/professional challenge

It was 2 cores 2.6GHz. (intel core2 duo). 2008/3/21, Olivier Teytaud <[EMAIL PROTECTED]>: > > What computing power did have that MoGo at its disposal? > > > 4 cores, 2.4 GHz. > > ___ > computer-go mailing list > computer-go@computer-go.org > http://ww

Re: [computer-go] f(score) instead of sign(score)

> So MoGo may be > using a floating point function to estimate the score of a playout, > otherwise there would be no reason to use floating point. But I may be > guessing wrong. Maybe they can tell us ? We don't (at least up to the release, I don't know everything they are doing now). Using the

Re: [computer-go] 13x13 study. Time and memory

2008/2/22, Alain Baeckeroot <[EMAIL PROTECTED]>: > Le jeudi 21 février 2008, Don Dailey a écrit : > > If you look at the table you will notice that going from level 4 to > > level 11 (which is 7 doublings and should take 128X longer) only takes > > 59.43 X longer. > > > > So if we plot 9X9 r

Re: [computer-go] 13x13 study.

Hi Don, 2008/2/21, Don Dailey <[EMAIL PROTECTED]>: > > If you look at the table you will notice that going from level 4 to level > 11 (which is 7 doublings and should take 128X longer) only takes 59.43 X > longer. > Mogo's "stop early" heuristic works better at longer levels. That is actually

Re: [computer-go] Re: MoGo 64 bits, mogo double

Hi Hideki, Isn't possible to just redirect stderr? Best, Sylvain 2008/2/14, Hideki Kato <[EMAIL PROTECTED]>: > Hi Olivier, > > New versions of MoGo don't put log files, which was very useful to > study. Don't you have plan to release such versions put log files? > > -Hideki > > Olivier Teyt

Re: [computer-go] Re: computer-go Digest, Vol 43, Issue 8

> >Thinking a little more about it, I think we have to add an hypothesis > >which is that, for a given move, the number of AMAF updates if < alpha > >(nb total UCT updates), with alpha < 1. That seems to hold for most of > >the updates (with alpha close to 0.5), but there may be cases where it > >d

Re: [computer-go] Re: computer-go Digest, Vol 43, Issue 8

> As far as I see, > if RAVE gives constant value 0 to one move, it will never be tested if > other moves > have non-zero AMAF values. > > A move > with "real" empirical probability 0 of winning and AMAF value of 0.01 > will always be preferred to a non-simulated move with AMAF 0.0, whatever > may

Re: [computer-go] Re: computer-go Digest, Vol 43, Issue 8

A new position is always visited unless the leaf of the tree is the end of the game. In that case, one player always win, so the other always win. Then, the losing player will explore all the other moves to avoid the sure loss. If all moves are still loosing, that will propagate to the move before,

Re: [computer-go] Re: computer-go Digest, Vol 43, Issue 8

> So: > - theoretically, I don't see any reason for mogo to be asymptotically >consistent I think it is still asymptotically consistent: - at "each" (or every n) iteration you add one node. - if the node is at the end of the game, the evaluation is perfect. - you play the move with the highest

Re: [computer-go] MoGo 64 bits, mogo double

Hi all, I added those downloads on the MoGo's download page: http://www.lri.fr/~gelly/MoGo_Download.htm Cheers, Sylvain 2008/2/9, Olivier Teytaud <[EMAIL PROTECTED]>: > For people requesting mogoRelease3 without the bug for long computation > times due to a float instead of a double: > > http://

Re: [computer-go] More UCT / Monte-Carlo questions (Effect of rave)

Hi Erik, > In the ICML version of UCT without RAVE, you did not use your First > Play Urgency, right? > > I think that using FPU has an effect similar to what others reported > with their progressive widening. From what I've seen it looks like > plain UCT, without FPU or progressive widening, has

Re: [computer-go] More UCT / Monte-Carlo questions (Effect of rave)

Hi Erik, > Thanks for your reply! How do you like your new job? Do you miss CompGo? ;-) I like it very much thanks. Do you want to come? ;). I miss computer go and all of you, but I read the list (not all) time to time, so I have some remembers :). I just can't do too many things at the same time.

Re: [computer-go] More UCT / Monte-Carlo questions (Effect of rave)

Hi Erik, > (1) They compared Rave to plain UCT. If they would have compared it to > a more sophisticated implementation (like the best Mogo before Rave) > they probably could not have shown a spectacular improvement. The best Mogo before Rave was very close to plain UCT with the sequence-like sim

Re: [computer-go] 9x9 study rolloff

limit is the largest tree allowed after collection > and the --limitTreeSize is how big it must get before collection? > > - Don > > > > > Sylvain Gelly wrote: > > Hi, > > > > With such a large number of playouts, the tree size limit (and so > > heavy prun

Re: [computer-go] 9x9 study rolloff

Hi, With such a large number of playouts, the tree size limit (and so heavy pruning) is certainly a possible hypothesis. The simplest way to test it would be to run the same MoGo_17 or _18 with a much bigger tree (taking more memory). --collectorLimitTreeSize is by default 40 (number of nodes)

Re: [computer-go] 19x19 Study

No problem for me. I did not want to multiply the number of versions not to confuse people. With the double version, don't forget it will increase the memory footprint for a given number of nodes. Sylvain 2008/1/30, Olivier Teytaud <[EMAIL PROTECTED]>: > > I can provide a new release with double

Re: [computer-go] 19x19 Study

ow many simulations would lead to this situation? > > > > Terry McIntyre <[EMAIL PROTECTED]> > - Original Message > From: Sylvain Gelly <[EMAIL PROTECTED]> > To: computer-go > Sent: Tuesday, January 29, 2008 10:36:38 AM > Subject: Re: [computer-go] 19x1

Re: [computer-go] 19x19 Study

> > between pairs > of programs, you can get a more and more confident belief about > the actual ELO. so they'll converge to the correct values, and > should do so reasonably rapidly. > You are right. My point was that here we have only 1 fixed rating, which is very low, and all the higher levels

Re: [computer-go] 19x19 Study

> > but not linearly and you can see a nice gradual curve in the plot. > > Now we have something we can argue about for weeks. Why is it not > mostly linear? Could it be the memory issue I just mentioned? > Hi Don and all participants to that study, that is very interesting! The memory constr

Re: [computer-go] MoGoRel3_3550pps

MoGo expects a gtp command to override it. Cheers, Sylvain 2008/1/13, Michael Williams <[EMAIL PROTECTED]>: > > Sylvain Gelly wrote: > > > > The reason I said that was this behavior from mogo. If I start it > > without that switch and as for a move, it alloc

Re: [computer-go] MoGoRel3_3550pps

> The reason I said that was this behavior from mogo. If I start it without > that switch and as for a move, it allocates 20 seconds. If I then issue a > small > time_left command and ask for another move, it allocates a much smaller > amount of time. Here is the output: > > Because you give a t

Re: [computer-go] Sylvain Gelly thesis in english

> > >Google finds it: > > >http://tao.lri.fr/Papers/thesesTAO/SylvainGellyThesis.pdf > That is NOT the latest version. Please at least let me put the latest version on my web site, it took me so long to correct it :). Sylvain ___ computer-go mailing list

Re: [computer-go] MoGoRel3_3550pps

2008/1/10, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > Hi Sylvain, > Have you finished your thesis? We are eager to read it:-) Hi, Yes I did! :).It is not on my website, but will (soon?). However, you should not be so eager to read it :) Cheers, Sylvain On 1/10/08, Sylvai

Re: [computer-go] MoGoRel3_3550pps

> > It looks like MoGo does respect the time_left commands from GTP, so I > don't think the totalTime parameter is required in this case. > What do you mean? If you don't put --totalTime, then MoGo indeed ignores time_left. If you put --totalTime, then it respect the time_left. Cheers, Sylvain ___

Re: [computer-go] MoGoRel3_3550pps

Hi, I guess the public version of MoGo was designed with a > focus on 9x9 and not 19x19. It was not more on 9x9 that 19x19, it was more or less the best settings of MoGo against gnugo at the moment I left the developpement (early september) for both 9x9 and 19x19. Or is there something else I s

Re: [computer-go] low-hanging fruit

> > You should be using area scoring only and if you are playing handicap > games then either YOU or MOGO is not counting them the same. Or > perhaps Mogo has a bug in the handicap code. > MoGo uses KGS handicap counting (add 1 point to white for each handicap stone) if the GTP set_handicap_st

Re: [computer-go] MoGo pondering

Hi, It just build the tree as usual, thinking as the opponent. 2007/11/6, Chris Fant <[EMAIL PROTECTED]>: > > Could Sylvain (or anyone who knows) talk about MoGo's pondering > strategy? Does it just build the tree as usual or does it speculate > on some number of moves and hope that the opponent

Re: [computer-go] RAVE in MoGo paper

Hi, 2007/10/8, Benjamin Teuber <[EMAIL PROTECTED]>: > > Hi everybody - especially Sylvain =) > > I'm wondering whether the formula to determine the balance between RAVE > and UCT, > beta = sqrt(c / 3 * parentVisits + c), > has any mathematical background - or is it just a best guess for something

Re: [computer-go] Update of MoGo binary release, and windows version available!

Hi, Yes you can: --nbTotalSimulations 3000 Once you set this option it ignores all other time settings. Cheers, Sylvain 2007/10/7, Yamato <[EMAIL PROTECTED]>: > > Sylvain, > > Can I set the number of the simulations per move instead of the > thinking time? (like "--simulations 3000") > If possi

Re: [computer-go] Mogo: nakade

gt; -Original Message- > From: Sylvain Gelly <[EMAIL PROTECTED]> > To: computer-go > Sent: Fri, 5 Oct 2007 5:48 am > Subject: Re: [computer-go] Mogo: nakade > > > I set 30 second playing > > time, but often it takes up to couple minutes for a move. > That is n

Re: [computer-go] Mogo: nakade

> I set 30 second playing > time, but often it takes up to couple minutes for a move. That is not normal, could you post the command line you use? Cheers, Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman

Re: [computer-go] Mogo: nakade

Hi Darren, Thank you for playing (I hope you enjoyed :)) and your report. > Sylvain, can you explain more about why it has this particular weakness? What you describe is exactly the issue I describe in the FAQ. >From my analysis this come from the fact that the simulations are more likely to make

Re: [computer-go] IEEE Spectrum article by Deep Blue creator

Hi, > Has anyone else done scaling experiments with 19x19 and UCT? > I did some months ago, and reported them in that list with the title "19x19 Go, scalability with time vs handicap" (http://www.mail-archive.com/computer-go%40computer-go.org/msg02775.html) The results are "old", but now everyon

Re: [computer-go] Mogo: tree preservation

Hi Darren, It preserves the tree if and only if you add: --pondering 1 If you don't want to use pondering, but you still want to keep the tree between moves, add --keepTreeIfPossible 1 (not documented, and from my memory, it may be not the right option :p) Hoping this helps, Sylvain 2007/9/28,

Re: [computer-go] Re: Update of MoGo binary release, and windows version available!

ime 300" for example. I guess some other settings than time > are necessary. > > So, my question is what setting allows Windows version being the same > strength as KGS version? > > Regards, > Hideki > > Sylvain Gelly: < > [EMAIL PROTECTED]>: > >Hi all

Re: [computer-go] Re: Update of MoGo binary release, and windows version available!

Hi Hideki, The Windows version, however, seems much weaker than MoGo that running > on KGS these days on 19x19, even giving much longer time setting such > as "--time 300" for example. I guess some other settings than time > are necessary. > Sorry, you are right the 19x19 settings always put th

Re: [computer-go] Update of MoGo binary release, and windows version available!

Hi Gilles, yes they are some problems to use MoGo with Drago. The main issue is the > initial message written to stderr as guessed by Dave. Actually, Drago > handles incorrectly stdout and stderr in the same way but this is easily > corrected. Good news! I have uploaded a patch for using MoGo

Re: [computer-go] Update of MoGo binary release, and windows version available!

Hi Dave and thanks, > Drago works well for Gnugo and also for my program. Mogo starts but then > exits prematurely with a message from Drago "abnormal termination of > engine". :-( > One thing, when I run it from the command line, it spits out a lot of > non-gtp format diagnostic informati

[computer-go] Update of MoGo binary release, and windows version available!

Hi all, you can find here: http://www.lri.fr/~gelly/MoGo_Download.htm an update of MoGo's release, especially binary for non pentium4 compatible processors, some other options explained, and maybe more interesting, an option for time management (I stupidly did not think that people would use MoGo

Re: [computer-go] Binary release of MoGo

Hi Jacques, 2007/9/17, Jacques Basaldúa <[EMAIL PROTECTED]>: > Hi Sylvain, > > Any news about the Windows release? The release time is closer now than before :) > It doesn't need to be fast. It > doesn't even need > to be multithreaded. It is for research only. We can believe that on a > quad cor

Re: [computer-go] Binary release of MoGo

Hi Hideki, > Some computer-go friends in Japan have reported that even current > binary of MoGo doesn't work on Athlon XP or Celeron. Both (and > Pentium III) have no SSE2 instructions while Pentium 4 has. Ok, I have to compile for older processor too then (I did not expect so old proc were stil

Re: [computer-go] Binary release of MoGo

Hi Edward and all, > I am very interested in a windows binary to use MoGo as an > extra sparring partner, (I cannot use linux at this moment), > I do not mind if the binary is slower, Maybe distributing a windows version only for known people is possible. I will do it ASAP, but I have to reboo

Re: [computer-go] Binary release of MoGo

Hi Markus, Hi all, I updated the package to fix the issues you get and some other minor ones. Please update before reporting a problem, and please report any further problem :-). > I don't know about Ubuntu, but the default GCC configuration on Fedora > does not set CPU-specific compiler options,

Re: [computer-go] Binary release of MoGo

> I didn't know you HAD to type a level option. Yes, sorry for that user NON-friendly behavior. It is simply an historical behavior, and I wanted to change the less number of things for this release. I will at some point add that to the FAQ :). > This is all quite a bit confusing Sorry again abou

Re: [computer-go] Binary release of MoGo

> It doesn't matter - if I do --19 the same behavior, I can not longer > type gtp commands in a shell - it goes into self-training. That is not normal. You mean you typed: ./mogo --19 and it does not go to gtp mode? > If I start like this: ./mogo --nbThreads 2 > It ALSO goes into self-tra

Re: Solved! Re: [computer-go] Re: Binary release of MoGo

> auto-numbering in GoGui prepends all commands with an integer ID, > which is sent to the program and should be used by the program in > its response, see the GTP specification. Ok, I did not know that, thanks. So that part of GTP is simply not supported in MoGo :). Cheers, Sylvain _

Re: Solved! Re: [computer-go] Re: Binary release of MoGo

n I turned off the auto-number > feature, mogo worked fine. > # Settings -> Configure Shell -> Auto number > > Cheers, > Hideki > > Sylvain Gelly: <[EMAIL PROTECTED]>: > >> I guess the search path you've coded is something wrong or different >

Re: [computer-go] Re: Binary release of MoGo

> I guess the search path you've coded is something wrong or different > depends on the distributions. The "search path" is simply "." > I'd like to suggest to use some > environment variable dedicated to mogo. I think the recent version of gogui let you define the "working directory". Also, as Gu

[computer-go] Re: Binary release of MoGo

Hi all, Thank you for all your comments and reports, and I am pleased some of you are happy to use it. Please feel free to share the links, especially for players who do not read this list. I am sorry it does not work for some of you. I will look into it as soon as I can. BTW, I tried to answer e

Re: [computer-go] Re: Binary release of MoGo

> I think gogui is in fact looking for files in the directory from which > it is launched. Try this to copy the opening database in this directory. Yes exactly, thank you Guillaume for explaining better than I can :p > It runs perfectly on an Opteron 2.6GHz. Good! > But not on a Power5+ processor

Re: [computer-go] Binary release of MoGo

> Is there a option like gnugo's "--capture-all-dead"? > In my test(./mogo --9 --time 1), seems mogo passed when not capture > alldead stones. As this release is mainly for humans to play, it is set to play against humans, so passing as soon as the opponent passes and it is "safe" to pass. If

Re: [computer-go] Binary release of MoGo

> when I run the Linux exeutable on my Fedora 8/Athlon XP, I get a > coredump: > > $ mogo --9 --time 12 > Load opening database opening succeed (nbEntries=618) (nbIllegalMoves removed > 0) > tried to open opening, success 1 > Illegal instruction (core dumped) > > could it be that it is compiled for

Re: [computer-go] Re: Binary release of MoGo

> >> tried to open opening, success 0<-- in grey > >Here it does not find the file, because the file is with the binaries > >and gogui (at least your version) looks into the gogui/bin directory. > >But that does not prevent MoGo to work. > > I guess so, as when I added "--us

Re: [computer-go] Binary release of MoGo

> Well, I'm hoping for a Mac version someday... Hopefully it will happen. As I don't have a Mac, I rely on external help. I'll let you know :). Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/

Re: [computer-go] Binary release of MoGo

> I'm a little confused. If I operate with no parameters it works ok, No parameters means --19 > but if I do ./mogo --7 (for instance) it goes into some kind of > self-training mode. Did you see a --7 option on the manual? :-p There is no "--7" option, nor a "--13" one. You should put a --9

Re: [computer-go] Binary release of MoGo

2007/9/10, Don Dailey <[EMAIL PROTECTED]>: > The command line parameter to change board size does nothing. > > I tried: > >./mogo --19 >./mogo -19 > > and it only seemed to want to play on 9x9 boards.Am I doing > something wrong? As I explained earlier in an answer, the command line

Re: [computer-go] Binary release of MoGo

> Have you tried Visual C++? > http://msdn2.microsoft.com/en-us/express/aa975050.aspx The thing is that VC++ does not have the pthread library. Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/

Re: [spam probable] Re: [computer-go] Binary release of MoGo

2007/9/10, David Stafford <[EMAIL PROTECTED]>: > What are the options for someone who would like a dan-level opponent (even if > it's 9x9) > but doesn't have a Linux system currently? Are there choices other than > MoGo? If not, > I'm willing to build a Linux box but I have some questions: > >

Re: [computer-go] Re: Binary release of MoGo

> I had a similar issue where pthread/gcc/cygwin combination produced a very > slow application. I had better success with Visual C++ and Boost (for > portable threads). You are right, I should have used Boost for the threads... Unfortunately, I used pthread, and that mean that the threading part

Re: [computer-go] Re: Binary release of MoGo

> BTW, MoGo doesn't work well with gogui 0.9, Fedora Core 5 and Core 2 > Quad system. Really? Argh :'( > 00:00 1 name > tried to open opening, success 0<-- in grey Here it does not find the file, because the file is with the binaries and gogui (at least your version) looks

Re: [computer-go] Re: Binary release of MoGo

> Try MinGW (and MSYS). MinGW has GCC ver. 4.2.1. > http://sourceforge.net/project/showfiles.php?group_id=2435 Yes, I saw that and tried. But the thing is that MoGo use pthread library for multitreading, and, as far as I know, MinGW does not provide pthread (does it?). It is why I needed cygwin.

Re: [computer-go] Binary release of MoGo

2007/9/9, Brian Slesinsky <[EMAIL PROTECTED]>: > Are there any plans to release the source? I don't think so. Plus, some will work on MoGo source code, so it is their decision, not mine. > Perhaps someone else will figure out how to port it. Well, it actually builds and work on windows, "only" the

[computer-go] Binary release of MoGo

Hi all, I am pleased to announce a binary release of current version of MoGo. It is specially designed for players but of course it may be interesting for some of you as a benchmark. You download it and see the instructions there: http://www.lri.fr/~gelly/MoGo.htm Of course, please feel free to t

Re: [computer-go] Slides for Villach-EC Lecture

Hi Chrilly, It was always the goal of McCarthy and his followers to simulate and to surpass the human mind. (...) UCT has nothing to do with human Go. It has some similarity to the behaviour of ant-collonies (its not in the technical sense an ant-colony algo). It was never the goal of AI to expla

Re: [computer-go] Slides for Villach-EC Lecture

Hi Chrilly, I am sorry about your fight with a dog, and I hope you are ok! I read your slides: interesting point of view, whereas you seem a little frustrated. Thank you for sharing your opinion. However, I have to disagree with this statement: "UCT: Complete Antithesis to AI-approach" I reall

Re: [computer-go] Why are different rule sets?

Hi Chrilly, Take a look at this list, there are already maybe more than 100 posts on this subject. While I agree with you, just don't worry, almost all computer go games are with the same set of rules, just ignore the rest. Cheers, Sylvain 2007/7/12, chrilly <[EMAIL PROTECTED]>: I am playing c

Re: [computer-go] Explanation to MoGo paper wanted.

Hi David, >> (...) I cannot imagine that progress will be >> made without a great deal of domain knowledge. > Depending on what you exactly mean I disagree. I mean progress by the standard usually applied to computer Go: programs that can beat 1D humans on a full board, and then get better. Fo

Re: [computer-go] Explanation to MoGo paper wanted.

Hi, > I'm on the other side of this issue. In my opinion all kinds of go > knowledge are fair game and I'm rather disappointed that so small > amounts of domain specific knowledge have been merged with the UCT > search approaches. > I agree. I really do not understand why using domain knowled

Re: [computer-go] 9x9 games wanted and the next big challenge

Hi Chrilly, 1) there are database of thousands of professional games for few dollards. There are not 9x9, but (i) making database is not making progress in the field, it is just having some temporary advantage in tournaments. (ii) Opening is much less important in Go than in Chess, it is why we a

Re: [spam probable] [computer-go] scalability study - final results

Hi Don, This is a very interesting study! Sylvain 2007/6/25, Don Dailey <[EMAIL PROTECTED]>: Someone just reminded me of the scalability study I did a few months back and I reported that I would continue to run it for perhaps a few more weeks. I did run about 20% more games, but the data was

Re: [computer-go] MoGo paper at ICML

Hi, In the paper you only present results of UCT_RAVE with the MoGo default policy. Did you run tests with UCT_RAVE using "pure" random playouts too? Yes we did, and the improvement was also huge, but I don't remember the exact results. I'm curious because I've tried millions ( well, it fee

  1   2   3   >