[computer-go] Is computer Havannah welcome here?
Hello to all, in 1979, Christian Freeling (NL) published Havannah, a very nice abstract board game for two players. It is a connection game with some territory components. Havannah had (commercially) good years: it was in the shortlist for the (German) Game of the Year in 1981 and 1982 and was produced by Ravensburger in several editions. Then it became a bit silent around Havannah. In 2002 Christian proposed a prize: for 10 years (so, until 2012) no computer program would win a single game (on board with side length 10) against him out of ten tries. If a program would achieve such a win, the programmer would get 1,000 Euro. Recently, Havannah has become available for online play on the server www.littlegolem.net . The game is well accepted there, with lots of tournaments, starting almost daily. In the fora of LittleGolem also discussion on computer Havannah has started, and there is now already one program (by Johannes Waldmann; based on UCT) which plays the game online on small boards. There would be even more discussion on computer Havannah in the LG fora but ... the master of LittleGolem is in big fear of spambots. So, you can write into his fora only, when you have played so and so MANY games before on LG. This excludes several competent persons/programmers from participation in the discussions. On the other hand, the computer Havannah scence is still too small to fill with life an own forum. Now, question: Would the computer-go mailinglist accept or welcome when the computer Havannah people uses this mailing list for the next few months? Some links: * The rules of Havannah http://www.littlegolem.net/jsp/blog/blog.jsp?blogid=7 * The fora of Little Golem (for those who want to read what exists) http://www.littlegolem.net/jsp/forum/forum2.jsp?forum=1 http://www.littlegolem.net/jsp/forum/forum2.jsp?forum=50 Registration on Little Golem is for free and simple. The fora can be read without being registered. * The website with the program of Johannes Waldmann http://dfa.imn.htwk-leipzig.de/havannah/ Ingo. -- Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Is computer Havannah welcome here?
Ingo Althöfer wrote: Now, question: Would the computer-go mailinglist accept or welcome when the computer Havannah people uses this mailing list for the next few months? Hi Ingo, I have just created a Havannah subforum in the game-programming forum: http://www.grappa.univ-lille3.fr/icga/phpBB3/index.php All Havannah programmers are welcome there. I have no objection to Havannah discussion being held here, though. Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Is computer Havannah welcome here?
On Sun, 2009-02-01 at 13:19 +0100, Ingo Althöfer wrote: Now, question: Would the computer-go mailinglist accept or welcome when the computer Havannah people uses this mailing list for the next few months? Not a problem for me. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Rules for remote play at the Computer Olympiad
Erik van der Werf wrote: Hi Remi, There is a simpler solution: do not allow remote play at all. I would be in favor of this solution. But this has no chance to make unanimity. Even with a strong majority in favor of that rule, Jaap would probably not accept it, anyways. As for stricter time controls; in principle I'm in favor. However, if you really want to enforce it we should have a real clock on the table like they have in the WCCC games. This would of course constitute a significant change from the usual relaxed (sloppy?) playing conditions... I believe we can still trust participants to count time correctly. Having to use a real clock is too annoying. The best solution regarding time control is probably what is done in the UEC Cup and EGC: connect programs to a server and let the server do time control. For a 3-round playoff I would propose that the third game uses komi bidding (one operator is given the right to choose the komi, and the other then chooses whether to play Black or White). An alternative is to play 4 rounds and use board-points as a tie-breaker. I am strongly against board-points as a tie-breaker. Most MC programs only optimize probability of winning. In any case, I think the 9x9-komi should go back to 6.5. I think it was moved to 7.5 to allow automated play on KGS. I believe allowing automated play on KGS with a strange komi is better than having no KGS play and a normal komi. Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Rules for remote play at the Computer Olympiad
On Feb 1, 2009, at 11:29 AM, Erik van der Werf wrote: Something else for the discussion. I would like to have a rule about mandatory displaying the thinking process of the program so that both operators have an idea of what is happening. Especially for remote play I think this is needed because now it is just too trivial to cheat. Do you want this just for 'remote' programs, or any program? What if the 'thinking process' is nothing intelligible for anyone else? Do we want to restrict programs made according to certain specifications which include that the thinking process is understandable? I don't know what the situation currently is in computer-Go, but I don't think the stakes are high enough to go over the trouble of cheating through a remote program (it's quite a lot of work). I have been accused of cheating once, but it was a rare thing to happen. I think either you allow remote programs and trust them, or you don't allow them at all. Anywhere in the middle will only cause more trouble. Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Rules for remote play at the Computer Olympiad
On Sun, Feb 1, 2009 at 2:54 PM, Rémi Coulom remi.cou...@univ-lille3.fr wrote: Erik van der Werf wrote: Hi Remi, There is a simpler solution: do not allow remote play at all. I would be in favor of this solution. But this has no chance to make unanimity. Even with a strong majority in favor of that rule, Jaap would probably not accept it, anyways. Well, we could at least try to convince him. With a strong majority in favor and a list of all the things that went wrong in China we at least have a good case. As for stricter time controls; in principle I'm in favor. However, if you really want to enforce it we should have a real clock on the table like they have in the WCCC games. This would of course constitute a significant change from the usual relaxed (sloppy?) playing conditions... I believe we can still trust participants to count time correctly. Having to use a real clock is too annoying. The problem is that the time info may simply be inaccessible when the connection breaks. The best solution regarding time control is probably what is done in the UEC Cup and EGC: connect programs to a server and let the server do time control. That is indeed a nice solution. What software was used for the UEC cup? How did they deal with programs that could not connect to the server; did some play manually? For a 3-round playoff I would propose that the third game uses komi bidding (one operator is given the right to choose the komi, and the other then chooses whether to play Black or White). An alternative is to play 4 rounds and use board-points as a tie-breaker. I am strongly against board-points as a tie-breaker. Most MC programs only optimize probability of winning. I don't like it much either; any tie breaker is bad in some sense, but I still prefer board-points over a coin-toss. In any case, I think the 9x9-komi should go back to 6.5. I think it was moved to 7.5 to allow automated play on KGS. I believe allowing automated play on KGS with a strange komi is better than having no KGS play and a normal komi. No, I originally proposed it because the official Chinese rules had switched to 7.5 komi. However, this was for 19x19 games. Anyway, I don't think the KGS restrictions are a good argument. Ideally we could persuade wms to have free komi setup under kgs-chinese rules, but otherwise it is still easy enough to let you program ignore the gtp-komi setup from kgs. Erik ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Rules for remote play at the Computer Olympiad
Erik van der Werf wrote: For a 3-round playoff I would propose that the third game uses komi bidding (one operator is given the right to choose the komi, and the other then chooses whether to play Black or White). An alternative is to play 4 rounds and use board-points as a tie-breaker. I am strongly against board-points as a tie-breaker. Most MC programs only optimize probability of winning. I don't like it much either; any tie breaker is bad in some sense, but I still prefer board-points over a coin-toss. With a komi of 7.5, top programs still lose games as white rather frequently. It is really not the coin toss that decides the winner. If board-points are taken into consideration, then programs that maximize score have an advantage. I really don't want to have to implement that kind of strategy in my program, just for the sake of improving its chance to win a playoff. Also, not allowing programs to resign is ugly. With top programs playing so few games against each other, the result of the whole tournament is a coin toss, anyways. Also, I don't like bidding: opening book preparation depends a lot on komi. Programmers should not have to prepare more than one opening book. Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Rules for remote play at the Computer Olympiad
Hi Remi, There is a simpler solution: do not allow remote play at all. Something else for the discussion. I would like to have a rule about mandatory displaying the thinking process of the program so that both operators have an idea of what is happening. Especially for remote play I think this is needed because now it is just too trivial to cheat. As for stricter time controls; in principle I'm in favor. However, if you really want to enforce it we should have a real clock on the table like they have in the WCCC games. This would of course constitute a significant change from the usual relaxed (sloppy?) playing conditions... For a 3-round playoff I would propose that the third game uses komi bidding (one operator is given the right to choose the komi, and the other then chooses whether to play Black or White). An alternative is to play 4 rounds and use board-points as a tie-breaker. In any case, I think the 9x9-komi should go back to 6.5. Erik On Sun, Feb 1, 2009 at 11:18 AM, Rémi Coulom remi.cou...@univ-lille3.fr wrote: Hi, During the Computer Olympiad in Beijing, some remote participants had problem connecting to their remote machines, which created many unpleasant incidents. In order to avoid these problems in the next Olympiad, I believe we need better rules for remote play. Here is what I suggest: - The start of a round must not be delayed until remote participants connect to their remote machine. In case of any technical problem with the connection, remote participants must either play locally or forfeit the game. If they take a lot of time to connect, that time must be substracted from their thinking time. - If, for any reason, we do not have time to play all the scheduled rounds, playing less rounds is better than delaying the last round to a date when some participants have to forfeit their game because they cannot attend. - It is less important, but I would also like to suggest that a 7-round playoff is much too long. 3 games are enough for 9x9. And the 9x9 playoff must be scheduled right at the end of the 9x9 tournament, so that participants in the 9x9 tournament do not have to wait for the end of the 19x19 tournament. These rules would avoid most of the incidents of the previous Olympiad. We could propose them to the tournament director if everybody agrees. Rémi ___ 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] Rules for remote play at the Computer Olympiad
Hi, During the Computer Olympiad in Beijing, some remote participants had problem connecting to their remote machines, which created many unpleasant incidents. In order to avoid these problems in the next Olympiad, I believe we need better rules for remote play. Here is what I suggest: - The start of a round must not be delayed until remote participants connect to their remote machine. In case of any technical problem with the connection, remote participants must either play locally or forfeit the game. If they take a lot of time to connect, that time must be substracted from their thinking time. - If, for any reason, we do not have time to play all the scheduled rounds, playing less rounds is better than delaying the last round to a date when some participants have to forfeit their game because they cannot attend. - It is less important, but I would also like to suggest that a 7-round playoff is much too long. 3 games are enough for 9x9. And the 9x9 playoff must be scheduled right at the end of the 9x9 tournament, so that participants in the 9x9 tournament do not have to wait for the end of the 19x19 tournament. These rules would avoid most of the incidents of the previous Olympiad. We could propose them to the tournament director if everybody agrees. Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] JFFoS + Criticality Heuristic + Parameter Optimization
Hi, I have just come back from a trip to Japan. I was invited to give presentation at the JFFoS Symposium and the UEC. You can now find slides of my presentations on my web page: The Monte-Carlo Revolution in Go http://remi.coulom.free.fr/JFFoS/JFFoS.pdf (Nothing new here. A simple presentation for a general audience) Criticality: a Monte-Carlo Heuristic for Go Programs http://remi.coulom.free.fr/Criticality/ Local Quadratic Logistic Regression for Stochastic Optimization of Parameters http://remi.coulom.free.fr/QLR/ (This is work in progress. I will very soon update that page with a more detailed paper that I will submit to ACG 12) I thank all the persons at JFFoS and UEC who invited me. Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Rules for remote play at the Computer Olympiad
On Sun, Feb 1, 2009 at 3:03 PM, Mark Boon tesujisoftw...@gmail.com wrote: On Feb 1, 2009, at 11:29 AM, Erik van der Werf wrote: Something else for the discussion. I would like to have a rule about mandatory displaying the thinking process of the program so that both operators have an idea of what is happening. Especially for remote play I think this is needed because now it is just too trivial to cheat. Do you want this just for 'remote' programs, or any program? Preferably any, but I'm naturally more suspicious of programs that play remotely :-) Currently the rule is that logs must be made available to the TD on request when there is a suspicion. However, it is hard to be precise when no information is displayed during the game. What if the 'thinking process' is nothing intelligible for anyone else? Do we want to restrict programs made according to certain specifications which include that the thinking process is understandable? Well, most programs can in principle display the move they are currently considering best, and usually also a principal variation, winning probability, etc. When a program is radically different from anything else, cannot show any intermediate results, and a conflict arises, then the author will probably have to try to convince the TD, for example by showing the source code. I don't know what the situation currently is in computer-Go, but I don't think the stakes are high enough to go over the trouble of cheating through a remote program (it's quite a lot of work). I have been accused of cheating once, but it was a rare thing to happen. With programs playing on KGS cheating is easy. Also, I think the stakes are increasing because we are now getting in the low amateur dan-levels. Erik ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Is computer Havannah welcome here?
There's already a havannah section on this game programming forum: http://www.grappa.univ-lille3.fr/ -- which could use an influx of traffic. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Rules for remote play at the Computer Olympiad
I'm in favor of starting rounds on time, with remote machines either getting a time penalty or playing locally (their choice). The clock should run for the remote machine as soon as the round is scheduled to start. Once a round is started the remote program cannot switch. For example if it starts to play locally, then the connection comes up, it must continue locally. A similar rule must be in effect for local players. If there is a local hardware failure and the local machine needs to be replaced with a new one, the clock should start on time and should continue to run while the backup local machine is prepared. I'm also in favor of allowing restarts while the clock is running. If a local machine crashes, the program can be restarted (continuing from the position at the crash), while the clock is running. If a remote connection is lost during a game, the game can be continued after the connection is repaired, but the clock runs while the hardware problem is being fixed. One possible issue, if a remote connection goes down permanently, can the remote program continue on local hardware? I think this should be allowed (again with the clock running while hardware is switched). The only problem might be if we allow rounds to start early to make the tournament go faster, especially if there is a round robin. Both programs should agree to an early start and if one has connection issues it should be OK to delay to the scheduled start with no penalty. I agree that the tournament has to have a predefined completion time, and all rounds much be completed by that time. There might be fewer rounds, or some rounds might have faster time limits. People make travel plans and it can be expensive to change them. David -Original Message- From: computer-go-boun...@computer-go.org [mailto:computer-go- boun...@computer-go.org] On Behalf Of Rémi Coulom Sent: Sunday, February 01, 2009 2:19 AM To: computer-go Subject: [computer-go] Rules for remote play at the Computer Olympiad Hi, During the Computer Olympiad in Beijing, some remote participants had problem connecting to their remote machines, which created many unpleasant incidents. In order to avoid these problems in the next Olympiad, I believe we need better rules for remote play. Here is what I suggest: - The start of a round must not be delayed until remote participants connect to their remote machine. In case of any technical problem with the connection, remote participants must either play locally or forfeit the game. If they take a lot of time to connect, that time must be substracted from their thinking time. - If, for any reason, we do not have time to play all the scheduled rounds, playing less rounds is better than delaying the last round to a date when some participants have to forfeit their game because they cannot attend. - It is less important, but I would also like to suggest that a 7-round playoff is much too long. 3 games are enough for 9x9. And the 9x9 playoff must be scheduled right at the end of the 9x9 tournament, so that participants in the 9x9 tournament do not have to wait for the end of the 19x19 tournament. These rules would avoid most of the incidents of the previous Olympiad. We could propose them to the tournament director if everybody agrees. Rémi ___ 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] Rules for remote play at the Computer Olympiad
I like having something mandatory, so we dont need to ask for it. Many Faces did not have this, because the backend and the GUI only communicated moves. But the backend was creating a log file and it would be easy to display the log with regular updates in a different window. To prevent cheating, the display needs to be real time. Log files created later or even once per move dont prevent cheating. For example, the cheater can choose a move, then ask a program to ponder on that move, and produce a log that shows a nice PV for the move the cheater played. If this rule is to be in effect, we need to know long before the contest, since it might not be easy to code and debug. David -Original Message- Something else for the discussion. I would like to have a rule about mandatory displaying the thinking process of the program so that both operators have an idea of what is happening. Especially for remote play I think this is needed because now it is just too trivial to cheat. Erik On Sun, Feb 1, 2009 at 11:18 AM, Rémi Coulom remi.cou...@univ-lille3.fr wrote: Hi, During the Computer Olympiad in Beijing, some remote participants had problem connecting to their remote machines, which created many unpleasant incidents. In order to avoid these problems in the next Olympiad, I believe we need better rules for remote play. Here is what I suggest: - The start of a round must not be delayed until remote participants connect to their remote machine. In case of any technical problem with the connection, remote participants must either play locally or forfeit the game. If they take a lot of time to connect, that time must be substracted from their thinking time. - If, for any reason, we do not have time to play all the scheduled rounds, playing less rounds is better than delaying the last round to a date when some participants have to forfeit their game because they cannot attend. - It is less important, but I would also like to suggest that a 7-round playoff is much too long. 3 games are enough for 9x9. And the 9x9 playoff must be scheduled right at the end of the 9x9 tournament, so that participants in the 9x9 tournament do not have to wait for the end of the 19x19 tournament. These rules would avoid most of the incidents of the previous Olympiad. We could propose them to the tournament director if everybody agrees. Rémi ___ 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] Rules for remote play at the Computer Olympiad
I think any requirement to show thinking in real time must apply to all programs equally. Otherwise some programs are at a disadvantage because they have to code a thinking display instead of making the program stronger. David -Original Message- From: computer-go-boun...@computer-go.org [mailto:computer-go- boun...@computer-go.org] On Behalf Of Erik van der Werf Sent: Sunday, February 01, 2009 6:26 AM To: computer-go Subject: Re: [computer-go] Rules for remote play at the Computer Olympiad On Sun, Feb 1, 2009 at 3:03 PM, Mark Boon tesujisoftw...@gmail.com wrote: On Feb 1, 2009, at 11:29 AM, Erik van der Werf wrote: Something else for the discussion. I would like to have a rule about mandatory displaying the thinking process of the program so that both operators have an idea of what is happening. Especially for remote play I think this is needed because now it is just too trivial to cheat. Do you want this just for 'remote' programs, or any program? Preferably any, but I'm naturally more suspicious of programs that play remotely :-) Currently the rule is that logs must be made available to the TD on request when there is a suspicion. However, it is hard to be precise when no information is displayed during the game. What if the 'thinking process' is nothing intelligible for anyone else? Do we want to restrict programs made according to certain specifications which include that the thinking process is understandable? Well, most programs can in principle display the move they are currently considering best, and usually also a principal variation, winning probability, etc. When a program is radically different from anything else, cannot show any intermediate results, and a conflict arises, then the author will probably have to try to convince the TD, for example by showing the source code. I don't know what the situation currently is in computer-Go, but I don't think the stakes are high enough to go over the trouble of cheating through a remote program (it's quite a lot of work). I have been accused of cheating once, but it was a rare thing to happen. With programs playing on KGS cheating is easy. Also, I think the stakes are increasing because we are now getting in the low amateur dan-levels. Erik ___ 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] JFFoS + Criticality Heuristic + Parameter Optimization
Hi, The criticality stuff looks really interesting. Do you apply it with the offline knowledge, or as a RAVE prior value, or otherwise? It looks like you precalculate (before the MTCS) the ownership + criticality map, maybe it can be extracted from playouts in the MTCS as well? ibd Original-Nachricht Datum: Sun, 01 Feb 2009 11:01:12 +0100 Von: Rémi Coulom remi.cou...@univ-lille3.fr An: computer-go computer-go@computer-go.org Betreff: [computer-go] JFFoS + Criticality Heuristic + Parameter Optimization Hi, I have just come back from a trip to Japan. I was invited to give presentation at the JFFoS Symposium and the UEC. You can now find slides of my presentations on my web page: The Monte-Carlo Revolution in Go http://remi.coulom.free.fr/JFFoS/JFFoS.pdf (Nothing new here. A simple presentation for a general audience) Criticality: a Monte-Carlo Heuristic for Go Programs http://remi.coulom.free.fr/Criticality/ Local Quadratic Logistic Regression for Stochastic Optimization of Parameters http://remi.coulom.free.fr/QLR/ (This is work in progress. I will very soon update that page with a more detailed paper that I will submit to ACG 12) I thank all the persons at JFFoS and UEC who invited me. Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How to properly implement RAVE?
By the way, I got about 75 ELO points (1650-1720) with light playouts out of RAVE. Do you think this is in the expected range? It's not really similar to the 20%-60% win rate rise vs. GnuGo described in some papers... At the moment I'm also tuning the bias in the range 0.001-0.1. Given uniformly random (light) playouts, is the bias expected to be bigger than with heavy playouts, meaning the constant has to be bigger aswell? Cheers, ibd -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] JFFoS + Criticality Heuristic + Parameter Optimization
Isaac Deutsch wrote: Hi, The criticality stuff looks really interesting. Do you apply it with the offline knowledge, or as a RAVE prior value, or otherwise? It looks like you precalculate (before the MTCS) the ownership + criticality map, maybe it can be extracted from playouts in the MTCS as well? ibd I use it as a pattern feature in my pattern-learning scheme described in the Amsterdam 2007 paper. I am not sure what you mean by offline knowledge or RAVE prior value. My system computes a gamma value for each move. This value is used in two ways: - progressive widening: moves with bad gamma are pruned - progressive bias: the value of a move, instead of w/n is (w+c*gamma) / n, with c a constant. I don't precalculate before MCTS. Criticality, like point owner, is re-calculated for each node of the tree, as it grows. It is computed from MCTS playouts. More precisely, search at a node starts without MC features. Move gammas are all computed with static features only. After a few playouts, gammas are updated with MC features, computed from the outcome of the first MC playouts. Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How to properly implement RAVE?
How many playouts per second do you get with each version? Sent from my iPhone On Feb 1, 2009, at 4:46 PM, Isaac Deutsch i...@gmx.ch wrote: By the way, I got about 75 ELO points (1650-1720) with light playouts out of RAVE. Do you think this is in the expected range? It's not really similar to the 20%-60% win rate rise vs. GnuGo described in some papers... At the moment I'm also tuning the bias in the range 0.001-0.1. Given uniformly random (light) playouts, is the bias expected to be bigger than with heavy playouts, meaning the constant has to be bigger aswell? Cheers, ibd -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit al len: http://www.gmx.net/de/go/multimessenger01 ___ 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] Announcements
Could I encourage people to announce any computer-go-related presentations they are giving in advance. (As well as new papers, related conferences, etc.) As an example, I might have managed to attend Remi's recent talks, but didn't hear about them in time. (Most mailing lists are 90+% lurkers, so even if giving a talk in Timbuktu there may turn out to be someone living locally!) Darren -- Darren Cook, Software Researcher/Developer http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic open source dictionary/semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] JFFoS + Criticality Heuristic + Parameter Optimization
Darren Cook wrote: I don't precalculate before MCTS. Criticality, like point owner, is re-calculated for each node of the tree, as it grows. It is computed from MCTS playouts. More precisely, search at a node starts without MC features. Move gammas are all computed with static features only. After a few playouts, gammas are updated with MC features, computed from the outcome of the first MC playouts. Hi Remi, Does this mean you play one playout then recalculate the criticality map, then play one more playout, and recalculate again? Just curious how much percentage of CPU is spent on those recalculations, and if there is any strength difference only recalculating after every N playouts? (If doing say 100K playouts, it seems to me that N could be as high as 500 or 1000 and the idea would still be useful; or just once after 1000 playouts might even be enough?) I only calculate once, after N=128 playouts. I did not try very hard to optimize N. I was using N=64 before (when I was using only point owner information). But criticality is a second-order feature, and accurate estimation requires more playouts. N=128 is still very noisy. Maybe it is better to delay it further than N=128. Also, you introduce it in the context of semeai. Does it also help with understanding of seki? (For instance, with the position I posted a couple of weeks ago, remove any heuristics or patterns that stop the program playing moves that reduce its liberties and then rely on the criticality map to discover when that is good or bad.) I did not try your position. But understanding seki is mostly a matter of playout policy. I do not use criticality in playouts. Crazy Stone already understands seki in playouts. Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
