Re: [computer-go] Dynamic Komi's basics
Hi Le 11/02/2010 à 10:32, Le Hir Matthieu a écrit : Hi, From what I think I understood, dynamic komi is supposed to try to keep the game more even. The dynamic komi is a bias in the evaluation in order to inform the bot that the game is balanced, and prevent it beeing blinded by the false feeling of large win in the beginning of a high handicap game. Else with black and 9 stones the bot would think i (bot) am ahead, just take it easy, this game is won, whereas it is not, the 9 stones are needed, and we human know that white will slowly but inexorably catch up. When the bot plays white, this is less a problem, as montecarlo bot will correctly play safer and safer as the game advances. Maybe it could help, by reducing the risks taken? If the computer is black, playing at 9 handi, will the burden komi ( negative) be 9 x - 7,5 ? - 67,5 ? It sounds highly improbable. On the other hand, 9 handicaps are supposedly giving an advantage of 90 to 120 points, so my natural thought would be that the bot would give itself at least a negative komi of that many points ? Yes this is the idea. The problem is to find the right balance, and not be slow when the bot aims at being safe, and not force the bot to take unneeded risks (you know better than me the pb slow/thick, thin/light, safe/crazy) .../... I am going to play a series of high handicap games ( as white) against pachIV on kgs, that explains why I'm curious to know about how this komi-stuff works precisely. no idea how/if this is implemented in different bots. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Pachi/fuego GnuGo hybrid
Le 18/01/2010 à 10:54, Petr Baudis a écrit : it would be great to share other information like LD and semeai critical moves; perhaps GNUGo even provides interface to get these as well. yes, via gtp you can easyly see in gogui :-), and maybe more with gnugo tool (regress.pike ?) Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Open source real time Go server
Le 18/01/2010 à 18:37, terry mcintyre a écrit : My pet peeve is the KGS score estimator, which is often wildly wrong. The best thing to do would be to remove the score estimator which prevent people from thinking. I bet there would be much less stupid chat during games whithout it :) Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] (no subject)
Le 04/01/2010 à 14:19, Nick Wedd a écrit : I have discussed these extra events in the past, and received feedback here; which, unfortunately, I have forgotten. So please, anyone who is interested, make your suggestions now. As a spectator i would like an Hanh tournament on 19x19, not too fast (~30 min each). I can run one bot if needed (gnugo fuego) Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] (no subject) wish hahn
Le 04/01/2010 à 18:09, Petr Baudis a écrit : I don't think Hahn tournament would be that interesting, As a physicist i like to experiment first, and think later, to understand what happened, which obviously was not foreseen ;-) I believe it will reveal some hidden aspect of the stronger engines, and for sure it will be *fun* to see stronger bots destroy weaker ones, (MC-RAVE end-game of strong bots is boring on 19x19) it would require some extensive modifications of especially the top programs No need to be perfect Hahn. Changing the aim to max_points seems to be just a change in metrics, it does not looks like very complicate and involve a lot of work in the tournament setup as well. This is solved by Nick Wedd (And, ~30 min each _is_ quite fast on 19x19. ;) I'll help you to convince Nick to give more time to your bot :) Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fuego parameter question
Le 06/12/2009 à 01:05, Darren Cook a écrit : You also need to set max_nodes quite high or Fuego will keep stopping to clear out its tree. I'm setting it to max_games*50, so for 8000: uct_param_search max_nodes 40 According to my notes fuego uses 75M + (65M per million max_nodes). So 15 million nodes will use about 1Gb. (That is on 32-bit linux.) I miss something: max_games and max_nodes are correlated or not ? why do you chose max_nodes = max_games*50 ? is it boardsize dependent ? I guess that either max_games or max_nodes should be specified, but not both (the first reached is the limiting factor ?) (a new param max_memory appeared recently in trunk, i suppose it is the new human understandable limit) So my config is stupid for fuego 0.4 :-) max_games=16.000 max_nodes=15.000.000 (1GB RAM on ia32) i attached my documented config file (with all the options and documentation i found in the list and on fuego.sf.net) Thanks. Alain ### # Configuration parameters for fuego # # see : # http://fuego.svn.sourceforge.net/viewvc/fuego/trunk/doc/manual/index.html # http://www.cs.ualberta.ca/TechReports/2009/TR09-09/TR09-09.pdf # # This file contains GTP commands # ### ### # Game rules and settings (may be changed by GUI) ### # Go Param # There is one parameter that is interesting to users: # Timelimit is the fixed time limit in seconds to use for a move generation, # if no time settings are used for the game. The default is 10. go_param timelimit 99 # Change the rules used in the game. # What rules are used by Fuego depends only on the settings in Go Param Rules. go_param_rules ko_rule pos_superko # Go Param Rules # WARNING : Note that entering text in the rules text entry of GoGui's game info dialog is # for storing this information in the file only. It is not transmitted to the Go program # because there is no GTP standard command for setting the rules. # What rules are used by Fuego depends only on the settings in Go Param Rules. go_rules kgs ### # uct_param_player ### # uct_param_player ponder #Whether to continue the search while waiting for the opponent's move. The default is 0 (=no). # # If this is set to 1, uct_param_player reuse_subtree must also be enabled. uct_param_player ponder 1 # uct_param_player reuse_subtree #Whether to reuse the reusable part of the tree from a previous move generation. The default is 0 (=no). # # Setting this to 1 (=yes) is required if pondering is used, but it also gives a small improvement in playing # strength if pondering is not used. uct_param_player reuse_subtree 1 uct_param_player max_games 16000 # uct_param_player ignore_clock 1 # Guess : take remaining time into account (to prevent time loss and try to use all available time for a game) # Guess2 : go_param timelimit N still controls the time for each move, even if ignore_clock is set to 1. uct_param_player ignore_clock 1 ### # uct_param_search ### # uct_param_search number_threads # The number of threads to use. The default is 1. # # This should be set to the number of cores or CPUs available on the system for # maximum performance. It has been tested with up to 8 cores. uct_param_search number_threads 2 # uct_param_search lock_free # Whether to enable lock-free multithreading. The default is 0 (=no). # # You should enable this on modern Intel or AMD CPUs (with IA-32 and Intel-64 architecture) # if more than two threads are used. # Note that without lock-free search the performance of Fuego can even decrease # if you use more threads. The maximum number of threads that can be used # without a decrease of performance, if the lock-free mode is not used, depends on the board size. # Petr Baudis said : (it makes it) faster - there should be no strength difference if you # limit games number, not time. uct_param_search lock_free 1 # uct_param_search max_nodes(obsoleted by max_memory after 0.4 ?) # Determines the maximum number of nodes in the search tree, and thus the maximum memory to use. # The default is 400. # # The node size is 48 bytes on 64-bit computers (and 32 bytes on 32-bit computers). # Fuego maintains two search trees internally. # You should use about 10 000 000 nodes per GB main memory that you want to give to Fuego on 64-bit computers # (and 15 000 000 per GB on 32-bit
Re: [computer-go] Re: Hahn system tournament and MC bots
Le 26/11/2009 à 10:08, Vlad Dumitrescu a écrit : On Thu, Nov 26, 2009 at 00:43, Darren Cook dar...@dcook.org wrote: When I read this it reminded me of experiments I tried before to pass more than one piece of information up from the leaf nodes of a (min-max) tree. E.g. a territory estimate and an influence estimate. I gave up as it got too complex to handle incomparable nodes (e.g. move A gets more territory, less influence). I remember having a really good reason to want to delay reducing multiple features to a single number , but it is all a bit fuzzy now. Does this type of search have a name, and any associated research? It feels like something that should be covered by some mathematical area, but I spent half of last night searching in vain. It's possible that I just didn't understand what those papers said. One issue is that when the value at a node includes other features than win/loss information, then the game is no longer zero-sum and then maximin should be used instead of minimax. Also the linearization of these feature's values should be done differently for each player (even if we might choose to play a little recklessly ourselves, for the opponent we should probably use the safest line of play). Maybe have a look at signal processing, using higher-orders statistics ? mean std-deviation = order 2 (or 1 ?) ... win by 10 with std = 100 seems much less secure than win by 5 with std=1 but maybe this is included in modern bots (i stopped at naive MC + AMAF) It's far in my memory, so i can't tell you much more Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Hahn system tournament and MC bots
Le 25/11/2009 à 12:39, Vlad Dumitrescu a écrit : On Wed, Nov 25, 2009 at 12:04, Nick Wedd n...@maproom.co.uk wrote: A program to play Hahn Go has no reason to calculate probabilities, it should just make the biggest move it can. Ah, okay, now I understand your point of view. Thanks for explaining. Making the largest move available is just one possible strategy to attain the goal of ending the game with the most points scored. A more general strategy is to weigh the moves' size with the risks they can backfire. This is taken onto account in the tree. If playing one move lead 10% of time to +10, and 90% to -20, the resulting value is -17 (of course with the bot evaluation/playout) Evaluating the risks is probably just as difficult (or maybe more difficult) than evaluating a move's value (which is difficult enough), but IMHO just being greedy is not helping one's game. Might it be for this reason that MCTS doesn't show good results when trying to maximize score? They don't try to maximise score, that's why they are not good at it :-) Best regards Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Hahn system tournament and MC bots
Le 25/11/2009 à 15:11, Vlad Dumitrescu a écrit : What I am considering is a way to analyze a list of moves, each having in turn a value that is a list of expected outcomes and their respective estimated probabilities, and to sort the moves by the expected outcome in the context of a given risk strategy. In practice, this means that the strategy is an algorithm that takes an outcome/probability list and converts it to a number, so that it can be compared to the other values. The algorithm in the example above is a linear weighted sum. Normal MC programs look only at the number of positive and negative outcomes. These are only two possibilities. Yes its the mathematical expectation of the aim of the game the bot is playing: score or win respectively correspond to the Hahn game or Go game. If using a more generic approach, the strategy can be parametrized and optimized (both offline and online), hopefully resulting in a better gameplay. I don't understand how anything could be better than the expectation, exept if you have additional information. For example mogo1 does not know bulky-five-dead-shape and has lots of problem to find it is dead (before being killed). So when playing against mogo1 you want to bias the estimator in the branches were bulky five appears ? Or did i totally misunderstood you ? Best regards. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Hahn system tournament and MC bots. and KGS tournament ?
Le 24/11/2009 à 00:24, dhillism...@netscape.net a écrit : For my fast/dumb neural net engine, Antbot9x9, I coevolved the weights using a similar tournament system. Each individual played a number of games against all the others, round robin, and the score was the sum of points for all of its games. Some observations/claims: Non-transitive effects seem more visible. Consistently overplaying garners extra points from weak opponents but needlessly loses extra points against strong ones. It becomes more important to play your opponent as well as the board: if you think that you have him outmatched, take some risky gambles, overplay. Every game in the tournament matters, right till the end of that game. I think it could be interesting to try some bot tournaments like this. It might be fun to watch. When the strongest bot was playing the weakest, even near the (painfully one-sided) end of the game there would be an element of suspense. The stronger bot would (or should) be trying to swindle a few last extra points it didn't deserve, and the fate of the tournament could hinge on it. - Dave Hillis In another thread Nick Wedd wrote: The December KGS bot tournament will be 9x9. I guess that if a cluster-Zen competes in that (I am hoping it will), it will be unbeatable. The existing pattern of KGS bot tournaments (see http://www.weddslist.com/kgs/future.html) means that the January one will also be 9x9, then February and March will both be 19x19. ... Is there a possibility for an Hahn tournament on KGS ? maybe with simplified rules: one point on board is one point in tournament ( (c) R.Jasiek ) If i understand what D.Hillis said, it can put in light some hidden aspects of the bots, and should be more spectacular than the wise-sure-win style of MC *Go* bots. And i guess it does not require lot of change in the code, only points instead of win/loss in the evaluation function should do the trick. I hope several strong programmers would like to participate, for fun and maybe discover several things in their code by pushing it to unusual limits. Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Hahn system tournament and MC bots
A Go tounrmaent with Hahn system has been retransmeted on kgs/eurogo TV With these rules, the actual count makes a difference (as opposed to just win/lose) Winning by 40.5gets 100 points ...... Losing by 40.5gets 0 point see http://senseis.xmp.net/?Bangneki http://www.suomigo.net/wiki/HahnSystem How current MCx bots can handle this kind of rules ? The traditional safe way would ensure 60 points, but trying crazy things (when losing) would cost a lot if the result ends by losing by resignation or -40.5 What is the impact for chosing the best move ? (choose the greediest amongst several with highest winning rate ?) Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Elo move prediction
Le 19/11/2009 à 09:35, Seth Pellegrino a écrit : Hello all, I'm working on an implementation of Rémi Coulom's Elo-based move prediction algorithm[1], and I seem to be running into efficiency issues. Very simple question to start: What is the programmation language ? Do you use 1d representation of the board (a list) or 2d ? 1d is much faster and i guess all efficient bots use it. You can have a look at brown random player (from G.Farneback) http://www.lysator.liu.se/~gunnar/gtp/brown-1.0.tar.gz it was built to provide gtp implementation, and legal random moves. my 2 cents. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Rated bots on KGS
Le 19/11/2009 à 13:10, Mark Boon a écrit : On Nov 19, 2009, at 1:24 AM, Nick Wedd wrote: So a bot which appears on KGS, gets rated as 25k, plays hundreds of games, and then improves to 15k, is going to do a lot of damage to the rating system. What happens when all those beginners that start at 25k improve, many of them well beyond 15k? afaik , there is a K factor linked to the confidence in the ranking, and add inertia (strong dans moves slowlier) I guess putting this K to espilon (or zillions) should solve the problem, allowing bots to have a rank without any impact on the rest of the pool. It might be a one line change (if bot K=0) Also adding a question mark for bot's rank to indicate it is not so good... Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Joseki Book
Le 10/11/2009 à 15:56, Stefan Kaitschick a écrit : Ofcourse I can't say what a correct opening is. What I can say though, is that if bots are onto something with their strange openings, at this point it's by accident. It is not by accident, it is consistent with what the bot can read. They really do underestimate the chances of an invader. Maybe it is obvious for a player stronger than the bot, but i am 1 stone weaker than zen19 and i have hard time to beat it, even if i know it will play cosmic style. And i find it is very strong at sacrifying something to go back to its beloved center That goes for moyo parachute invasions as well as corner invasions. I think that's because the likelyhood of randomly playing killing moves is greater than the chance of randomly playing shinogi moves. Disproving the initial hypothesis about such an invasion is an unsolved task. David Fotland made a similar comment about semeais that are incorrectly evaluated because the losing side can play its moves in any order while the winning side cannot. I have the same problem during my games against humans :) It seems 1d bots have more or less the same problems as 'cosmic 1d' players. Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Joseki Book
Le 09/11/2009 à 08:04, Jessica Mullins a écrit : Hi, I am wondering what is the best way to build a Joseki Book? I am a student at Lewis Clark College and am working with Professor Peter Drake to build a Joseki Book for the program Orego. Right now I am extracting moves from professor players and saving those into a database. Then if during game play a position is contained in the database, play the response move like the professional. I am just wondering what other people have done to build a Joseki Book, or if anyone knows of any papers that might be helpful. I don't knwo how to build such a book, but Kogo's Joseki dictionnary is a huge .sgf file containging joseki + trick moves and punishment. Maybe it can be parsed to extract only joskis. Gnugo includes a joseki db, with tags (joseki, hamete ...) so maybe it can be used more easily. my 2 cents. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Mirror Go against Zen
Le 23/07/2009 à 09:21, Ingo Althöfer a écrit : .../... Therefore I really like the test series by Yamato (with 30 out of 100 wins for Zen against mirror strategy) Can we assume that both programs are approximately equal or is MFGO clearly stronger (or visa versa?) In normal go (on KGS) Zen seems to be ahead of all other programs on moderate hardware. Mirror go seems to be a world of its own... gnugo --mirror will try to play mirror go :) maybe fun/interesting to add one on cgos ? my 2 cents Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Mirror Go against Zen
Le 20/07/2009 à 15:34, Don Dailey a écrit : Again, I don't understand go so well, but how do you win against mirror go? It seems you must either take advantage somehow of the non-symmetry of the center point OR take advantage of the fact that a capture could break the symmetry. Is that right? yes there are well-know tactics to break symetry, part of them implemented in gnugo. - play on contact of the center stone, and after some moves you will capture something or force your opponent to break symetry (to avoid being captured) - ladder collision (i dont know how to do this) There are some 9d pro games with mirror go during rather long time. my 2 cents Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Mirror Go against Zen
Le 20/07/2009 à 16:01, Don Dailey a écrit : Ok, so I am right about this, you take advantage of the asymmetry of captures. But go programs do not KNOW they are playing mirror go GNU Go knows if the game is mirror-go or not, and decide to break it when a sufficent number of moves is reached and would have no motivation to specifically set this up. in Torino for ICGA tournament some years ago, one go program was playing only mirror-go and pass when playing mirror was impossible (the student was starting his PhD and came mainly for conferences, he had no time to develop his program) iirc this program lost all its games, but it was interesting to check games. I guess strong players / developpers will see more things than me. So how is it that some equally strong programs have no problem while others do? some detect symetry and know how to break it. Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Slightly OT: Sound in CGoban
Le 16/07/2009 à 22:28, Peter Drake a écrit : I've recently been getting an odd distorted buzzing with every sound played by CGoban3, the KGS client. This doesn't happen with other applications, so I don't think it's a hardware or driver problem. Has anyone else encountered this? Peter Drake http://www.lclark.edu/~drake/ you should mailto:ad...@gokgs.com to report this. btw, if you can advocate fo a public bug tracker it would be a great improvement for the community :) Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fast ways to evaluate program strength.
Le 08/04/2009 à 07:28, Petri Pitkanen a écrit : This is nice idea and this is to a degree what GnuGo regression test does. afaik, gnugo testsuite (based on a previous one) is not totally suitable for MC programs, as some position are dead lost / clear win but shows gg misbehavior. Some part should be re-usable, at least as a validation of simple known LD position for example. Some times ago i tested a new (so weak) program on gg tests, it passed less than 25%, when gg is above 65%. It would nice to know the results of various programs on this suite, and see what happens. Probably this would lead to filter out many tests, and help gnugo team to improve relevancy of the test suite ? But as there is more than one way to skin the cat, it will not capture true strength of the programs. If you put Mogo to solve the tests from a book for example 501 opening problems, it will probably fail minimum of 75% of them because it has completely different style from what is expected from humans. This will also lead to different solution in connecting and capturing. MC program may reach the conclusion that it best option to ignore the whole connection issue. They often do exactly that. Thats why its a big task to set up a test suite (and we should start now). Strong programs should have better results than weak ones ;-) Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Black/White winning rates with random playout?
Le jeudi 8 janvier 2009, Nuno Milheiro a écrit : It seems normal to me, Blac is only one play ahead, which value is several points (probably 7,5 hence the komi value) given intelligent play, given random play the value of one more move may be only one point. You should try with more komi value to see which is the fair komi value for random play 2009/1/8 i...@gmx.ch Hi, What's an usual winning rate for black/white from an empty 9x9 board, black playing first, 7.5 komi? I play 50k games when starting my program, and I usually get around 60% winning rate for white. This seems rather high to me, and I suspect a bug somewhere. Do you have any data I could compare with? I use random playouts, only moves that fill eyes are pruned. This has been discussed some times ago wrt correct komi. Aloril did some experiments with various programs, and this tends to confirm that the komi depends on the strenght of the player. For a random player, komi is near 1 point = mostly the advantage of plonking one more stone on the board. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] komi for 13x13 and 19x19
Le samedi 2 août 2008, Christoph Birk a écrit : On Aug 2, 2008, at 10:34 AM, Don Dailey wrote: Does it make sense to use a komi of 7.5 for 13x13 and 19x19 under CGOS rules? I don't know about 13x13, but for 19x19 you should use 6.5. Is'nt the komi 6.5 with japanese rules = 7.5 with chinese rules ? Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] off topic: Tobacco
Le mardi 8 avril 2008, Dave Dyer a écrit : By the way, has anyone seen the Philip Morris commercials? I believe they were forced into this as part of the extortion by the state attorneys general. It's Penance for illegally targeting young non-smokers with Joe Camel, and promoting their products while denying that they were dangerous to your health. And now they turn to third-world where no law protect people. I saw huge brand new 4x4, painted with Malb colors, giving free cigarettes at the outside of schools in Dakar, and organising lots of dancing nights with free cigarettes. Shame on them. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Hybrid theory
Le vendredi 1 février 2008, David Doshay a écrit : This is the direction in which we are moving with SlugGo. We also expect it to be difficult to integrate different approaches, but this has always been our research direction: when there are multiple codes which will each give an evaluation of a situation, how does one design an arbitrator that makes the final decision? I asked how one do in my lab in speach recognition. They use home made very simple method, but deeply linked to the internal of our tools. The good news is that the phD student is going to study a little voting methods and alike before his the end of his thesis ! Maybe in some monthes i'll have more info :) Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: komi argument = silly
Le vendredi 7 mars 2008, Petr Baudis a écrit : This has nothing to do with black/white distinction. The idea is to dynamically adjust the komi to make UCT to aim at higher and potentially less sure win or lower and potentially more sure loss. Of course, depending on whether it takes black or white you would adjust the komi in the correct direction. clear summary :) I just don't understand why one would need to change the komi in order to fix endgame. When winning probability of best move is known (with a confidence interval) just pick the move which does more points (inside this interval) would solve the endgame problem. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] GNU Go is not public domain
Hi On http://cgos.boardspace.net/study/13/index.html we read : a reference point, a popular program in the public domain called Gnugo It is open source and libre program GPL, but not public domain. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 13x13 study. Time and memory
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 rank vs time, maybe we have a straight line :) ELO vs size of the tree (or memory usage) should show the same ? On 13x13 study it does, but there are not enough data at high level. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 13x13 study. Time and memory
Le vendredi 22 février 2008, Sylvain Gelly a écrit : 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 rank vs time, maybe we have a straight line :) It would indeed be very interesting to see that plot! and if i remember it was Don's initial claim, that doubling thinking time (for humans and scalable bots) will produce a fixed Elo increase, at least until exhaustion of other resources (human fall asleep, bot fill memory ...) Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 13x13 study.
Le jeudi 21 février 2008, Don Dailey a écrit : The study is running very well. We have 32 computers being used so far, some participants are providing 2 (or even more) computers. It would be great to get even more as we get into higher levels, as it will take a LOT of power to get a lot of games when each games takes 2 or 3 hours or more. Is it possible to have a indicative time and memory consumption at each level, for 9x9 and 13x13 study ? I guess this does not vary too much on recent hardware (factor 2 at max), and it is interesting to extrapolate how the scalability is (im)possible. Thanks a lot for this interesting and convincing study. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: computer-go Digest, Vol 43, Issue 8
Le lundi 18 février 2008, Michael Williams a écrit : But as was pointed out before, these high levels of MoGo are probably still not pro level, right? On 9x9 Big_slow_Mogo is near pro level, maybe more. 6 monthes ago or so it was able to regurlarly beat pro without komi on 9x9. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] gpugo. optimisation
Le mercredi 13 février 2008, Florian Erhardt a écrit : If anyone knows where I could get SIMPLE docs explaining optimizations for vector cpus, that would be great. Some basic advices and links. Read Linux Coding Style, especially section concerning indentation and functions. Draw the flow char of your program, and estimate number of loops and significant I/O. This is incredibly useful (and needs only 5 minutes to do) The basis of optimisation (test against zero is faster, unroll, Single dimension arrays are faster than multi-dimensioned arrays...) http://www.abarnett.demon.co.uk/tutorial.html I would add: * do loops where computation on X(i) does not depend on X(i-1) (or i+1). This is mandatory for vector processing. * loops are small (few lines not 100 lines) so the compiler can understand what happens and do the correct thing. * Move all invariant code outside the loop * Don't believe the compiler can do everything for you (it can if the code is clean because _you_ know what it expects) This one is very clear, but it uses Cray tools http://www.asc.edu/seminars/optimization/opt_intro.html Of course profile your code (gcc -pg, if you uses gcc.) What compiler do you use ? Last, read the compiler documentation, and take notes, at least to have an idea of what kind of optimisation it can(not) do. If after all possible optimisations you reach 30 % of theoretical maximum performance, you can be proud of your code, maybe it impossible to do better. I know there are some crazy optimisation gurus on the list, and hope they will give more links and advices. my 2 cents Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: komi
Le mardi 12 février 2008, David Schneider-Joseph a écrit : On Feb 11, 2008, at 8:42 PM, Don Dailey wrote: David Schneider-Joseph wrote: By definition, komi is proportional to the value of moving first. Likewise, by definition, your skill is the amount of value you get out of a move. Therefore, better players should play with higher komi. This was observed on cgos 9x9, and discussed last year or before. i think its on Aloril site. Very weak program need a komi 0.5 Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Fw: big_Mogo_19
Le vendredi 8 février 2008, terry mcintyre a écrit : Probably true, but I am already running into RAM limits with big_Mogo18 - had to halve the number of instances of the autotest program, and am installing RAM in the next few days to alleviate this problem. There is also the time-per-game, which will approximately double. I'd vote for moving on to 13x13 Could you give an order of magnitude of time per move (or per game) and memory usage, needed for each level of play ? It would be nice to plot this on the same graph, to see how it correlates with ELO. Regards Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Hybrid theory
Le samedi 2 février 2008, terry mcintyre a écrit : Apologies for not quoting Don Dailey's text on Borda voting -- yahoo is doing something truly awful with quoted text, for some reason. It also break mail-thread, putting your post in uncorelated thread. Maybe switch to another mail ? ;-) Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Transformation between KGS ratings and Elo
Le samedi 2 février 2008, Christoph Birk a écrit : On Sat, 2 Feb 2008, Alain Baeckeroot wrote: 1800 is gnugo, so this puts top programs near 1k (2d for extreme mogo_18) this seems reasonable to me. Are you confusing 19x19 and 9x9? The ELO/KGS table is for 19x19, while mogo_18 plays 9x9. oops, sorry, yes everything is fine :) Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Hybrid theory
Le vendredi 1 février 2008, David Doshay a écrit : This is the direction in which we are moving with SlugGo. We also expect it to be difficult to integrate different approaches, but this has always been our research direction: when there are multiple codes which will each give an evaluation of a situation, how does one design an arbitrator that makes the final decision? There is a phD student in my lab working on such a topic in speech recognition (use several different statistical estimators and combine the informations to get the best one or the best tree). This give some nice improvements: more or less 5 engines with 25 % error, give a system which does 20% error, and this is a huge improvement. I'll post some references, i guess the tools and methods are more or less well known. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Transformation between KGS ratings and Elo
Le vendredi 1 février 2008, Andy a écrit : See below I created a table that shows the transformation from KGS ratings to the Elo that CGOS uses. I set 6k=1800 because I believe that is what GNU 3.7.10 is under both systems. Does anyone have more data points for bots that play on both systems? Also is there an all times list for 19x19? CS-9-17-2CPU is on top at 2297, but I don't think that's the strongest CrazyStone. I think other strong 19x19 bots are not on the current list either. To create the table I calculated the probability for a player of rank X to upset a player of rank X+1. Then I converted this to the equivalent number of Elo points for the same upset rate. Finally I made a running total, setting 6k to 1800. The transform could be done using calculus I suppose but it's been a long time since I did that! :) ELO set rank k1 rank 6k=1800 10k 0.80139 1,244 9k 0.80139 1,383 8k 0.80139 1,522 7k 0.80139 1,661 6k 0.80139 1,800 5k 0.80139 1,939 4k 0.88153 2,078 3k 0.97168 2,231 2k 1.05182 2,399 1k 1.13197 2,582 1d 1.22211 2,779 2d 1.30226 2,990 3d 1.30226 3,216 4d 1.30226 3,442 5d 1.30226 3,667 6d 1.30226 3,893 7d 1.30226 4,119 8d 1.30226 4,345 9d 1.30226 4,571 1800 is gnugo, so this puts top programs near 1k (2d for extreme mogo_18) this seems reasonable to me. Im surprised when i compare this scale to http://en.wikipedia.org/wiki/Go_ranks_and_ratings Obviously there is a factor 2 between both ratings scales, (as i don't believe mogo_18 is 9d EGF ;), but this is just not important, as far as we know it. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] scalability study
Le vendredi 1 février 2008, terry mcintyre a écrit : Regarding the scalability study, ... I'm very curious about that flat spot for Mogo-16, 17, and 18. ( http://cgos.boardspace.net/study/index.html ) I think its just lack of data Mogo_16 = 2958+47 / -45 Mogo_17 = 2953+86 / -78 Mogo_18 = 2947+87 / -79 The smooth curves gives a better feeling: there is no plateau, just a slowdown in improvement. Also don't forget that these games are mainly self play, so result is less reliable than the middle of the curve (which would be even more reliable with a more programs but thats the role of cgos 9X9 :) Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 19x19 Study - prior in bayeselo, and KGS study
Le mercredi 30 janvier 2008, David Fotland a écrit : 3 kyu at this level is a lot for a person. I've know club players who never got better than 9k, and people who study and play may still take a year or more to make this much improvement. Many club players stall somewhere between 7k and 4k and never get any better. Agreed 100% One example from one serious young guy (14yo) in my club. I think he is clever (outside of go), and serious and he works on go with 2 friends of his classroom, they discovered go together last year. They also read books and once a month or so have a 3d player who come to teach them... http://www.gokgs.com/graphPage.jsp?user=minoru I wish i could improve as fast as they are doing, and they are already stronger than some adults who play since years and don't improve anymore. Alain -Original Message- From: [EMAIL PROTECTED] [mailto:computer-go- [EMAIL PROTECTED] On Behalf Of Don Dailey Sent: Tuesday, January 29, 2008 7:18 PM To: computer-go Subject: Re: [computer-go] 19x19 Study - prior in bayeselo, and KGS study I wish I knew how that translates to win expectancy (ELO rating.)Is 3 kyu at this level a pretty significant improvement? - Don Hiroshi Yamashita wrote: Instead of playing UCT bot vs UCT bot, I am thinking about running a scaling experiment against humans on KGS. I'll probably start with 2k, 8k, 16k, and 32k playouts. I have a result on KGS. AyaMC 6k (5.9k) 16po http://www.gokgs.com/graphPage.jsp?user=AyaMC AyaMC2 9k (8.4k) 1po http://www.gokgs.com/graphPage.jsp?user=AyaMC2 16po ... 2po x8 core (8sec/move on Xeon 2.66GHz) 1po ... 5000po x2 core (2sec/move on Opteron 2.4GHz) (5.9k) and (8.4k) are from the graph. AyaMC2 has played 97 games in a day on average. (2sec/move) I changed program 01/19/2008, but it is not stable yet. On this condition, 7 days or more will be needed for stable rating. Hiroshi Yamashita ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 19x19 Study. Nakade is difficult
Le mercredi 30 janvier 2008, Don Dailey a écrit : I must not understand the problem. My program has no trouble with nakade unless you are talking about some special case position.My program immediately places the stone on the magic square to protect it's 2 eyes.I can't believe mogo doesn't do this, it would be very weak if it didn't. Worth to see, http://senseis.xmp.net/?NakadeExample3 This example comes from Modern Famous Games (Gendai no Meikyoku), vol. 6: Go Seigen, II p. 59. In the game, both players, Go Seigen and Fujisawa Kuranosuke misread this corner. (4 points nakade can become 2 points nakade) Also this incredible capture 16 stones, but still dead :) http://senseis.xmp.net/?BiggestKnownEyeSpaceForWhichThereIsANakade Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Scalbility study: low end
Le jeudi 24 janvier 2008, Don Dailey a écrit : Hi Hideki, No need to stop any of the weaker games since 99% of the compute time is consumed by the strongest half. Also, only the new mogo's will be scheduled to play until they catch up - however their opponent will almost always be the stronger players. The probability of one of them playing against an opponent in the lower half is low. - Don Is it planned to also add Fatman 14 15 16 ? Or is there some impossibility ? Also it would be nice to have an order of magnitude of memory usage and time used for each level. Thanks a lot for this great study Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] out of topic: Bobby Fisher
Hello http://www.theregister.co.uk/2008/01/18/fischer_dead/ Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Is MC-UCT really scalable ... is a troll
Le mercredi 23 janvier 2008, ivan dubois a écrit : Hi Alain, Sorry for being so insistant : You should browse the archive of the list, nearly the same discussion about infinite and scalability happenned in 2007. No i just said that, unless i really understood nothing, i read here from well known competent persons that MC+UCT scales infinitely , and would reach perfect play with infinite computational resources, and this is theoretically proven (which is not the case for classical program like our beloved GNU Go). This is absolutely true. Now this can also be said for a mini-max solver (my point). Don Dailey answered better than i could do, yes minimax also scales. So MC+UCT scales. (even against humans, martians, trolls, computers, gods ... :) The conclusion does not follow. Ah ? Why not ? what is wrong in the reasonning ? Should i think : It scales in theory so it does NOT scale in practice ? The fact that it eventualy reaches perfect play with enough computing power does NOT mean that it scales well. Proof : A mini-max solver does reach perfect play with enough computing power BUT does not scale. we dont have the same informations. For Minimax scales too, maybe the improvement curve has a smaller slope than MC+UCT curve, but Actualy, this theoritical property is a NESCESSARY condition for UCT to scale, but it is not a SUFFICIANT condition. The scalability of UCT has been proven by its outstanding results From a pure logical point of vue - Positive experiment are never a valid proof. They are only examples that makes one feel his theory is right. - Only counter example are proof that the theory is wrong. and Don's experiments, not by mathematics. Are you a troll ? Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 19x19 cgos ranking page
Le mardi 22 janvier 2008, Olivier Teytaud a écrit : Have you selected the room with bot's name as a member? Yes. Seemingly only public rooms are possible for bots. I'm interested in if someone has a solution for private rooms. I know that Aloril is running one mogobot clone in my go teacher's private room, so it is possible. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New scalability study : show uncertainty ?
Le mardi 22 janvier 2008, Michael Williams a écrit : ... perhaps only uniformly random playouts will scale to perfection. The reason that MC/UCT scales to perfection is because of the UCT part, not the MC (playout) part. People seems to forget this a lot. I agree on this _only_ if the UCT check all possible moves. If not one can be limited by the quality of the playout. Pure random-MC playout has the great advantage of being totally neutral and unbiased. If you use gnugo for playout, as it has systematical errors (like wrong estimation of life and death for groups surrounded at some distance) your playout will be biased toward a wrong solution, far from perfect. I think Sluggo showed this very clearly. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Is MC-UCT really scalable ... is a troll
Le mardi 22 janvier 2008, David Fotland a écrit : The UCT-MC programs do particularly well against traditional programs because they expose the brittleness inherent in the pattern databases they use. Strong humans are not so easily beaten by playing unconventional and somewhat inferior moves. I think Remi posted a game of CrazyStone on 19x19 commented by one pro who said this move is 2 dan level. So far no go program got such analyse, and the also the huge novelty provided by MC/UCT programs is they have a _real_ strenght with their own style, like humans: play solid when winning, and play hamete (tricky moves) when losing. On kgs MC programs played hundreds (if not thousands) games against humans, and no doubt they fully merit their rank, and no doubt they are improving. Infinite scalability is a theoricaly proved property, so please don't feed the troll :-) Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Is MC-UCT really scalable against humans?
Le mardi 22 janvier 2008, Mark Boon a écrit : On 22-jan-08, at 11:33, Magnus Persson wrote: So feel free to argue that 19x19 has properties that are unique, but in doing so please *specify* exactly what this means and why a computer program has to deal with it to play really strong. Magnus, Would you argue the same for 3x3 Go? I think there are a lot of skills involved in playing 19x19 Go that one doesn't need in 9x9 Go. Mostly involving longer term planning like combining corner joseki, influence and thickness and more such things. Are't these things only shortcuts for a poor human brain, only a way to compensate their lack of reading ability. Like in fluid dynamics, one use macroscopic description (pression, temperature, mass, speed =patterns and josekis) to summarize a huge amount of underlying very simple things (molecules position and speeds = stones and mutlples semeais) But these macroscopic representations are flawned enought to oblige real testing in wind-tunnel or alike before launching a new protoype of plane. In go the real strenght of a players is limited by its reading and counting capacity, no matter how much theory he knows. on 9X9 MC/UCT showed they are strong at reading and counting, that matters. Maybe it will turn out that a computer doesn't need different concepts for 19x19 to play well. So far the evidence is to the contrary and programmers are inclined to add more knowledge related things to their program when moving to 19x19. I think combining good fuseki ala mango (see kgs ;), with other MC/UCT will give a nice improvement. We 'll see with Mogo match against professional soon :-) Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] orego license?
Le mardi 22 janvier 2008, Peter Drake a écrit : The license for Orego is GPL: basically, you can do whatever you want with it, but don't sell it, claim our stuff is your invention, or try to prevent anyone else from using it. You can sell GPL, but you can't prevent the owner to redristribute it freely or sell it again ;) Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Is MC-UCT really scalable ... is a troll
Le mardi 22 janvier 2008, [EMAIL PROTECTED] a écrit : Infinite scalability is a theoricaly proved property, so please don't feed the troll :-) Are you saying that the scalability is linear between number of playouts and ranking? No i just said that, unless i really understood nothing, i read here from well known competent persons that MC+UCT scales infinitely , and would reach perfect play with infinite computational resources, and this is theoretically proven (which is not the case for classical program like our beloved GNU Go). So MC+UCT scales. (even against humans, martians, trolls, computers, gods ... :) Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] KGS private room
Le lundi 21 janvier 2008, Olivier Teytaud a écrit : I am trying to connect a bot to a KGS private room. If we set computer-go as the room, the bot comes and plays against its opponents. But if we set the name of the room, the bot comes and can be seen in the room, but does not play. Someone has already solved such an issue ? stupid question : I have never tested this, but is your bot allowed in this room ? Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New scalability study : show uncertainty ?
Le samedi 19 janvier 2008, Don Dailey a écrit : The new scalability study is in progress. It will be very slow going, only a few games a day can be played but we are trying to get more computers utilized. I will update the data a few times a day for all to see. This includes a crosstable and ratings graphs. The games will be made available for anyone who wants them. Although it's not on the graph itself, Gnugo-3.7.11 level 10 is set to be 1800.0 ELO.The bayeselo program is used to calculate ratings. Results can be found here: http://cgos.boardspace.net/study/index.html It would be nice to also plot uncertainty bar around the estimated rank. I wonder if fatman trend near 13 is an artefact or if the curve shows it has reached some limit in scalabitly. Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Anchor player
Le jeudi 17 janvier 2008, Don Dailey a écrit : Perfect! I will adjust the level so that it plays as strong as possible on CGOS without taking a risk of getting into time trouble on modest hardware. Then I can make Mogo the anchor player. Even if i love Mogo, and i am very impressed, i think it is a bad idea to use it as an anchor, as it is closed source. It can be used as a floating anchor (= a player always present, with no changes in settings), but i really think using GNU Go or one other open source program for the anchor is the best for the community. my 2 cents. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Sylvain Gelly thesis in english
Le dimanche 13 janvier 2008, terry mcintyre a écrit : From: Rémi Coulom [EMAIL PROTECTED] Sylvain Gelly wrote: Yes I did! :).It is not on my website, but will (soon?). However, you should not be so eager to read it :) Cheers, Sylvain Google finds it: http://tao.lri.fr/Papers/thesesTAO/SylvainGellyThesis.pdf Thanks, Rémi! Now eagerly awaiting the English translation! It is in english since page 24. pages 1-23 are french summary :-) Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] To French speakers: computer Go on the French Radio
Le jeudi 10 janvier 2008, Olivier Teytaud a écrit : They announce that a match will be organized between MoGo and a professional player in March, during the Paris Go Tournament. It will be the MPI version of mogo, and in various board-sizes. What will be the hardware for Mogo ? Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Difficult and strong move
Le mardi 8 janvier 2008, terry mcintyre a écrit : - Original Message From: Stuart A. Yeates [EMAIL PROTECTED] I recommend Mathematical Go: Chilling Gets the Last Point by Elwyn Berlekamp and David Wolfe. The book contains a number of such positions, as well as an approach that allows to make as many more as you need. http://math.berkeley.edu/~berlek/cgt/gobook.html Most interesting! Has anyone implemented these methods for endgame analysis in a computer program? If don't remeber exactly the names, but there are some papers about thermography applied to endgame in go game. I think i find them in Markus Enzenbererg go bibliography. The main feeling i had, is that it can be usefull in very end game when the board can be divided in independant sub-boards , and that it seemed very tough work for very small result if we consider current state of the art in computer go. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How to get more participation in 19x19 CGOS?
Le mardi 8 janvier 2008, Don Dailey a écrit : ... On 19x19 it might be 30 minutes per side like we have now, with 5 minute games for the fast time control.We would probably have to work it out so that program like gnugo would be able to handle the fast time control at their standard settings. At level 10, gnugo might need more than 10 min for some games (with lots of possible ataris or kos). At level 0 (with tons of really ugly moves, and only 2 stones weaker on kgs) 5 min should be ok. I think adding handicap to 19x19 is really a needed feature. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: language efficiency
Le mardi 18 décembre 2007, Harald Korneliussen a écrit : Some thinking out loud here on the topic of languages and efficiency: I'd like to know how well MoGo would have played if you let it think for a week for every move. Only it seems to me that is not possible, because I don't think MoGo will run for a week without crashing. Crazystone also crashes quite a lot, I guess you are under windoz, you should try linux ;-) Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Where and How to Test the Strong Programs?
Le mercredi 12 décembre 2007, Ben Lambrechts a écrit : How do AGA ratings compare to KGS? Sensei's Library is your friend ;o) http://senseis.xmp.net/?RankWorldwideComparison I believe this page has not been updated since last year change on kgs ranking scale. Kgs have the big advantage of letting some bots get a rank, which is very convenient. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Microsoft Research Lectures: Akihiro Kishimoto
Le mercredi 12 décembre 2007, Harri Salakoski a écrit : Such comment just take my word back little it is maybe awesome but I can't say is it or not, as have still bugs left. E E E E E E BEE WWWEBEE E E EWBEE E E WEBEE ABCDEFG For example current version(not released) goes trought 162438 nodes before it proofs black B2 kills(without any ordering help). . . . . . . . . . . . . . . B B B B B . . w w w . B . . . . . w B . . . . w . B . . A B C D E F G with 7 empty places, should'nt it be less than 7**3 = 2187 ? How much nodes does it uses for this ? B B B B B B B B B B B . B B B B B B B . B w w w . B B B . . . w B B B . . w . B B B A B C D E F G Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo rank on 9x9 on kgs
Le jeudi 6 décembre 2007, Don Dailey a écrit : Lavergne Thomas wrote: If some bot can be setup to play on kgs for enough time to get a solid rank and then put on cgos to get an elo rating with the same configuration we could find a formula to convert elo to kgs ranks. For sure, this is not perfect but I think is good enought. But most of us feel that you cannot do this with GO programs - you need humans. For instance you could take GnuGo, get a 19x19 rating and then play on 9x9 CGOS and use it as a reference point.However GnuGo was not designed to play 9x9 go. My own program Lazarus is terrible at 19x19 but pretty good at 9x9. It could probably give a low kyu player a really good game on 9x9 but it would be easily beat at 19x19 - so it's not a good way to standardize.I believe GnuGo is more balanced in this way - but it's probably a bad idea in general to figure it this way. Your idea is fine for 19x19 CGOS. - Don I used 946 9x9 games of my gnugo bot on kgs: On 9x9 it appears that gnugo _has_ the same rank as on 19x19. So just giving standard gnugo a fixed kyu on cgos (lets say 6k like kgs) should give rather good estimation. /Alain PS: Here are the histograms for my ranked bots on kgs, for those who wants to do more subtle estimation and cannot wait monthes before their bot gathered enough games on kgs :) (these are old games before ranking system changes, so gnugo 3.7.9 and 10 were 13k kgs, they are now 6k) I filtered out handicap games and unfinished, but did not check cheaters. The tables are #occurence #opponent_rank(kgs_old_kyu) For komi 7 and 7.5 gg99_rank/km7$ cat black_lose_agaisnt.csv 1 2 1 10 2 13 gg99_rank/km7$ cat black_wins_agaisnt.csv 1 10 1 12 2 13 gg99_rank/km7$ cat white_wins_agaisnt.csv 1 2 3 9 1 10 1 11 19 12 44 13 2 15 4 16 3 18 2 19 1 20 2 21 2 25 2 26 4 30 gg99_rank/km7$ cat white_lose_agaisnt.csv 1 3d 1 2 5 9 2 10 1 11 4 12 47 13 1 14 2 16 1 17 2 18 1 19 1 21 2 25 6 30 For komi 0 and 0.5 : gg99_rank/km0$ cat black_wins_agaisnt.csv 1 5 1 6 13 7 14 8 16 9 11 10 34 11 50 12 2 14 3 17 1 18 1 24 1 30 gg99_rank/km0$ cat black_lose_agaisnt.csv 1 3 1 4 2 5 1 6 6 7 11 8 17 9 5 10 23 11 23 12 1 17 1 20 gg99_rank/km0$ cat white_wins_agaisnt.csv 28 12 211 13 5 25 1 30 gg99_rank/km0$ cat white_lose_agaisnt.csv 31 12 245 13 1 14 2 16 1 17 1 22 4 25 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Elo and handicap matching
Le mardi 4 décembre 2007, Don Dailey a écrit : The only issue is that I don't know if GnuGo is representative of 19x19 to 9x9 go strength. I am interested in knowing how a human 19x19 scales down to 9x9 play. It's well known that programs scale up poorly. Ah yes, i forgot this :) My personnal rule is - on 13x13 divide handicap by 2 - on 9x9 divide by 3 It is a bit rough, but quite good. More subbtle attempts are summarized at: http://senseis.xmp.net/?HandicapForSmallerBoardSizes http://senseis.xmp.net/?AGAHandicaps and http://www.timhunt.me.uk/go/handicaps/ with and interesting observation in the end. Alain. However, this data should still be quite useful. - Don Alain Baeckeroot wrote: Le mardi 4 décembre 2007, Don Dailey a écrit : For 9x9 ELO works better. For 19x19 it's less clear cut.The handicap system appears to be a good system at 19x19 and has the very nice merit of allowing grossly mismatched players to compete. I think the two systems can be married by adding a fixed offset per stone handicap to your ELO. Stats from official european go federation, on 150 000 games nearly solves the problem of doing ELO vs handicap matching. http://gemma.ujf.cas.cz/~cieply/GO/statev.html Just need to find one anchor, lets says gnugo , rated 6k on kgs in 2007-11... Alain PS i posted this link some times on the list, but nobody seems to consider it is useful (except Sylvain Gelly ;-) I would be glad if someone could explain to me why this does not solve the problem. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Elo and handicap matching
Le mardi 4 décembre 2007, Christoph Birk a écrit : On Tue, 4 Dec 2007, Alain Baeckeroot wrote: For 9x9 ELO works better. For 19x19 it's less clear cut.The handicap system appears to be a good system at 19x19 and has the very nice merit of allowing grossly mismatched players to compete. I think the two systems can be married by adding a fixed offset per stone handicap to your ELO. Stats from official european go federation, on 150 000 games nearly solves the problem of doing ELO vs handicap matching. http://gemma.ujf.cas.cz/~cieply/GO/statev.html Just need to find one anchor, lets says gnugo , rated 6k on kgs in 2007-11... That's nice, but on 19x19. I was interested in calibrating CGOS 9x9 versus some moderatly strong humans. It is possible to download mogo games on kgs and filter dan players games then make some stats. My estimate was more than 2d (kgs) for mogo 1.0 some monthes ago. My experience on 9x9 on kgs against mogo_1.0: I was 1 kyu on kgs and mogo was significantly stronger than me: i lose more than 2/3 on 10 games, and the rare victories were due to some blunder of mogo (nakade in corner, instead of seki). Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] KGS connection
Le dimanche 11 novembre 2007, Stuart A. Yeates a écrit : On 10/11/2007, Nick Wedd [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Chris Fant [EMAIL PROTECTED] writes A beginner could easily run gnugo for a day or two, get a 7k rank for the gnugo account, then replace gnugo with an account that moves randomly for a few moves then resigns. Play this new robot as white with handicap 6, and you will soon get a dan-level account. Nick Wedd It is broken in the sense that even as things stand, he can persuade his big brother to open an account, win games, get a 2-dan rating, and then throw games to him. I don't see how any system could prevent this. [...] This can be done relatively easily using network algorithms. I don't understand how any algorithm can prevent cheaters without using some kind of trusted authentification. I think you have a gold mine in your hand if you can do this. Hopefully KGS dot aim to be secured as a banking system, and won't ask my finger prints before i can connect for a game :-) Essentially your throttle how much of a contribution each other player can make to a player's rank. This throttling would probably be done relative difference in the rank between players and the square of the size of the pool of players. Such a metric would actually benefit all players, by encouraging them to play as many different other players as possible and avoid the formation of player cliques. One would have to ensure that you weren't penalising player who always played at a certain time of day in a certain timezone, however. i suspect most people plays always at a certain time of the day, in their timezone, so currently there might be 3 cliques: Asia, Europe, and Americas. Cheers /Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo development and MC
Le lundi 5 novembre 2007, Don Dailey a écrit : I noticed there are various Gnugo with Monte Carlo enhancements. Will any of these be integrated into the the Gnugo releases? It seems like a logical move. As far as i know MonteGNU is more or less: http://trac.gnugo.org/gnugo/ticket/150 and currently mainly (only?) Gunnar is working on it. /Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Where is Mogo?
Le lundi 29 octobre 2007, Don Dailey a écrit : I don't see Mogo on the server?Where is Mogo? However CrazyStone is there to represent the Monte Carlo programs and seems to be doing a very good job indeed! CS-8-26-2CPU http://www.lri.fr/%7Eteytaud/cross/CS-8-26-2CPU.html is doing absurdly well for far, winning almost every game it plays. - Don According to http://gemma.ujf.cas.cz/~cieply/GO/statev.html this seems to say CS-8-26-2CPU is near 4 stones stronger than GNU (even if 6/7 games is not statistically very robust estimation) I m waiting to see how CS_H3 do ... Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Handicap vs Elo
Le lundi 29 octobre 2007, Don Dailey a écrit : I don't see Mogo on the server?Where is Mogo? However CrazyStone is there to represent the Monte Carlo programs and seems to be doing a very good job indeed! CS-8-26-2CPU http://www.lri.fr/%7Eteytaud/cross/CS-8-26-2CPU.html is doing absurdly well for far, winning almost every game it plays. - Don According to http://gemma.ujf.cas.cz/~cieply/GO/statev.html this seems to say CS-8-26-2CPU is near 4 stones stronger than GNU (even if 6/7 games is not statistically very robust estimation) I m waiting to see how CS_H3 do ... Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] best approach forward
Le jeudi 11 octobre 2007 22:31, Christoph Birk a écrit : On Thu, 11 Oct 2007, Don Dailey wrote: But we had a 19x19 server and it WAS NOT interesting. Nobody seemed willing to play on it. Maybe that has changed now. It was not interesting because there was only one competitive program on it (MoGo). Most people's programs are too weak at 19x19, but having MCGO, MoGo and CS would at least create some competition. And putting _handicap_ stones seems much more important on 19x19. With proper handicap even a ~weak program have 50% winning chance, and this is good for the moral of the bot ;) Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Former ... inhuman MC/UCT style
Le vendredi 12 octobre 2007 06:10, Dave Dyer a écrit : Considering how monte carlo actually works, I think it's plausible to argue that it works best where the distance to endgame is small. And for a player against Mogo this is very un-human feature on 19x19. - Fuseki is done agaisnt a 10k with vague but consistent cosmic style. - End game is played agaisnt a high dan opponent ! and you lose ;-) For me this is the most difficult to manage when playing mogo : i must force myself to take a huge lead before end-game. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] IEEE Spectrum article by Deep Blue creator
Le mardi 2 octobre 2007 16:46, Ian Osgood a écrit : Greetings, I noticed that the following link was recently added to the Computer Go Wikipedia article. http://www.spectrum.ieee.org/oct07/5552 Cracking Go, by Feng-hsiung Hsu, IEEE Spectrum magazine, October 2007. He claims it should be possible to build a Go machine stronger than any human player. Ian Unless i missed something in this 4 pages article, there is nothing in it ! Just vague phrase, and assumption that brute force (ala deep blue) _may_ give a strong go machine. I think classical, MC and UCT programmers have contributed much more to computer go than this respectable researcher. Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] problems w/ 19x19 cgos server
Le vendredi 21 septembre 2007 21:35, [EMAIL PROTECTED] a écrit : If the 19x19 CGOS is going to be retired due to lack of interest, I wonder if there would be interest in trying out an ultra-blitz version for a while: games as fast as the com. links would permit.? (Game storage would be an issue. Maybe they just wouldn't get stored.) It could be a limited time trial. It might push the front runners out of their comfort zones and tempt some of those on the sidelines to join in. What do people think? - Dave Hillis With rather short time settings, gnugo can be the same strenght as mogo. I guess something like 10-15 min is correct on 19X19. Maybe a good idea is to find the time setting where these 2 bots have 50% win against each other. This would be of great interest for other programs. Else i bet gnugo will crush all programs in ultra blitz (at level 0 gnugo loses only 2 kyu on KGS compared to level 10) Alain. -Original Message- From: Don Dailey [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Fri, 21 Sep 2007 1:25 pm Subject: Re: [computer-go] problems w/ 19x19 cgos server I had to take the 19x19 server down due to disk space limits on the boardspace server. Almost nobody has been using it anyway. I will also be archiving the 9x9 games on another site soon. If someone wants to host it on a unix machine that is visible I would consider relocating the server if there is enough interest. I'm wondering if a 13x13 server would be more popular. David Doshay is going to host a site to archive games and I will put all the 19x19 games that have been played on the 19x19 server there for future reference. - Don terry mcintyre wrote: Two problems with the 19x19 server. 1) when I tried to click on a game for the 19x19 server, I got a 404 not found error. The same process works on the 9x9 links. Example of broken link from the Standings page: http://cgos.boardspace.net/19x19/SGF/2007/09/16/26970.sgf 2) my copy of GnuGo cannot connect to the 19x19 server. This happens periodically. Terry McIntyre [EMAIL PROTECTED] They mean to govern well; but they mean to govern. They promise to be kind masters; but they mean to be masters. -- Daniel Webster Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: http://us.rd.yahoo.com/evt=48253/*http://mobile.yahoo.com/go?refer=1GNXIC mail, news, photos more. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ Check Out the new free AIM(R) Mail -- Unlimited storage and industry-leading spam and email virus protection. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Binary release of MoGo
On Monday 10 September 2007 10:37:17 Sylvain Gelly wrote: 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 you really want it not to pass, you should add a --playsAgainstHuman 0 (I am not exactly sure of the exact spelling of the option and I can't test from here. Let me know if it does not work). By the way, is --time 0.1 valid? Yes Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ Thanks for releasing binary mogo, and congratulations for your really nice job. I'm waiting patiently for your phd theses... I have access to a cool cluster (50 CPU 100 Go RAM) and will asap run the ~1500 gnugo genmove regression tests with mogo ... just to see what happens. I'll post the results when it is done, but i have to wait for availability... Bonnes continuations. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] SGF parsing
Le lundi 9 juillet 2007 18:46, Joshua Shriver a écrit : Ok found some KGS games, and they make a lot more sense. With the specification I can see what all of the OT, AP, TM, FF, etc commads are. However I don't understand the way it sets the location, so far nothing I've seen describes it. ;B[kr] for example. I thought Go boards used A..x 1..y notation. Perhaps I'm wrong. If i remeber well: * Real life wooden Go board uses A...x without I , 1..y but sgf uses only letters for both coordinates (including I) * Axes are not the same. for board: Ox toward East, Oy toward North for sgf: Ox toward south, Oy toward East Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 9x9 games wanted and the next big challenge
Le dimanche 8 juillet 2007 11:51, chrilly a écrit : If it would be really a big challenge, there would be some money. There was a computer challenge with 1 million dollar prize during many years, for a program abble to beat one professional choosen by the sponsor. I don't know if it is still valid offer. In chess nowadays there is also no money. But once it was a good business and there was some considerable money for Deep Blue and on a smaller scale also for Hydra, there was Don's project at MIT, one got a big Cray for Cray-Blitz, Ken Thompson build a chess engine Its like some hobbyst engineers and hobby-pilots would try to fly to the moon. Titanic was build by professionals, and Noah's arch by an amateur ;-) (Kon Tiki is a more recent and scientific exemple of incredible amateurish success) Its probably only good for to write some academic papers. In this case its even an advantage that everything is so amateuristic. The general level is low and one can be the one-eyed king under blind ones. If i remeber, last year you said something like As a professional programmer, i don't want to ruin my reputation with a poor go program :-) And the state of the art is: go programs are just dumb on 19x19, lots of research are needed, but more engeneering power would probably do nothing. Its clear to me that things are as they are in the West. Go is played only by a small freak community. But if it is so important in China/Korea/Japan why is'nt there something like Fritz and ChessBase? Or does it exist and we are living in a completly other Go-world? Some dozens of 9x9 pro games are at http://gobase.org/9x9/ There are databases of nearly 5 pro games on 19X19, this should be good enough for some years in computer go. 9x9 is a teaching tool, or a fun tactical exercice, but it is not Go because of lack of strategy. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] mogobot against 5 dan pro on kgs
Hi everybody Guojuan (5p) has played some games agaisnt mogobot on kgs. Worth to look at, and mogobot 3.0 won some on 9x9 Congrats to mogobot team, and thanks to Guo Juan for the games :) Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: 9x9 vs 19x19 (was: computer-go Digest)
Le mardi 22 mai 2007 01:52, Dave Dyer a écrit : I figured that a credible anchor player for 19x19 might need a lot of cycles, and need to play a lot of games at first, so spreading the load would be a good idea. Maybe GNU Go 3.7.10 is _the_ good anchor player for 19x19: - everybody use it at home for tests - at level 10 it is fast, level 8 is slightly weaker but really much faster - it is one of the strongest program available - it is GPL Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 19x19 Go, scalability with time vs handicap
Le dimanche 22 avril 2007 22:26, Sylvain Gelly a écrit : Hello Daniel, Le dimanche 22 avril 2007 21:26, [EMAIL PROTECTED] a écrit : For human players a difference of 2 kyu means that the winning ratio of the stronger player is almost 100%. Is it? Do you have some statistics? If so, that is interesting, because that means that neither MoGo nor GnuGo exploit well (comparing to humans) the handicap stones (see results of handicaps with settings which make them even at H0). For kyu players 2 handicap does not mean very much. For dan players the difference becomes more significant. Nice stats on even game http://gemma.ujf.cas.cz/~cieply/GO/statev.html For pro i have been told that Lee Chang Ho is 2 points stronger than one of his favorite partner but has more than 70% victory, and he considers improving his game play by 2 points a workload for one life :) Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] The physics of Go playing strength.
Le lundi 9 avril 2007 14:06, Don Dailey a écrit : But the point is that as long as you can provide time and memory you will get improvement until perfect play is reached. Is there any proof that heavy player converge toward the same solution as the pure random playout ? With infinite resource, i agree that random playout will find the best move. But it seems that nothing is guaranted for heavy playout. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] The physics of Go playing strength.
Le dimanche 8 avril 2007 03:05, Don Dailey a écrit : A few weeks ago I announced that I was doing a long term scalability study with computer go on 9x9 boards. I have constructed a graph of the results so far: http://greencheeks.homelinux.org:8015/~drd/public/study.jpg Thanks for this interesting study. [snip] Feel free to interpret the data any way you please, but here are my own observations: 1. Scalability is almost linear with each doubling. 2. But there appears to be a very gradual fall-off with time - which is what one would expect (ELO improvements cannot be infinite so they must be approaching some limit.) Could'nt the inflexion of heavy curve also mean that the advantage of heavy play-out disappears when the number of simulation is very high ? With huge number of simulation the heavy player could become weaker than the light player, due to the wrong knowledge introduced in the play-out. Sadly it seems hard to test this (12-13-14) without huge computing power, a distributed [EMAIL PROTECTED], or a big amount of patience :-) 3. The heavy-playout version scales at least as well, if not better, than the light play-out version. (You can see the rating gap between them gradually increase with the number of play-outs.) between 10 and 11 the trend changes. Regards. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Big board. Temperature
Le vendredi 2 mars 2007 12:55, Jacques Basaldúa a écrit : In CGT the temperature is the difference between the value if you play and the value if you pass. Thanks for your lights :) Ok i better understand my confusion. In Go CGT-temperature applied to yose strongly looks like ordinary points (moku). I just found http://senseis.xmp.net/?TemperatureCGT The conclusion is much more clear for me: The temperature of a game is also a measure of the average gain a player can make by a gote play in it. It has the same value as the miai-value of the play, in go terms. Alain. The name question should be answered by a native English speaker, but I guess it is an common use of the word hot. Let's call it hotness ;-) Jacques. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Big board. Temperature
Physics temperature is a macroscopic description (global) of the underlying (un)-stability, so it comes to mind very quickly :) Unfortunately the term temperature used in Computer Game theory is misleading for physicists. CGT-temperature = value of the best move in go, this has very little relation do with a global description of unstability. (I propose to ban the term temperature from CGT, and replace it by value, unless someone can explain the link with temperature in physics, and shows some identical properties ;-) Le jeudi 1 mars 2007 08:27, Darren Cook a écrit : Just trying to understand what you guys are talking about... I realize it is a rather small picture, but do the terminal positions of 19x19 games between very strong players show more fractal qualities (or some other physics thing) than between, say, 15 kyu amateurs? Yes. Pro games are near a limit of (un)-stability. It seems one see the kind of physics he knows better (D.Doshay sees magnetic transition, D.Hillis percolation and spin glass, i see fluid dynamics and solidification ...) The common denominator is a critical state, with sudden change in properties, from a nearly homogeneous state. - Beginners are under critical - Pro near critical - (Quasi) Random players above critical. Or, from another angle, how do you imagine a very large board would look in a game between two very strong players? And would it be any different for 15 kyu players? For sure. On 19x19 one can estimate players strenght by seeing a position. 15 kyu is ugly ;) (overconcentrated, hyperstatic, not mixed, very little Work of stones/groups, ...) Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Big board. Temperature
Le jeudi 1 mars 2007 11:51, Jason House a écrit : alain Baeckeroot wrote: (I propose to ban the term temperature from CGT, and replace it by value, unless someone can explain the link with temperature in physics, and shows some identical properties ;-) While I bet most of us dislike the term, it seems to express an inherent concept. OK. Do you have some good link which clearly explain CGT temperature ? Nowhere i find something explaining why it is a good name, in the sense it is alike what all physicists call temperature (= more or less global average of underlying agitation*density). Renaming temperature to value will lose that. I know that when I first came across the term temperature, I had to look up what it meant and then learned something. If it was value, I never would have. I read some papers about thermography in go, and in this papers it was much more clear if i replace temperature with value. Some clever temperature stuff sounds trivial if you replace it by the word value. Like saying winning strategy = play the highest temperature point. Also except in small yose, it is hard to have a thermometer, about as hard as a valuemeter ;-) I agree that using value could also be misleading, but it seems much better name than temperature. maybe cgtemperate, or cvalue ? Cheers Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Big board. Temperature
Le jeudi 1 mars 2007 12:36, Nick Wedd a écrit : [EMAIL PROTECTED] writes (I propose to ban the term temperature from CGT, and replace it by value, unless someone can explain the link with temperature in physics, and shows some identical properties ;-) This would be confusing. A position in CGT has a value and a temperature. If you really want to use some other word for temperature, don't choose a word that already has a different meaning in the same context. Ah, this shows how much i misunderstood what i have read on the topic :-( By the way - I thought CGT stood for Combinatorial Game Theory. Yes, it was big brain lag. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board, ++physics
Le mercredi 28 février 2007 16:49, Oliver Lewis a écrit : On 2/23/07, David Doshay [EMAIL PROTECTED] wrote: On 22, Feb 2007, at 9:03 PM, alain Baeckeroot wrote: ... I made very slow progress to formalize this ... But the whole stuff is rather coherent in my mind. Then I envy you. I have been trying to bring what I know about MC in physics together with Go for over 20 years, and I get tripped up every time by temperature. I know how to deal with it properly in the physics, but I still have no idea at all about how to cool the MC Go simulations. The concept of temperature as used in CGT (combinatorial game theory) has not helped me. David - using Alain's analogy about temperature being related to mixing, isn't there a link with what Peter Drake calls the proximity heuristic in the MC playouts? A completely random MC player may be too hot and one that always plays next to already occupied points too cold. In between, it should be possible to define a temperature parameter which controls how close to the existing points a random MC playout happens. You could then test how strength varies with this temperature parameter. Is this what either of you had in mind? Yes :) Beginners do not mix enought, random players mix too much. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] scalability studies with UCT
Le jeudi 22 février 2007 17:00, Don Dailey a écrit : It appears that at 9x9 Lazarus needs more play-outs to equalize with gnugo. However, it also appears that at higher levels the superiority is even greater than in the 7x7 games. This is non-intuitive and probably not really the case - I assume this is due to sampling error since fewer games have been played on this boardsize. We also need to see the highest level lose a few games as this surely distorts the table significantly (you cannot get an accurate ELO rating if you don't win AND lose some games.) I may try 11x11 or 13x13 boards at a later time - focusing on lower levels since the longer levels are very time consuming. I will post an update to this in a few days once I've gathered substantially more data. Thanks for sharing your experiments. btw, GNU Go have databases for joseki and fuseki on 9X9 and 13x13. Maybe running with --nojosekidb --nofusekidb otpions would be better for scale comparison. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board. Torus ?
Le vendredi 23 février 2007 01:19, Matt Gokey a écrit : Here is a thought experiment to test: define the board only logically using a graph (nodes and neighbor nodes). No topological shape and no mesh layout over any shape is needed. If all nodes have exactly four neighbors, there is no method or algorithm that you can run to find an edge. All nodes will look equivalent. I was partly wrong, but i maintain this board is anisotropic : It contains squares and triangles, not equally spaced, all triangles are on the borders. Here is a simple algorithm to define the borders: Starting from one node and moving to the next, you can go to the Left, Front, Right or Back. - Insides nodes : if you go always to the Right, in 4 steps you are back to the initial position. - Near border nodes: there is one starting direction where you need only 3 steps to go back if you always turn to the Right - Border nodes: 9 steps. QED number of neighbors is not enought to define the topology, (i suspect this is well known ;-) So i maintain it is a cylinder, with 2 borders which correspond to our visual feeling. Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board, ++physics
Le jeudi 22 février 2007 01:16, David Doshay a écrit : It is pretty clear to me that, if the analogy to MC simulations in magnets is of any value, the temperature of the Go game you show is hotter than optimal. If the temperature were at the transition temperature, then each of the renormalized lattices would look just like a piece that size cut from the original. Because the details all get smaller, the original lattice is on the random, or hotter, side of the transition. Thank you very much for this work. I am mulling this over ... how to cool the Go simulation slightly from the pure MC that you did. Your analogy with physics encourage me to share other physical analogies. 1/ Cooling the simulation could be done by controlling the mixing rate and the density of stones. -Beginners'games are too cold, not enought mixed (=overconcentrated or very high viscosity, nearly solid state, not ignitable) -Professionnal games are probably near critical state (explosive conditions, gaz state) -MC-players are nearly random = too hot, too mixed, plasma state. 2/ Soap Bubbles = potential territory In addition to previous fluid state, i see hypothetical bubbles: - beginners makes some (less than 10) big bubbles, and their size and place are early known. (still too cold and too high viscosity) - professional can makes lots of bubbles (20+), but they are changing and turning very often and quickly - nearly-random makes a foam 3/ Solidification and cristal growth often comes to mind. Cristal growth need a seed to begin, generally it is a defect or some impurity. In go the defect are the corners: - they need less material to build a frontier (like soap bubbles) so corners are the beginning of the process of solidification or cristal growth. - the topology of the corner (2 libs, 3 libs and 4 libs) imposes the size and shape of a living group. - impurity is a captured stone/group 4/ shape/size resonance (un)fortunately the 19x19 size is just the critical size to have problems. -17x17 is too small, corners influence is too strong, it is quickly possible to take the border. (= 3 bubbles) -21x21 is too wide, it is not possible to quickly prevent easy invasion. (= 4 bubbles) (a strong go player told me: both are boring to play) -19x19 is critical, just in between, that's why it's fun (=3.1415 bubbles ;) I made very slow progress to formalize this, except density which is rather trivial, and a kind of temperature, but it needs a lot of go knowledge to work (something like gnugo internals), so it is not (yet) very suitable for a fast MC simulator. But the whole stuff is rather coherent in my mind. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board. Torus ?
Le mercredi 21 février 2007 02:10, Antonin Lucas a écrit : No need for those difficulties, you can play along this board : http://www.youdzone.com/go.html I think this is not a torus, even if each vertice has 4 neighbours. I can easily mentally transform this into a cylinder, with an rectangular lattice and additional connection on the borders to have 4 neighbours. But there is still a weird border topology, all direction are not equivalent. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] CGOS: Forfeit
Le mardi 20 février 2007 13:10, Heikki Levanto a écrit : P.S. Was there a good description of what a bot should do to finish a game earlier - my current ones play to the bitter end, with only 1-point eyes left. Might as well quit earlier if I can. Don't play moves which would be self-atari for opponent leaves 2 points eyes, after you have captured all dead stones. my 2 cents. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Monte-Carlo Go simulation
Le jeudi 8 février 2007 22:09, Sylvain Gelly a écrit : It seems i was ambiguous: I was speaking of the simulation player too. What i meant is a random simulation player is not biased, whereas a better simulation player is biased by its knowledge, and thus can give wrong evaluation of a position. I think we have to start defining what the bias. For me the bias is the difference between the expected value of the outcomes of playouts by the simulation player and the real minimax value. In this definition the uniform random simulation player is VERY biased and gnugo much less. OK, by i used bias in common sense, to mean that the strong simulator has preferences for some moves, and doesn't consider them equally, or worse doesn't consider some moves. So it will miss some good points due to its knowledge, whereas the random player will find the move. A trivial example is GNU Go: its analyze is sometimes wrong. Of course, if not computer go would be solved :-). Even if it is obviously much stronger than a random player, it would give wrong result if used as a simulation player. Hum, are you sure? I m 100% sure of this :-) I think that GnuGo with randomisation, (and much faster of course) would make a very good simulation player (much better than any existing simulation player). Even with randomization, GNU Go considers only a few dozen of possible moves, and makes systematic errors. Some times ago Rémi Coulom asked for positions illustrating computer stupidity (2006-11-22) http://computer-go.org/pipermail/computer-go/2006-November/007107.html and GNU Go provided some nice examples where its (wrong/misunderstood) knowledge induces a failure in play. One very impressive was GNU GO 3.6 not invading where obviously it is possible to invade (Steven Clark 2006-11-27) http://computer-go.org/pipermail/computer-go/2006-November/007184.html But a weaker player than GnuGo can make an even better simulation player. yes. David Doshay experiments with SlugGo showed that searching very deep/wide does not improve a lot the strength of the engine, which is bound by the underlying weaknesses of GNU Go. Yes, this a similar non trivial result. I think there are more existing experimental and theoritical analysis of this, though. Perhaps such an analysis already exist for MC also, it is just that I don't know. Or maybe i just understood nothing of what you explained ;) It was not really explanations, just thoughts. I have no the solution, just think that it is an interesting question, and that it may be discussed. May be from a strong explanation of this phenomenon could come new ideas. I understand all these counter examples, I just think that it is more complicated than that. Sylvain I fully agree. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] early results
Le samedi 27 janvier 2007 14:07, Don Dailey a écrit : On Fri, 2007-01-26 at 20:18 -0800, David Doshay wrote: I would highly recommend that you do your testing against a different Go engine. Self-play is a weak indicator. Cheers, David I agree that there is a pretty good amount of in-transitivity with self-play. However there is not a practical way to test with another program that I can see. You don't get reliable ELO ratings with programs significantly stronger or weaker. You can use the furiously fast and weak following programs: gnugo-1.2 (604 ELO on cgos 9X9 , 22k on kgs) liberty 1.0 (986 ELO , 14k) gnugo-2.0 (1236 ELO, 10k) They work with GTP thanks to Aloril, and are GPL licensed. A beginner with 3 month of play is between 10-15k on kgs For stronger one, and still very fast, gnugo 3.6 at level 0 should do it. Regards. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] early results
Le samedi 27 janvier 2007 14:58, alain Baeckeroot a écrit : Le samedi 27 janvier 2007 14:07, Don Dailey a écrit : I agree that there is a pretty good amount of in-transitivity with self-play. You can use the furiously fast and weak following programs: gnugo-1.2 (604 ELO on cgos 9X9 , 22k on kgs) liberty 1.0 (986 ELO , 14k) gnugo-2.0 (1236 ELO, 10k) Howerver, kgs says there is 4 stone difference between liberty-1.0 and gnugo-2.0 but Aloril tests show that in match, the difference is 14 stones (out of 1000 games) http://londerings.novalis.org/wlog/index.php?title=GNU_Go_games More fun test results at: http://londerings.novalis.org/wlog/index.php?title=Minor_items_2005 Diversity seems needed for calibration of rating. Regards. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Can a computer beat a human?
Le mercredi 24 janvier 2007 19:56, Stuart A. Yeates a écrit : Since no one has mentioned bounding memory, a complete lookup table (a complete table of correct moves, perfect-hashed by board state) should do the trick. With 10^170 legal position for 19x19 what would be the size of this table ? I m afraid we cannot build it with all the matter in visible universe. Cheers. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Can a computer beat a human?
Le mercredi 24 janvier 2007 23:06, Jim O'Flaherty, Jr. a écrit : You can if you use some sort of compression scheme...involving multiple values per quanta. I bet there's more than enough room...in the universe...probably just in your eyelash. True i forgot about fantastic quantum-computer, which so far solved only very specific and tiny problems or quantum mechanics. Normal quantum computer need more than 564 qubit to store the 10^170 pos, Maybe one can do better for go with a 361 qubit computer wich behave with go rules :) This need some serious amount of research ... Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Can a computer beat a human?
Le jeudi 25 janvier 2007 02:16, Lars Nilsson a écrit : On 1/24/07, alain Baeckeroot [EMAIL PROTECTED] wrote: True i forgot about fantastic quantum-computer, which so far solved only very specific and tiny problems or quantum mechanics. In the spirit of this, lets bring the quantum computer built at U of Illinois that computers its answer without actually running.. By placing our photon in a quantum superposition of running and not running the search algorithm, we obtained information about the answer even when the photon did not run the search algorithm, said graduate student Onur Hosten, lead author of the Nature paper. We also showed theoretically how to obtain the answer without ever running the algorithm, by using a 'chained Zeno' effect. http://www.news.uiuc.edu/news/06/0222quantum.html That should take care of any objection like the universe would end before the computer finished searching the entire game-tree. ;) Lars Nilsson Last paragraph begin by this sentence: While the researchers’ optical quantum computer cannot be scaled up,... and Kwiat’s team succeeded in counterfactually searching a four-element database using Grover’s quantum search algorithm. Grover's algorithm is O(N^1/2) instead of O(N) wich might not be enought for go. http://en.wikipedia.org/wiki/Grover%27s_algorithm Utilizing two coupled optical interferometers, nested within a third, I m afraid using 3 interferometer to search a 4 bit data base is slightly inefficient and costly :) If this could scale, it would need more than 500 interferometers to build a go-enabled machine. (or 500*501/2 ?) This is thermodynamical principe, you need an inifinetly big machine to do something infinitely small. This is already true for current computers, Moore law also describe the resources needed for building new more powerful computers (money, plants, complexity of the whole stuff ...) ,not doubling each 18 month , but regurlarly increasing, to such a point that financial or material resource can become the limiting factor soon. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Can a computer beat a human?
Le jeudi 25 janvier 2007 02:16, Lars Nilsson a écrit : In the spirit of this, lets bring the quantum computer built at U of Illinois that computers its answer without actually running.. By placing our photon in a quantum superposition of running and not running the search algorithm, we obtained information about the answer even when the photon did not run the search algorithm, said graduate student Onur Hosten, lead author of the Nature paper. We also showed theoretically how to obtain the answer without ever running the algorithm, by using a 'chained Zeno' effect. http://www.news.uiuc.edu/news/06/0222quantum.html That should take care of any objection like the universe would end before the computer finished searching the entire game-tree. ;) They implemented Zenbot :) http://senseis.xmp.net/?ComputerGoServer#toc69 Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] an idea... computer go program's rank vs time
Le dimanche 21 janvier 2007 19:02, Don Dailey a écrit : On Sun, 2007-01-21 at 13:34 -0200, Mark Boon wrote: To move up 200 ELO points in Go is usually not achieved by looking at more positions but by acquiring new concepts. To acquire a new concept in just a few hours is a rare thing. Some of these concepts would maybe take years to acquire if there wasn't someone to teach it to them. And you can gain new insights or concepts in a single short study period. Study with books or teacher can lead to quick improvement. But alone more time can be useless, one just don't see the correct thing. Historically, Dosaku discovered overconcentration strategy, but it needed 150 years to find a global counter strategy (the Shusaku kosumi). The few games i played against mogobot on 19x19 shows that it does not know overconcentration. And i can safely bet that increasing thinking time will not solve this, and computer cannot reach amateur 1d without this concept (either explicit or implicit in large patterns like Mango) The example you gave about studying a position for two hours and then showing it to someone 600 ELO points stronger. I think in Go someone who is 600 ELO points stronger can let the other player think about every move for a whole day and still beat him using on average just 10-20 sec. per move. It doesn't scale the way it does with Chess. I don't believe this at all. You should ;) But it's difficult to argue about it since it is extremely difficult to construct a fair experiment in this regard. Just play a game, analyse it carefully with all the books and internet, try to find the mistakes, and after ask a strong dan to comment the game ! He will instantaneoulsy tell you nice things, very clearly, but you just have not seen that. Also, we should keep in mind that amateur in go are just hmm amateur, and they don't master the game, maybe not even the basis. Maybe strong dan can efficiently analyse their own games, but for kyus even with very long time, nothing very good will show up, kyu are limited by their knowledge and poor reading. And programs on 19x19 are weak kyus. But I continue to be amazed that so many people think GO cannot be approached in a methodical logical way or that the human mind cannot break it down with the application of time and effort. I am amazed that people think human can do anything ;) we are not gods, we are just humans :) (this is off-topic phylosophy, and not a troll) By the way, can I assume that in world champion GO matches they use fast time controls because long time controls don't help in Go? Important tournament have long thinking time, and need 2 days like in chess. In such games, sometimes one player spend 1 hour on one move... But they are pros, and maybe some other reasons (financial, tv ...) can explain why some tournaments are reducing the time from 8h each to 3h. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] an idea for a new measure of a computer go program's rank.
Le dimanche 21 janvier 2007 01:23, Don Dailey a écrit : On Sat, 2007-01-20 at 15:34 -0700, Arend Bayer wrote: Hi Don, To put another perspective on it: If I had an hour for every move in a tournament game, I might play good EGF 5d level instead of average EGF 4d. That's a big difference from my perspective, but a small one when you compare it with the strength difference between me and a Korean who just became pro. This is understood. See what I said above.I don't really know how much 1 extra dan represents at this level - I think it translates to 200 or more ELO points. We can figure this out - what is the win expectancy of 5 dan over 4 dan without handicap? http://gemma.ujf.cas.cz/~cieply/GO/statev.html 4D 30.6% (out of 4000 games) Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Can Go be solved???... Komi
Le vendredi 12 janvier 2007 23:45, Chrilly a écrit : It would be interesting if the empirical Komi depends on the playing strength. It seems that for nearly random players, the komi is close to 0 (or maybe 1 under chinese rules to compensate for 1 more stone) Gunnar reported komi = 0.05 for brown (random except does not fill eyes) and Aloril reported komi = 1.5 for his veryweakbot. Also stats on even games, shows this for amateur players http://gemma.ujf.cas.cz/~cieply/GO/statev.html Playing even game against 1 rank stronger (so give W 6.5 komi instead of 0.5) shows very significant difference only for strong dan players, not before. For pro, i have been told that Lee Chang Ho is 2 points stronger than one of his opponent, and achieves nearly 70% wins against him (in even games) I would assume,that the tempo of Black is worth more for strong players. You seem to be right :) But there is on the other side the law of the balance of stupity. Also white loosed due too his lack of skills tempo/sente and the net effect is for all playing levels the same. Monte-Carlo Go is based on this law. Chrilly Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Useless moves in the endgame and slow move in beginning
Le mercredi 10 janvier 2007 10:32, Sylvain Gelly a écrit : Hello, Also on 19x19 mogos plays also some very slow moves in the beginning of 7 handicap game. [...] In 19x19, MoGo only considers local moves, near the move you just played or the last move it played. It even doesn't look at other moves, so the slow moves are mandatory. So placing handicap ala japanese (= on star points) would be an easy improvement. This placement is optimal repartition of strenght on the board, it would avoid over-concentration of handicap stones, and makes local moves better (as global advantage is already done with handi). But i find free placement more fun for white, even if it often gives easier game due to black misplacement of handi (very often overconcentrated) I did not try something like plays globally until the xxx move then locally. Perhaps it should help. Hmm its probably rather difficult to find the balance, local answer are very often needed. Good stuff would be : when no local answer is needed, then take initiative and play one big/global move. I agree there is lt to do in 19x19 :). Mogo is already very impressive :) Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Can Go be solved???... PLEASE help!
Le samedi 13 janvier 2007 16:46, Hideki Kato a écrit : CM-1's processing element is not a transputer but a custom (CMOS) 1-bit ALU with 4Ki bit of RAM. I know this is not essential but believe this kind of correction is old men's role :-). oops, true, my memory mixed up some old stuff :) Also 2^12 != 65536 but still CM1 was 12d, with 16 tiny proc at each corner of the hyper cube. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
