Re: [computer-go] Dynamic Komi's basics
On Thu, Feb 11, 2010 at 11:24:25PM +0900, Hiroshi Yamashita wrote: I also get a bit good result to change komi inside. My code is like this. Interesting, thank you! I already started experimenting with something quite similar this week too (no commit pushed out in pachi codebase yet), I call that online komi for myself. winning rate (wins/all) 0.544 (336/617) komi chage by previous thinking result. You mean adjusting komi after each simulation or after each move? (I think the former?) -- Petr Pasky Baudis A great many people think they are thinking when they are merely rearranging their prejudices. -- William James ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Dynamic Komi's basics
You mean adjusting komi after each simulation or after each move? (I think the former?) Yes, each simulation, like this, play w e5 genmove b AdjustingKomi(latest_komi); move = getBestMoveUCT(); latest_komi = CalculateAdjustingKomi(); =c3 play w d4 genmove b AdjustingKomi(latest_komi); move = getBestMoveUCT(); latest_komi = CalculateAdjustingKomi(); =e3 Undo or load position are a bit difficult... Hiroshi Yamashita ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Dynamic Komi's basics
try: (handicap - 0.5) x 14 Erik 2010/2/11 Le Hir Matthieu mate...@hotmail.fr Hi, I have a few questions concerning dynamic komi, I am not a programmer though and will try my best to be understandable. First, I'm wondering how komi is determined when a dynamic system is used : * According to this page : http://senseis.xmp.net/?Komi%2FvalueOfFirstMove the value of komi at first move is half the points the black move is supposed to be ( 14 points) 7,5 komi in even games. How does this apply to high handicap games ? From what I think I understood, dynamic komi is supposed to try to keep the game more even. If the computer is black, playing at 9 handi, will the burden komi ( negative) be 9 x - 7,5 ? - 67,5 ? It sounds highly improbable. On the other hand, 9 handicaps are supposedly giving an advantage of 90 to 120 points, so my natural thought would be that the bot would give itself at least a negative komi of that many points ? I can't figure out well how komi is determined at first move. In relation with the previous question, I'm wondering how komi is determined and what its value is for every handicap game ( as black and as white). Is there a specific value for each ( before first move is played) or is it only determined by the way it was programmed and the programmer's preferences ? I am going to play a series of high handicap games ( as white) against pachIV on kgs, that explains why I'm curious to know about how this komi-stuff works precisely. Thanks for helping, Matthieu, aka CGBSpender. [image: Animations GRATUITES pour votre messagerie - par IncrediMail! Cliquez ici!] http://www.incredimail.com/?id=605280rui=122199674 ___ 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] Dynamic Komi's basics
Le Hir Matthieu wrote: First, I'm wondering how komi is determined when a dynamic system is used Either use komi bidding or determine a new (or the same) komi value for every next game. For the latter, the basic idea is to observe for which komi the winning rates were above / below 50%. You can make things more complicated by forming averages of some series of games. the value of komi at first move is half the points the black move is supposed to be ( 14 points) 7,5 komi in even games. This conjecture is the best we can guess but is unproven. How does this apply to high handicap games ? Not at all because handicap requires further assumptions. I can't figure out well how komi is determined at first move. So far it is not determined at move 1 but before the start of a game. and what its value is for every handicap game ( as black and as white). Also with handicaps you can observe winning probabilities empirically. -- robert jasiek ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Dynamic Komi's basics
Hi Le 11/02/2010 à 10:32, Le Hir Matthieu a écrit : Hi, From what I think I understood, dynamic komi is supposed to try to keep the game more even. The dynamic komi is a bias in the evaluation in order to inform the bot that the game is balanced, and prevent it beeing blinded by the false feeling of large win in the beginning of a high handicap game. Else with black and 9 stones the bot would think i (bot) am ahead, just take it easy, this game is won, whereas it is not, the 9 stones are needed, and we human know that white will slowly but inexorably catch up. When the bot plays white, this is less a problem, as montecarlo bot will correctly play safer and safer as the game advances. Maybe it could help, by reducing the risks taken? If the computer is black, playing at 9 handi, will the burden komi ( negative) be 9 x - 7,5 ? - 67,5 ? It sounds highly improbable. On the other hand, 9 handicaps are supposedly giving an advantage of 90 to 120 points, so my natural thought would be that the bot would give itself at least a negative komi of that many points ? Yes this is the idea. The problem is to find the right balance, and not be slow when the bot aims at being safe, and not force the bot to take unneeded risks (you know better than me the pb slow/thick, thin/light, safe/crazy) .../... I am going to play a series of high handicap games ( as white) against pachIV on kgs, that explains why I'm curious to know about how this komi-stuff works precisely. no idea how/if this is implemented in different bots. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Dynamic Komi's basics
Hi! On Thu, Feb 11, 2010 at 10:32:49AM +0100, Le Hir Matthieu wrote: First, I'm wondering how komi is determined when a dynamic system is used : * According to this page : http://senseis.xmp.net/?Komi%2FvalueOfFirstMove the value of komi at first move is half the points the black move is supposed to be ( 14 points) 7,5 komi in even games. How does this apply to high handicap games ? I *think* that komi value is miai-counted, not deiri-counted, so in miai counting that corresponds to the 7.5 value also proposed in the article. I have never been an expert in the counting theory, however, so maybe I am wrong. Pachi uses 7.5 points per handicap stone, in some testing I also used 8 points per stone which gives similar winrates. It makes no theoretical sense to use the 0.5 fraction in this, but it seems to work well enough and I did not have time to tune for better value. From what I think I understood, dynamic komi is supposed to try to keep the game more even. If the computer is black, playing at 9 handi, will the burden komi ( negative) be 9 x - 7,5 ? - 67,5 ? It sounds highly improbable. Yes, this is the komi value pachi uses. I have found that higher komi values work similarly well (perhaps a bit worse) as long as the komi is not completely ridiculous. On the other hand, 9 handicaps are supposedly giving an advantage of 90 to 120 points, so my natural thought would be that the bot would give itself at least a negative komi of that many points ? I can't figure out well how komi is determined at first move. extra_komi = 7.5 * handicap_stones_count Then it is linearly decreased until it hits 0 at move 200. This is the most naive implementation. In practice, neither extra_komi determination nor its application throughout the game should be linear, probably. There is a lot of experiments to be done. :-) In relation with the previous question, I'm wondering how komi is determined and what its value is for every handicap game ( as black and as white). Is there a specific value for each ( before first move is played) or is it only determined by the way it was programmed and the programmer's preferences ? It is only determined by the programmer's preferences and more importantly empirical measurements of what kind of values worked best. P.S.: For some measured dynamic komi positive effects, please see the presentation I posted few months ago. I plan to finish up and submit a paper with investigation of also other approaches hopefully in time for the IEEE call for papers. ;-) -- Petr Pasky Baudis A great many people think they are thinking when they are merely rearranging their prejudices. -- William James ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Dynamic Komi's basics
The basic i think of Dynamic komi in my opinion is the following. The bot must be able to distinguish good from bad moves (this doesn't need much explanation i guess) and a bot '' by implementation thinks that the opponent is as good as he is. (in most algorithms he is playing against himself) The main way to distinguish between good and bad moves is that good moves lead to a win and bad moves lead to a loss. (or relative more chanche to a win and less change to a win). The problem can occur that with a to low (for the player) (internal) komi all moves lead to a loss (or a high losing chanche) and then the distinction between good and bad moves is factually lost. (this is what couses brain death moves in a for the bot lost game, the bot is unable to distuinguish between good and bad moves) The chanche that all moves win is much less likely some moves are so bad they will lose even against all odds. So the (internal) komi needs to be set so that good moves win and bad moves lose. (and that is in short the whole problem with komi how to make sure that this happens. In high handicap games the player who has black has an easier game but so a bot playing black (under normal komi) will think of almost all moves as good (they all lead to a win) and if he is playing playing White that all moves are losing (there is not even one good move) The internal komi most be set so that the bot thinks that only one (ore only a few) moves are good in the hope that the really good move (I mean the good moves on the board) is that one. During the game this all becomes dynamic. The opponent blunders (or a slightly sub optimal move) The bot will think it has (to) many more moves that will win, (and plays teh wrong one) the bot plays suboptimal and all moves lead to a loss. (and he cannot find any good one anymore) hope this helps On Thu, Feb 11, 2010 at 11:14 AM, Alain Baeckeroot alain.baecker...@laposte.net wrote: Hi Le 11/02/2010 à 10:32, Le Hir Matthieu a écrit : Hi, From what I think I understood, dynamic komi is supposed to try to keep the game more even. The dynamic komi is a bias in the evaluation in order to inform the bot that the game is balanced, and prevent it beeing blinded by the false feeling of large win in the beginning of a high handicap game. Else with black and 9 stones the bot would think i (bot) am ahead, just take it easy, this game is won, whereas it is not, the 9 stones are needed, and we human know that white will slowly but inexorably catch up. When the bot plays white, this is less a problem, as montecarlo bot will correctly play safer and safer as the game advances. Maybe it could help, by reducing the risks taken? If the computer is black, playing at 9 handi, will the burden komi ( negative) be 9 x - 7,5 ? - 67,5 ? It sounds highly improbable. On the other hand, 9 handicaps are supposedly giving an advantage of 90 to 120 points, so my natural thought would be that the bot would give itself at least a negative komi of that many points ? Yes this is the idea. The problem is to find the right balance, and not be slow when the bot aims at being safe, and not force the bot to take unneeded risks (you know better than me the pb slow/thick, thin/light, safe/crazy) .../... I am going to play a series of high handicap games ( as white) against pachIV on kgs, that explains why I'm curious to know about how this komi-stuff works precisely. no idea how/if this is implemented in different bots. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Dynamic Komi's basics
Hi! I forgot two important points: On Thu, Feb 11, 2010 at 01:06:34PM +0100, Petr Baudis wrote: On the other hand, 9 handicaps are supposedly giving an advantage of 90 to 120 points, so my natural thought would be that the bot would give itself at least a negative komi of that many points ? I can't figure out well how komi is determined at first move. extra_komi = 7.5 * handicap_stones_count Then it is linearly decreased until it hits 0 at move 200. The amount of extra komi applied is determined at the tree leaf where it is applied. That is, it's 1 - current_move_number / 200 in tree root, but deeper in the tree, it's 1 - (current_move_number + node_depth) / 200. This ensures some kind of sanity especially when reusing older trees, the values have well defined characteristics. This is the most naive implementation. In practice, neither extra_komi determination nor its application throughout the game should be linear, probably. There is a lot of experiments to be done. :-) In relation with the previous question, I'm wondering how komi is determined and what its value is for every handicap game ( as black and as white). Is there a specific value for each ( before first move is played) or is it only determined by the way it was programmed and the programmer's preferences ? Dynamic komi is used only in games where the program is black. I have found that it does not work well at all when the program is white, it played too slow moves, then found itself hopelessly behind when it was too late to do anything about it. But I also think UCT without dynamic komi plays a lot worse as black than white in high handicap games, so the problem to solve is not as big (if indeed any). -- Petr Pasky Baudis A great many people think they are thinking when they are merely rearranging their prejudices. -- William James ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Dynamic Komi's basics
On Thu, Feb 11, 2010 at 01:06:34PM +0100, Petr Baudis wrote: extra_komi = 7.5 * handicap_stones_count Then it is linearly decreased until it hits 0 at move 200. All this discussion made me think - has anyone tried to adjust the komi between the simulations. Run (say) 10% of the simulations you expect to run for a move, and see how many of the moves ended in a win. If there are many moves, adjust the komi to make winning harder. If there no moves at all, adjust the komi to make winning easier. Repeat after a small number of simulations (maybe after every one). Yes, this will add noise to the results, when a reasonably good move gets a loss marked against it when the komi gets too hard, but then again, the whole system is noisy already, with random simulations at the leaves of the tree... This sounds like such a simple and obvious idea that someone must have tried it already. If I had a working implementation to play with, I might try it myself, but I don't, and I don't have the time to set one up and try. - Heikki -- Heikki Levanto In Murphy We Turst heikki (at) lsd (dot) dk ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Dynamic Komi's basics
Pachi uses 7.5 points per handicap stone Pachi is wrong. See the first paragraph of There is a relationship in http://senseis.xmp.net/?Komi/valueOfFirstMove The rest of the page is quite confusing but but the value of one move at the beginning of a game is definitely twice the komi. A move early in the game is worth about 14 points, not 7.5. I would write the proof as follows. Assume x is the value of one move, and komi is the value of the right to play next. After playing the first move, black has won x points on the board and lost the right to play next, so blacked gained x-komi in total. White has gained the right to play next, so komi points. For this to be fair, the value gained by white must be equal to the value gained by black: x - komi = komi or: x = 2*komi. Jean-loup 2010/2/11 Petr Baudis pa...@ucw.cz Hi! On Thu, Feb 11, 2010 at 10:32:49AM +0100, Le Hir Matthieu wrote: First, I'm wondering how komi is determined when a dynamic system is used : * According to this page : http://senseis.xmp.net/?Komi%2FvalueOfFirstMove the value of komi at first move is half the points the black move is supposed to be ( 14 points) 7,5 komi in even games. How does this apply to high handicap games ? I *think* that komi value is miai-counted, not deiri-counted, so in miai counting that corresponds to the 7.5 value also proposed in the article. I have never been an expert in the counting theory, however, so maybe I am wrong. Pachi uses 7.5 points per handicap stone, in some testing I also used 8 points per stone which gives similar winrates. It makes no theoretical sense to use the 0.5 fraction in this, but it seems to work well enough and I did not have time to tune for better value. From what I think I understood, dynamic komi is supposed to try to keep the game more even. If the computer is black, playing at 9 handi, will the burden komi ( negative) be 9 x - 7,5 ? - 67,5 ? It sounds highly improbable. Yes, this is the komi value pachi uses. I have found that higher komi values work similarly well (perhaps a bit worse) as long as the komi is not completely ridiculous. On the other hand, 9 handicaps are supposedly giving an advantage of 90 to 120 points, so my natural thought would be that the bot would give itself at least a negative komi of that many points ? I can't figure out well how komi is determined at first move. extra_komi = 7.5 * handicap_stones_count Then it is linearly decreased until it hits 0 at move 200. This is the most naive implementation. In practice, neither extra_komi determination nor its application throughout the game should be linear, probably. There is a lot of experiments to be done. :-) In relation with the previous question, I'm wondering how komi is determined and what its value is for every handicap game ( as black and as white). Is there a specific value for each ( before first move is played) or is it only determined by the way it was programmed and the programmer's preferences ? It is only determined by the programmer's preferences and more importantly empirical measurements of what kind of values worked best. P.S.: For some measured dynamic komi positive effects, please see the presentation I posted few months ago. I plan to finish up and submit a paper with investigation of also other approaches hopefully in time for the IEEE call for papers. ;-) -- Petr Pasky Baudis A great many people think they are thinking when they are merely rearranging their prejudices. -- William James ___ 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: Réf. : Re: [computer-go] Dynamic Komi's basics
In other words, pachi's dynamic komi should be twice as high as it is ? I should have been more careful in my choice of words. There can be a big difference between the theoretical value of the first move (which is twice the komi), and the parameter value which should be used to make the bot play best. Bots have many tuning parameters and most of the time the only way to get the optimal values is to try, measure and keep what works best. I will try this experiment and report what works best for Pachi. It's quite possible that the optimal value will be somewhere between 7.5 and 15. Jean-loup 2010/2/11 Le Hir Matthieu mate...@hotmail.fr In other words, pachi's dynamic komi should be twice as high as it is ? Currently, on first move - at 9 handi - pachi has an advantage of about 66 points thanks to his komi. It should be about 130? How would that affect his play ? More second line, slack and no man's land moves ? My reasoning may be silly but... If the initial dynamic komi is doubled, the bot has to work twice less hard and can play loose, slack moves and still keep the lead , right ? As opposed to this, halving the initial komi from 66 to about 35 points, wouldn't that force to bot to play more efficient, sharp moves ? What I'm afraid of, though, is that after a while ( when the bot has caught up enough) it might start again to play slack again ? Matthieu *---Message original---* *De :* Jean-loup Gailly jl...@gailly.net *Date :* 11/02/2010 16:00:33 *A :* computer-go computer-go@computer-go.org *Sujet :* Re: [computer-go] Dynamic Komi's basics Pachi uses 7.5 points per handicap stone Pachi is wrong. See the first paragraph of There is a relationship in http://senseis.xmp.net/?Komi/valueOfFirstMove The rest of the page is quite confusing but but the value of one move at the beginning of a game is definitely twice the komi. A move early in the game is worth about 14 points, not 7.5. I would write the proof as follows. Assume x is the value of one move, and komi is the value of the right to play next. After playing the first move, black has won x points on the board and lost the right to play next, so blacked gained x-komi in total. White has gained the right to play next, so komi points. For this to be fair, the value gained by white must be equal to the value gained by black: x - komi = komi or: x = 2*komi. Jean-loup 2010/2/11 Petr Baudis pa...@ucw.cz Hi! On Thu, Feb 11, 2010 at 10:32:49AM +0100, Le Hir Matthieu wrote: First, I'm wondering how komi is determined when a dynamic system is used : * According to this page : http://senseis.xmp.net/?Komi%2FvalueOfFirstMove the value of komi at first move is half the points the black move is supposed to be ( 14 points) 7,5 komi in even games. How does this apply to high handicap games ? I *think* that komi value is miai-counted, not deiri-counted, so in miai counting that corresponds to the 7.5 value also proposed in the article. I have never been an expert in the counting theory, however, so maybe I am wrong. Pachi uses 7.5 points per handicap stone, in some testing I also used 8 points per stone which gives similar winrates. It makes no theoretical sense to use the 0.5 fraction in this, but it seems to work well enough and I did not have time to tune for better value. From what I think I understood, dynamic komi is supposed to try to keep the game more even. If the computer is black, playing at 9 handi, will the burden komi ( negative) be 9 x - 7,5 ? - 67,5 ? It sounds highly improbable. Yes, this is the komi value pachi uses. I have found that higher komi values work similarly well (perhaps a bit worse) as long as the komi is not completely ridiculous. On the other hand, 9 handicaps are supposedly giving an advantage of 90 to 120 points, so my natural thought would be that the bot would give itself at least a negative komi of that many points ? I can't figure out well how komi is determined at first move. extra_komi = 7.5 * handicap_stones_count Then it is linearly decreased until it hits 0 at move 200. This is the most naive implementation. In practice, neither extra_komi determination nor its application throughout the game should be linear, probably. There is a lot of experiments to be done. :-) In relation with the previous question, I'm wondering how komi is determined and what its value is for every handicap game ( as black and as white). Is there a specific value for each ( before first move is played) or is it only determined by the way it was programmed and the programmer's preferences ? It is only determined by the programmer's preferences and more importantly empirical measurements of what kind of values worked best. P.S.: For some measured dynamic komi positive effects, please see the presentation I posted few months ago. I plan to finish up and submit a paper with investigation of also other
Re: [computer-go] Dynamic Komi's basics
2010/2/11 Jean-loup Gailly jl...@gailly.net A move early in the game is worth about 14 points, not 7.5. While this may be true for professional-level play, the value of the first move for balancing Monte-Carlo playouts towards a 50% win rate should be expected to be lower. Erik ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Dynamic Komi's basics
Jean-loup Gailly wrote: I would write the proof as follows. Assume x is the value of one move Yours is not a proof because what follows is not just a single move of value x but a game tree of moves of various sizes, which need not even decrease constantly. Many years ago, Barry Phease was a bit farther by assuming a constant decrement and forming a sum. His was not a proof either because sizes of moves in the paths of the game tree need not decrease constantly. Rather than being proofs, such arguments are plausible approximations. -- robert jasiek ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Dynamic Komi's basics
Many Faces does almost the same thing (handicap games with black only, 7 points per handicap stone, decreasing linearly with move number to move 90). It looks like this change gained about half a rank on KGS. David -Original Message- From: computer-go-boun...@computer-go.org [mailto:computer-go- boun...@computer-go.org] On Behalf Of Petr Baudis Sent: Thursday, February 11, 2010 4:52 AM To: computer-go Subject: Re: [computer-go] Dynamic Komi's basics Hi! I forgot two important points: On Thu, Feb 11, 2010 at 01:06:34PM +0100, Petr Baudis wrote: On the other hand, 9 handicaps are supposedly giving an advantage of 90 to 120 points, so my natural thought would be that the bot would give itself at least a negative komi of that many points ? I can't figure out well how komi is determined at first move. extra_komi = 7.5 * handicap_stones_count Then it is linearly decreased until it hits 0 at move 200. The amount of extra komi applied is determined at the tree leaf where it is applied. That is, it's 1 - current_move_number / 200 in tree root, but deeper in the tree, it's 1 - (current_move_number + node_depth) / 200. This ensures some kind of sanity especially when reusing older trees, the values have well defined characteristics. This is the most naive implementation. In practice, neither extra_komi determination nor its application throughout the game should be linear, probably. There is a lot of experiments to be done. :-) In relation with the previous question, I'm wondering how komi is determined and what its value is for every handicap game ( as black and as white). Is there a specific value for each ( before first move is played) or is it only determined by the way it was programmed and the programmer's preferences ? Dynamic komi is used only in games where the program is black. I have found that it does not work well at all when the program is white, it played too slow moves, then found itself hopelessly behind when it was too late to do anything about it. But I also think UCT without dynamic komi plays a lot worse as black than white in high handicap games, so the problem to solve is not as big (if indeed any). -- Petr Pasky Baudis A great many people think they are thinking when they are merely rearranging their prejudices. -- William James ___ 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] Dynamic Komi's basics
Yours is not a proof because what follows is not just a single move of value x but a game tree of moves of various sizes, So let me try to be more precise. Assume a 19x19 no-handicap game played by perfect players with New Zealand rules with komi k. k is chosen as the largest value N+0.5 (with N integer) which guarantees a win by black. k exists because with New Zealand rules the game is finite. Black cannot win by an infinite amount of points, so there is an upper bound for k, therefore k exists. Now give the choice to black to either play the first move, or pass and receive x extra points, x constrained to be an integer. Let m be the smallest value of x that black will accept to pass instead of playing, and still be sure of winning. m exists because the game is finite, and black being perfect can determine m exactly. m is my definition of the value of the first move. I am not attempting to define the value of subsequent moves, and not assuming that these values decrease constantly. I am only interested in the relation between m and k. If black passes, black has m points, white has k points, white to play. White playing perfectly for maximum score will lose by exactly 0.5 point. If white is given one extra point, white would be exactly in the position that black was at initially: next to play and guaranteed to win by 0.5. The player next to move on the empty board and with a guaranteed 0.5 win has a cash deficit of k points in the first case (black to play) and m-(k+1) points in the other (black passed and white to play). So k = m-(k+1) or m = 2*k+1. Again the above analysis only considers the game theoretical value of the empty board, not any subsequent position. I welcome any correction if there is a flaw in my reasoning (which is quite possible). Jean-loup 2010/2/11 Robert Jasiek jas...@snafu.de Jean-loup Gailly wrote: I would write the proof as follows. Assume x is the value of one move Yours is not a proof because what follows is not just a single move of value x but a game tree of moves of various sizes, which need not even decrease constantly. Many years ago, Barry Phease was a bit farther by assuming a constant decrement and forming a sum. His was not a proof either because sizes of moves in the paths of the game tree need not decrease constantly. Rather than being proofs, such arguments are plausible approximations. -- robert jasiek ___ 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] Dynamic Komi's basics
Jean-loup Gailly wrote: m is my definition of the value of the first move. Willemien wrote: in 7x7 go under perfect play and without komi black wins by 9 points. if Black passes on the first move then under the same perfect play white wins with 9 points (again without komi) Does that mean that the value of the first move is 18 points? The problem is that there is not the single value. Jean's definition is nice and under that definition the related value Willemien refers to would be the same as his. The crucial question now is whether that value is the deire endgame value (or, since the local-tally is 2, twice the miai value) of the first move or is some other value (which accidentally might or might not be the same when practically determining it for a board). According to http://senseis.xmp.net/?MiaiCounting, since by symmetry (either Black first stone or White first stone) we may assume that the value does not depend on ko threats and since the first play does not threaten to raise the temperature, we may as well assume that the first play on the board is gote and, using Jean's construction, determine both the count and the local-tally to determine the miai value (and, multiplying by 2, the deire value). I would like to make a minor improvement: The addition of 0.5 to a komi is artificial. Better omit it and revise Jean's calculation accordingly. This gives k = m-k or m = 2*k. So apart from some ambiguity of what is a ko threat and what is a gote (which can be ignored by using a simplified substitute for the usually used term of miai value), I am tempted to believe that Jean-loup's construction embedded in the above context is indeed a proof now. The construction via maximal / minimal value under assumed perfect play and the parameter x relate the 1990ies' raw sketch along the idea Black passes, then instead White makes the first play to perfect play. Note that the miai value of the second play on the board in relation to komi is still unknown. -- robert jasiek Assume a 19x19 no-handicap game played by perfect players with New Zealand rules with komi k. k is chosen as the largest value N+0.5 (with N integer) which guarantees a win by black. k exists because with New Zealand rules the game is finite. Black cannot win by an infinite amount of points, so there is an upper bound for k, therefore k exists. Now give the choice to black to either play the first move, or pass and receive x extra points, x constrained to be an integer. Let m be the smallest value of x that black will accept to pass instead of playing, and still be sure of winning. m exists because the game is finite, and black being perfect can determine m exactly. m is my definition of the value of the first move. I am not attempting to define the value of subsequent moves, and not assuming that these values decrease constantly. I am only interested in the relation between m and k. If black passes, black has m points, white has k points, white to play. White playing perfectly for maximum score will lose by exactly 0.5 point. If white is given one extra point, white would be exactly in the position that black was at initially: next to play and guaranteed to win by 0.5. The player next to move on the empty board and with a guaranteed 0.5 win has a cash deficit of k points in the first case (black to play) and m-(k+1) points in the other (black passed and white to play). So k = m-(k+1) or m = 2*k+1. Again the above analysis only considers the game theoretical value of the empty board, not any subsequent position. I welcome any correction if there is a flaw in my reasoning (which is quite possible). Jean-loup ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
