Re: [computer-go] Re: Hahn system tournament and MC bots
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). regards, Vlad ___ 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
On Thu, Nov 26, 2009 at 12:06, Alain Baeckeroot alain.baecker...@laposte.net wrote: 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) That's a good suggestion, thanks. I still have a feeling that the values aren't really random, so I'm not sure if regular statistics will work, but on the other hand MCTS does work, so they might too. best regards, Vlad ___ 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
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. 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? best regards, Vlad ___ 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
On Wed, Nov 25, 2009 at 12:51, Alain Baeckeroot alain.baecker...@laposte.net wrote: Le 25/11/2009 à 12:39, Vlad Dumitrescu a écrit : 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) Reducing the value to -17 is losing a lot of information. Another move might have 20% chances of +10 and 80% chances of -24 giving -17, are they really just as good? Also, not all 10% are created equal :-) Let's say there are 10 possible moves, so only one leads to a win. It's a big difference if that move is forced or obvious (for a human player), or if it is something that only a professional would try after thinking for an hour or more. I don't know how to instruct a computer to take that into account... To put this another way, I think that it would be a step in the right direction to be able to handle the uncertainities of the values in the tree. Maybe some already do that? best regards, Vlad ___ 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
On Wed, Nov 25, 2009 at 14:18, Nick Wedd n...@maproom.co.uk wrote: 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) Reducing the value to -17 is losing a lot of information. Another move might have 20% chances of +10 and 80% chances of -24 giving -17, are they really just as good? If you are using Hahn scoring, yes, they are just as good. With any other form of scoring, the lost information matters. Ok, then we are probably having completely different mental models of what we are talking about :-) 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. If using a more generic approach, the strategy can be parametrized and optimized (both offline and online), hopefully resulting in a better gameplay. best regards, Vlad ___ 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
On Wed, Nov 25, 2009 at 15:49, Alain Baeckeroot alain.baecker...@laposte.net wrote: 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 ? I wasn't going to go that far. The kind of detailed biasing you mention belongs to a different layer, IMHO. I was only considering the amount of risk one would like to take, so that there is a difference between a move with outcomes ((+10, 10%),(-20, 90%)) and ((+9, 20%),(-23.5, 80%)) which with a simple linear weighting both yield -17. Depending on the situation, I might even rank higher ((+3, 50%), (-42, 50%)) that gives -20 with the simple linear approach. The strategy can be dynamic, both in terms of opponent (if it's stronger, play more carefully) and as the game proceeds (my previous invasion failed, be more careful) (we go into endgame, I'm ahead, play conservatvely). best regards, Vlad ___ 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
Hi all, If I may get out of lurking mode and try to understand the problem here... IMHO there is another issue here that creates a difference and makes the strategies for normal go and hahn go incomparable. I has been touched upon by previous posters, but not spelled out. Normal go strategy applies as-is to both a single game and to a whole tournament. One plays the in the same way no matter what happens outside the current game. Hahn go strategy is only relevant for a tournament (otherwise one can simply play normal go, it doesn't matter by how many points one wins). And thus it includes a meta-strategy involving the results in the other games and knowledge of one's opponents. Using a hahn strategy in a single game or in a tournament that is scored as normal go will probably yield worse performance, like it was pointed out here before, because it requires more processing whose results are then ignored. Or am I missing something? best regards, Vlad ___ 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
On Tue, Nov 24, 2009 at 11:18, Tapani Raiko pra...@cis.hut.fi wrote: Hi, Hahn go strategy is only relevant for a tournament (otherwise one can simply play normal go, it doesn't matter by how many points one wins). And thus it includes a meta-strategy involving the results in the other games and knowledge of one's opponents. One can also play a single game for instance with money bets based on the Hahn points, which makes Hahn go strategy relevant also for a single game. Right. Didn't think about that. The idea however is that it's another game altogether than normal go and we really can't compare playing strength between them. In the tournament setting, in your interpretation, the goal is not to maximize the (expected) number of Hahn points in each game, but to maximize the probability of having more Hahn points at the end of the tournament than your opponent(s). It would also be useful to see what is happening on the other boards during a tournament round, since it might affect your point goal. It might even be useful to spend time waiting in order to gather information from the other boards. ;-) Exactly. The goal is to win the tournament and this involves more than just playing games. The meta-strategy is probably independent of which games are played, but it affects the strategy chosen in each instance of a game. Of course, one can just ignore all that and just win all games with 40 points or more. :-) Then one can use a normal go strategy with the appropriate komi. regards, Vlad ___ 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
On Tue, Nov 24, 2009 at 11:18, Tapani Raiko pra...@cis.hut.fi wrote: One can also play a single game for instance with money bets based on the Hahn points, which makes Hahn go strategy relevant also for a single game. Just a thought: if the bet is I can beat you with X points on the board or more, then it's exactly like trying to win a normal game with X points komi, right? Are there any other kind of bets? regards, Vlad ___ 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
On Tue, Nov 24, 2009 at 14:20, Tapani Raiko pra...@cis.hut.fi wrote: Vlad Dumitrescu wrote: Just a thought: if the bet is I can beat you with X points on the board or more, then it's exactly like trying to win a normal game with X points komi, right? Are there any other kind of bets? Yes, having to pay the amount of Hahn points in money. The Hahn system originates from the Korean betting system, mentioned also in the novel First Kyu by Sung-Hwa Hong. Both players deposit the amount for the maximum loss under the go board and the money is split after the game according to the score. Thanks, I had read that. So the only difference in play is when losing, one has to keep trying to lose as little as possible, resigning isn't an option. When ahead, there's no reason to try to win big, unless the goal is to reach a certain amount of points in a certain number of games. (Programs aren't greedy in the same way we people are :-) regards, Vlad ___ 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
On Tue, Nov 24, 2009 at 15:45, Jeff Nowakowski j...@dilacero.org wrote: On Tue, Nov 24, 2009 at 03:06:51PM +0100, Vlad Dumitrescu wrote: So the only difference in play is when losing, one has to keep trying to lose as little as possible, resigning isn't an option. When ahead, there's no reason to try to win big, unless the goal is to reach a certain amount of points in a certain number of games. (Programs aren't greedy in the same way we people are :-) Let's assume that the program will play for a gambler, and will play many (an indefinite number) of independent games. Then I think no reason to try to win big is wrong. The rational approach to gambling is to maximize your expected value for each game. Yes, but that doesn't necessarily mean that the strategy should be to push each game to the limit. Trying to win with a large margin is less safe than with a small one, so it depends on the gambler's mindset. So now the problem becomes harder -- you have to realistically guess the risk vs reward over a spectrum of points. And also possibly add knowledge about the opponent(s). I think this game is clearly more difficult than a binary win/loss game. This is exactly my opinion, too. regards, Vlad ___ 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
On Tue, Nov 24, 2009 at 16:11, Nick Wedd n...@maproom.co.uk wrote: Suppose my attempts to read the game tell me If I seal off my territory at A, I will win by 5 points. If instead I invade at B, then 70% of the time I will win by 25 points, 30% of the time I will lose by 5 points. If I am playing Go, I will prefer A. If I am playing bang neki, I will prefer B. Sure. But different gamblers have different break-even limits, i.e. different mindsets. Some are cautious and prefer 80% for those 25 points; some are reckless and would go for B even with 60%. Anyway, we are digressing. Thank you all for the response! regards, Vlad ___ 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
2009/11/24 terry mcintyre terrymcint...@yahoo.com: Please try to explain why the hahn calculation isn't working in a normal game so as to ensure a win. I'm talking about strong human players. In my view, we have hahn: object of the game = max board score normal: object of the game = board score komi Both seem just as easy and interesting. If you are winning in the Hahn sense, your score also exceeds komi; but Hahn scoring - either by accumulating points in a tournament ranking, or converting points to dollars in bang neki fashion, gives you incentive to achieve larger scores. Thank you,Terry, for the explanation. I understand (and I think I already said it too) that normal go is easier. What Nick said before was: This calculation is correct for Hahn scoring, but not for normal scoring, or indeed any other way of scoring. The way I read it, just because one way is easier doesn't mean it is incorrect in other cases. My question was about why he thinks the calculation is incorrect for other ways of scoring. best regards, Vlad ___ 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
On Tue, Nov 24, 2009 at 23:58, Nick Wedd n...@maproom.co.uk wrote: Vlad Dumitrescu vladd...@gmail.com writes Please try to explain why the hahn calculation isn't working in a normal game so as to ensure a win. I'm talking about strong human players. Are you talking about omniscient players? If not, I have already answered: Suppose my attempts to read the game tell me If I seal off my territory at A, I will win by 5 points. If instead I invade at B, then 70% of the time I will win by 25 points, 30% of the time I will lose by 5 points. If I am playing Go, I will prefer A. If I am playing bang neki, [or Hahn scoring] I will prefer B. Hi Nick, I'm not talking about omniscient players. My problem with your answer above is that 70% of the time I will win by 25 points contains implicit assumptions, which affect the exact numbers and thus the choice one would make. How is the 70% calculated? Against whom? The ratio will be different against someone 3 stones stronger, against someone of my strength or someone three stones weaker. Do the playlines leading to a 25 points win involve a stupid mistake that the opponent must make, or are they about luring him gently in a non-optimal position? Or is it a big fight that is involved, I can't read it but feel 70% confident I can win it? Opponent modeling will also play a role and then the percentage can't even be computed anymore, the player has to guess, to gamble. It is here that one's personality comes to play. This guy doesn't like to invade deep, let's expand this moyo. That guy is a fierce fighter, better to play it safe. Personally, I would almost always play A in a tournament situation (or with money involved). In a Hahn tournament, it depends on the overall situation, if a small win in this game isn't enough then I must try B if I want to win. If it's for fun, then exploring B is much more interesting and offers more opportunity to learning. best regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Erlang and computer go
On Fri, Aug 14, 2009 at 22:16, Carter Chengcarter_ch...@yahoo.com wrote: I have been considering experimenting with Erlang as a means of prototyping certain aspects of a computer go program and I was curious if anyone has tried this already. How does a system like Erlang compare performance wise to writing something in say C/C++ (fastest) or Java? Hi, I have started for some year ago to try to withe an Erlang library to play go, but got distracted by other stuff. Erlang has a lot of nice features, but in this particular instance speed isn't one of them. The main issue is that there are no mutable data structures, so for all processing there will be a lot of copying. This is somewhat simplified, of course, but the conclusion still holds. I don't have any hard numbers, it would depend very much upon the choice of data structure. Erlang would be good at coordinating work done by simple and fast slaves, written in C for example. It would be very appropriate for a distributed engine. The problem here is that the problem of synchronizing a distributed UCT tree hasn't been solvet yet, to my knowledge. regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Presentation of my personnal project : evolution of an artificial go player through random mutation and natural selection
On Tue, Feb 24, 2009 at 08:40, Daniel Burgos dbur...@gmail.com wrote: I worked on this some time ago. I did not use neural networks but patterns with feedback. The problem with feedback is that it is difficult to know when it reaches its final state. Usually you get oscillations and that state never happens. I tried to solve that using timeouts, but what I got were random players. One way to handle this is to let the feedback loopbacks have a significant atenuation, so that the system will eventually settle to an equilibrium if the inputs don't change anymore. As with anything else, YMMV. regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Monte-Carlo Tree Search reference bot
On Wed, Dec 3, 2008 at 05:17, Mark Boon [EMAIL PROTECTED] wrote: I had set myself as an arbitrary goal that it should do at least 20K playouts. But with real liberties, AMAF and a RAVE formula I got stuck in the 16K-17K range. According to my profiler that is mostly due to the expensive formula used to compare nodes, where it says it spends 25% of total time. The formula I'm using is: beta * (virtual-win-ratio + RAVE) + (1-beta) * (win-ratio + UCT) beta = 1 - log(parent-visits) / 20 UCT = exploration-factor *sqrt( log(parent-visits) / (nr-visits+1) ) RAVE = exploration-factor *sqrt( log(parent-visits) / (nr-virtual-visits+1) ) Hi, This is probably something you already do, but just in case you don't, here comes a simple optimization trick: since parents-visits is an integer value and in a somewhat bounded range (0..max_playouts), the logarithm can be precomputed in a table. Then even sqrt(log()) can be precomputed also. Similarly, a table with sqrt(integer()) can be used for the other values. best regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] small study
On Sun, Oct 26, 2008 at 21:22, Don Dailey [EMAIL PROTECTED] wrote: I'm doing a small study of the scalability of the reference bot at various numbers of playouts. I still need a lot more games, but in general you eventually start to see a point of diminishing returns for each doubling. I didn't take it any farther than 8192, but my guess is that anything beyond this is not going to give you much. I imagine that it approaches some hypothetical level in an asymptotic way. I may test 16384 later. Hi! I may remember incorrectly, but didn't your previous scalability test show that when a new player was added at the top, the previous top players' ratings got a slight boost too? Meaning that at the top (and possibly at the bottom too, but that's unimportant) the levels may be a little squashed by the border effect? It's very possible that the effect is negligible, but we can't know until we measure... The differences between adjacent levels look very symmetrical at the top and bottom, so a few more levels might reveal what is going on. best regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] reference bots java and C
On Tue, Oct 21, 2008 at 00:11, Don Dailey [EMAIL PROTECTED] wrote: I would be willing for people to hosts these tests on a variety of systems. Sorry, I misunderstood your original announcement. I suppose you're going to describe the whole setup once you get to that part, so I will wait. best regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] reference bots java and C
On Mon, Oct 20, 2008 at 22:30, Don Dailey [EMAIL PROTECTED] wrote: I will build a web site soon and hope others participate with conforming programs in any language or system. The format I would like is that you zip it up and it unzips to a directory (or directory tree.) Preferably cross platform but not a requirement. (My C version probably isn't cross platform without at least some minor changes.) Cool, another good idea that is at least as good as CGOS :-) If the reference bot is in an interpreted language, how will you handle installing the runtime? What OS and distribution are you running the bots on? best regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming (languages) light-simulation contest
Hi, On Wed, Oct 15, 2008 at 02:51, Claus Reinke [EMAIL PROTECTED] wrote: So, once you've got your representations (sets/bitmaps, arrays/hashtables, etc.) implemented in libraries, the programming language itself may not matter much any more (recursion simplifies things, but whether one recursively collects sets of liberties in imperative, functional, logic, or object-oriented code may not make much difference - even assembler might be manageable, given such libraries, just that it might doom your code when you move to a different machine in future). Good points (even those I didn't quote). I'd just like to point out that once the representations and libraries above are implemented, one effectively has implemented a go-specific language! One could in principle give it a concrete syntax different than the one of the host language, but it's not certain it would be worth it. best regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Paper for AAAI (David Silver) PDF problem
Hi On Mon, Apr 7, 2008 at 12:48 PM, Jacques Basaldúa [EMAIL PROTECTED] wrote: http://www.cs.ualberta.ca/~silver/research/publications/files/MoGoNectar.pdf Your paper has a PDF problem concerning embedded font BXGQFO+CMR12. I have used different versions of Adobe Reader. I even updated one of the computers to the latest version and I still cannot read any mathematical expressions. I guess this applies to all Windows users. FYI, it works fine for me (on Windows). regards, Vlad -- ...__o ...\, ( )/ ( )... ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Should 9x9 komi be 8.0 ?
Hi, On Wed, Feb 13, 2008 at 7:51 PM, Don Dailey [EMAIL PROTECTED] wrote: In a serious competition you would want to throttle down the playing strength (when playing black) so that it could win more and not just quit (resign) out of frustration! Why throttle the playing strength? Wouldn't be enough to raise the threshold where the program resigns? Naively put: if all results say the game is lost, switch the evaluation to best possible score and continue playing for a while. If any winning paths appear, switch back to normal evaluation, else resign. best regards, Vlad ___ 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
Hi Don, On Jan 30, 2008 9:02 PM, Don Dailey [EMAIL PROTECTED] wrote: According to Sensei's Library, nakade is: It refers to a situation in which a group has a single large internal, enclosed space that can be made into two eyes by the right move--or prevented from doing so by an enemy move. Several examples are shown that where there are exactly 3 points. My example shows 4 empty points in a big eye but they have even bigger examples. So I think this is nakade. 3 points make a nakade, but 4 points in a line don't: c1 is answered with d1 and d1 with c1. regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] orego license?
Hi, This question is for Mr Drake, but maybe others can't find the answer in the archives either... What is the license for orego? I thought I would run some tests like the ones from the Move Ordering vs Heavy Playouts: Where Should Heuristics Be Applied in Monte Carlo Go? paper and Orego seems like the least steep path. Is it interesting to get feedback on the code? Maybe not the actual go-playing stuff, but the generic framework so that it's easier to plug in functionality in it. best regards, Vlad -- Some people see things that are and ask, Why? Some people dream of things that never were and ask, Why not? Some people have to go to work and don't have time for all that. --- George Carlin ___ 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
Hi! On Jan 8, 2008 7:17 PM, terry mcintyre [EMAIL PROTECTED] wrote: The www page for the Mathematical Go book refers to the Japanese word tedomori -- which I googled; this book page is the only reference to tedomori. No mention on senseis.xmp.net; can anyone supply a definition? It's tedomari and the sensei page is http://senseis.xmp.net/?Tedomari best regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Odd results on 19x19
On Jan 6, 2008 11:37 PM, Don Dailey [EMAIL PROTECTED] wrote: I'm not sure I get the whole picture regarding multi-dimensional ratings. How can you compare two players with a 2-dimensional rating? You can't, so how would one use this rating? In my book, a rating's goal is to make things comparable... A 2-dimensional or more rating would be used to predict the winner. You would be able to say that a given player will beat another specified player some percentage of the time. With more than one dimension perhaps the formula would be a better predictor since it could take playing styles into consideration. It could not be used to rank players in the sense of putting them on a scale such as CGOS uses. Since there is an inherently intransitive relationship, you cannot rank players in strict order with more than 1 dimension. Thanks all who answered! I see the point, the confusion in my mind was caused by the use of the word ranking which for me does imply an ordering. best regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Odd results on 19x19
On Jan 6, 2008 11:00 PM, Don Dailey [EMAIL PROTECTED] wrote: The idea of a non one dimension rating model is interesting. If you decide to pursue this I can give you the CGOS data in a compact format, 1 line per result. Hi all, I'm not sure I get the whole picture regarding multi-dimensional ratings. How can you compare two players with a 2-dimensional rating? You can't, so how would one use this rating? In my book, a rating's goal is to make things comparable... best regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
On Dec 13, 2007 12:17 PM, Jacques Basaldúa [EMAIL PROTECTED] wrote: Nick Wedd wrote: In one of the British Championship Match games, a bit over ten years ago, Zhang Shutai made an illegal ko move against Matthew Macfadyen, and immediately conceded that he had lost the game. Is the game record available? I am interested because I have only found 2 situations in real games: a. Triple ko b. Double ko when the group sharing the kos has nothing better than life in seki. Both have cycles smaller than 8 ply and my software doesn't check longer cycles. I guess any human player would recognize these situations. So if a strong player didn't it must be something more complicated. It doesn't have to be. It can simply be so that he recaptured the ko directly. I remember (but can't find it) that it was relatively recently that a japanese 9 dan pro did the same mistake. regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] low-hanging fruit - yose
Hi, Thank you all who answered my question. I think I understand better what each of you talks about. I still have the feeling that at some level different people think about different things when referring to some notion, but it's probably just me. On Dec 10, 2007 11:26 PM, Don Dailey [EMAIL PROTECTED] wrote: This uncertainity is what gives the less-than-1 confidence you discussed, but my feeling is that it varies too much with the sequence length -- the answer would be to add some intelligence, like MoGo and the other top programs do. Yes.You may not have 100% confidence, but it's a huge step in the right direction. After all, how can you do better than actually matching the goal of your program with the actual goal of the game? Beginners essentially make it their goal to win stones, advanced players set the goal of doing whatever it takes to win. This is correct. But isn't a beginner that happens to have the right goals still just a beginner, as long as it lacks the technique to follow the goals and also can't properly evaluate the result of a line of play? best regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] low-hanging fruit - yose
On Dec 11, 2007 3:34 AM, terry mcintyre [EMAIL PROTECTED] wrote: But what about doing a top-level analysis of the board just before starting playouts, offering some hints to the more interesting moves? During the middle game, and especially during the endgame, top-level analysis can provide excellent guidance regarding good and bad plays, I would think. Or maybe one could also add pit stops every 20 ply or so, where a heavy playout is made and such higher-level analysis can be conducted? Of course, it could be another case of improvement-that-weakens-the-play, but I am not sure that all such cases are really weakening the play -- maybe it's just an effect of doing less simulations because of the heavier playouts. best regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Lisp time
On Dec 12, 2007 7:28 PM, terry mcintyre [EMAIL PROTECTED] wrote: What I've googled so far looks a bit rudimentary - mostly based on unix fork semantics. I'm looking for something much lighter-weight, Erlang-style, which could support thousands of cheap concurrent threads. In Erlang, the cost of such threads is comparable to the cost of a function call. Why not go for Erlang, then? :-) There's people talking about starting using a lispy syntax for erlang (of course that won't make it lisp) regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] low-hanging fruit - yose
Hi Don, On Dec 10, 2007 9:08 PM, Don Dailey [EMAIL PROTECTED] wrote: /snipped a lot of interesting stuff/ However MC play-outs is not horizon limited like this. It's stupid to make it greedy because it may notice that winning the big group leads to a loss every time and that some other course of action is more productive. I like the way you make your arguments. I have a question about the above, hopefully you or somebody else will know the answer. Am I confused in my understanding that a weakness of MC evaluation is that due to its random play it will miss sequences where there is only one winning move at each play? This is the way I am interpreting the nakade problem discussed in another thread: to keep a dead-by-nakade group dead, one must not miss one single move in the sequence. Of course, in games the nakade example is just one of the simpler variants, most semeai (capturing races) will fall into that category. This uncertainity is what gives the less-than-1 confidence you discussed, but my feeling is that it varies too much with the sequence length -- the answer would be to add some intelligence, like MoGo and the other top programs do. best regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Language [offtopic, aside]
Hi, On Nov 20, 2007 3:03 PM, Stuart A. Yeates [EMAIL PROTECTED] wrote: The logical (but worrying) conclusion I draw from that paragraph is that you would like to see a language with an intended application of go... Why would that be a worrying conclusion? regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Perudo
Hi, I don't know about the others, but I got all the messages you sent. regards, Vlad On 8/27/07, Nick Wedd [EMAIL PROTECTED] wrote: This is not about Perudo, it is a test message. I want to make an announcement that I make here every month, but I can't. I've even tried making the whole announcement into French, but it seems that it still doesn't get posted. Nick -- Nick Wedd[EMAIL PROTECTED] ___ 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] Congratulations to GNU and to MoGoBot19!
Hi, On 6/20/07, Don Dailey [EMAIL PROTECTED] wrote: But it's least complicated with Fischer clock because everything is steady state, no mode shifts where suddenly things are reckoned differently. A simple glance at the clock is all you need to know the situation. I'm not sure I understand how Fischer time works in practice: can you use it without a digital clock? The advantage of the Canadian system is that it is easy to use with regular Chess clocks. best regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] On expanding the UCT tree
Hi, see below On 5/7/07, Peter Drake [EMAIL PROTECTED] wrote: In the first playout, my first move is A, so then I have: ROOT 1 A 1 Now I try move B, updating the tree to: ROOT 2 A 1 B 1 Fine so far. Now UCT likes A better, so the next playout starts with A, C, giving me: ROOT 3 A 2 C 1 B 1 Here's the problem. On the next playout, I'll want to look at the other alternative to A. In doing so, I will need to compute the UCT value of trying C again, especially if (as in the Gelly tech report) I don't automatically choose untried moves over tried moves. When I look through the children of A and count a total of one playout, it seems natural that I should update the playout count for A: ROOT 3 A 1 C 1 B 1 I am sorry, I may be much too tired right now, but why should A=C+D? Isn't it C+D+1, because A was also evaluated as a leaf? (this requires the root to be initialized at 1) best regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Time Control for the new CGOS
Hi, regarding time controls and the impossibility to please everyone, I'd like to make a suggestion: Let the engines specify a preferred time control and use a scheduler that takes that into account (as a strong recommendation). For example if there are two engines wanting to play at 10 minutes, pair them with higher probability. There could be just a few predefined time limits, maybe 5, 10, 15 minutes for 9x9. IMHO this would be better than using a different server for each time limit or than changing the time limit at intervals (although having a one week rotation between 5 and 10 minutes seems ok). Of course, the scheduling algorithm becomes more complex and it may not be as fair. On the other hand, it may not be very important to achieve fairness on a short scale as long as it is fair enough over a longer period of time. just my 2c best regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Is skill transitive? No.
Hi, On 1/30/07, Don Dailey [EMAIL PROTECTED] wrote: It would be interesting if it would be possible to construct a 2 dimensional model statistically. A 2 dimensional system would not be a perfect fit either, but would simply be a better approximation.So in some way a players strength could be expressed by 2 numbers instead of 1, and the 2 numbers together would predict your chances of beating another (2 dim) player more accurately that a 1 dimension system could. And of course you could extend this. But I don't have a clue how one would construct such a system or if it's even possible - but it seems like more information should be better than less. Unfortunately, having more than one dimensions makes comparisons impossible - if an ordering relation is defined over the domain, then this domain is one-dimensional with regard to that relation. In other words, one can't compare vectors, just scalars. So the multi-dimensional strength vector has to be turned into a scalar (by for example a weighted sum) and we're back where we started... best regards, Vlad (master of the obvious :-) ___ 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
Hi Matt, On 1/25/07, Matt Gokey [EMAIL PROTECTED] wrote: But just because a rule of thumb holds for Chess doesn't mean it does for Go. Of course I could be wrong, but I was just trying to introduce reasonable doubt, since Don always seems so sure of himself ;-) If I may venture trying to rephrase your arguments, do you mean that since difficulty grows exponentially there may be a qualitative leap between chess and go? Comparing chess and go is difficult, but I think this effect can be seen between 9x9 and 19x19 go too: the two games are quite different, because in 9x9 there is practically no strategic element and this element brings a whole new dimension to the game. Or did I misunderstand you? best regards, Vlad ___ 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!
Hi, On 1/12/07, Nick Apperson [EMAIL PROTECTED] wrote: yeah, there are upper limits placed on computation rate by thermodynamics. 19x19 is way beyond those as Dave pointed out. But, even if you believe that technology will improve and the most revolutionary change yet will come to understanding of physics and that change will give us signifigantly more computational power and time etc... You can always make a bigger board. If life comes to a point where go could be solved for any size board, you will no longer be in this world and solving things such as is go solvable? will have no meaning. Well, if I may be excused for being way too pedantic on this topic, raw computing power isn't the only way. Mathematical solutions might easily reduce the search space just enough to allow a full search of what's left of it. On the other hand, I'm not worried. There will always be challenging games to play and to try to master. best regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Anchor Player
On 12/25/06, Jacques Basaldúa [EMAIL PROTECTED] wrote: Hideki Kato wrote: Nevertheless, I have certain experience (not with MC) of computer go with handicap and I can tell: Waiting for the opponent to blunder is only a good strategy if the handicap is lower than it should. E.g. 7 kyu difference Handi 3. If the handicap approaches its real value, that does not work. I have seen (many times) GnuGo not being able to win a H7 game to an opponent more than 10 kyu weaker. That happens because it had to invade unclear positions. The more the invasion is postponed, the worse. The weaker player simply does defensive uninteresting play and so does the stronger player (with better yose, but that's not enough). If I (manually) use two or three turns just to invade, GnuGo tries to save the invading stones and that's more than enough to win the game. Hi, This depends on your definitions. If the position is unclear and GnuGo doesn't invade, then I'd say *that* is a blunder (especially when being behind). The idea is to play the best move available, and let the weaker player make suboptimal ones -- in the end, if the handicap is correct, the net result should be zero and the result would be the same as in an even game with an equal partner. The best move may be a somewhat risky invasion - of course one has to assume the partner will not play perfectly, but everybody does that every time anyway, right? Otherwise nobody would have any hope to win and so nobody would play ;-) best regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Anchor Player
Hi, On 12/22/06, Stuart A. Yeates [EMAIL PROTECTED] wrote: On 12/21/06, Jacques Basaldúa [EMAIL PROTECTED] wrote: Handicap play is a *different* problem. The rules of go include rules for handicapping. It seems to me that this implies that a complete solution for the game of go must include the ability to play such games. Yes, of course. But is it that difficult? The goal would 'just' have to change from winning to getting the best possible result. Now if one has already solved the game for the former goal, it should be trivial to adapt it for the latter, right? As a matter of fact, after solving the game for any goal, almost any computer science related matter would become rather trivial, I think :-) I.e. if the NP complete problems are solved, only easy ones remain! best regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Anchor Player
Hi Don, On 12/22/06, Don Dailey [EMAIL PROTECTED] wrote: It's easy to adapt monte carlo programs to have the goal of trying to win as much space or territory as possible but many of us have studied this as see that it seriously weakens monte carlo programs. My (jokingly serious) point was that if you succeed solving the normal game of Go, fixing it for this additional constraing should be trivial (i.e. possibly only some 6 to 8 orders of magnitude simpler) But this is not the real problem. It seems that the handicap system is not reasonable in general for computers. [...] It seems that playing the best move possible (best in the sense of maximizing your territory gain) is not the best strategy when playing a handicap game. You literally have to play foolishly in order to dupe your opponent into losing. I would beg to partially disagree. The above is true if giving handicap to a player of equal strength, or at least stronger than the handicap would be fair for. IMHO if I give handicap it is because the other player is weaker, so I don't *have* to play foolishly - he will make mistakes that I can see and exploit. If I still can't win, it means the handicap should be lowered... This is the strategy that one uses even in even games, right? One plays what one thinks is best given the position, and if the opponent's reply is less than optimal one tries to punish it (with various degrees of success, but that's another issue :-)) Best regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
