Re: [computer-go] Positions illustrative of computer stupidity ?
Le mercredi 22 novembre 2006 20:44, Rémi Coulom a écrit : Hi, I am in search of Go positions that are easy to understand for humans, and difficult for computers. Hi Maybe too late ... Nethertheless, i remember a funny thing. Some time ago i implemented opponent good move is good for me in a GNU Go bot and this gave funny things like reverse monkey jump. David Doshay reported this too with early SlugGo (which also takes into account opponent good moves) XXXO ..XO ..X. .a.. Instead of blocking the monkey jump, O plays in a :) I m pretty sure no human player would think of this. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Positions illustrative of computer stupidity ?
This is a good example of a reasonable heuristic leading to an undesired solution after a correct evaluation. Most of the time SlugGo did this it was correct that stopping the opponent's monkey-jump was the biggest move on the board, so using the heuristic was valuable. It just took things too far and chose the exact same move for the fix. We had to soften the heuristic to Moves near their best move may be very good for me. Playing with the weights for near cut down on the number of reverse monkey jumps. Cheers, David On 3, Dec 2006, at 5:17 AM, alain Baeckeroot wrote: Le mercredi 22 novembre 2006 20:44, Rémi Coulom a écrit : Hi, I am in search of Go positions that are easy to understand for humans, and difficult for computers. Hi Maybe too late ... Nethertheless, i remember a funny thing. Some time ago i implemented opponent good move is good for me in a GNU Go bot and this gave funny things like reverse monkey jump. David Doshay reported this too with early SlugGo (which also takes into account opponent good moves) XXXO ..XO ..X. .a.. Instead of blocking the monkey jump, O plays in a :) I m pretty sure no human player would think of this. 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] Positions illustrative of computer stupidity ?
Le lundi 27 novembre 2006 16:36, Steven Clark a écrit : Computer stupidity? How about how GNUGo has no problem invading under my 4,4 stone, but refuses to invade under my 5,5 stones? I assume this is because there is a joseki entry for 4,4, but none for 5,5 openings. Attached is a rather silly game I played against GNUGo exploiting this fact (I will admit that I used undo several times to get the bot to do what I wanted, but the fact that I can get away with this is pretty funny...) Cheers -Steven Funny game :) FYI, in the final position latest development release 3.7.10 does invade at 5-3 or, if corner are protected by san-san, it goes to k3 :) This even when databases are turned off (fuseki and joseki :). Cheers. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Positions illustrative of computer stupidity ?
alain Baeckeroot wrote: Le mercredi 22 novembre 2006 20:44, Rémi Coulom a écrit : Hi, Hi Rémi I am in search of Go positions that are easy to understand for humans, and difficult for computers. One incredibly simple example for human, where GNU Go horribly fails. The only move is tengen (center of the board). I don't know if its a simple bug, or a more difficult evaluation problem. It happens even if all databases are disabled (fuseki and joseki). Thanks to Aloril, who tell it to Min-u Kang (my go teacher :) Cheers. Alain. Thanks Alain. Again, this position is very easy for Monte-Carlo programs. Even on 19x19, Crazy-Stone finds tengen rapidly (in about 30s with a single thread on a 3.4GHz PIV, but this varies a lot depending on randomness). Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Positions illustrative of computer stupidity ?
Le samedi 25 novembre 2006 00:38, alain Baeckeroot a écrit : Le mercredi 22 novembre 2006 20:44, Rémi Coulom a écrit : Hi, Hi Rémi I am in search of Go positions that are easy to understand for humans, and difficult for computers. One incredibly simple example for human, where GNU Go horribly fails. The only move is tengen (center of the board). I don't know if its a simple bug, or a more difficult evaluation problem. It happens even if all databases are disabled (fuseki and joseki) I investigated a little this thickness evaluation problem: The first player getting tengen spoils 2 opponent moves. The stones can still help for some ladders, but they can be seen as dead. So it nearly equivalent to 2 handicap game, (miai counting gives: one stone is used to kill 2, remains 2 'not used' stones), with weirdly placed handicap, so at least the advantage is greater than 1 normal corner handicap move. I tried a simple fix in gnugo, now it find the proper move in this test case. But as a side effect: On a 19x19 it plays too slow, and lose 10/10 games agaisnt standard GNU Go. (5 as W, 5 as B, this is small sample i agree) On 9x9, it seems to have a smaller impact: as Black 5/10 games win as White 2/10 games win So at least parameter tuning is needed, maybe more refined stuff for evaluating the value of cut/connect move ... this is not simple :) QED. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Positions illustrative of computer stupidity ?
I can't help but feel we are missing something. With UCT we miss those wonderful beta cutoff's that you get with straightforward alpha beta pruning - but with alpha beta pruning you are still exploring a lot more useless nodes.It seems the 2 are just not very compatible. Currently UCT does seem like the best choice by far. Yes, in the current state of the art. What would be great is to understand in what extend this would continue to be true if we change the evaluation function. What I believe (but this is only intuition, this have to be proved !), is that UCT is very efficient in Go because our evaluation function is bad. With a good/(very)^+ good evaluation function, alpha-beta would become much better than UCT. I think this is clearly the case if you can reach the end of the game in the tree for example. I don't know if someone tried UCT in chess to see the results. As we often assume that the evaluation function in chess is much better than in Go, it would be a good test case? [...] But UCT may be a rather extreme example of this phenomenon - better to go deep even without a huge number of simulations. Of course with UCT none of the evaluations are completely wasted, they all have an impact on potential root choices. It is an interesting point of view indeed. I did not see UCT on that angle... This would confirm our results where launching several simulations for each node (instead of node) where not improving the results (comparing at equal number of nodes. Comparing at equal number of simulations this was much worse !). Yet, one of the property of UCT which I think is very useful in Go is the smooth pruning. The other is that the value is between the mean and the min-max in a smooth manner, while keeping the convergence toward the min-max. Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Positions illustrative of computer stupidity ?
Le mercredi 22 novembre 2006 20:44, Rémi Coulom a écrit : Hi, Hi Rémi I am in search of Go positions that are easy to understand for humans, and difficult for computers. One incredibly simple example for human, where GNU Go horribly fails. The only move is tengen (center of the board). I don't know if its a simple bug, or a more difficult evaluation problem. It happens even if all databases are disabled (fuseki and joseki). Thanks to Aloril, who tell it to Min-u Kang (my go teacher :) Cheers. Alain. simple-test-19.sgf Description: application/go-sgf simple-test-99.sgf Description: application/go-sgf ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Positions illustrative of computer stupidity ?
Le Jeudi 23 Novembre 2006 11:47, Chris Fant a écrit : ... Its an interesting question if Monte-Carlo programms would also play infinite strong. I was under the impression that most MC implementations were guaranteed to converge on the optimal move. Yes, but it does not come from the MC part, but for example UCT garantees to visit all the nodes infinitely often whatever the evaluation function returns. However, the convergence will be VERY slow if the evaluation function is bad. Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Positions illustrative of computer stupidity ?
I think they will play very strong. Sofar all my tests indicates nice scaling, but I admit I have not tried a proper experiment for a long time since I do not have any extra hardware. Perhaps the Mogo team could do something but the problem is that Mogo is so strong it would beat most programs 100% with modest increases in computation time on 9x9. What we can say from experiments is that the scaling with time is very good with few simulations, but becomes less interesting with a lot of simulations. With the same settings (not the best, but the ones for which we have the most number of results), against gnugo at level 0 (s/m == simulations/move): 3000 s/m : 35%, 1 s/m : 60%, 7 s/m : 90%. Against gnugo at level 8 (default) it gives respectively 50% and 80% for 10k s/m and 70k s/m. MoGo on cgos plays with something like 300k s/m, but I don't think it is much better than with 70 k s/m. Quick experiments showed that the improvement was only few % against gnugo. However, I saw that the improvement is larger against MC based programs (classical non transitivity of the results), and against itself it is huge. I also saw that after each improvement, the number of simulations was less important than before, so the scaling is less impressive. Perhaps it comes from the fact that now the opening moves are those where MoGo loses most of its games and, as Magnus said, the number of simulations are not so important in the opening. We did not investigate that. Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Positions illustrative of computer stupidity ?
Sylvain, The improvement over a given opponent should be measured by ELO points, not win percentage unless you do the extra math. I cannot quite tell if you were considering that or not - if so then ignore this. Going from 50% wins to 60% with is a modest improvement, but going from 80% to 90% is a MAJOR improvement. UCI is completely scalable, but may not be optimally scalable. It may turn out that there are other ways to handle the best first search. My fear with UCI type methods is that it might be progressively less efficient as you get much faster. It is probably a matter of finding just the right formula for allocating work. Or it might turn out that some form of alpha/beta search using monte/carlo as an evaluator is the right thing given enough power - which suggests some kind of hybrid approach. UCI may be the best way to handle nodes closer to the leaf and perhaps be viewed as a kind of quies search for a standard alpha/beta engine. I'm just taking a wild guess here. - Don On Thu, 2006-11-23 at 13:24 +0100, [EMAIL PROTECTED] wrote: I think they will play very strong. Sofar all my tests indicates nice scaling, but I admit I have not tried a proper experiment for a long time since I do not have any extra hardware. Perhaps the Mogo team could do something but the problem is that Mogo is so strong it would beat most programs 100% with modest increases in computation time on 9x9. What we can say from experiments is that the scaling with time is very good with few simulations, but becomes less interesting with a lot of simulations. With the same settings (not the best, but the ones for which we have the most number of results), against gnugo at level 0 (s/m == simulations/move): 3000 s/m : 35%, 1 s/m : 60%, 7 s/m : 90%. Against gnugo at level 8 (default) it gives respectively 50% and 80% for 10k s/m and 70k s/m. MoGo on cgos plays with something like 300k s/m, but I don't think it is much better than with 70 k s/m. Quick experiments showed that the improvement was only few % against gnugo. However, I saw that the improvement is larger against MC based programs (classical non transitivity of the results), and against itself it is huge. I also saw that after each improvement, the number of simulations was less important than before, so the scaling is less impressive. Perhaps it comes from the fact that now the opening moves are those where MoGo loses most of its games and, as Magnus said, the number of simulations are not so important in the opening. We did not investigate that. Sylvain ___ 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] Positions illustrative of computer stupidity ?
David Fotland wrote: Many Faces plays L10, which looks like it also breaks both ladders. -David Thanks for testing. What if Black replies with K9 ? It looks like K9 restores both ladders (to my naive eye). What about the first position I posted, where more tempting moves are available elsewhere ? Do you know whether your program chooses that move for the right reason ? Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Positions illustrative of computer stupidity ?
I think it's all in the presentation. Even if they are not even beginners, with skill you can help them appreciate how some basic concepts are difficult for a computer. For instance, I think that you can teach the principle of 2 eyes with a very simple example perhaps involving just 1 point eyes. Then move to showing them that if the eyes are bigger, it starts getting ambiguous very quickly - and at some point it starts taking a relatively advanced player to discern when a bigger space is equivalent to an eye. You start just by showing them a group with 1 single point eye and how it gets captured. They you progress: what if there is another eye? etc. - Don On Wed, 2006-11-22 at 12:27 -0800, steve uurtamo wrote: i think that these won't be terribly easy for your audience to parse. part of the problem is that gnugo is actually better than a beginner, for instance. i'd say anything that isn't tactical in nature is a good example. moves that don't directly make any territory, but which threaten to, for instance. look at the first 8-10 moves of most any KGS game played by robert jasiek (sum) that ended in an early resignation. s. Sponsored Link Mortgage rates near 39yr lows. $420k for $1,399/mo. Calculate new payment! www.LowerMyBills.com/lre ___ 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] Positions illustrative of computer stupidity ?
The attached position requires some basic understanding of Go. But its in my experience a nasty problem. There is a simple rule for capture races. The side with the higher number of liberties wins (if there are no eyes and more =2 inside liberties involved). The side to move counts as a 1/2 liberty. Unfortunately this rule is not valid in the position. White is unconditionally dead. All liberties are equal, some are more equal. Chrilly Semeai01.sgf Description: Binary data ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Positions illustrative of computer stupidity ?
Attached is another simple problem. A tactical-solver might work as this. It checks all strings. If the number of liberties is below a thresold (e.g. 3) it defines the string as a prey and tries to kill the string. Then the solver takes the next prey, tries to kill it. For this tactical solver the white stones are save. Each prey can escape individually, but due to the double-atari one of them is dead. This is a trivial example, but there are more difficult ones which are much harder to solve. Even the best strong programms like Handtalk are very vulnerable to double attacks (there are other ones like Many Faces which do not suffer from this problem).. Chrilly DoubleThreat.sgf Description: Binary data ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
