Re: Interesting question/experiment about value of cube ownership
MK: I don't understand why YOU wouldn't double at 99%? Can you explain this? If the oppenent will still take at 100% then why risk losing 2 points 1% of the time? I thought I answered your question about win rates previously. A bot that always doubles, I'd expect to lose 0.3 ppg. It's hard to search back on my phone app, so maybe that's incorrect.) A bot that doubles immediately it's ahead, I'd expect to lose about half that. Those values assume the bot plays as well as gnubg for the remainder of the game. If the opponent will make further cube errors, then it should be a little bit more. From: MK Sent: Wednesday, April 3, 2024 10:29:11 pm To: Ian Shaw ; GnuBg Bug Subject: Re: Interesting question/experiment about value of cube ownership On 4/2/2024 7:08 AM, Ian Shaw wrote: > A cube strategy against a bot that never passes: Not never but we loosely say that since it takes at GWC > 0, i.e. even at 0.0001% > only double when (a) you are 100% to win I don't understand why you wouldn't double at 99%? Can you explain this? > (b) it's the last roll of the game and you have an advantage. Yes, this is very bad for the mutant and already happens now. > So the take point is 16.7%. Gammons complicate it, but I'm > sure you get the idea. If you can clearly define your strategy, I would be glad to create a script to run the experiment to see what will happen. BTW: you are still avoiding the issue of how much the mutant will win compared to what it would be expected to win based on its total "cube error rate". What win rate would you say a mutant that takes at GWC > 0.0001 even on the last roll, (which must be the biggest possible cube error), will achieve? Any guesses by anyone..? MK
Re: Interesting question/experiment about value of cube ownership
MK: What I PROPOSE is doing the same thing done training TD-Gammon v.1, I.E. random self-play, but this time also cubeful and MATCHFUL, i.e. random cube as well as checker decisions. As I remember it (though it's many years since I read the research), the self-play wasn't accomplished by picking random moves. It was the initial network weights that were random. The move picked was the best-ranked move of all the evaluated moves. This is a calculation, not a random selection. How do you propose to rank double vs no double, and take vs pass? From: MK Sent: Wednesday, April 3, 2024 10:01:17 PM To: Ian Shaw ; GnuBg Bug Subject: Re: Interesting question/experiment about value of cube ownership On 4/2/2024 5:13 AM, Ian Shaw wrote: > What would be your proposed structure for training a > cubeful bot? What gains and obstacles do you foresee. I don't know what you mean by "structure". What I propose is doing the same thing done training TD-Gammon v.1, i.e. random self-play, but this time also cubeful and matchful, i.e. random cube as well as checker decisions. Apparently Tseauro still works at IBM with access to huge CPU powers. Perhaps he can be put to shame for the damage he caused to BG AI by what he did with TD-Gammon v.2 and be urged to redeem himself. In other forums, people talk about doing "XG rollouts on Amazon's cloud servers", etc. Doing more biased rollouts is plain stupid/illogical. Any such efforts would be put to better use in training a new bot instead. The question is who would volunteer to do it. People like the Alpha-Zero team, etc. don't seem to want to touch "gamblegammon" with a ten feet pole, possibly because of the gambling nature of the game. In the past, I have suggested in RGB that random rollout feature can be added to GnuBG and results from trustable users can be collected over time in a central database to gradually create a bot that won't rely on concocted, biased/inaccurate cube formulas and match equity tables. Unfortunately the faithfuls are happy with their dogmas and no better bots are likely in the near future... :( MK
Re: Interesting question/experiment about value of cube ownership
On 4/2/2024 7:08 AM, Ian Shaw wrote: A cube strategy against a bot that never passes: Not never but we loosely say that since it takes at GWC > 0, i.e. even at 0.0001% only double when (a) you are 100% to win I don't understand why you wouldn't double at 99%? Can you explain this? (b) it's the last roll of the game and you have an advantage. Yes, this is very bad for the mutant and already happens now. So the take point is 16.7%. Gammons complicate it, but I'm sure you get the idea. If you can clearly define your strategy, I would be glad to create a script to run the experiment to see what will happen. BTW: you are still avoiding the issue of how much the mutant will win compared to what it would be expected to win based on its total "cube error rate". What win rate would you say a mutant that takes at GWC > 0.0001 even on the last roll, (which must be the biggest possible cube error), will achieve? Any guesses by anyone..? MK
Re: Interesting question/experiment about value of cube ownership
On 4/2/2024 5:13 AM, Ian Shaw wrote: What would be your proposed structure for training a cubeful bot? What gains and obstacles do you foresee. I don't know what you mean by "structure". What I propose is doing the same thing done training TD-Gammon v.1, i.e. random self-play, but this time also cubeful and matchful, i.e. random cube as well as checker decisions. Apparently Tseauro still works at IBM with access to huge CPU powers. Perhaps he can be put to shame for the damage he caused to BG AI by what he did with TD-Gammon v.2 and be urged to redeem himself. In other forums, people talk about doing "XG rollouts on Amazon's cloud servers", etc. Doing more biased rollouts is plain stupid/illogical. Any such efforts would be put to better use in training a new bot instead. The question is who would volunteer to do it. People like the Alpha-Zero team, etc. don't seem to want to touch "gamblegammon" with a ten feet pole, possibly because of the gambling nature of the game. In the past, I have suggested in RGB that random rollout feature can be added to GnuBG and results from trustable users can be collected over time in a central database to gradually create a bot that won't rely on concocted, biased/inaccurate cube formulas and match equity tables. Unfortunately the faithfuls are happy with their dogmas and no better bots are likely in the near future... :( MK
Re: question
On 4/2/2024 5:39 PM, Max S wrote: HI Am I able to import a file of a position, match score etc and you would return the XG analysis to me? If I understand correctly that you want to post here a GnuBG ID, (i.e. position + match ID), and want someone to post the XG analysis, I will do it for you (instead of giving unsolicited advice, etc.) It may perhaps be interesting for all to compare the two bots' analysis. (If you want, specify the skill level for XG analysis.) MK
Re: question
Hi Max, GnuBg can import match files and analyse them. You can also copy an XG position id and paste it into gnubg. Like XG, it can identify errors and estimate how lucky the rolls are. The results won't be exactly the same as XG because the analysis engine is different. But it will be very similar. Does this answer your question? Regards, Ian Shaw From: bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org on behalf of Max S Sent: Wednesday, April 3, 2024 2:39:07 AM To: bug-gnubg@gnu.org Subject: question HI Am I able to import a file of a position, match score etc and you would return the XG analysis to me?
Re: question
Hello Max, Il 02 aprile 2024 alle 19:39 Max S ha scritto: > HI > Am I able to import a file of a position, match score etc and you would > return the XG analysis to me? what do you mean with “XG analysis”? —F
question
HI Am I able to import a file of a position, match score etc and you would return the XG analysis to me?
Re: Interesting question/experiment about value of cube ownership
Of course I don't assume that gnubg always wins. That would be naive. A cube strategy against a bot that never passes: only double when (a) you are 100% to win (b) it's the last roll of the game and you have an advantage. The bot can also take a double deeper than normal, since the mutant will always take the recube to 4. So the risk is 1 point and the reward is 5 points (instead of 3). So the take point is 16.7%. Gammons complicate it, but I'm sure you get the idea. From: MK Sent: Tuesday, April 2, 2024 12:08:49 pm To: Ian Shaw ; GnuBg Bug Subject: Re: Interesting question/experiment about value of cube ownership On 3/31/2024 4:18 AM, Ian Shaw wrote: > If the mutant strategy is always to take, then gnubg GAINS when > Mutant > takes a D/P because that increases the points GnuBg wins. Yes, of course, but only and only if the GnuBG wins. Obviously you faithfully assume that GnuBG will always win and keep raking in the higher cube points but experiment like the ones I did may prove it otherwise. And this is only speaking about winning more than 50% of points. To this day, I have never been able get you guys to talk about mutant strategies winning more than what would be expected from their cube error rates, which is even more important in debunking the elaborate so-called "cube skill theory" a complete mound of cow pies... > Currently, gnubg is assuming it is playing against a player using > it's own cube strategy. And this is why they are as easy to derail as toy trains on tracks around the xmas tree and to beat even by people like me, who is a nobody compared to gamblegammon giants. See my 10-years old experiments against various bots at my site: https://montanaonline.net/backgammon/ I do however believe that future bots, trained through cubeful and matchful self-play, will come very close to "perfect" play that no human may possibly beat but current bots, including GnuBG, are not even worth a mention by that measure. > It could be reprogrammed to take advantage of knowing that it's > opponent would never pass. Okay, well, I'm daring to tell me how do you propose the bot could be reprogrammed to do that? You don't need to post the programming code here. Just explain how the bot would achieve that in plain language. I bet you won't be able to do. Empty talk is cheap... Let me hold your hand to make another baby step: even if you could reprogram a bot to to that, it would become just another version of the same toy train on tracks going in circles around the xmas tree, with the same weakness of exploitability by being totally predictable. After that, you would have to reprogram you bot by revising your jackoffski cube formulae again... Do you see your problem..? MK > > *From:* MK > *Sent:* Friday, March 29, 2024 2:28:09 AM > *To:* Ian Shaw ; GnuBg Bug > *Subject:* Re: Interesting question/experiment about value of cube ownership > On 3/19/2024 3:54 AM, Ian Shaw wrote: > >> MK "Those numbers are based on how the bot would play against itself. >> If you accept the bot's decisions as best/perfect and if you try to >> play just like bot, assuming that your opponent will also try to play >> just like the bot, of course you wouldn't/shouldn't double." > >> Agreed. Against a worse player, you can take with fewer winning chances. >> If your opponent will give up enough equity in errors to overcome the >> error of the bad take (and your own subsequent errors), then you should >> still come out ahead. > > I hope you are realizing that you are agreeing with the bot, not with me. > What you quoted from me above was in response to your previously saying: > > "I wouldn’t double. As shown by the rollouts, I'd be giving > "up 0.36 points per game, on average. Even if I knew you would > "roll 66, I would still take, because the equity of -0.276 * 2 > "is still better than giving up a whole 1.000 point. > > Would you drop if you knew that the mutant would roll 77? You wouldn't. > (Just exaggerating to make a point, while reminiscing how Jellyfish was > not only rolling 77's but shamelessly playing them to escape 6-primes:) > > Once the mutant conditionally pre-doubles, (i.e. if rules allow it, in > case it wins the opening roll), you will become hostage to its strategy, > or in better sounding words, you will be dancing to its tune... ;) > > Reaching a D/P later won't help you either because the mutant will not > drop and will force you to keep playing until the last roll, perhaps > trading the cube more times back and forth. > > Letting the bot play for both side after the "opening double" actually > defeats the purpose o
Re: Interesting question/experiment about value of cube ownership
Yes, I am referring to theoretical continuous model for the 20% value, and agree it would apply to any suitable game, not just backgammon. But backgammon isn't a continuous game. It has jumps in equity betewen one opportunity to double and the next. The concept of cube efficiency is the estimate to allow for this. What other approximations are there? If course, at deeper plies than 0, bots look at the outcomes of all possible sequences so the effect of the cube efficiency approximation diminishes. What would be your proposed structure for training a cubeful bot? What gains and obstacles do you foresee. If course I think similarly about your other insulting terminology. Speaking personally, it reduces the amount of pleasure I get from the discussion and therefore the amount of time I'm prepared to put in. From: MK Sent: Tuesday, April 2, 2024 11:43:40 AM To: Ian Shaw ; GnuBg Bug Subject: Re: Interesting question/experiment about value of cube ownership On 3/31/2024 3:53 AM, Ian Shaw wrote: > I'm glad we agree on the basic 25% take point. Do you also agree on > the the theoretical 20% take point for perfect cube efficiency? If by "theoretical" you mean a purely mathematical proposition, i.e. not specifically related to cubeful backgammon, cubeful hopscotch, cubeful snakes and ladders, etc., or (to repeat myself) as applied in simple games where you can calculate those 25% and 20% accurately and consistently, then I would say I agree with you. > As far as I know, the only part of cube theory not calculated > mathematically is the estimate made for cube efficiency. But it's > a long time since I read Janowski so I may be wrong on that. Since no bot was ever trained through cubeful self-play, all cubeful calculations of all kinds are "mythematically" calculated, by using repeatedly adjusted constants to produce the results desired by the humans of faith... > (I think you are using "gamble gammon" as a pejorative. I suspect > that every time you do so, you lose credibility with anyone likely > to read this. You may wish to take this into account, bearing in > mind that most backgammon with the cube isn't played for money.) I like writing poems, coining new expressions, country music lyrics, word plays, puns, etc. and ta times I use them pejoratively but not so much with "gamblegammon", for which I used worse names. There was a game called "backgammon" before the "doubling cube" was introduced to it for gambling purposes, which changed it drastically enough for it to be considered a "variant" of backgammon, just like any other such variants. I have argued for over 20 years that the "cubeful backgammon variant" needs to be given a new name and I proposed "gamblegammon", which I thought was quite appropriate. I have been calling it "gamblegammon" in other forums like RGB ever since and invited others to suggest other names for it if they didn't like my "gamblegammon". Feel free to offer your suggestion. While on the subject, I'm surprised that you didn't catch on to many other expressions that I have been using pejoratively, such as my "fartoffski cube skill formula" against the "jackoffski cube skill formula", etc. Focus on understanding and refuting my arguments. If you (all) can't, then I really don't care about my credibility with people who can't understand my arguments, let alone rise up to defeat my arguments. MK > ---- > *From:* MK > *Sent:* Friday, March 29, 2024 4:34:39 AM > *To:* Ian Shaw ; GnuBg Bug > *Subject:* Re: Interesting question/experiment about value of cube ownership > On 3/19/2024 7:44 AM, Ian Shaw wrote: > >> I don’t "divinely believe" in the current cube theory. I understand >> the maths behind it. If you have found errors in the maths, then I >> would be glad to re-evaluate. > >> Let's find out where you disagree by starting from the beginning. >> What is your analysis of the basic 25% takepoint calculation? > > > I'm not questioning whether a simple doubling theory, (assuming it > can be called a "theory"), can be applied in simple game where you > can calculate that 25% accurately and consistently. > > I'm questioning whether some doubling strategy can be applied in > gamblegammon, based on a jumble of incomplete/inaccurate empirical > statistics and mathematical calculation formulas that were several > times retrofitted to produce some expected results, and call it a > "cube skill theory". > > In RGB, some mathematicians had argued that it could be called a > "theory" because it was mathematically proven, which can not be > because th
Re: Interesting question/experiment about value of cube ownership
On 3/31/2024 4:18 AM, Ian Shaw wrote: If the mutant strategy is always to take, then gnubg GAINS when > Mutant takes a D/P because that increases the points GnuBg wins. Yes, of course, but only and only if the GnuBG wins. Obviously you faithfully assume that GnuBG will always win and keep raking in the higher cube points but experiment like the ones I did may prove it otherwise. And this is only speaking about winning more than 50% of points. To this day, I have never been able get you guys to talk about mutant strategies winning more than what would be expected from their cube error rates, which is even more important in debunking the elaborate so-called "cube skill theory" a complete mound of cow pies... Currently, gnubg is assuming it is playing against a player using it's own cube strategy. And this is why they are as easy to derail as toy trains on tracks around the xmas tree and to beat even by people like me, who is a nobody compared to gamblegammon giants. See my 10-years old experiments against various bots at my site: https://montanaonline.net/backgammon/ I do however believe that future bots, trained through cubeful and matchful self-play, will come very close to "perfect" play that no human may possibly beat but current bots, including GnuBG, are not even worth a mention by that measure. It could be reprogrammed to take advantage of knowing that it's opponent would never pass. Okay, well, I'm daring to tell me how do you propose the bot could be reprogrammed to do that? You don't need to post the programming code here. Just explain how the bot would achieve that in plain language. I bet you won't be able to do. Empty talk is cheap... Let me hold your hand to make another baby step: even if you could reprogram a bot to to that, it would become just another version of the same toy train on tracks going in circles around the xmas tree, with the same weakness of exploitability by being totally predictable. After that, you would have to reprogram you bot by revising your jackoffski cube formulae again... Do you see your problem..? MK *From:* MK *Sent:* Friday, March 29, 2024 2:28:09 AM *To:* Ian Shaw ; GnuBg Bug *Subject:* Re: Interesting question/experiment about value of cube ownership On 3/19/2024 3:54 AM, Ian Shaw wrote: MK "Those numbers are based on how the bot would play against itself. If you accept the bot's decisions as best/perfect and if you try to play just like bot, assuming that your opponent will also try to play just like the bot, of course you wouldn't/shouldn't double." Agreed. Against a worse player, you can take with fewer winning chances. If your opponent will give up enough equity in errors to overcome the error of the bad take (and your own subsequent errors), then you should still come out ahead. I hope you are realizing that you are agreeing with the bot, not with me. What you quoted from me above was in response to your previously saying: "I wouldn’t double. As shown by the rollouts, I'd be giving "up 0.36 points per game, on average. Even if I knew you would "roll 66, I would still take, because the equity of -0.276 * 2 "is still better than giving up a whole 1.000 point. Would you drop if you knew that the mutant would roll 77? You wouldn't. (Just exaggerating to make a point, while reminiscing how Jellyfish was not only rolling 77's but shamelessly playing them to escape 6-primes:) Once the mutant conditionally pre-doubles, (i.e. if rules allow it, in case it wins the opening roll), you will become hostage to its strategy, or in better sounding words, you will be dancing to its tune... ;) Reaching a D/P later won't help you either because the mutant will not drop and will force you to keep playing until the last roll, perhaps trading the cube more times back and forth. Letting the bot play for both side after the "opening double" actually defeats the purpose of the experiment but since there is no "separately existing, fully functional mutant bot (that would play like me;)" to make it play against GnuBG 2-ply, this is the only way we can do it and it's better than nothing. So, this way the really "semi-mutant" play will lose but it still will not lose more than what would be expected from the cube error rate that the mutant incurs from this "opening double". This alone is enough to prove that the currently dogmatized "cube skill theory" is a jarful of cow chip cookies... MK
Re: Interesting question/experiment about value of cube ownership
On 3/31/2024 3:53 AM, Ian Shaw wrote: I'm glad we agree on the basic 25% take point. Do you also agree on the the theoretical 20% take point for perfect cube efficiency? If by "theoretical" you mean a purely mathematical proposition, i.e. not specifically related to cubeful backgammon, cubeful hopscotch, cubeful snakes and ladders, etc., or (to repeat myself) as applied in simple games where you can calculate those 25% and 20% accurately and consistently, then I would say I agree with you. As far as I know, the only part of cube theory not calculated mathematically is the estimate made for cube efficiency. But it's a long time since I read Janowski so I may be wrong on that. Since no bot was ever trained through cubeful self-play, all cubeful calculations of all kinds are "mythematically" calculated, by using repeatedly adjusted constants to produce the results desired by the humans of faith... (I think you are using "gamble gammon" as a pejorative. I suspect that every time you do so, you lose credibility with anyone likely to read this. You may wish to take this into account, bearing in mind that most backgammon with the cube isn't played for money.) I like writing poems, coining new expressions, country music lyrics, word plays, puns, etc. and ta times I use them pejoratively but not so much with "gamblegammon", for which I used worse names. There was a game called "backgammon" before the "doubling cube" was introduced to it for gambling purposes, which changed it drastically enough for it to be considered a "variant" of backgammon, just like any other such variants. I have argued for over 20 years that the "cubeful backgammon variant" needs to be given a new name and I proposed "gamblegammon", which I thought was quite appropriate. I have been calling it "gamblegammon" in other forums like RGB ever since and invited others to suggest other names for it if they didn't like my "gamblegammon". Feel free to offer your suggestion. While on the subject, I'm surprised that you didn't catch on to many other expressions that I have been using pejoratively, such as my "fartoffski cube skill formula" against the "jackoffski cube skill formula", etc. Focus on understanding and refuting my arguments. If you (all) can't, then I really don't care about my credibility with people who can't understand my arguments, let alone rise up to defeat my arguments. MK *From:* MK *Sent:* Friday, March 29, 2024 4:34:39 AM *To:* Ian Shaw ; GnuBg Bug *Subject:* Re: Interesting question/experiment about value of cube ownership On 3/19/2024 7:44 AM, Ian Shaw wrote: I don’t "divinely believe" in the current cube theory. I understand the maths behind it. If you have found errors in the maths, then I would be glad to re-evaluate. Let's find out where you disagree by starting from the beginning. What is your analysis of the basic 25% takepoint calculation? I'm not questioning whether a simple doubling theory, (assuming it can be called a "theory"), can be applied in simple game where you can calculate that 25% accurately and consistently. I'm questioning whether some doubling strategy can be applied in gamblegammon, based on a jumble of incomplete/inaccurate empirical statistics and mathematical calculation formulas that were several times retrofitted to produce some expected results, and call it a "cube skill theory". In RGB, some mathematicians had argued that it could be called a "theory" because it was mathematically proven, which can not be because the so-called "cube skill" is not a purely mathematical proposition. In a game involving luck like gamblegammon, (more luck than skill in my personal opinion), the proposition is necessarily statistical, empirical one and thus needs to be empirically proven. You say "let's start from the beginning". Yes, let's do so indeed. TD-Gammon v.1 was empirically trained through self-play of cubeless "money games", including gammons but not backgammons, and perhaps not enough trials. That's it. That's your beginning... To that, you use all kinds of "maths and mirrors" to add backgammon rates, cubeful equity formulas, cubeful matchful equity tables, etc. to "estimate" your winning chances, in order to apply to it what you a "basic 25% take point". And I'm questioning sanity of all this, in fact I'm arguing that it's all a pile of cow pies. Shortcuts was taken in the days of TD-Gammon because of not having enough CPU power, which is no longer true. Yet, there is no signs of any willingness out there to create cubefully, matcfully trained better gamblegammon bots. It's easier to destroy a falsely claimed "theory" by poking
Re: Interesting question/experiment about value of cube ownership
If the mutant strategy is always to take, then gnubg GAINS when Mutant takes a D/P because that increases the points GnuBg wins. Currently, gnubg is assuming it is playing against a player using it's own cube strategy. It could be reprogrammed to take advantage of knowing that it's opponent would never pass. From: MK Sent: Friday, March 29, 2024 2:28:09 AM To: Ian Shaw ; GnuBg Bug Subject: Re: Interesting question/experiment about value of cube ownership On 3/19/2024 3:54 AM, Ian Shaw wrote: > MK "Those numbers are based on how the bot would play against itself. > If you accept the bot's decisions as best/perfect and if you try to > play just like bot, assuming that your opponent will also try to play > just like the bot, of course you wouldn't/shouldn't double." > Agreed. Against a worse player, you can take with fewer winning chances. > If your opponent will give up enough equity in errors to overcome the > error of the bad take (and your own subsequent errors), then you should > still come out ahead. I hope you are realizing that you are agreeing with the bot, not with me. What you quoted from me above was in response to your previously saying: "I wouldn’t double. As shown by the rollouts, I'd be giving "up 0.36 points per game, on average. Even if I knew you would "roll 66, I would still take, because the equity of -0.276 * 2 "is still better than giving up a whole 1.000 point. Would you drop if you knew that the mutant would roll 77? You wouldn't. (Just exaggerating to make a point, while reminiscing how Jellyfish was not only rolling 77's but shamelessly playing them to escape 6-primes:) Once the mutant conditionally pre-doubles, (i.e. if rules allow it, in case it wins the opening roll), you will become hostage to its strategy, or in better sounding words, you will be dancing to its tune... ;) Reaching a D/P later won't help you either because the mutant will not drop and will force you to keep playing until the last roll, perhaps trading the cube more times back and forth. Letting the bot play for both side after the "opening double" actually defeats the purpose of the experiment but since there is no "separately existing, fully functional mutant bot (that would play like me;)" to make it play against GnuBG 2-ply, this is the only way we can do it and it's better than nothing. So, this way the really "semi-mutant" play will lose but it still will not lose more than what would be expected from the cube error rate that the mutant incurs from this "opening double". This alone is enough to prove that the currently dogmatized "cube skill theory" is a jarful of cow chip cookies... MK
Re: Interesting question/experiment about value of cube ownership
I'm glad we agree on the basic 25% take point. Do you also agree on the the theoretical 20% take point for perfect cube efficiency? As far as I know, the only part of cube theory not calculated mathematically is the estimate made for cube efficiency. But it's a long time since I read Janowski so I may be wrong on that. (I think you are using "gamble gammon" as a pejorative. I suspect that every time you do so, you lose credibility with anyone likely to read this. You may wish to take this into account, bearing in mind that most backgammon with the cube isn't played for money.) Regards, Ian Shaw From: MK Sent: Friday, March 29, 2024 4:34:39 AM To: Ian Shaw ; GnuBg Bug Subject: Re: Interesting question/experiment about value of cube ownership On 3/19/2024 7:44 AM, Ian Shaw wrote: > I don’t "divinely believe" in the current cube theory. I understand > the maths behind it. If you have found errors in the maths, then I > would be glad to re-evaluate. > Let's find out where you disagree by starting from the beginning. > What is your analysis of the basic 25% takepoint calculation? I'm not questioning whether a simple doubling theory, (assuming it can be called a "theory"), can be applied in simple game where you can calculate that 25% accurately and consistently. I'm questioning whether some doubling strategy can be applied in gamblegammon, based on a jumble of incomplete/inaccurate empirical statistics and mathematical calculation formulas that were several times retrofitted to produce some expected results, and call it a "cube skill theory". In RGB, some mathematicians had argued that it could be called a "theory" because it was mathematically proven, which can not be because the so-called "cube skill" is not a purely mathematical proposition. In a game involving luck like gamblegammon, (more luck than skill in my personal opinion), the proposition is necessarily statistical, empirical one and thus needs to be empirically proven. You say "let's start from the beginning". Yes, let's do so indeed. TD-Gammon v.1 was empirically trained through self-play of cubeless "money games", including gammons but not backgammons, and perhaps not enough trials. That's it. That's your beginning... To that, you use all kinds of "maths and mirrors" to add backgammon rates, cubeful equity formulas, cubeful matchful equity tables, etc. to "estimate" your winning chances, in order to apply to it what you a "basic 25% take point". And I'm questioning sanity of all this, in fact I'm arguing that it's all a pile of cow pies. Shortcuts was taken in the days of TD-Gammon because of not having enough CPU power, which is no longer true. Yet, there is no signs of any willingness out there to create cubefully, matcfully trained better gamblegammon bots. It's easier to destroy a falsely claimed "theory" by poking holes in it than to prove a proposition so that you can call it a theory, and this is what I'm trying to accomplish with my experiments. Since I can't single-handedly create a better bot, I'm trying what I can do to create a need for, thus an incentive for the creation of such a bot, "from scratch". My "fartoffski mutant cube strategy", (based on arbitrary stages of game and double/take points), in my experiments 11 and 12 came within margin of error of beating GnuBG 2-ply. Folks, it's time for better gamblegammon bots... MK
Re: Interesting question/experiment about value of cube ownership
On 3/19/2024 7:44 AM, Ian Shaw wrote: I don’t "divinely believe" in the current cube theory. I understand the maths behind it. If you have found errors in the maths, then I would be glad to re-evaluate. Let's find out where you disagree by starting from the beginning. What is your analysis of the basic 25% takepoint calculation? I'm not questioning whether a simple doubling theory, (assuming it can be called a "theory"), can be applied in simple game where you can calculate that 25% accurately and consistently. I'm questioning whether some doubling strategy can be applied in gamblegammon, based on a jumble of incomplete/inaccurate empirical statistics and mathematical calculation formulas that were several times retrofitted to produce some expected results, and call it a "cube skill theory". In RGB, some mathematicians had argued that it could be called a "theory" because it was mathematically proven, which can not be because the so-called "cube skill" is not a purely mathematical proposition. In a game involving luck like gamblegammon, (more luck than skill in my personal opinion), the proposition is necessarily statistical, empirical one and thus needs to be empirically proven. You say "let's start from the beginning". Yes, let's do so indeed. TD-Gammon v.1 was empirically trained through self-play of cubeless "money games", including gammons but not backgammons, and perhaps not enough trials. That's it. That's your beginning... To that, you use all kinds of "maths and mirrors" to add backgammon rates, cubeful equity formulas, cubeful matchful equity tables, etc. to "estimate" your winning chances, in order to apply to it what you a "basic 25% take point". And I'm questioning sanity of all this, in fact I'm arguing that it's all a pile of cow pies. Shortcuts was taken in the days of TD-Gammon because of not having enough CPU power, which is no longer true. Yet, there is no signs of any willingness out there to create cubefully, matcfully trained better gamblegammon bots. It's easier to destroy a falsely claimed "theory" by poking holes in it than to prove a proposition so that you can call it a theory, and this is what I'm trying to accomplish with my experiments. Since I can't single-handedly create a better bot, I'm trying what I can do to create a need for, thus an incentive for the creation of such a bot, "from scratch". My "fartoffski mutant cube strategy", (based on arbitrary stages of game and double/take points), in my experiments 11 and 12 came within margin of error of beating GnuBG 2-ply. Folks, it's time for better gamblegammon bots... MK
Re: Interesting question/experiment about value of cube ownership
On 3/19/2024 7:37 AM, Ian Shaw wrote: MK: This is why I am doing my various experiments. One of which that I had previously mentioned in this very thread involves a "mutant cubestrategy" of doubling at GWC > 50% and taking at GWC > 0%. In that experiment of 20,000 money games, the mutant won 40.80% of total points against GnuBG 2-ply. Since winning the opening roll gives the player GWC > 50%, I ran a variant of the above experiment making the mutant also double if it wins the opening roll. This time, after 20,000 money games the mutant won 45.77% of total points. These sound similar enough that I'll combine them. Overall, the mutant strategy if doubling as soon as you had an advantage lost 0.1343 points per game. Always doubling immediately lost 0.36 ppg. So, not doubling until you are winning appears to be a better strategy than always doubling. But, as you expected, the mutant strategy isn't as good as the current cube algorithm, which loses 0 ppg. I think you misunderstood the whole thing. You need to compare the first mutant strategy to the bot playing against itself straight. The mutant is expected to lose. The fact that it didn't lose too badly is a separate point by itself. Then you need to compare mutant's variant strategy of doubling at once to bot's regular play against itself with the only difference of doubling at once. Now we are comparing mutant variant against mutant and bot variant against bot. In the case of the bot, doubling at once causes the variant bot to lose points. However, in the case of the mutant, doubling at once causes the variant mutant ti win more points, not compared to the bot but compared to the mutant itself! I can imagine how difficult it may be for some of you guys to stick your heads out of the box and try to understand what I'm trying to demonstrate. I'm not saying that the above crude mutant cube strategy is better than the 2-ply bot but that if it was the only way people played gamblegammon on a different planet, then doubling as soon as winning the opening roll would be the correct cube action that wins more points than not doubling. I hope this is clear now, because I don't know how else I can explain this. However, I don’t think 4 trials is enough. Your strategy has huge variance. Have you calculated the statistical significance as suggested by one of the earlier responders? I recall that he suggested a similar experiment with lower variance to reduce the required number of trials, but you didn't want to try it. I can't find that post at the moment, so I don’t know how many trials he calculated, but since your cube can get very high you would inevitably need more trials. You must be thinking of the first experiment that I had mention, in which the mutant would double/take/drop totally randomly. In that the cube has gone astronomically high and I abandoned it after only 30,000 games since I realized that even a million trials may not be enough, let alone a few hundred thousands that was suggested to me. In the above experiment the variance is surely big but I wouldn't say huge. I agree that 20,000 trials for each mutant variant is barely enough to give a glimpse of the possible results. With my now shared scripts, nothing prevents anyone to run as many trials as they consider enough. (I may do some more myself also if I find the time for it). My preliminary results may be considered well enough indicators to justify pursuing the experiment further with more trials. MK
Re: Interesting question/experiment about value of cube ownership
On 3/19/2024 3:54 AM, Ian Shaw wrote: MK "Those numbers are based on how the bot would play against itself. If you accept the bot's decisions as best/perfect and if you try to play just like bot, assuming that your opponent will also try to play just like the bot, of course you wouldn't/shouldn't double." Agreed. Against a worse player, you can take with fewer winning chances. If your opponent will give up enough equity in errors to overcome the error of the bad take (and your own subsequent errors), then you should still come out ahead. I hope you are realizing that you are agreeing with the bot, not with me. What you quoted from me above was in response to your previously saying: "I wouldn’t double. As shown by the rollouts, I'd be giving "up 0.36 points per game, on average. Even if I knew you would "roll 66, I would still take, because the equity of -0.276 * 2 "is still better than giving up a whole 1.000 point. Would you drop if you knew that the mutant would roll 77? You wouldn't. (Just exaggerating to make a point, while reminiscing how Jellyfish was not only rolling 77's but shamelessly playing them to escape 6-primes:) Once the mutant conditionally pre-doubles, (i.e. if rules allow it, in case it wins the opening roll), you will become hostage to its strategy, or in better sounding words, you will be dancing to its tune... ;) Reaching a D/P later won't help you either because the mutant will not drop and will force you to keep playing until the last roll, perhaps trading the cube more times back and forth. Letting the bot play for both side after the "opening double" actually defeats the purpose of the experiment but since there is no "separately existing, fully functional mutant bot (that would play like me;)" to make it play against GnuBG 2-ply, this is the only way we can do it and it's better than nothing. So, this way the really "semi-mutant" play will lose but it still will not lose more than what would be expected from the cube error rate that the mutant incurs from this "opening double". This alone is enough to prove that the currently dogmatized "cube skill theory" is a jarful of cow chip cookies... MK
RE: Interesting question/experiment about value of cube ownership
MK: Even though I think most of you won't absorb what I wrote above, because you all "divinely believe" in the current "cube skill theory", I won't consider it a total waste of my time even if it sows a seed of doubt in just one mind. I don’t "divinely believe" in the current cube theory. I understand the maths behind it. If you have found errors in the maths, then I would be glad to re-evaluate. Let's find out where you disagree by starting from the beginning. What is your analysis of the basic 25% takepoint calculation? -- Ian
RE: Interesting question/experiment about value of cube ownership
MK: This is why I am doing my various experiments. One of which that I had previously mentioned in this very thread involves a "mutant cube strategy" of doubling at GWC > 50% and taking at GWC > 0%. In that experiment of 20,000 money games, the mutant won 40.80% of total points against GnuBG 2-ply. Since winning the opening roll gives the player GWC > 50%, I ran a variant of the above experiment making the mutant also double if it wins the opening roll. This time, after 20,000 money games the mutant won 45.77% of total points. These sound similar enough that I'll combine them. Overall, the mutant strategy if doubling as soon as you had an advantage lost 0.1343 points per game. Always doubling immediately lost 0.36 ppg. So, not doubling until you are winning appears to be a better strategy than always doubling. But, as you expected, the mutant strategy isn't as good as the current cube algorithm, which loses 0 ppg. However, I don’t think 4 trials is enough. Your strategy has huge variance. Have you calculated the statistical significance as suggested by one of the earlier responders? I recall that he suggested a similar experiment with lower variance to reduce the required number of trials, but you didn't want to try it. I can't find that post at the moment, so I don’t know how many trials he calculated, but since your cube can get very high you would inevitably need more trials.
RE: Interesting question/experiment about value of cube ownership
MK "Those numbers are based on how the bot would play against itself. If you accept the bot's decisions as best/perfect and if you try to play just like bot, assuming that your opponent will also try to play just like the bot, of course you wouldn't/shouldn't double." Agreed. Against a worse player, you can take with fewer winning chances. If your opponent will give up enough equity in errors to overcome the error of the bad take (and your own subsequent errors), then you should still come out ahead.
Re: Interesting question/experiment about value of cube ownership
On 3/16/2024 6:15 PM, Ian Shaw via wrote: As this thread became more about the starting position than the original subject, I will branch out a separate thread for that and only reply to the cube issue in this one. Knowing the absolute equity is only useful for cube actions, and since the rules prohibit doubling on the opening roll, it's not very useful to me to make a distinction. It's just another arbitrary rule. All rules can be changed. Since I am trying to engage you all in theorizing for new ideas and better understanding concepts, it is very useful. "In fact, I'd argue that with the cube centered, you should be allowed to double if you want before you open your eyes > but this is a whole different subject and for one of the experiments that I have done and will share soon." I wouldn’t double. As shown by the rollouts, I'd be giving up 0.36 points per game, on average. Even if I knew you would roll 66, I would still take, because the equity of -0.276 * 2 is still better than giving up a whole 1.000 point. Those numbers are based on how the bot would play against itself. If you accept the bot's decisions as best/perfect and if you try to play just like bot, assuming that your opponent will also try to play just like the bot, of course you wouldn't/shouldn't double. However, there has never been any empirical evidence, based on "double-blind experiments", offered to support that. This is why I am doing my various experiments. One of which that I had previously mentioned in this very thread involves a "mutant cube strategy" of doubling at GWC > 50% and taking at GWC > 0%. In that experiment of 20,000 money games, the mutant won 40.80% of total points against GnuBG 2-ply. Since winning the opening roll gives the player GWC > 50%, I ran a variant of the above experiment making the mutant also double if it wins the opening roll. This time, after 20,000 money games the mutant won 45.77% of total points. In a control experiment of bot 2-ply vs bot 2-ply, with the only mutation being that the winner of the opening roll did double immediately, after 20,000 money games the mutant won 51.45% of total points. I have completed my 13 experiments and trying to make them available as a neat web page but I just can't seem to spare enough time to finalize it, which I keep saying soon. When I finish, you can download all data and scripts to run your own experiment to whatever number of trial you will consider statistically significant. Based on my own experiments, which I consider well enough, I predict that you won't like what you will discover... Even though I think most of you won't absorb what I wrote above, because you all "divinely believe" in the current "cube skill theory", I won't consider it a total waste of my time even if it sows a seed of doubt in just one mind. MK
Fwd: Interesting question/experiment about value of cube ownership
MK, You wrote "Not the "equity" but the "equity difference" between the "from" position and the "to" position." I can't see any difference in outcome between selecting the play that maximises the equity of the move made, and maximising the equity gain between the current position and the new position. The latter option just adds an unnecessary subtraction step, so I doubt that's how it's programmed. I agree that the Temp Map you posted is showing the equity with doubles allowed. I've put then into a spreadsheet so you can see the calculations. https://docs.google.com/spreadsheets/d/17XFvQPvWNqGMRgZScl2qcTW2ovNeCISq/edit?usp=sharing=117015456330598325471=true=true The equity of 31 after returning to the opening position is +0.219. The equity after an opening 31 is also +0.219. I conclude that there is no problem with the equity calculation that would affect how gnubg plays. The temp map was a later addition to gnubg, so I don't think it's used in the luck calculation. Even if the luck calculation is down as per the temperature map, and there is an error in the luck calculation of the opening roll, it won't permeate through to other rolls. The luck calculation is based on the actual roll compared to the other 21 (14 in the opening) possible rolls. The luck of 31 after returning to the opening position is +0.112. It's a good roll but not as good as any double. It's just above the average of +0.107. The worst roll is 14 at -0.113. The luck of an opening 31 is +0.219. It's a great roll, compared to the average of 0.000. The worst roll is 14 at -0.219. You want to make a distinction between the game not started being on roll before the move. For example, if you tossed a coin to see who started and then the winner rolls any non-double and plays it. Then winning the opening roll would show a luck of +0.052. The luck of an opening 31 is +0.167. This adds to +0.219, the same as above. This all seems consistent to me. Your argument about a fallacy appears to be a semantic one. When I say, "the equity before the opening roll is zero", I'm aware that the opening roll also defines who rolls first, and I'm using it in that context. If the opening roll were a coin toss, I wouldn’t speak in the same terms. I would say, "the equity before the toss is zero" because that's the average equity of all 30 possible outcomes (player 1 wind the toss & rolls, player 2 wins the toss and rolls). I would also say, "the equity having won the toss is +0.052 before rolling" because that's the average equity of the remaining 15 possible outcomes. Do you agree with the preceding paragraph? Knowing the absolute equity is only useful for cube actions, and since the rules prohibit doubling on the opening roll, it's not very useful to me to make a distinction. "In fact, I'd argue that with the cube centered, you should be allowed to double if you want before you open your eyes but this is a whole different subject and for one of the experiments that I have done and will share soon." I wouldn’t double. As shown by the rollouts, I'd be giving up 0.36 points per game, on average. Even if I knew you would roll 66, I would still take, because the equity of -0.276 * 2 is still better than giving up a whole 1.000 point. A couple of final points. I'm sure the match equity tables are calculated correctly. The starting player of any subsequent game is equally likely, so the equity of each game starts at zero. I did read some of the old rgb threads. They descended into rudeness and I lost interest. For some reason, your last 2 messages got caught in my spam filter, hence the late reply. Regards, Ian -Original Message- From: MK Sent: Wednesday, March 6, 2024 9:35 PM To: Ian Shaw ; bug-gnubg@gnu.org Cc: Philippe Michel Subject: Re: Interesting question/experiment about value of cube ownership On 3/4/2024 5:26 AM, Ian Shaw wrote: Since at least you care to continue this discussion, I will invest more of my time and effort mainly for the sake of improving GnuBG. > Sorry, MK, I didn't read back over the old threads, It was in my a previous post in this current thread here but it's no big deal. However, if you are serious about discussing this issue, which one of many related ones, you really need to read at least this thread in RGB (which I had mentioned in my last post): https://groups.google.com/g/rec.games.backgammon/c/QU1jM9aatO0/m/peIBhLJNAgAJ There is a lot in there, including a bug that I had pointed out in "analysis.c" that had been there since 2014, which is still there. See lines 243-246 in 2022 and 272-275 in current version: https://cvs.savannah.gnu.org/viewvc/gnubg/gnubg/analysis.c?revision=1.241=markup https://cvs.savannah.gnu.org/viewvc/gnubg/gnubg/analysis.c?revision=1.263=markup Too bad that the development/maintenance team isn't hearing me. > Yo
Re: Interesting question/experiment about value of cube ownership
Cat got your tongues? Meow... ;) MK
Re: Interesting question/experiment about value of cube ownership
On 3/4/2024 5:26 AM, Ian Shaw wrote: Since at least you care to continue this discussion, I will invest more of my time and effort mainly for the sake of improving GnuBG. Sorry, MK, I didn't read back over the old threads, It was in my a previous post in this current thread here but it's no big deal. However, if you are serious about discussing this issue, which one of many related ones, you really need to read at least this thread in RGB (which I had mentioned in my last post): https://groups.google.com/g/rec.games.backgammon/c/QU1jM9aatO0/m/peIBhLJNAgAJ There is a lot in there, including a bug that I had pointed out in "analysis.c" that had been there since 2014, which is still there. See lines 243-246 in 2022 and 272-275 in current version: https://cvs.savannah.gnu.org/viewvc/gnubg/gnubg/analysis.c?revision=1.241=markup https://cvs.savannah.gnu.org/viewvc/gnubg/gnubg/analysis.c?revision=1.263=markup Too bad that the development/maintenance team isn't hearing me. You asked earlier about the GNUBG ID I used. It was: 4HPwATDgc/ABMA:cAkA This is the ID obtained after the sequence I suggested: 4HPwATDgc/ABMA:cAkA They are identical, so there is no indication in the ID to indicate whether it is the opening roll. Let's clarify things. The starting position when you open GnuBG is 4HPwATDgc/ABMA:cAgAAAE at which analyze functions aren't yet available. 4HPwATDgc/ABMA:cAkAAAE (g changed to k) sets the game started flag (with nothing happened yet) and analyze functions become available. 4HPwATDgc/ABMA:cAg is the same position with the stupid JacKoby on :( Sorry for not being more careful. It makes a slight -0.0075 difference in the average equity of the position (+0.0989 vs +0.1064). The Contact Net does not have an input for Opening Roll, which makes sense. The bot plays by maximizing the equity of the next position. The opening layout – with doubles prohibited - is never the next position. Not the "equity" but the "equity difference" between the "from" position and the "to" position. The starting position has an average equity just like any other position except that it has two different equities depending on its initial and subsequent (recycled) occurrences. This is the issue here. Comparing evaluation, Rollout as Normal Position, Rollout as Initial Position, we can see that the evaluation is close to the value of the rollout. "Close" but not the "same" because the evaluation is based on erroneously including doubles in the average position equity even in the initial occurrence of the starting position! See the bug in the code above, which is only part of the reason. (Also see the attached temp map and eval images). The rollout as the initial position is lower since it doesn’t include those useful doubles. That's why I had asked if bot's auto-playing was the same as roll-outs... If you paste the 4HPwATDgc/ABMA:cAkAAAE and look at the temperature map, you can see that the average position equity of +0.1064 includes doubles and is almost twice what it should be +0.0521 (a difference of +0.0543). This makes all subsequent equity and luck calculations wrong! since they are all based on the equity difference between two positions, before and after what is rolled (and how it's played). If a bot is claimed to be superior to humans, it can't contain such inaccuracies... I don’t think the value of 0.36 ppg for cube ownership that we both obtained is a "coincidence". I think it's evidence that your script is a good emulation of a rollout. It wouldn't be a coincidence for it to be "close enough", based the above facts, but it being exactly the same must have been a coincidence. If you think 0.36 is inaccurate, I’m open to persuasion. Do you have a theory as to why it’s wrong, or what you think the correct value is? I believe I have provided enough factual evidence above... Regarding the equity at the beginning of the game, I’m not aware of any “age-old fallacy”. It's well established that winning the opening roll confers an advantage. I don’t think there's any theory that says the equity (between equal opponents) is non-zero before the opening roll. There wasn't/isn't. That's what I'm calling "a fallacy" because the equity between equal players before the "opening roll" isn't zero. You all confuse "before the game starts" and "before the opening roll" because in GambleGammon (what I call the BG variant played with the cube), deciding who goes first and the opening roll happen simultaneously. Imagine we are equal players wanting to play just one game. You roll your die with your eyes closed and ask who won the opening roll. I say you did. At that point you are on roll but haven't rolled the opening roll yet, (your eyes are still closed and you don't yet know the numbers lying on the board). For having won the opening roll, you already accrued an average +0.0521 equity. In fact, I'd argue that with the cube centered, you should be
RE: Interesting question/experiment about value of cube ownership
Sorry, MK, I didn't read back over the old threads, to see what links you had referenced, before I replied. It was late at night, and I was using my phone rather than a PC. In that case, I must have misunderstood what you meant by, "Is making the bot auto-play the same as doing rollouts?" It seemed to me that, since only you know what’s in your scripts, it was most likely that you were asking about rollouts are, although that also seemed unlikely. You asked earlier about the GNUBG ID I used. It was: 4HPwATDgc/ABMA:cAkA This is the ID obtained after the sequence I suggested: 4HPwATDgc/ABMA:cAkA (Thanks for the link to the BKGM post. I’d forgotten about it, but fortunately it had recently been discussed on Daily Gammon, where someone else also found your 4-roll solution!) They are identical, so there is no indication in the ID to indicate whether it is the opening roll. Therefore, the evaluation is the same. The Contact Net does not have an input for Opening Roll, which makes sense. The bot plays by maximizing the equity of the next position. The opening layout – with doubles prohibited - is never the next position. Comparing evaluation, Rollout as Normal Position, Rollout as Initial Position, we can see that the evaluation is close to the value of the rollout. The rollout as the initial position is lower since it doesn’t include those useful doubles. Ply Cube Pwin Pwin2 Pwin3 Plose Plose2 Plose3 E cubeless E No Double E Double/Take Action 2 eval n/a 0.5248 0.1495 0.0069 0.4752 0.1248 0.0053 +0.0759 +0.0982 ‑0.1712 NB (23.0%) 2 1Cen 0.5256 0.1532 0.0082 0.4744 0.1287 0.0053 +0.0785 +0.1187 Normal 2Opp 0.5274 0.1521 0.0074 0.4726 0.1295 0.0056 +0.1586 -0.2127 NB (27.3%) 2 1Cen 0.5130 0.1461 0.0069 0.4870 0.1336 0.0058 +0.0395 +0.0580 Initial 2Opp 0.5147 0.1468 0.0068 0.4853 0.1332 0.0059 +0.0881 -0.3002 NB (27.6%) I don’t think the value of 0.36 ppg for cube ownership that we both obtained is a "coincidence". I think it's evidence that your script is a good emulation of a rollout. If you think 0.36 is inaccurate, I’m open to persuasion. Do you have a theory as to why it’s wrong, or what you think the correct value is? Regarding the equity at the beginning of the game, I’m not aware of any “age-old fallacy”. It's well established that winning the opening roll confers an advantage. I don’t think there's any theory that says the equity (between equal opponents) is non-zero before the opening roll. Indeed, the construction of most match equity tables is based on the equity at the start of the game being zero (unless they are assuming unequal players). Finally, please lay off the disparagement. “What will it take for you guys to give some credit/benefit of the doubt to others than just yourselves?” is unnecessary. I’m not sure which group of ‘guys’ you lump me into; I’m just a gnubg user and a moderate player. I give lots of credit to loads of people who have contributed far more to backgammon than I ever will. Ian --Original Message- From: MK mailto:playbg-...@yahoo.com>> Sent: Monday, March 4, 2024 3:17 AM To: Ian Shaw mailto:ian.s...@riverauto.co.uk>>; bug-gnubg@gnu.org<mailto:bug-gnubg@gnu.org> Cc: Philippe Michel mailto:philippe.mich...@free.fr>> Subject: Re: Interesting question/experiment about value of cube ownership On 3/1/2024 6:02 PM, Ian Shaw wrote: > "Is making the bot auto-play the > same as doing rollouts?" > > It sounds like you are asking what a rollout is? I wasn't. > https://www.gnu.org/software/gnubg/manual/html_node/Introduction-to-ro > llouts.html I had read it many a times before. > https://www.bkgm.com/openings/rollouts.html This is funny. You are referring me back to the same link that I had given in my reply to you on February 10, here in this very same thread... :) What will it take for you guys to give some credit/benefit of the doubt to others than just yourselves? > Your auto-play script sounds very similar but I don't know exactly > what it does. Fair enough. My explaining in my previous post about what it does in this specific experiment was probably too brief and not very clear. > The main difference would be that you can make your scripts double > using your own algorithm. Yes, in some experiment I did that but not in this one. > Or indeed, veer from the bot's best chequer play. I haven't done any checker experiments yet but I may. > Minor differences might be the play settings for search depth and > pruning. Okay. You now made me realize that even unchecking all of the optional settings in roll-outs, it will not be the same as bot auto-playing. We both must have come up with the same 0.36 ppg by coincidence. Regardless, I believe that it's inaccurate in eith
Re: Interesting question/experiment about value of cube ownership
On 3/3/2024 8:16 PM, MK wrote: The next day after that, I checked it in Snowie and I posted a comprehensive recap about the subject. See: Sorry I forgot to give the link. Here it is: https://groups.google.com/g/rec.games.backgammon/c/rFZyUcg8IPQ/m/gxuWiERmCAAJ MK
Re: Interesting question/experiment about value of cube ownership
On 3/1/2024 6:02 PM, Ian Shaw wrote: "Is making the bot auto-play the same as doing rollouts?" It sounds like you are asking what a rollout is? I wasn't. https://www.gnu.org/software/gnubg/manual/html_node/Introduction-to-rollouts.html I had read it many a times before. https://www.bkgm.com/openings/rollouts.html This is funny. You are referring me back to the same link that I had given in my reply to you on February 10, here in this very same thread... :) What will it take for you guys to give some credit/benefit of the doubt to others than just yourselves? Your auto-play script sounds very similar but I don't know exactly what it does. Fair enough. My explaining in my previous post about what it does in this specific experiment was probably too brief and not very clear. The main difference would be that you can make your scripts double using your own algorithm. Yes, in some experiment I did that but not in this one. Or indeed, veer from the bot's best chequer play. I haven't done any checker experiments yet but I may. Minor differences might be the play settings for search depth and pruning. Okay. You now made me realize that even unchecking all of the optional settings in roll-outs, it will not be the same as bot auto-playing. We both must have come up with the same 0.36 ppg by coincidence. Regardless, I believe that it's inaccurate in either case anyway. Try this manual sequence, and evaluate the next move. This gets you back to the start position. But doubles would be allowed, so the bot evaluation should not be the same as that of the opening roll. 64: 13/7 24/20 33: 24/18* 13/7 21: bar/24 20/18* 51: bar/24 18/13 32: 18/13 Ah, it's getting interesting. GnuBG doesn't know the difference between the initial and recycled "starting position". XG does but wrongly, backwards. Snowie did but adjusted it by the wrong amount. I first wrote about this problem with XG in response to a related discussion in RGB, on Dec 26, 2022. See: https://groups.google.com/g/rec.games.backgammon/c/RgcdohfwyYs/m/NtnrIaUTCAAJ Then I checked the same problem in Gnubg and I posted about it on the same day. See: https://groups.google.com/g/rec.games.backgammon/c/QU1jM9aatO0/m/EBkivQ3vBQAJ The next day after that, I checked it in Snowie and I posted a comprehensive recap about the subject. See: This is a very important issue regarding the ages-old fallacy that the equity at the start of the game, i.e. the equity of the starting position, is zero. It's not! Anyone who really cares about the accuracy of bots' equity calculations should make time to read the above three threads or at least the first article in each, because miscalculating the equity of the opening moves ripple through the following moves, causing them all to be wrong even if slightly but also compoundingly depending on which bot does what how... Incidentally, in the third thread above, you'll find a link to one of my only two posts that ever appeared on BKGM, this one being about the shortest possible moves to recycle to the starting position. See: https://www.bkgm.com/rgb/rgb.cgi?view+68 My 4-rolls solution allowed doubles and I had explained later in RBG that it would be legal not only if initial doubles are allowed in some variants but also when we recycled to the starting position more than once. See: https://groups.google.com/g/rec.games.backgammon/c/8vUhA8fpEN0/m/nXMtpFOrmFoJ So, yes, I was the one who not only didn't assume you could recycle only once but also tested the three bots to see if/how they would treat the starting position if it occurred multiple times. I guess I just like to not stop until I get to the bottom of things... MK
Re: Interesting question/experiment about value of cube ownership
"Is making the bot auto-play the
same as doing rollouts?"
It sounds like you are asking what a rollout is? There are plenty of resources
on the net.
https://www.gnu.org/software/gnubg/manual/html_node/Introduction-to-rollouts.html
https://www.bkgm.com/openings/rollouts.html
Your auto-play script sounds very similar but I don't know exactly what it does.
The main difference would be that you can make your scripts double using your
own algorithm. Or indeed, veer from the bot's best chequer play.
Minor differences might be the play settings for search depth and pruning.
Try this manual sequence, and evaluate the next move. This gets you back to the
start position. But doubles would be allowed, so the bot evaluation should not
be the same as that of the opening roll.
64: 13/7 24/20
33: 24/18* 13/7
21: bar/24 20/18*
51: bar/24 18/13
32: 18/13
From: MK
Sent: Friday, March 1, 2024 10:46:29 PM
To: Ian Shaw ; bug-gnubg@gnu.org
Cc: Philippe Michel
Subject: Re: Interesting question/experiment about value of cube ownership
On 3/1/2024 6:22 AM, Ian Shaw wrote:
> 27000 trials at 0-ply and 1-ply. 135000 trials at 2-ply.
> There’s almost no difference in value between the rollout
> that took 8 minutes and the one that tool 23 hours, which
> speaks to the strength of the initial evaluation.
This is good to know. Can you post the position ID so that
there is no misassumptions.
> The rollout suggests that the value of cube ownership in
> the initial position is worth about 0.36 points.
This is very interesting. Is making the bot auto-play the
same as doing rollouts? During the past weeks, I have done
12 different experiments with 20,000 games in each. I'm now
putting it all on a neatly organized web page which I will
share here soon.
Six of my experiments were about the value of winning the
opening roll and/or owning the cube from the start (i.e.
before the first move for the mutant but before the second
move for the bot since it always auto-plays and there is no
way to intercept before its first move).
Very interestingly I also came up with 0.36 ppg and 0.28 ppc
("points per cube" decision).
I collected and tabulated quite a lot of various stats which
will be on my web page, along with the actual scripts I ran,
saved games, log files, etc. so that you all can derive your
own conclusions with or without replicating my experiments,
with the important ones being about "mutant cube strategies".
> One thing to notice is that the rollout has the on-roll
> player winning about 1% less than the evaluations posted
> by MK. I think this is due to the evaluation assuming that
> initial doubles may be played, whereas I set the rollout
> to play as the initial position.
I'm not sure what you are referring to here. What I had posted
was the GnuBG's 2-ply evaluation of the opening position (i.e.
without initial doubles). So, that 1% must be the difference
between that and your rollouts?? (as well as my experiments?)
> I haven’t found a way toa ask gnubg for an evaluation for the
> initial roll. Is there one?
> You could get a 1-ply evaluation by combining all 15 0-ply
> evaluations of the first roll, and so forth.
I don't understand these. Hopefully others will pitch in their
comments in response...
MK
> *From:*bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org
> *On Behalf Of *Ian Shaw
> via Bug reports for and
> general discussion about GNU Backgammon.
> *Sent:* Thursday, February 8, 2024 11:39 AM
> *To:* playbg-...@yahoo.com; bug-gnubg@gnu.org
> *Cc:* Philippe Michel
> *Subject:* RE: Interesting question/experiment about value of cube ownership
>
> It just so happens that I rolled out the opening position a few days ago for
> another reason. This
> was at 7-away 7-away rather than $ play, because I was interested in match
> play. I doubt that makes
> a huge difference.
>
> This was using gnubg-1_08_dev-20240103-setup.exe not the newest
> gnubg-1_08_001-20240204-setup.exe
> that Philippe released recently.
>
> Philippe, am I correct in thinking that the cube handling on these two
> versions is the same? Your
> announcement emails both include the same comment.
>
> “Improvement to cube decisions at 0- and 1-ply and weaker levels. Cube error
> rates are approximately
> halved and the repartition of errors (premature doubles vs. missed doubles
> vs. take or pass errors)
> is now similar to higher plies instead of being mostly premature doubles.”
>
> The rollout results indicate about 1% fewer wins for the roller than the
> evaluations.
>
> 4HPwATDgc/ABMA:cAngAAAE
>
> Cube analysis
>
> Rollout cubeless equity +0.0408 (Money: +0.0396)
>
> Cubeful equities:
>
> 1. No double +0.0655
>
> 2. Double, pass+1. (+0.9345)
>
> 3. Dou
Re: Interesting question/experiment about value of cube ownership
On 3/1/2024 6:22 AM, Ian Shaw wrote:
27000 trials at 0-ply and 1-ply. 135000 trials at 2-ply.
There’s almost no difference in value between the rollout
that took 8 minutes and the one that tool 23 hours, which
speaks to the strength of the initial evaluation.
This is good to know. Can you post the position ID so that
there is no misassumptions.
The rollout suggests that the value of cube ownership in
the initial position is worth about 0.36 points.
This is very interesting. Is making the bot auto-play the
same as doing rollouts? During the past weeks, I have done
12 different experiments with 20,000 games in each. I'm now
putting it all on a neatly organized web page which I will
share here soon.
Six of my experiments were about the value of winning the
opening roll and/or owning the cube from the start (i.e.
before the first move for the mutant but before the second
move for the bot since it always auto-plays and there is no
way to intercept before its first move).
Very interestingly I also came up with 0.36 ppg and 0.28 ppc
("points per cube" decision).
I collected and tabulated quite a lot of various stats which
will be on my web page, along with the actual scripts I ran,
saved games, log files, etc. so that you all can derive your
own conclusions with or without replicating my experiments,
with the important ones being about "mutant cube strategies".
One thing to notice is that the rollout has the on-roll
player winning about 1% less than the evaluations posted
by MK. I think this is due to the evaluation assuming that
initial doubles may be played, whereas I set the rollout
to play as the initial position.
I'm not sure what you are referring to here. What I had posted
was the GnuBG's 2-ply evaluation of the opening position (i.e.
without initial doubles). So, that 1% must be the difference
between that and your rollouts?? (as well as my experiments?)
I haven’t found a way toa ask gnubg for an evaluation for the
initial roll. Is there one?
You could get a 1-ply evaluation by combining all 15 0-ply
evaluations of the first roll, and so forth.
I don't understand these. Hopefully others will pitch in their
comments in response...
MK
*From:*bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org
*On Behalf Of *Ian Shaw via Bug reports for and
general discussion about GNU Backgammon.
*Sent:* Thursday, February 8, 2024 11:39 AM
*To:* playbg-...@yahoo.com; bug-gnubg@gnu.org
*Cc:* Philippe Michel
*Subject:* RE: Interesting question/experiment about value of cube ownership
It just so happens that I rolled out the opening position a few days ago for another reason. This
was at 7-away 7-away rather than $ play, because I was interested in match play. I doubt that makes
a huge difference.
This was using gnubg-1_08_dev-20240103-setup.exe not the newest gnubg-1_08_001-20240204-setup.exe
that Philippe released recently.
Philippe, am I correct in thinking that the cube handling on these two versions is the same? Your
announcement emails both include the same comment.
“Improvement to cube decisions at 0- and 1-ply and weaker levels. Cube error rates are approximately
halved and the repartition of errors (premature doubles vs. missed doubles vs. take or pass errors)
is now similar to higher plies instead of being mostly premature doubles.”
The rollout results indicate about 1% fewer wins for the roller than the
evaluations.
4HPwATDgc/ABMA:cAngAAAE
Cube analysis
Rollout cubeless equity +0.0408 (Money: +0.0396)
Cubeful equities:
1. No double +0.0655
2. Double, pass +1. (+0.9345)
3. Double, take -0.2999 (-0.3654)
Proper cube action: No double, take (28.1%)
Rollout details:
Centered 1-cube:
0.5129 0.1480 0.0083 - 0.4871 0.1351 0.0073 CL +0.0408 CF +0.0655
[0.0001 0.0002 0.0001 - 0.0001 0.0001 0.0001 CL 0.0003 CF 0.0008]
gnubg owns 2-cube:
0.5156 0.1522 0.0091 - 0.4844 0.1375 0.0150 CL +0.1216 CF -0.2999
[0.0001 0.0002 0.0001 - 0.0001 0.0002 0.0002 CL 0.0007 CF 0.0012]
Full cubeful rollout with variance reduction
186624 games, rollout as initial position, Mersenne Twister dice generator with
seed 823069761
Play: world class 2-ply cubeful prune [world class]
keep the first 0 0-ply moves and up to 8 more moves within equity 0.16
Skip pruning for 1-ply moves.
Cube: 2-ply cubeful prune [world class]
Cheers,
Ian
-Original Message-
From: bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org
<mailto:bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org>mailto:bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org>> On Behalf Of MK
Sent: Thursday, February 8, 2024 2:23 AM
To: bug-gnubg@gnu.org <mailto:bug-gnubg@gnu.org>
Subject: Interesting question/experiment about value of cube ownership
I'm chugging along with my mutant cube skill experiments as I can spare time, saving all games,
which I will share on my web site, when I'm done, along with my scripts.
While doing the double at
RE: Interesting question/experiment about value of cube ownership
I've rolled at the opening position again, at money play. 27000 trials at 0-ply and 1-ply. 135000 trials at 2-ply. There's almost no difference in value between the rollout that took 8 minutes and the one that tool 23 hours, which speaks to the strength of the initial evaluation. The rollout suggests that the value of cube ownership in the initial position is worth about 0.36 points. One thing to notice is that the rollout has the on-roll player winning about 1% less than the evaluations posted by MK. I think this is due to the evaluation assuming that initial doubles may be played, whereas I set the rollout to play as the initial position. Ply Cube Pwin Pwin2 Pwin3 Plose Plose2 Plose3 Ecl End Edt Action 0 1Cen 0.5135 0.1425 0.0065 0.4865 0.1310 0.0055 +0.0395 +0.0599 8 m 2Opp 0.5141 0.1428 0.0064 0.4859 0.1317 0.0056 +0.0804 -0.2941 NB (27.4%) 1 1Cen 0.5136 0.1472 0.0071 0.4864 0.1352 0.0059 +0.0405 +0.0594 38 m 2Opp 0.5136 0.1495 0.0074 0.4864 0.1350 0.0060 +0.0867 -0.2977 NB (27.5%) 2 1Cen 0.5130 0.1461 0.0069 0.4870 0.1336 0.0058 +0.0395 +0.0580 23 h 2Opp 0.5147 0.1468 0.0068 0.4853 0.1332 0.0059 +0.0881 -0.3002 NB (27.6%) I haven't found a way toa ask gnubg for an evaluation for the initial roll. Is there one? You could get a 1-ply evaluation by combining all 15 0-ply evaluations of the first roll, and so forth. Cheers, Ian From: bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org On Behalf Of Ian Shaw via Bug reports for and general discussion about GNU Backgammon. Sent: Thursday, February 8, 2024 11:39 AM To: playbg-...@yahoo.com; bug-gnubg@gnu.org Cc: Philippe Michel Subject: RE: Interesting question/experiment about value of cube ownership It just so happens that I rolled out the opening position a few days ago for another reason. This was at 7-away 7-away rather than $ play, because I was interested in match play. I doubt that makes a huge difference. This was using gnubg-1_08_dev-20240103-setup.exe not the newest gnubg-1_08_001-20240204-setup.exe that Philippe released recently. Philippe, am I correct in thinking that the cube handling on these two versions is the same? Your announcement emails both include the same comment. "Improvement to cube decisions at 0- and 1-ply and weaker levels. Cube error rates are approximately halved and the repartition of errors (premature doubles vs. missed doubles vs. take or pass errors) is now similar to higher plies instead of being mostly premature doubles." The rollout results indicate about 1% fewer wins for the roller than the evaluations. 4HPwATDgc/ABMA:cAngAAAE Cube analysis Rollout cubeless equity +0.0408 (Money: +0.0396) Cubeful equities: 1. No double +0.0655 2. Double, pass+1. (+0.9345) 3. Double, take-0.2999 (-0.3654) Proper cube action: No double, take (28.1%) Rollout details: Centered 1-cube: 0.5129 0.1480 0.0083 - 0.4871 0.1351 0.0073 CL +0.0408 CF +0.0655 [0.0001 0.0002 0.0001 - 0.0001 0.0001 0.0001 CL 0.0003 CF 0.0008] gnubg owns 2-cube: 0.5156 0.1522 0.0091 - 0.4844 0.1375 0.0150 CL +0.1216 CF -0.2999 [0.0001 0.0002 0.0001 - 0.0001 0.0002 0.0002 CL 0.0007 CF 0.0012] Full cubeful rollout with variance reduction 186624 games, rollout as initial position, Mersenne Twister dice generator with seed 823069761 Play: world class 2-ply cubeful prune [world class] keep the first 0 0-ply moves and up to 8 more moves within equity 0.16 Skip pruning for 1-ply moves. Cube: 2-ply cubeful prune [world class] Cheers, Ian -Original Message- From: bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org<mailto:bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org> mailto:bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org>> On Behalf Of MK Sent: Thursday, February 8, 2024 2:23 AM To: bug-gnubg@gnu.org<mailto:bug-gnubg@gnu.org> Subject: Interesting question/experiment about value of cube ownership I'm chugging along with my mutant cube skill experiments as I can spare time, saving all games, which I will share on my web site, when I'm done, along with my scripts. While doing the double at > 50% experiment, I remembered an old question I had asked in RGB about a year ago: What if the winner of the opening roll is allowed pre-double? See thread: https://groups.google.com/g/rec.games.backgammon/c/BVEnaqGM6dg/m/2c685q4DAAAJ When you evaluate the opening position in GnuBG, this is what you get: = Position ID: 4HPwATDgc/ABMA Match ID:cAkA Evaluator:Contact Win W(g)W(bg) L(g)L(bg) EquityCubeful static: 52.115.4 0.813.0 0.8 +0.067+0.084 1 ply: 52.714.8 0.912.9 0.5 +0.076+0.098 2 ply: 52.514.9 0.712.5
Re: Interesting question/experiment about value of cube ownership
On 2/11/2024 6:01 AM, EDWARD GOLDBERG wrote: Can I be removed from this email list please? https://lists.gnu.org/mailman/options/bug-gnubg/
Re: Interesting question/experiment about value of cube ownership
Can I be removed from this email list please?
> On Feb 10, 2024, at 9:59 PM, MK wrote:
>
> Hi Ian,
>
> Thanks for the additional info. Unfortunately it didn't help
> me understand anything better or answer my own question. I'm
> still trying and hope that you or others will continue this
> subject to help me with it, which will benefit all in the end.
>
> For the cubeless equity of the opening position, I'm going by
> the rollout results, (which had taken 7 months to do), from:
>
> https://bkgm.com/openings/rollouts.html
>
> In the summary section towards the end, it says:
>
> "Your average equity if you win the opening roll is +.0393."
>
> So, if I run 10,000 cubeless games with "X" always winning the
> opening roll, "X" will win 393 points, i.e. 3.93%, more than "O"?
>
> =
> When the mutant ("X") is on roll (i.e. won the opening roll),
>
> GNUbg ID: 4HPwATDgc/ABMA:cAkA evaluate says:
>
>Win W(g)W(bg) L(g)L(bg) EquityCubeful
> 2 ply: 52.514.9 0.712.5 0.5 +0.076+0.099
>
> 2-ply cubeless equity +0.076
> 52.5 14.9 0.7 - 47.5 12.5 0.5
> Cubeful equities:
> 1. No double +0.099
> 2. Double, pass+1.000 (+0.901)
> 3. Double, take-0.171 (-0.270)
>
> How do I relate any of these numbers to the +0.0393 above? Why is
> the cubeless equity +0.076?
>
> I suppose the cubeful equity +0.099 is somehow extrapolated using
> some formulas and I should accept it as just that?
>
> =
>
> When I set cube to 2 owned by the bot ("O"), with "X" on roll,
>
> GNUbg ID: 4HPwATDgc/ABMA:QQkA evaluate says:
>
>Win W(g)W(bg) L(g)L(bg) EquityCubeful
> 2 ply: 52.514.9 0.712.5 0.5 +0.076-0.086
>
> Cubeless equity is the same. Shouldn't the cubeful equity be
> +0.076 - 0.171 = -0.095? Why is it -0.086? Which one is correct?
>
> =
>
> If I set the cube to 2 owned by mutant ("X") who is also on roll,
>
> GNUbg ID: 4HPwATDgc/ABMA:UQkA evaluate says:
>
>Win W(g)W(bg) L(g)L(bg) EquityCubeful
> 2 ply: 52.514.9 0.712.5 0.5 +0.076+0.255
>
> 2-ply cubeless equity +0.076
> 52.5 14.9 0.7 - 47.5 12.5 0.5
> Cubeful equities:
> 1. No double +0.255
> 2. Double, pass+1.000 (+0.745)
> 3. Double, take-0.171 (-0.426)
>
> Cubeless equity is still the same. Should I try to understand why
> the D/T is the same as centered cube but now the cubeful equity is
> +0.255? Is it +0.076 + 0.171 = +0.247 close enough or what is it??
>
> =
>
> So, again, what I would like to know is if I run 10,000 games from
> each of the above three positions, what results should I expect?
>
> In other words, which one of these many different equity numbers
> (with no obvious correspondences for me) do I use to multiply by
> 10,000 to predict by how much the mutant will win or lose?
>
> MK
>
Re: Interesting question/experiment about value of cube ownership
Hi Ian,
Thanks for the additional info. Unfortunately it didn't help
me understand anything better or answer my own question. I'm
still trying and hope that you or others will continue this
subject to help me with it, which will benefit all in the end.
For the cubeless equity of the opening position, I'm going by
the rollout results, (which had taken 7 months to do), from:
https://bkgm.com/openings/rollouts.html
In the summary section towards the end, it says:
"Your average equity if you win the opening roll is +.0393."
So, if I run 10,000 cubeless games with "X" always winning the
opening roll, "X" will win 393 points, i.e. 3.93%, more than "O"?
=
When the mutant ("X") is on roll (i.e. won the opening roll),
GNUbg ID: 4HPwATDgc/ABMA:cAkA evaluate says:
Win W(g)W(bg) L(g)L(bg) EquityCubeful
2 ply: 52.514.9 0.712.5 0.5 +0.076+0.099
2-ply cubeless equity +0.076
52.5 14.9 0.7 - 47.5 12.5 0.5
Cubeful equities:
1. No double +0.099
2. Double, pass+1.000 (+0.901)
3. Double, take-0.171 (-0.270)
How do I relate any of these numbers to the +0.0393 above? Why is
the cubeless equity +0.076?
I suppose the cubeful equity +0.099 is somehow extrapolated using
some formulas and I should accept it as just that?
=
When I set cube to 2 owned by the bot ("O"), with "X" on roll,
GNUbg ID: 4HPwATDgc/ABMA:QQkA evaluate says:
Win W(g)W(bg) L(g)L(bg) EquityCubeful
2 ply: 52.514.9 0.712.5 0.5 +0.076-0.086
Cubeless equity is the same. Shouldn't the cubeful equity be
+0.076 - 0.171 = -0.095? Why is it -0.086? Which one is correct?
=
If I set the cube to 2 owned by mutant ("X") who is also on roll,
GNUbg ID: 4HPwATDgc/ABMA:UQkA evaluate says:
Win W(g)W(bg) L(g)L(bg) EquityCubeful
2 ply: 52.514.9 0.712.5 0.5 +0.076+0.255
2-ply cubeless equity +0.076
52.5 14.9 0.7 - 47.5 12.5 0.5
Cubeful equities:
1. No double +0.255
2. Double, pass+1.000 (+0.745)
3. Double, take-0.171 (-0.426)
Cubeless equity is still the same. Should I try to understand why
the D/T is the same as centered cube but now the cubeful equity is
+0.255? Is it +0.076 + 0.171 = +0.247 close enough or what is it??
=
So, again, what I would like to know is if I run 10,000 games from
each of the above three positions, what results should I expect?
In other words, which one of these many different equity numbers
(with no obvious correspondences for me) do I use to multiply by
10,000 to predict by how much the mutant will win or lose?
MK
RE: Interesting question/experiment about value of cube ownership
It just so happens that I rolled out the opening position a few days ago for another reason. This was at 7-away 7-away rather than $ play, because I was interested in match play. I doubt that makes a huge difference. This was using gnubg-1_08_dev-20240103-setup.exe not the newest gnubg-1_08_001-20240204-setup.exe that Philippe released recently. Philippe, am I correct in thinking that the cube handling on these two versions is the same? Your announcement emails both include the same comment. “Improvement to cube decisions at 0- and 1-ply and weaker levels. Cube error rates are approximately halved and the repartition of errors (premature doubles vs. missed doubles vs. take or pass errors) is now similar to higher plies instead of being mostly premature doubles.” The rollout results indicate about 1% fewer wins for the roller than the evaluations. 4HPwATDgc/ABMA:cAngAAAE Cube analysis Rollout cubeless equity +0.0408 (Money: +0.0396) Cubeful equities: 1. No double +0.0655 2. Double, pass+1. (+0.9345) 3. Double, take-0.2999 (-0.3654) Proper cube action: No double, take (28.1%) Rollout details: Centered 1-cube: 0.5129 0.1480 0.0083 - 0.4871 0.1351 0.0073 CL +0.0408 CF +0.0655 [0.0001 0.0002 0.0001 - 0.0001 0.0001 0.0001 CL 0.0003 CF 0.0008] gnubg owns 2-cube: 0.5156 0.1522 0.0091 - 0.4844 0.1375 0.0150 CL +0.1216 CF -0.2999 [0.0001 0.0002 0.0001 - 0.0001 0.0002 0.0002 CL 0.0007 CF 0.0012] Full cubeful rollout with variance reduction 186624 games, rollout as initial position, Mersenne Twister dice generator with seed 823069761 Play: world class 2-ply cubeful prune [world class] keep the first 0 0-ply moves and up to 8 more moves within equity 0.16 Skip pruning for 1-ply moves. Cube: 2-ply cubeful prune [world class] Cheers, Ian -Original Message- From: bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org On Behalf Of MK Sent: Thursday, February 8, 2024 2:23 AM To: bug-gnubg@gnu.org Subject: Interesting question/experiment about value of cube ownership I'm chugging along with my mutant cube skill experiments as I can spare time, saving all games, which I will share on my web site, when I'm done, along with my scripts. While doing the double at > 50% experiment, I remembered an old question I had asked in RGB about a year ago: What if the winner of the opening roll is allowed pre-double? See thread: https://groups.google.com/g/rec.games.backgammon/c/BVEnaqGM6dg/m/2c685q4DAAAJ When you evaluate the opening position in GnuBG, this is what you get: = Position ID: 4HPwATDgc/ABMA Match ID:cAkA Evaluator:Contact Win W(g)W(bg) L(g)L(bg) EquityCubeful static: 52.115.4 0.813.0 0.8 +0.067+0.084 1 ply: 52.714.8 0.912.9 0.5 +0.076+0.098 2 ply: 52.514.9 0.712.5 0.5 +0.076+0.099 Cube analysis 2-ply cubeless equity +0.076 52.5 14.9 0.7 - 47.5 12.5 0.5 Cubeful equities: 1. No double +0.099 2. Double, pass+1.000 (+0.901) 3. Double, take-0.171 (-0.270) Proper cube action: No double, take (23.0%) = I have created a Python script to intervene if the human player wins the opening roll, to set the cube at 2 owned by the bot, and then to execute "end game" command, for the bot to play for both sides at the same checker and cube skill settings. So, you know the equity gained by winning the opening roll and the equity lost by making the cube error at the same time, before the first move. Can anyone tell me what I will be expecting to see after, let's say, 10,000 games, in terms of which side will win/lose by what percentage? BTW: I already know. ;) I'm asking to see how confident are you in GnuBG's equity and/or error calculations and how competent are you to make mathematical predictions? MK
Interesting question/experiment about value of cube ownership
I'm chugging along with my mutant cube skill experiments as I can spare time, saving all games, which I will share on my web site, when I'm done, along with my scripts. While doing the double at > 50% experiment, I remembered an old question I had asked in RGB about a year ago: What if the winner of the opening roll is allowed pre-double? See thread: https://groups.google.com/g/rec.games.backgammon/c/BVEnaqGM6dg/m/2c685q4DAAAJ When you evaluate the opening position in GnuBG, this is what you get: = Position ID:4HPwATDgc/ABMA Match ID: cAkA Evaluator: Contact Win W(g)W(bg) L(g)L(bg) EquityCubeful static: 52.115.4 0.813.0 0.8 +0.067+0.084 1 ply: 52.714.8 0.912.9 0.5 +0.076+0.098 2 ply: 52.514.9 0.712.5 0.5 +0.076+0.099 Cube analysis 2-ply cubeless equity +0.076 52.5 14.9 0.7 - 47.5 12.5 0.5 Cubeful equities: 1. No double +0.099 2. Double, pass+1.000 (+0.901) 3. Double, take-0.171 (-0.270) Proper cube action: No double, take (23.0%) = I have created a Python script to intervene if the human player wins the opening roll, to set the cube at 2 owned by the bot, and then to execute "end game" command, for the bot to play for both sides at the same checker and cube skill settings. So, you know the equity gained by winning the opening roll and the equity lost by making the cube error at the same time, before the first move. Can anyone tell me what I will be expecting to see after, let's say, 10,000 games, in terms of which side will win/lose by what percentage? BTW: I already know. ;) I'm asking to see how confident are you in GnuBG's equity and/or error calculations and how competent are you to make mathematical predictions? MK
RE: No bugs, just a question
Hi Tim, What an awesome explanation. Thanks a lot. -- Ian -Original Message- From: Bug-gnubg On Behalf Of Timothy Y. Chow Sent: 06 July 2022 14:59 To: bug-gnubg@gnu.org Subject: Re: No bugs, just a question There is a subtle point about luck that is not well understood even by some professional mathematicians. In a series of games (or matches, but for simplicity let me focus on games), one must distinguish between 1. counting the number of games in which I was luckier, and 2. determining who was luckier overall on a roll-by-roll basis. The distinction is subtle, but very important, so let me belabor it a bit. For #2, what we do is to examine each roll individually, note how lucky it was, and add up the luck over all rolls in all games. For #1, what we do is to examine each game in turn and, *restricting our attention to only the rolls in that game*, determine who had more total luck. If I had more total luck in that game, then I declare that game to be a "game in which I was luckier"; otherwise, it's a game in which I was unluckier. Let me emphasize that in #1, we ignore *how much luckier* I was in that game. I could be massively luckier, or just barely luckier, but as long as I'm luckier, I declare that game to be one in which "I was luckier." Similarly, I ignore whether I was massively unluckier or just barely unluckier when declaring a game to be one in which I was unluckier. Now here is the crucial observation. It is entirely possible, and in fact common, for two players to be equally lucky in sense #2, and yet for there to be a highly lopsided count in sense #1. That is, I might be unluckier in many more games, and yet equally lucky on a roll-by-roll basis. This sounds like a contradiction, but it is not; for example, maybe I am unluckier in 90% of the games, but in each of those games, my net luck is -0.1 per game, whereas in the 10% of the games in which I am luckier, my net luck is +0.9 per game. Then I am much unluckier in sense #1 but equally lucky in sense #2. "Okay," you might grudgingly concede, "that's *possible*, but surely that's highly *unlikely*." If backgammon were purely a game of luck, then you're right; it would be highly unlikely. However, this is where skill comes in: The more skillful player will (almost always) be luckier in sense #1. This fact is highly counterintuitive to most people. After all, the more skillful player is just as likely as the less skillful player to be luckier in sense #2. There is no correlation between skill and "luck #2," so how could there be a correlation between skill and "luck #1"? A full mathematical proof is complicated, but here is the main idea: If I'm more skillful, then I need less luck to win the game. In most games, I'll get the small margin of luck that I need to win the game, and only rarely will I suffer the long string of bad luck that will cause me to lose. Here's a much simpler game to illustrate the idea: "Unfair Football." There's a ball on a field and it moves left and right randomly until it crosses one of the two goal lines. The ball's random motion is symmetric; it is just as likely to move left as it is to move right. But the game is unfair *because the ball doesn't start in the middle.* The ball starts closer to one of the goal posts. Obviously, the team with the unfair advantage will win more often, even though the motion of the ball is "fair" in some sense. Although the analogy with backgammon is not perfect, it is pretty good; having more skill is analogous to having an unfair advantage in Unfair Football. In both games, if you examine luck on a move-by-move basis, it is unbiased; nevertheless, one side consistently wins more often. In particular, in Unfair Football, the luckier player (in sense #1) *always* wins. In backgammon, the luckier player (in sense #1) does not always win, but we expect that the luckier player (in sense #1) will almost always win, for basically the same reasons. This doesn't mean that skill is irrelevant in backgammon, any more than the bias in Unfair Football is irrelevant. The skillful player will win more often, *because greater skill causes greater luck in sense #1* (even though it cannot affect luck in sense #2). The beauty of backgammon as a gambling game lies precisely in this seeming paradox. The "mark" will notice that the "shark" only wins when the shark is luckier, and reasons that luck must even out in the end. So the mark keeps playing and keeps losing, because the mark does not understand the difference between luck #1 and luck #2. Tim
Re: No bugs, just a question
There is a subtle point about luck that is not well understood even by some professional mathematicians. In a series of games (or matches, but for simplicity let me focus on games), one must distinguish between 1. counting the number of games in which I was luckier, and 2. determining who was luckier overall on a roll-by-roll basis. The distinction is subtle, but very important, so let me belabor it a bit. For #2, what we do is to examine each roll individually, note how lucky it was, and add up the luck over all rolls in all games. For #1, what we do is to examine each game in turn and, *restricting our attention to only the rolls in that game*, determine who had more total luck. If I had more total luck in that game, then I declare that game to be a "game in which I was luckier"; otherwise, it's a game in which I was unluckier. Let me emphasize that in #1, we ignore *how much luckier* I was in that game. I could be massively luckier, or just barely luckier, but as long as I'm luckier, I declare that game to be one in which "I was luckier." Similarly, I ignore whether I was massively unluckier or just barely unluckier when declaring a game to be one in which I was unluckier. Now here is the crucial observation. It is entirely possible, and in fact common, for two players to be equally lucky in sense #2, and yet for there to be a highly lopsided count in sense #1. That is, I might be unluckier in many more games, and yet equally lucky on a roll-by-roll basis. This sounds like a contradiction, but it is not; for example, maybe I am unluckier in 90% of the games, but in each of those games, my net luck is -0.1 per game, whereas in the 10% of the games in which I am luckier, my net luck is +0.9 per game. Then I am much unluckier in sense #1 but equally lucky in sense #2. "Okay," you might grudgingly concede, "that's *possible*, but surely that's highly *unlikely*." If backgammon were purely a game of luck, then you're right; it would be highly unlikely. However, this is where skill comes in: The more skillful player will (almost always) be luckier in sense #1. This fact is highly counterintuitive to most people. After all, the more skillful player is just as likely as the less skillful player to be luckier in sense #2. There is no correlation between skill and "luck #2," so how could there be a correlation between skill and "luck #1"? A full mathematical proof is complicated, but here is the main idea: If I'm more skillful, then I need less luck to win the game. In most games, I'll get the small margin of luck that I need to win the game, and only rarely will I suffer the long string of bad luck that will cause me to lose. Here's a much simpler game to illustrate the idea: "Unfair Football." There's a ball on a field and it moves left and right randomly until it crosses one of the two goal lines. The ball's random motion is symmetric; it is just as likely to move left as it is to move right. But the game is unfair *because the ball doesn't start in the middle.* The ball starts closer to one of the goal posts. Obviously, the team with the unfair advantage will win more often, even though the motion of the ball is "fair" in some sense. Although the analogy with backgammon is not perfect, it is pretty good; having more skill is analogous to having an unfair advantage in Unfair Football. In both games, if you examine luck on a move-by-move basis, it is unbiased; nevertheless, one side consistently wins more often. In particular, in Unfair Football, the luckier player (in sense #1) *always* wins. In backgammon, the luckier player (in sense #1) does not always win, but we expect that the luckier player (in sense #1) will almost always win, for basically the same reasons. This doesn't mean that skill is irrelevant in backgammon, any more than the bias in Unfair Football is irrelevant. The skillful player will win more often, *because greater skill causes greater luck in sense #1* (even though it cannot affect luck in sense #2). The beauty of backgammon as a gambling game lies precisely in this seeming paradox. The "mark" will notice that the "shark" only wins when the shark is luckier, and reasons that luck must even out in the end. So the mark keeps playing and keeps losing, because the mark does not understand the difference between luck #1 and luck #2. Tim
Re: No bugs, just a question
Maybe you should ask yourself this: what makes a position strong? You can argue that in such positions most rolls are "lucky", as in giving you another strong position, or most opponent rolls are "unlucky". This might go some way to explain this perceived impression. You make a bad move, your position is much the worst for it, so you allowed your opponent to "get lucky" -Joseph On Sat, 2 Jul 2022 at 15:35, Tom Moulton wrote: > There is no such logic in the code that I have ever seen > > The human mind has a great ability to find patterns in chaos. > > This topic comes up a lot with the playing bots on fibs.com > > Tom > > > On July 1, 2022 10:47:11 PM EDT, Paul Thornett > wrote: >> >> I play backgammon to a reasonable standard and have always regarded >> myself as an unlucky player, both as a real-life player and when >> playing the gnubg version. >> >> But, over several years, I have become convinced of a strong tendency >> in gnubg to punish what it may regard as a bad move with remarkable, >> even outrageous, luck. This has become so apparent to me that I can >> usually predict extraordinarily lucky throws by the computer >> immediately before they are made. This also, on occasion, works in >> reverse. Occasionally the computer makes what I would regard as a bad >> move. This has then resulted in a series of ridiculously lucky throws >> by myself. >> >> I can offer no evidence for this wild assertion, it's purely anecdotal. >> -- >> Regards, >> Paul Thornett >> >> >> Regards, >> >> Paul Thornett >> >> >> On Tue, 28 Jun 2022 at 03:32, Ian Shaw wrote: >> >>> >>> Hi Teddy, >>> >>> >>> >>> The luckier player wins a lot of the time. However, I’ve definitely seen >>> many games where the luckier player had played badly enough to still lose. >>> It’s often me! >>> >>> >>> >>> Perhaps you’re sample size is not large enough. That’s all I can suggest. >>> >>> >>> >>> (I’m not sure what happens if you play on any setting lower than ‘expert’). >>> >>> >>> >>> Best regards, >>> >>> Ian Shaw >>> >>> >>> >>> From: Bug-gnubg On >>> Behalf Of hereodt Z >>> Sent: 25 June 2022 20:04 >>> To: bug-gnubg@gnu.org >>> Subject: No bugs, just a question >>> >>> >>> >>> Dear all who created GNUBg, >>> >>> >>> >>> >>> >>> Thank you for your wonderful, GREAT software. >>> >>> >>> >>> It provided me with countless hours of fun and relaxation.Maybe a little >>> TOO much, but that's my problem ;). >>> >>> >>> >>> >>> >>> >>> >>> How come the winner, be it me or the computer, is always the luckiest >>> player? >>> >>> >>> >>> I thought backgammon was a game of skill. 'Course, luck plays a role, but >>> the outcome of the game to be SOLELY based on LUCK?! C'mon! How is it >>> possible? >>> >>> >>> >>> Let's say I am not skilled and indeed, I can win only if I get lucky . >>> >>> >>> >>> But the computer is World Class, after all. How come IT never wins when it >>> is less lucky than me? >>> >>> >>> >>> >>> >>> Thank you and Best regards, >>> >>> Teddy >>> >>> >>> >>> >>> >>> >>> >> -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. >
Re: No bugs, just a question
There is no such logic in the code that I have ever seen The human mind has a great ability to find patterns in chaos. This topic comes up a lot with the playing bots on fibs.com Tom On July 1, 2022 10:47:11 PM EDT, Paul Thornett wrote: >I play backgammon to a reasonable standard and have always regarded >myself as an unlucky player, both as a real-life player and when >playing the gnubg version. > >But, over several years, I have become convinced of a strong tendency >in gnubg to punish what it may regard as a bad move with remarkable, >even outrageous, luck. This has become so apparent to me that I can >usually predict extraordinarily lucky throws by the computer >immediately before they are made. This also, on occasion, works in >reverse. Occasionally the computer makes what I would regard as a bad >move. This has then resulted in a series of ridiculously lucky throws >by myself. > >I can offer no evidence for this wild assertion, it's purely anecdotal. > >- >Regards, > Paul Thornett > > >Regards, > >Paul Thornett > > >On Tue, 28 Jun 2022 at 03:32, Ian Shaw wrote: >> >> Hi Teddy, >> >> >> >> The luckier player wins a lot of the time. However, I’ve definitely seen >> many games where the luckier player had played badly enough to still lose. >> It’s often me! >> >> >> >> Perhaps you’re sample size is not large enough. That’s all I can suggest. >> >> >> >> (I’m not sure what happens if you play on any setting lower than ‘expert’). >> >> >> >> Best regards, >> >> Ian Shaw >> >> >> >> From: Bug-gnubg On >> Behalf Of hereodt Z >> Sent: 25 June 2022 20:04 >> To: bug-gnubg@gnu.org >> Subject: No bugs, just a question >> >> >> >> Dear all who created GNUBg, >> >> >> >> >> >> Thank you for your wonderful, GREAT software. >> >> >> >> It provided me with countless hours of fun and relaxation.Maybe a little TOO >> much, but that's my problem ;). >> >> >> >> >> >> >> >> How come the winner, be it me or the computer, is always the luckiest player? >> >> >> >> I thought backgammon was a game of skill. 'Course, luck plays a role, but >> the outcome of the game to be SOLELY based on LUCK?! C'mon! How is it >> possible? >> >> >> >> Let's say I am not skilled and indeed, I can win only if I get lucky . >> >> >> >> But the computer is World Class, after all. How come IT never wins when it >> is less lucky than me? >> >> >> >> >> >> Thank you and Best regards, >> >> Teddy >> >> >> >> >> >> > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: No bugs, just a question
I play backgammon to a reasonable standard and have always regarded myself as an unlucky player, both as a real-life player and when playing the gnubg version. But, over several years, I have become convinced of a strong tendency in gnubg to punish what it may regard as a bad move with remarkable, even outrageous, luck. This has become so apparent to me that I can usually predict extraordinarily lucky throws by the computer immediately before they are made. This also, on occasion, works in reverse. Occasionally the computer makes what I would regard as a bad move. This has then resulted in a series of ridiculously lucky throws by myself. I can offer no evidence for this wild assertion, it's purely anecdotal. - Regards, Paul Thornett Regards, Paul Thornett On Tue, 28 Jun 2022 at 03:32, Ian Shaw wrote: > > Hi Teddy, > > > > The luckier player wins a lot of the time. However, I’ve definitely seen many > games where the luckier player had played badly enough to still lose. It’s > often me! > > > > Perhaps you’re sample size is not large enough. That’s all I can suggest. > > > > (I’m not sure what happens if you play on any setting lower than ‘expert’). > > > > Best regards, > > Ian Shaw > > > > From: Bug-gnubg On > Behalf Of hereodt Z > Sent: 25 June 2022 20:04 > To: bug-gnubg@gnu.org > Subject: No bugs, just a question > > > > Dear all who created GNUBg, > > > > > > Thank you for your wonderful, GREAT software. > > > > It provided me with countless hours of fun and relaxation.Maybe a little TOO > much, but that's my problem ;). > > > > > > > > How come the winner, be it me or the computer, is always the luckiest player? > > > > I thought backgammon was a game of skill. 'Course, luck plays a role, but the > outcome of the game to be SOLELY based on LUCK?! C'mon! How is it possible? > > > > Let's say I am not skilled and indeed, I can win only if I get lucky . > > > > But the computer is World Class, after all. How come IT never wins when it is > less lucky than me? > > > > > > Thank you and Best regards, > > Teddy > > > > > >
Fwd: No bugs, just a question
Hi Ian, The luckier player wins a lot of the time. However, I’ve definitely seen many games where the luckier player had played badly enough to still lose. It’s often me! Lol. With GNUBg or human partner? And at what rate? That's what's bugging me. It happens way too rarely in my games, I think Perhaps you’re sample size is not large enough. That’s all I can suggest. No worries about that, I studied engineering too, IT even ;). Sample size is at least a few hundred matches, I might have reached the thousand mark even. An in this sample I have just one vague memory of one match where the luckier player (deemed so by GNUBg, 'course) lost. (I’m not sure what happens if you play on any setting lower than ‘expert’). I set the computer to "World Class". My computer is too slow for higher levels. But I played a couple of times at the next one to see what happens and the computer smashed me to pieces ha ha! Ian, thank you for trying to answer my question I just noticed that on a pretty large batch of matches, the winner is the less lucky player in, let's say, 2 out of 1000, tops. And that seems not normal. I realize that I asked this question without providing the actual data - I didn't save the games after I looked at the analysis. So you cannot possibly give me a clear answer. Let's try a different way According to your experience as both programmer and player, what is a usual percentage of the less lucky winning? If I were to save every game from now on, how many matches (minimum) would you need for it to be statistically sound? Dear Jon, Your first two remarks are too technical for me :) "I’m not sure if a more skilled player is likely to get more lucky rolls because of being in better positions - or if that gets averaged in the statistics of the luck calculation?" This last one, I believe the first part is true from simple game observation, with GNUBg or real partners - to what degree I cannot know. The second part - not sure how GNUBg evaluates luck, but I would think so. So Hey! We could say that the better player will not only win, but also be more lucky because of their skill; and on the other hand, the less skilled can win ONLY if they get lucky (dumb luck)? Interesting thought hmm? Is it true? And to what degree? We've all studied Math, we need a quantitative answer. But I think that on big enough batch the winner should be the less lucky player more often than it happens in my games. Especially when the winner is GNUBg @ World Class. Best, Teddy On Tue, Jun 28, 2022 at 2:52 PM Jon Kinsey wrote: > If 2 players are similar in skill then luck is the determining factor. > Even if the skill difference is quite big, jokers are going to give bigger > equity swings than blunders in general. > > Cube decisions in larger matches give more opportunities for (big) > mistakes and a beginner will lose almost all the time in say a match to 11 > against gnubg. > > I’m not sure if a more skilled player is likely to get more lucky rolls > because of being in better positions - or if that gets averaged in the > statistics of the luck calculation? > > Jon > > > On 26 Jun 2022, at 01:24, hereodt Z <777theod...@gmail.com> wrote: > > > > > > Dear all who created GNUBg, > > > > > > Thank you for your wonderful, GREAT software. > > > > It provided me with countless hours of fun and relaxation.Maybe a little > TOO much, but that's my problem ;). > > > > > > > > How come the winner, be it me or the computer, is always the luckiest > player? > > > > I thought backgammon was a game of skill. 'Course, luck plays a role, > but the outcome of the game to be SOLELY based on LUCK?! C'mon! How is it > possible? > > > > Let's say I am not skilled and indeed, I can win only if I get lucky . > > > > But the computer is World Class, after all. How come IT never wins when > it is less lucky than me? > > > > > > Thank you and Best regards, > > Teddy > > > > > > >
RE: No bugs, just a question
Hi Teddy, The luckier player wins a lot of the time. However, I’ve definitely seen many games where the luckier player had played badly enough to still lose. It’s often me! Perhaps you’re sample size is not large enough. That’s all I can suggest. (I’m not sure what happens if you play on any setting lower than ‘expert’). Best regards, Ian Shaw From: Bug-gnubg On Behalf Of hereodt Z Sent: 25 June 2022 20:04 To: bug-gnubg@gnu.org Subject: No bugs, just a question Dear all who created GNUBg, Thank you for your wonderful, GREAT software. It provided me with countless hours of fun and relaxation.Maybe a little TOO much, but that's my problem ;). How come the winner, be it me or the computer, is always the luckiest player? I thought backgammon was a game of skill. 'Course, luck plays a role, but the outcome of the game to be SOLELY based on LUCK?! C'mon! How is it possible? Let's say I am not skilled and indeed, I can win only if I get lucky . But the computer is World Class, after all. How come IT never wins when it is less lucky than me? Thank you and Best regards, Teddy
No bugs, just a question
Dear all who created GNUBg, Thank you for your wonderful, GREAT software. It provided me with countless hours of fun and relaxation.Maybe a little TOO much, but that's my problem ;). How come the winner, be it me or the computer, is always the luckiest player? I thought backgammon was a game of skill. 'Course, luck plays a role, but the outcome of the game to be SOLELY based on LUCK?! C'mon! How is it possible? Let's say I am not skilled and indeed, I can win only if I get lucky . But the computer is World Class, after all. How come IT never wins when it is less lucky than me? Thank you and Best regards, Teddy
Re: SQL question
I believe something like this should work https://www.sqlservertutorial.net/sql-server-basics/sql-server-update-join/ Using an inner join. Let me know if you need help. C On Thu, 14 Jan 2021 at 22.52, Philippe Michel wrote: > A few weeks ago, someone reported two bugs (#59208 and #59209) in the > way match results are stored in the database. > > I have committed a fix when for new entries, but existing ones have to > be updated directly in the database. The commands below should work for > sqlite3 but I think it should be possible to do this purely in SQL, > without intermediate files (and in a way working as is for mysql or > postgresql) > > Are there readers more familiar with SQL who could suggest better commands > ? > > .output fixgame.sql > .separator "" > select "update game set result = ", -actual_result/abs(actual_result), > "*result where game_id=", game_id, ";" from gamestat where gamestat_id = > 2*game_id; > .output > .read fixgame.sql > > .output fixsession.sql > .separator "" > select "update session set result = ", actual_result/abs(actual_result), " > where session_id=", session_id, " and result = 0;" from matchstat where > matchstat_id = 2*session_id; > .output > .read fixsession.sql > > >
SQL question
A few weeks ago, someone reported two bugs (#59208 and #59209) in the way match results are stored in the database. I have committed a fix when for new entries, but existing ones have to be updated directly in the database. The commands below should work for sqlite3 but I think it should be possible to do this purely in SQL, without intermediate files (and in a way working as is for mysql or postgresql) Are there readers more familiar with SQL who could suggest better commands ? .output fixgame.sql .separator "" select "update game set result = ", -actual_result/abs(actual_result), "*result where game_id=", game_id, ";" from gamestat where gamestat_id = 2*game_id; .output .read fixgame.sql .output fixsession.sql .separator "" select "update session set result = ", actual_result/abs(actual_result), " where session_id=", session_id, " and result = 0;" from matchstat where matchstat_id = 2*session_id; .output .read fixsession.sql
Re: Question regarding python scripting
On Wed, Dec 25, 2019 at 10:20:42PM +, Cihan Göksu wrote:
> Is there a way to communicate between the interactive pyshell (by typing
> ">") and an external python script? For example, how can I send commands
> to py Interactive shells via another python script? Is it possible to
> import e.g. gnubg.match object into another python script?
gnubg.* is not a module that you can import in another python
interpreter, it is only available to gnubg's embedded python.
The general idea is to do the reverse: run your python script inside
gnubg's python shell, where you can use anything available in your
Python path. Something like:
% ./gnubg -t
...
(No game) >
...
>>> from pytz import *
>>> timezone('Europe/Paris');
etc...
Question regarding python scripting
Dear GNUbg, First, I would like to greatly thank you for this fantastic software and express a big big applause! Here, I'm trying to check out python scripting and a little rookie :-) Is there a way to communicate between the interactive pyshell (by typing ">") and an external python script? For example, how can I send commands to py Interactive shells via another python script? Is it possible to import e.g. gnubg.match object into another python script? Thank you very much for your help in advance! Cheers, Cihan
Re: [Bug-gnubg] question about GNU Backgammon
Hi Robert, I don’t think you can automatically get a hint. At one time the analysis would run automatically in the background, which would have accomplished much the same thing. However, this feature was dropped years ago. The closest you can get is to enable Tutor mode. This will give you a message very time you make a mistake (configurable). I’ve never tried setting the threshold to 0 or a negative value. This might make the tutor pop up after every play. I hope this helps. Ian From: Bug-gnubg [mailto:bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org] On Behalf Of tili...@gmx-topmail.de Sent: 18 August 2019 18:37 To: bug-gnubg@gnu.org Subject: [Bug-gnubg] question about GNU Backgammon Hello GNU team, I have a question about how to change the settings in GNU Backgammon: Is it possible to always and automatically get a hint after one's own dice have been rolled? Best regards, Robert ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
[Bug-gnubg] question about GNU Backgammon
Hello GNU team, I have a question about how to change the settings in GNU Backgammon: Is it possible to always and automatically get a hint after one's own dice have been rolled? Best regards, Robert ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Race position theoretical question?
Yes! This position actually proves that there are positions that can both loose backgammon and still be won. X can get all his checkers off in 15 rolls (with only 6-6 rolls), while O also may use 15 rolls to get off all checkers. Based on this example, I actually guess there are several positions with this property. Josephs position also work, but it has to be the race leading player on roll. Thanks guys, -Øystein On Tue, Jan 29, 2019 at 9:46 PM Philippe Michel wrote: > On Tue, Jan 29, 2019 at 08:00:22PM +0100, Øystein Schønning-Johansen wrote: > > Hi all! > > > > Here is a theoretical question for all of you: > > > > Can a race (aka. non-contact) position, be possible to lose backgammon > with > > a good dash of unluck, and still be possible to win (with a good dash of > > luck). > > Something like this ? > > GNU Backgammon Position ID: /P8BAPD/Bw > Match ID : UQkA > +13-14-15-16-17-18--19-20-21-22-23-24-+ O: GNUbg > | | | X O | 0 points > | | | X O | > | | | X O | > | | | X O | > | | | F F | > v| |BAR| | > | | | | > | | | | > | | | | > | | | | On roll > | | | | 0 points > +12-11-10--9--8--7---6--5--4--3--2--1-+ X: You (Cube: 2) > Pip counts : O 45, X 315 > > X wins if he rolls only 6-6s and O only 2-1s, and loses a backgammon if > he is moderately unlucky. > ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Race position theoretical question?
On Tue, Jan 29, 2019 at 08:00:22PM +0100, Øystein Schønning-Johansen wrote: > Hi all! > > Here is a theoretical question for all of you: > > Can a race (aka. non-contact) position, be possible to lose backgammon with > a good dash of unluck, and still be possible to win (with a good dash of > luck). Something like this ? GNU Backgammon Position ID: /P8BAPD/Bw Match ID : UQkA +13-14-15-16-17-18--19-20-21-22-23-24-+ O: GNUbg | | | X O | 0 points | | | X O | | | | X O | | | | X O | | | | F F | v| |BAR| | | | | | | | | | | | | | | | | | On roll | | | | 0 points +12-11-10--9--8--7---6--5--4--3--2--1-+ X: You (Cube: 2) Pip counts : O 45, X 315 X wins if he rolls only 6-6s and O only 2-1s, and loses a backgammon if he is moderately unlucky. ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Race position theoretical question?
Don't know if it will work, but have you tried 8 W pieces on point 2, one black piece on 3 and the rest black pieces at B home. W can win with two doubles (2 to 6), or lose with a sequence of (2-1, 3-1,...) throws while B gets a sequence of 6-6. The odds will be low but might be > 0. -Joseph On Wed, 30 Jan 2019 at 08:02, Øystein Schønning-Johansen wrote: > > Hi all! > > Here is a theoretical question for all of you: > > Can a race (aka. non-contact) position, be possible to lose backgammon with a > good dash of unluck, and still be possible to win (with a good dash of luck). > It is assumed that the player is really trying to get of the backgammon, and > plays the best move to get off the backgammon. We do not take stupidity into > account. > > A bit more mathematically stated: > Let S be the set of all possible race positions. > Let A be the subset of S where P(lose backgammon) > 0. > Let B be the subset of S where P(win) > 0. > > Is the intersection of A and B an empty set? > > I think it is, but I cannot find a simple proof. (It probably is an obvious > proof to this, however I'm too narrow minded to see it.) > > If it is not an empty set, can you please post a position in this > intersection? > > Thanks, > -Øystein > ___ > Bug-gnubg mailing list > Bug-gnubg@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-gnubg ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
[Bug-gnubg] Race position theoretical question?
Hi all! Here is a theoretical question for all of you: Can a race (aka. non-contact) position, be possible to lose backgammon with a good dash of unluck, and still be possible to win (with a good dash of luck). It is assumed that the player is really trying to get of the backgammon, and plays the best move to get off the backgammon. We do not take stupidity into account. A bit more mathematically stated: Let S be the set of all possible race positions. Let A be the subset of S where P(lose backgammon) > 0. Let B be the subset of S where P(win) > 0. Is the intersection of A and B an empty set? I think it is, but I cannot find a simple proof. (It probably is an obvious proof to this, however I'm too narrow minded to see it.) If it is not an empty set, can you please post a position in this intersection? Thanks, -Øystein ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] question: move validation
I'm wondering in which file of the project is move validation done, more particularly if a given move is valid given a specific dice roll. This is in eval.c. This is a part of the source I don't really understand but GenerateMoves() should be a adequate starting point. If you want to look at gnubg source, the attached diagram may be useful. If you are interested in backgammon moves generation in general, not specifically how it is done in gnubg, the following file might be easier to use : http://cvs.savannah.gnu.org/viewvc/*checkout*/gnubg/gnubg-nn/gnubg/eggmoveg.c This is from the software used to train gnubg neural nets and I think its author, Joseph Heled posted in this mailing list that its move generation code is simpler and more efficient than what is used in gnubg. gnubg.pdf Description: Adobe PDF document ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
[Bug-gnubg] question: move validation
Hello there, I'm a student and I'm studying gnubg source code, I'm wondering in which file of the project is move validation done, more particularly if a given move is valid given a specific dice roll. Sorry for this question, I generally try to avoid disturbing mailing lists with non important questions. All the best, Jules ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] I have a question regarding SAVE SETTINGS
On Mon, 2015-08-31 at 22:22 +, Edward D. Collins wrote: > Greetings, > > > My gnu backgammon settings do appear to be saved during sessions. So > I don't really have a problem. However, I do have a question. The > help files talk about a SAVE SETTINGS option. The newer versions save settings automatically so this option was removed. -- Shawn K. Quinn <skqu...@rushpost.com> ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
[Bug-gnubg] Question
Hi, I'm using gnubg again since a few days ago, after several years not being able to launch it. Michael Petch helped me to install it and now it works. I dont know if he is the one to answer my next question and I dont wanna bother him again. I would like to play against my son using 2 computers. I saw that an external player can be set and I read some posts about the socket and puting gnub in listen mode. But it is not working, the screen is most of the time gray. Am I doing something wrong or what I'm trying is not possible? Thanks a lot, Carlos ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Question
That external interface is not designed for peer to peer play. Your best bet is to play on a having server such as fibs.com gridgammon.com or even yahoo.com Tom On April 23, 2015 11:53:01 AM EDT, Carlos Morales wwwcarlosmora...@gmail.com wrote: Hi, I'm using gnubg again since a few days ago, after several years not being able to launch it. Michael Petch helped me to install it and now it works. I dont know if he is the one to answer my next question and I dont wanna bother him again. I would like to play against my son using 2 computers. I saw that an external player can be set and I read some posts about the socket and puting gnub in listen mode. But it is not working, the screen is most of the time gray. Am I doing something wrong or what I'm trying is not possible? Thanks a lot, Carlos ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] GNUbg 1.03.001 source release / Python3 / Question of minimum Python support
On Sat, 9 Aug 2014, Michael Petch wrote: At present we support Python back to about 2.3 (That I have tested). It may work on 2.2 but I haven't tried. Pyhon2.2 is currently our minimum version supported. My question is whether we wish to continue using 2.2 as the minimum going forward. I am wondering if we might consider something like Python 2.7 and higher. Python2.7 can be built on older platforms that may not come pre-installed with it (much older versions of Centos and Fedora for example). CentOS 6, that can hardly be called much older and will be supported for quite a long time, is still at Python version 2.6. CentOS 5 uses it as well. That would probably be a better minimum. ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
[Bug-gnubg] GNUbg 1.03.001 source release / Python3 / Question of minimum Python support
Howdy All, I have tagged 1.03.001 in CVS (revision control). This is an official release of the sources however I won't be building binaries from it unless it is requested. This release caters to those environments/distros that may wish to start catering to Python 3. Python3 is now supported at compile time and run time. Many of the scripts that broke under Python3 have been modified to support Python2 and Python3 On OS/X 10.4 with Python 2.3.5 the 1.03.000 and earlier version can crash while closing down the embedded Python. This release fixes that issue. At present we support Python back to about 2.3 (That I have tested). It may work on 2.2 but I haven't tried. Pyhon2.2 is currently our minimum version supported. My question is whether we wish to continue using 2.2 as the minimum going forward. I am wondering if we might consider something like Python 2.7 and higher. Python2.7 can be built on older platforms that may not come pre-installed with it (much older versions of Centos and Fedora for example). Python 2.7 seems to be the minimum standard for a lot of projects these days. Python 2.7 is the last of the 2.x series. It was first released officially in 2010. To to date they are up to 2.7.8 in updates. -- Michael Petch CApp::Sysware Consulting Ltd. OpenPGP FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304 ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] gnu gammon question
Hi Nicholas, I've never heard any talk on the list about developing a card game, but It is definitely a possibility for other groups. A quick search of SourceForge turned up four Rummy projects, with one Windows project named Gin Rummy. Hope this helps. http://sourceforge.net/directory/games/card-games/?q=Gin+Rummy Myshkin LeVine Sent from my iPad On Feb 23, 2014, at 1:34 AM, Nicholas Suplizio nicholassupli...@gmail.com wrote: Hi, I was wondering if the GNUBG crew ever considered writing an evaluator/SIM for Gin Rummy. Would something like this be a possibility? If it has already been done can you point me in the right direction? Please help, thanks. Nicholas ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] gnu gammon question
That link is not working. Open Source (Windows) http://ginrummy.sourceforge.net/ And NetRummy (two players LAN / Intranet / TCP/IP) http://sourceforge.net/projects/netrummy/ N. On Tue, Feb 25, 2014 at 11:02 AM, Myshkin LeVine mysh...@verizon.netwrote: Hi Nicholas, I've never heard any talk on the list about developing a card game, but It is definitely a possibility for other groups. A quick search of SourceForge turned up four Rummy projects, with one Windows project named Gin Rummy. Hope this helps. http://sourceforge.net/directory/games/card-games/?q=Gin+Rummy Myshkin LeVine Sent from my iPad On Feb 23, 2014, at 1:34 AM, Nicholas Suplizio nicholassupli...@gmail.com wrote: Hi, I was wondering if the GNUBG crew ever considered writing an evaluator/SIM for Gin Rummy. Would something like this be a possibility? If it has already been done can you point me in the right direction? Please help, thanks. Nicholas ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg -- Logic will get you from A to B. Imagination will take you everywhere. A. Einstein ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] gnu gammon question
Nicholas Suplizio nicholassupli...@gmail.com writes: Thank you for your help. So far I don't think anything like what I'm looking for exists. I do quite a bit of programming but I've never taken on a project like developing a Gin Rummy evaluator before. The most valuable part of GNUBG to me is the hint feature and I'd like something similar for Gin. Any recommendation as to where I may read up on how something like that is designed? I was told it had something to do with combinatorics. Could you provide further guidance of material that may help me with this project? The place where you'd start is building a mathematical model of the game. Both backgammon and gin rummy are games with a substantial randomness component, which means that your mathematical model is going to involve a lot of probability calculations (unlike, say, chess or go, where it's instead a pure positional evaluation and game tree problem). That's where the combinatorics come in. The nature of the randomness is somewhat different for a card game like gin rummy, however. Backgammon has no hidden but knowable information. The full state of the game is present and openly visible on the board, and the only unknown factor (apart from opponent decisions) is upcoming die rolls. However, those rolls are *completely* random. Gin rummy paints a more complex picture. Quite a bit of important knowledge is knowable but hidden, namely the complete list of all previously-played cards. Therefore, a computer player will be better than any human player except one with perfect memory since a computer counts cards perfectly and therefore can make full use of state knowledge about the game that most humans will struggle to retain. Similarly, the upcoming card draws in gin rummy are *not* completely random. They are skewed by the cards that have previously appeared. The ideal gin rummy player is constantly recalculating probability tables for the likelihood of drawing various cards given the cards that have already appeared in the game, and then making decisions based on probability of outcomes given that game state. All this means that a human backgammon player can compete with even very good computer backgammon players better than a human gin rummy player can compete with a computer gin rummy player that takes the simple step of remembering the full game state, an operation that's trivial for a computer but quite difficult for a human. But in terms of writing that computer player, the devil is in the math. You would need to work out the probability calculations of the likelihood of particular draws given various card retention strategies, which is quite doable but which may involve a fair bit of probability work. Quite a bit more than backgammon, since the amount of information that you have is much larger and the randomness space is also much larger. It's much more similar to writing a computer poker player than writing a computer backgammon player. -- Russ Allbery (ea...@eyrie.org) http://www.eyrie.org/~eagle/ ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
[Bug-gnubg] gnu gammon question
Hi, I was wondering if the GNUBG crew ever considered writing an evaluator/SIM for Gin Rummy. Would something like this be a possibility? If it has already been done can you point me in the right direction? Please help, thanks. Nicholas ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
[Bug-gnubg] question
Will GNU run on a chrome book? ctt...@gmail.com ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
[Bug-gnubg] Evaluation question
I've found Gnu evaluates desperation situations very poorly. Specifically, if an opponent is rolling off and you are racing to get one piece off to avoid a gammon, Gnu mis-evaluates moves. From this position: GNU Backgammon Position ID: GreDA0DbbgcBAA Match ID : AQG7 +12-11-10--9--8--7---6--5--4--3--2--1-+ O: GammonBot_II (Cube: 2) | X O | | O O O O O O | 0 points | X| | O O O O O O | Rolled 66 | X| | O O | | | | | | | | | ^| |BAR| | 5 point match, game 1 | | | | | | | | | X| | X| | X X | | XX | | X X | X | XX X| 0 points +13-14-15-16-17-18--19-20-21-22-23-24-+ X: You My moves of 63:13/10, 13/7, 31:8/5 7/6 and 65 10/4 8/3 were rated very bad, bad, and doubtful. How can this be? My sole goal at this point is to avoid a gammon (which I managed to do, btw). Any move I made other than the ones I did would have resulted in a gammon... (i got one piece off). Any thoughts? Thanks! Michael McKinnon (Match attached as jellyfish file) 5 point match Game 1 GammonBot_II : 0You : 0 1) 12: 24/23 13/11 45: 13/8 24/20 2) 44: 13/9 13/9 9/5 9/5 62: 25/23 24/18 3) 36: 23/20 13/7 54: 25/21 23/18 4) 32: 25/22 6/4 25: 25/23 23/18 5) 54: 22/18 18/13 46: 18/14 14/8 6) 22: 25/23 24/22 22/20 6/4 15: 18/13 8/7 7) 13: 8/7 6/3 56: 13/7 13/8 8) 33: 13/10 13/10 10/7 8/5 Doubles = 2 9) Takes 13: 8/7 6/3 10) 12: 23/22 5/3 46: 11) 52: 20/15 10/8 35: 12) 13: 15/14 14/11 41: 25/24 7/3 13) 25: 25/20 11/9 54: 8/3 6/2 14) 33: 7/4 7/4 4/1 4/1 63: 15) 54: 20/15 15/11 15: 16) 33: 8/5 8/5 5/2 5/2 64: 17) 56: 11/6 20/14 46: 18) 35: 14/11 9/4 44: 19) 66: 11/5 6/0 6/0 6/066: 25/19 19/13 13/7 13/7 20) 36: 5/0 3/0 63: 13/7 13/10 21) 33: 5/2 4/1 4/1 3/0 31: 8/5 7/6 22) 26: 5/0 2/0 65: 10/4 8/3 23) 14: 2/1 4/0 14: 8/4 7/6 24) 23: 2/0 1/0 53: 7/2 7/4 25) 23: 1/0 1/0 21: 7/6 2/0 26) Doubles = 4Drops Wins 2 points Game 2 GammonBot_II : 2You : 0 1) 15: 13/8 24/23 54: 24/20 13/8 2) 45: 24/20 13/8 33: 8/5 8/5 6/3 6/3 3) 24: 25/21 23/21 34: 20/16 16/13 4) 61: 13/7 8/732: 13/10 10/8 5) 11: 8/7 6/5 6/5 6/5 13: 24/21 6/5 6) 13: 5/4 7/4 15: 25/24 13/8 7) 23: 13/11 13/10 42: 24/22 5/1 8) 46: 10/6 11/5 55: 8/3 13/8 13/8 13/8 9) Doubles = 2Drops Wins 1 point Game 3 GammonBot_II : 3You : 0 1) 24: 8/4 6/4 54: 24/20 13/8 2) 21: 13/11 6/5 63: 25/22 24/18 3) 11: 8/7 6/5 4/3 4/3 33: 4) 41: 13/9 11/10 54: 25/21 5) 64: 10/4 8/446: 6) 33: 24/21 13/10 10/7 9/663: 7) 44: 24/20 20/16 13/9 9/552: 25/23 8) 23: 13/11 5/2 15: 25/24 9) 62: 7/1 16/14 43: 10) 63: 11/5 5/254: 11) 52: 6/1 7/5 44: 12) 35: 21/18 18/13 14: 13) 52: 14/9 13/11 15: 14) 32: 11/8 5/316: 15) 43: 9/5 8/5 21: 16) 31: 5/2 5/4 34: 17) 43: 4/0 3/0 61: 18) 34: 6/3 6/2 43: 19) 14: 4/3 4/0 16: 25/19 20) 46: 5/1 5/0 34: Wins 3 points and the match ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Evaluation question
On 19/06/2013 5:31 PM, progr...@nwon.com wrote: I've found Gnu evaluates desperation situations very poorly. Specifically, if an opponent is rolling off and you are racing to get one piece off to avoid a gammon, Gnu mis-evaluates moves. My moves of 63:13/10, 13/7, 31:8/5 7/6 and 65 10/4 8/3 were rated very bad, bad, and doubtful. How can this be? My sole goal at this point is to avoid a gammon (which I managed to do, btw). Any move I made other than the ones I did would have resulted in a gammon... (i got one piece off). Any thoughts? What version of GNUBG are you using. Help Menu/About/Buildinfo the line at the top should show the build number. What platform OS are you using (Windows9, Win8, OSX, Ubuntu etc? What analysis level are you using (Settings Menu/Analysis/Analysis Level option is what I'd like to know)? Were you using tutor mode while playing and it told you these errors. If this was in Tutor mode, what tutor level do you use - you can see that here: Settings Menu/Analysis/Eval Hint/Tutor Level). If you saved the analysed match as an SGF file I'd be able to look at it here to see the actual evaluations. The reason I ask these questions is that my copy of GNUBG (0.90-mingw 20121023) has an analysis shows that the only one GNUBG disagreed a bit with was the 63 and it didn't even rate as doubtful. It had about a 0.030 error. The rest of the moves the bot agreed with your plays. Thanks -- Michael Petch GNU Backgammon Maintainer / Developer OpenPGP FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304 ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Evaluation question
On 19/06/2013 10:29 PM, Michael Petch wrote: The reason I ask these questions is that my copy of GNUBG (0.90-mingw 20121023) has an analysis shows that the only one GNUBG disagreed a bit with was the 63 and it didn't even rate as doubtful. It had about a 0.030 error. The rest of the moves the bot agreed with your plays. I happened to do an analysis after I sent this where it was set to expert which uses no look ahead and it shows the errors you suggest for the three moves. Expert is a very low analysis level. I recommend using at a minimum World Class analysis (Settings Menu/Analysis/Analysis Level set to World Class. I would also set eval/tutor mode to same as analysis if you use the tutor mode. -- Michael Petch GNU Backgammon Maintainer / Developer OpenPGP FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304 ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Analyse - Market Window question?
The link to your screenshots do not work for me, I'm afraid. -- Ian (more below) i.e. it says my cube market window opens up at 50.286%... but I was around 55.7% to win the game at this point? yet it says my cube decision was very bad. Ian Shaw wrote If this were the last roll of the game, and you would never get a chance to double later, it would be correct to double. I would hope that the displayed data would be giving me relevant information on my market window with reference to my *current* move, not for the future last roll of the game? The opening of the doubling window is a commonly understood, and calculable, theoretical reference value. When you should actually double in practice is, I think, more of a judgement call. Obviously, gnubg has some hard rules about when to actually double. I don't know what they are, but I believe they are based on Janowski's formulas, and are quite complicated. They take into account the possible gammons and recubes to the end of the match. They aren't something that humans tend to use in actual play. You do raise interesting points. As experienced players and/or developers, it's sometimes difficult to see what might be missing or confusing to a newcomer. It probably would be useful to display the actual range at which you should double. I suspect the reason it isn't displayed is that it's not something that is calculated and used by a bot. The bot will simply double if the equity from doubling exceeds the equity from not doubling. It doesn't calculate a range of winning percentages, adjust for gammons and recubes, estimate whether it's in this range, and then make a doubling decision - that's what humans have to do, and that's what the values in the theory popup are there to help with. So yes, one answer is that you are a n00b and you don't understand what you are looking at! Another answer is that the developers haven't made the popup informative enough. Doubling theory is a tricky part of the game, and it's possible that they haven't come up with a meaningful way of displaying what you would like to see. Disclaimer: I don't fully understand gnubg's doubling mechanisms myself, so there may be someone out there who can give better information. -- Ian ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Analyse - Market Window question?
On 9 June 2013 15:34, sebalotek waynejos...@gmail.com wrote: I've attached another example from my practice game today - If I'm reading the screenshot correctly my Take Point for the offered cube should be above 30.079. My Current win percentage = 31.0%. So why is it classified as 'Bad' when I do Take at this stage? Is it me being n00by again or is this a bug? http://gnu-backgammon.996308.n3.nabble.com/file/n6714/gnubg_cube_market_05.jpg http://gnu-backgammon.996308.n3.nabble.com/file/n6714/gnubg_cube_market_04.jpg Hi, notice that on your screenshot you actually have two takepoints: dead cube at 37% and fully live at 30%. Your real take point is somewhere between the two. As said by Ian, gnubg uses Janowski's formulas for cubeful equities and these try to estimate the equity considering the real' cube liveliness, which is between dead cube and fully live cube. They are called market windows because the real take point (or other point) lies somewhere in the range they show. I think that mostly the market windows are (by advanced/expert players) to understand how the window changes depending on the score: at some scores the window is huge, at some others it's tiny. Max. ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Analyse - Market Window question?
Hi Ian, Thanks for your reply and for your example. In fact my question was not so much to do with the 'position' of the game, but with how to understand the relevance of the 'Analyse - Market Window' function. i.e. it says my cube market window opens up at 50.286%... but I was around 55.7% to win the game at this point? yet it says my cube decision was very bad. Ian Shaw wrote If this were the last roll of the game, and you would never get a chance to double later, it would be correct to double. I would hope that the displayed data would be giving me relevant information on my market window with reference to my *current* move, not for the future last roll of the game? I've attached another example from my practice game today - If I'm reading the screenshot correctly my Take Point for the offered cube should be above 30.079. My Current win percentage = 31.0%. So why is it classified as 'Bad' when I do Take at this stage? Is it me being n00by again or is this a bug? http://gnu-backgammon.996308.n3.nabble.com/file/n6714/gnubg_cube_market_05.jpg http://gnu-backgammon.996308.n3.nabble.com/file/n6714/gnubg_cube_market_04.jpg Finally, it think it would be really useful if when the analysis for the cube decision is shown to also display basic information for the relevant TP / DP / CP there rather than having to go into the separate 'Analyse - Market Window' function as per my added text in red. Thanks again for your feedback and help, Wayne -- View this message in context: http://gnu-backgammon.996308.n3.nabble.com/Analyse-Market-Window-question-tp3838p6714.html Sent from the Gnu - Backgammon mailing list archive at Nabble.com. ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Analyse - Market Window question?
Hi Wayne, The double point of the market window is the lowest winning chance at which you could consider a double. If this were the last roll of the game, and you would never get a chance to double later, it would be correct to double. In most circumstances, you should wait until you are nearer the Cash Point to double. If you double now, with about 55% winning probability, there is a good chance that things may go badly for you, and now it is only your opponent who has access to the cube. If you want to know more about doubling theory, try www.bkgm.com., for example http://www.bkgm.com/articles/GOL/Oct99/hanka99.htm This isn't really a forum for position analysis, but I'll give yours a try. In your position, both sides have an anchor on the 20-point, and the race is even. A classic reference position for a 20-point holding game would be for one side to have an anchor, the other side to have escaped his back men to the midpoint and have a 20-pip lead in the race. This would be a double and take. (You'll need to use a fixed width font such as Courier New to see the board position properly.) GNU Backgammon Position ID: 2G7BAQOYnwcHAA Match ID : cAkE +24-23-22-21-20-19--18-17-16-15-14-13-+ O: White | O O O | | O O X | 0 points | O O O | | O X | |O | |X | | | | | | | | | | |BAR| |v (Cube: 1) |6 | | | |X | |X | |X | |X O | | X O X | |X O | On roll | X O X | |X O | 0 points +-1--2--3--4--5--6---7--8--9-10-11-12-+ X: Blue Cube analysis 2-ply cubeless equity +0.5069 0.7478 0.0258 0.0002 - 0.2522 0.0144 0.0003 Cubeful equities: 1. Double, take +0.8423 2. Double, pass +1. ( +0.1577) 3. No double+0.7936 ( -0.0487) Proper cube action: Double, take You can see that you have some work to do to get to my reference position; you must roll high and well to escape both back men and your opponent gets nothing much. Roughly speaking, since you need to roll 55 or 66 to get into a position where you can offer your opponent a borderline take/pass cube, you can't really have a double now. I hope this helps. -- Ian From: bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org [mailto:bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org] On Behalf Of Wayne Joseph Sent: 06 June 2013 19:05 To: bug-gnubg@gnu.org Subject: [Bug-gnubg] Analyse - Market Window question? Hallo all, I am sorry for the new n00b question. Please can anybody explain to me how the 'Analyse - Market Window' function works? In the screenshot below, I thought I offered a fairly decent cube, I held both 5-points and had a little, but handy, 4-prime going. The score was 0-0 (7-away, 7-away) and I was only 3 pips down in the race. The Market Window function for me is very confusing (disregarding how relatively strong my position looked over the board). In the yellow highlighted line of the first screenshot below it says my cube market window opens up at 50.286% so I think it was correct to cube once I got above this? After analysis, gnubg said my cube action was 'Very Bad' but I was around 55.7% to win the game at this point? Can anybody explain why I am misunderstanding this feature? Position ID: NM/BAQawt8EBAw Match ID: cAngAAAE ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
[Bug-gnubg] GNUBg Position ID question
According to the description of the Position ID in the gnubg manual, http://www.gnu.org/software/gnubg/manual/html_node/A-technical-description-of-the-Position-ID.html Position-ID , the first bits in the key describe the checkers for the player _on_ roll. However, when copying the id from within gnubg, it seems that after having decoded the bits, the first section of the key actually describes the checkers for the player not on roll. For example, after playing an opening 31 by making the fivepoint and the other player being on roll, and yet to make a move, the position id copied from gnubg is sGfwATDgc/ABMA Decoding wrt Basde64 the first 16 bits are 1011 01100111 with endianness the first 16 checker bits are then 1101 11100110 giving 2 checkers on the five point, 4 on the six, 2 on the eight. Has the format officially changed or am I missing something ? Thanks. -- View this message in context: http://old.nabble.com/GNUBg-Position-ID-question-tp34892952p34892952.html Sent from the Gnu - Backgammon mailing list archive at Nabble.com. ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Embarrassing question about TanBoard type.
On Mon, Apr 23, 2012 at 9:24 PM, Philippe Michel philippe.mich...@sfr.frwrote: On Sun, 22 Apr 2012, Øystein Schønning-Johansen wrote: Hi, The board type in GNU Backgammon is typedef'ed as a 2d array anBoard[2][25], but which player is on roll? Is the player with index 0 or the player with index 1 ? I'm getting confused. Player 1 is on roll, at least when it comes down to evaluating the position. See for instance the comment in EvalRaceBG() in eval.c. Thanks, that was what I thought. However I got confused by a bug in my own code. I was so confused for a while that I thought (at least for a while) that this was changed in GNU Backgammon. -Øystein ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Embarrassing question about TanBoard type.
On Sun, 22 Apr 2012, Øystein Schønning-Johansen wrote: Hi, The board type in GNU Backgammon is typedef'ed as a 2d array anBoard[2][25], but which player is on roll? Is the player with index 0 or the player with index 1 ? I'm getting confused. Player 1 is on roll, at least when it comes down to evaluating the position. See for instance the comment in EvalRaceBG() in eval.c.___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
[Bug-gnubg] 0ply question
Hi all, just stumbled on this. Take the position below: all the moves have cubeful equity of -1, as next turn, O would double and X will have to drop, independently on which move X makes now. Question: how can 0ply get this right, know that next cube decision is a D/P ? I was under the impression that 0ply should only feed the resulting position in the net, get the cubeless numbers and translate them to cubeful using janowski's stuff. Does 0ply checker take into account the next cube decision ? MaX. GNU Backgammon Position ID: UAAAQAUAAA Match ID : cIno +13-14-15-16-17-18--19-20-21-22-23-24-+ O: Alex Rietti | | | O O | OOO 0 points | | | | OOO | | | | OOO | | | | OO | | | | OO v| |BAR| | 7 point match (Cube: 1) | | | | XX | | | | XX | | | | XX | | | | XXX Rolled 12 | | | X X X | XXX 0 points +12-11-10--9--8--7---6--5--4--3--2--1-+ X: Carlo Melzi 1. Cubeful 0-ply5/3 4/3 Eq.: -1,000 0,167 0,000 0,000 - 0,833 0,000 0,000 0-ply cubeful, noise 0,06 (d) [beginner] 2. Cubeful 0-ply6/3 Eq.: -1,000 ( +0,000) 0,155 0,000 0,000 - 0,845 0,000 0,000 0-ply cubeful, noise 0,06 (d) [beginner] 3. Cubeful 0-ply5/2 Eq.: -1,000 ( +0,000) 0,155 0,000 0,000 - 0,845 0,000 0,000 0-ply cubeful, noise 0,06 (d) [beginner] 4. Cubeful 0-ply6/4 5/4 Eq.: -1,000 ( +0,000) 0,141 0,000 0,000 - 0,859 0,000 0,000 0-ply cubeful, noise 0,06 (d) [beginner] 5. Cubeful 0-ply4/1 Eq.: -1,000 ( +0,000) 0,133 0,000 0,000 - 0,867 0,000 0,000 0-ply cubeful, noise 0,06 (d) [beginner] 6. Cubeful 0-ply6/5 4/2 Eq.: -1,000 ( +0,000) 0,126 0,000 0,000 - 0,874 0,000 0,000 0-ply cubeful, noise 0,06 (d) [beginner] ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
[Bug-gnubg] embarrassing question (from me): where are
The 0.17 weights and the benchmark files? They are no longer on ftp://ftp.demon.nl/pub/games/gnubg/nn-training/benchmarks Thanks, Joseph ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] embarrassing question (from me): where are
On 01/08/2012 10:05 PM, Joseph Heled wrote: The 0.17 weights and the benchmark files? They are no longer on ftp://ftp.demon.nl/pub/games/gnubg/nn-training/benchmarks Thanks, Joseph ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg ftp://ftp.demon.nl/pub/Demon/games/gnubg/databases/ Demon Internet Netherlands was purchased by xs4all in 2006/2007 and the contents of the ftp server are now somewhat re-arranged as I understand it (I left as part of the takeover), but it appears they kept their commitment to maintain access to these files ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] embarrassing question (from me): where are
On 01/08/2012 10:18 PM, Jim Segrave wrote: On 01/08/2012 10:05 PM, Joseph Heled wrote: The 0.17 weights and the benchmark files? They are no longer on ftp://ftp.demon.nl/pub/games/gnubg/nn-training/benchmarks Thanks, Joseph ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg ftp://ftp.demon.nl/pub/Demon/games/gnubg/databas forgot to mention - the training stuff is under ftp://ftp.demon.nl/pub/Demon/games/gnubg/nn-training Demon Internet Netherlands was purchased by xs4all in 2006/2007 and the contents of the ftp server are now somewhat re-arranged as I understand it (I left as part of the takeover), but it appears they kept their commitment to maintain access to these files ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Neural network symmetry question
Øystein Schønning-Johansen wrote: Sent: 12 December 2011 20:59 So, we don't care about the exactness of the absolute evaluation, we care about the relative evaluation between the moves (or resulting positions after each move). That is what makes it select good moves! This strategy was originally adopted by Tesauro. I agree that it is fine for chequerplay, where you only have to find the best play relative to the alternatives. However, for cube decisions it is important to know the absolute equity. It is known that gnubg is inaccurate in some areas, most notably holding-game cube action, where gnubg overestimates the holding player's chances. I wonder if this is due to only training for relative move selection. It might be worth devising a training regime that trains for absolute equity. This ought to give good chequerplay, too, since if the nn can accurately determine the absolute value of each position it will inevitably rank candidates correctly, too. n Ian ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Neural network symmetry question
If gnubg could estimate the opponents rating based upon error rate then it could be more aggressive on a redouble since the other player is likely to make errors to modify the cube decision. This may have NOTHING to do with what your're talking about right now... :) Tom On 12/16/2011 06:43 AM, Ian Shaw wrote: Øystein Schønning-Johansen wrote: *Sent:* 12 December 2011 20:59 So, we don't care about the exactness of the absolute evaluation, we care about the relative evaluation between the moves (or resulting positions after each move). That is what makes it select good moves! This strategy was originally adopted by Tesauro. I agree that it is fine for chequerplay, where you only have to find the best play relative to the alternatives. However, for cube decisions it is important to know the absolute equity. It is known that gnubg is inaccurate in some areas, most notably holding-game cube action, where gnubg overestimates the holding player's chances. I wonder if this is due to only training for relative move selection. It might be worth devising a training regime that trains for absolute equity. This ought to give good chequerplay, too, since if the nn can accurately determine the absolute value of each position it will inevitably rank candidates correctly, too. n Ian ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Neural network symmetry question
This is nothing to do with what I'm talking about (which is optimising the nn for perfect play), but it's an interesting idea to contemplate. It could be successful, if the bot can account for the opponent's error rate. Typically, it could take worse positions if believed the opponent would misplay them. However, you need to consider what happens if the opponent is actually superior. The bot would think the player was making errors, and adjust accordingly, but it would be adjusting in the wrong direction. Take my previous example: the bot would take a position it would drop if it assumed perfect play, and by taking is in an even worse position because it is being outplayed. It's possible that this could be overcome by factoring in some luck analysis and variance reduction to realise that it is being outplayed because the opponent is too unfeasibly lucky, but I've not really thought about this angle. n Ian From: Thomas A. Moulton [mailto:t...@moulton.us] Sent: 16 December 2011 12:00 To: Ian Shaw Cc: Øystein Schønning-Johansen; Mark Higgins; Frank Berger; bug-gnubg@gnu.org Subject: Re: [Bug-gnubg] Neural network symmetry question If gnubg could estimate the opponents rating based upon error rate then it could be more aggressive on a redouble since the other player is likely to make errors to modify the cube decision. This may have NOTHING to do with what your're talking about right now... :) Tom On 12/16/2011 06:43 AM, Ian Shaw wrote: Øystein Schønning-Johansen wrote: Sent: 12 December 2011 20:59 So, we don't care about the exactness of the absolute evaluation, we care about the relative evaluation between the moves (or resulting positions after each move). That is what makes it select good moves! This strategy was originally adopted by Tesauro. I agree that it is fine for chequerplay, where you only have to find the best play relative to the alternatives. However, for cube decisions it is important to know the absolute equity. It is known that gnubg is inaccurate in some areas, most notably holding-game cube action, where gnubg overestimates the holding player's chances. I wonder if this is due to only training for relative move selection. It might be worth devising a training regime that trains for absolute equity. This ought to give good chequerplay, too, since if the nn can accurately determine the absolute value of each position it will inevitably rank candidates correctly, too. Ian ___ Bug-gnubg mailing list Bug-gnubg@gnu.orgmailto:Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Neural network symmetry question
It is true that for moves we are interested only in relative evaluations between moves, but in cube actions we are interested in relative and value against the drop point. The GNUbg training data contained both move positions and cube action positions. My idea was (and I am not sure if this was original, probably not) to add training data incrementally. For moves, this consisted of a pair or positions - one with the best move, the other with the move chosen by the net. For cube actions it was just the position. And the values where obtained from the 2ply evaluation by the same net. This may be one of the main sources of the odd/even ply issue, but it was not obvious how to overcome this. With today CPU power, I wonder if GNUbg can play using medium length roolouts using a very small net. At least this may be able to indicate the places where gnubg fails to see the long term. -Joseph On 17 December 2011 04:48, Ian Shaw ian.s...@riverauto.co.uk wrote: This is nothing to do with what I’m talking about (which is optimising the nn for “perfect” play), but it’s an interesting idea to contemplate. It could be successful, if the bot can account for the opponent’s error rate. Typically, it could take worse positions if believed the opponent would misplay them. However, you need to consider what happens if the opponent is actually superior. The bot would think the player was making errors, and adjust accordingly, but it would be adjusting in the wrong direction. Take my previous example: the bot would take a position it would drop if it assumed perfect play, and by taking is in an even worse position because it is being outplayed. It’s possible that this could be overcome by factoring in some luck analysis and variance reduction to realise that it is being outplayed because the opponent is too unfeasibly “lucky”, but I’ve not really thought about this angle. n Ian From: Thomas A. Moulton [mailto:t...@moulton.us] Sent: 16 December 2011 12:00 To: Ian Shaw Cc: Øystein Schønning-Johansen; Mark Higgins; Frank Berger; bug-gnubg@gnu.org Subject: Re: [Bug-gnubg] Neural network symmetry question If gnubg could estimate the opponents rating based upon error rate then it could be more aggressive on a redouble since the other player is likely to make errors to modify the cube decision. This may have NOTHING to do with what your're talking about right now... :) Tom On 12/16/2011 06:43 AM, Ian Shaw wrote: Øystein Schønning-Johansen wrote: Sent: 12 December 2011 20:59 So, we don't care about the exactness of the absolute evaluation, we care about the relative evaluation between the moves (or resulting positions after each move). That is what makes it select good moves! This strategy was originally adopted by Tesauro. I agree that it is fine for chequerplay, where you only have to find the best play relative to the alternatives. However, for cube decisions it is important to know the absolute equity. It is known that gnubg is inaccurate in some areas, most notably holding-game cube action, where gnubg overestimates the holding player’s chances. I wonder if this is due to only training for relative move selection. It might be worth devising a training regime that trains for absolute equity. This ought to give good chequerplay, too, since if the nn can accurately determine the absolute value of each position it will inevitably rank candidates correctly, too. Ian ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Neural network symmetry question
I ran my test out to 400k runs and the symmetric network starting drifting down, with the normal one edging it out in head to head competitions. But the real evidence against it came from looking at probability estimates from a couple benchmark positions: one where white is almost certainly going to win, and one where white is almost certainly going to lose. The symmetric case did much worse than the normal case in those examples. I assume this is what the gnubg benchmark stuff is about btw? Comparing probability estimates in a bunch of benchmark board positions against rolled-out probabilities? How do you condense the many different cases into a single number - ie sum( weight * difference^2 ) - how do you relatively weight the different benchmark positions? Also I thought some more about the basic implications of this symmetry constraint and it just seems wrong: the network probabilities are a fn of difference in white and black inputs instead of each separately. That a priori just doesn't seem flexible enough. On Dec 11, 2011, at 5:44 PM, Joseph Heled jhe...@gmail.com wrote: My experience tells me that 100,000 trials may not be sufficient. With today's computing power it should be easy to do at least a couple of millions. -Joseph On 12 December 2011 11:22, Mark Higgins migg...@gmail.com wrote: I tried a little experiment on this: a 10-hidden-node network with a single probability-of-win output, but two setups. The first doesn't have a whose turn is it input and doesn't add any symmetry constraints. The second has the extra inputs for the turn and makes the symmetry constraint I described. I trained them in parallel and benchmarked them against pub eval and against each other. The symmetric case performed a little better: it trained more quickly, did better against pub eval, and was on par or a little better than the other case when playing head to head. Details and data here: http://compgammon.blogspot.com/2011/12/testing-value-of-symmetry-constraint.html Of course not conclusive with such a simple setup, but kind of suggestive anyways. On Dec 10, 2011, at 2:22 PM, Mark Higgins wrote: Thx! Makes sense. Though I wonder if adding back in the whose move is it input and reducing the hidden-output weights by half ends up as a net benefit for training. Maybe I'll test it out. On Dec 10, 2011, at 2:06 PM, Frank Berger fr...@bgblitz.com wrote: Hi Mark, If I take a given board and translate the position into the inputs and then evaluate the network, it gives me a probability of win. If I then flip the board's perspective (ie white vs black) and do the same, I get another probability of win. Those two probabilities should sum to 1, since one or the other player must win (or equivalently, the probability of white winning = probability of black losing = 1 - probability of black winning). I assume your assumption is wrong. IIRC in an earlier paper there was an input to indicate who's on. It is much simpler to present the position from the point of the moving player, because the net has to learn less. I'm not that familiar with the gnubg code, but I think they do it in this way, so you can't just turn the perspective. ciao Frank ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Neural network symmetry question
On Mon, Dec 12, 2011 at 9:11 PM, Mark Higgins migg...@gmail.com wrote: I assume this is what the gnubg benchmark stuff is about btw? Comparing probability estimates in a bunch of benchmark board positions against rolled-out probabilities? How do you condense the many different cases into a single number - ie sum( weight * difference^2 ) - how do you relatively weight the different benchmark positions? The gnubg benchmark database has the resulting position and rollouts of that for each possible move in given position. The net selects the best move, and the there is a error rate on each move. So, we don't care about the exactness of the absolute evaluation, we care about the relative evaluation between the moves (or resulting positions after each move). That is what makes it select good moves! Credit to Joseph for the gnubg bechmark database. -Øystein ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Neural network symmetry question
I tried a little experiment on this: a 10-hidden-node network with a single probability-of-win output, but two setups. The first doesn't have a whose turn is it input and doesn't add any symmetry constraints. The second has the extra inputs for the turn and makes the symmetry constraint I described. I trained them in parallel and benchmarked them against pub eval and against each other. The symmetric case performed a little better: it trained more quickly, did better against pub eval, and was on par or a little better than the other case when playing head to head. Details and data here: http://compgammon.blogspot.com/2011/12/testing-value-of-symmetry-constraint.html Of course not conclusive with such a simple setup, but kind of suggestive anyways. On Dec 10, 2011, at 2:22 PM, Mark Higgins wrote: Thx! Makes sense. Though I wonder if adding back in the whose move is it input and reducing the hidden-output weights by half ends up as a net benefit for training. Maybe I'll test it out. On Dec 10, 2011, at 2:06 PM, Frank Berger fr...@bgblitz.com wrote: Hi Mark, If I take a given board and translate the position into the inputs and then evaluate the network, it gives me a probability of win. If I then flip the board's perspective (ie white vs black) and do the same, I get another probability of win. Those two probabilities should sum to 1, since one or the other player must win (or equivalently, the probability of white winning = probability of black losing = 1 - probability of black winning). I assume your assumption is wrong. IIRC in an earlier paper there was an input to indicate who's on. It is much simpler to present the position from the point of the moving player, because the net has to learn less. I'm not that familiar with the gnubg code, but I think they do it in this way, so you can't just turn the perspective. ciao Frank ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Neural network symmetry question
My experience tells me that 100,000 trials may not be sufficient. With today's computing power it should be easy to do at least a couple of millions. -Joseph On 12 December 2011 11:22, Mark Higgins migg...@gmail.com wrote: I tried a little experiment on this: a 10-hidden-node network with a single probability-of-win output, but two setups. The first doesn't have a whose turn is it input and doesn't add any symmetry constraints. The second has the extra inputs for the turn and makes the symmetry constraint I described. I trained them in parallel and benchmarked them against pub eval and against each other. The symmetric case performed a little better: it trained more quickly, did better against pub eval, and was on par or a little better than the other case when playing head to head. Details and data here: http://compgammon.blogspot.com/2011/12/testing-value-of-symmetry-constraint.html Of course not conclusive with such a simple setup, but kind of suggestive anyways. On Dec 10, 2011, at 2:22 PM, Mark Higgins wrote: Thx! Makes sense. Though I wonder if adding back in the whose move is it input and reducing the hidden-output weights by half ends up as a net benefit for training. Maybe I'll test it out. On Dec 10, 2011, at 2:06 PM, Frank Berger fr...@bgblitz.com wrote: Hi Mark, If I take a given board and translate the position into the inputs and then evaluate the network, it gives me a probability of win. If I then flip the board's perspective (ie white vs black) and do the same, I get another probability of win. Those two probabilities should sum to 1, since one or the other player must win (or equivalently, the probability of white winning = probability of black losing = 1 - probability of black winning). I assume your assumption is wrong. IIRC in an earlier paper there was an input to indicate who's on. It is much simpler to present the position from the point of the moving player, because the net has to learn less. I'm not that familiar with the gnubg code, but I think they do it in this way, so you can't just turn the perspective. ciao Frank ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Neural network symmetry question
Thx - I'll run it longer and with more hidden nodes and see what happens. On Dec 11, 2011, at 5:44 PM, Joseph Heled jhe...@gmail.com wrote: My experience tells me that 100,000 trials may not be sufficient. With today's computing power it should be easy to do at least a couple of millions. -Joseph On 12 December 2011 11:22, Mark Higgins migg...@gmail.com wrote: I tried a little experiment on this: a 10-hidden-node network with a single probability-of-win output, but two setups. The first doesn't have a whose turn is it input and doesn't add any symmetry constraints. The second has the extra inputs for the turn and makes the symmetry constraint I described. I trained them in parallel and benchmarked them against pub eval and against each other. The symmetric case performed a little better: it trained more quickly, did better against pub eval, and was on par or a little better than the other case when playing head to head. Details and data here: http://compgammon.blogspot.com/2011/12/testing-value-of-symmetry-constraint.html Of course not conclusive with such a simple setup, but kind of suggestive anyways. On Dec 10, 2011, at 2:22 PM, Mark Higgins wrote: Thx! Makes sense. Though I wonder if adding back in the whose move is it input and reducing the hidden-output weights by half ends up as a net benefit for training. Maybe I'll test it out. On Dec 10, 2011, at 2:06 PM, Frank Berger fr...@bgblitz.com wrote: Hi Mark, If I take a given board and translate the position into the inputs and then evaluate the network, it gives me a probability of win. If I then flip the board's perspective (ie white vs black) and do the same, I get another probability of win. Those two probabilities should sum to 1, since one or the other player must win (or equivalently, the probability of white winning = probability of black losing = 1 - probability of black winning). I assume your assumption is wrong. IIRC in an earlier paper there was an input to indicate who's on. It is much simpler to present the position from the point of the moving player, because the net has to learn less. I'm not that familiar with the gnubg code, but I think they do it in this way, so you can't just turn the perspective. ciao Frank ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Neural network symmetry question
You have an input that represents whose turn it is (one input for white, one for black, value one if that player is on turn and zero otherwise). I think that's in the original Tesauro setup isn't it? On Dec 10, 2011, at 1:10 AM, Joseph Heled jhe...@gmail.com wrote: Well, I am not sure how you flip the position, since it matters who is on the move. -Joseph On 10 December 2011 16:17, Mark Higgins migg...@gmail.com wrote: I've been playing around a bit with neural networks for backgammon and found something interesting, and want to see whether this is already part of gnubg. Assume a Tesauro-style network with the usual inputs, and some number of hidden nodes. And for simplicity, just one output representing the probability of win. If I take a given board and translate the position into the inputs and then evaluate the network, it gives me a probability of win. If I then flip the board's perspective (ie white vs black) and do the same, I get another probability of win. Those two probabilities should sum to 1, since one or the other player must win (or equivalently, the probability of white winning = probability of black losing = 1 - probability of black winning). But that constraint isn't satisfied with the usual TD setup. If however you make a few assumptions: * Hidden layer nodes don't include bias weight. * Hidden-input weights have a specific symmetry: weight of the i'th hidden node vs the j'th input node = w(i,j) = -w(i,j*), where j* is the index of the other player's corresponding position. * Output layer node doesn't include a bias weight. Then you can show that, for each set of output-hidden node weights, those weights sum to zero, the flip-the-perspective constraint is satisfied. This seems to reduce the number of weights by about half, since you need only half the middle weights. The network should be more accurate since a known symmetry is respected, and should converge quicker since there are fewer parameters to optimize. You can generalize to a bias weight on the output node; in that case, the constraint is on the bias weight that it = -1/2 sum( output-hidden node weights ). You can generalize as well to including a gammon win output node. In this case there are no constraints on the output-hidden node weights, but the probability of a gammon loss can be calculated from the probability of a gammon win weights, and you don't need to explicitly include an output node for the gammon loss. I googled around a fair bit but couldn't figure out whether this is well known or already included somewhere in gnubg. I took a look through eval.c but it's a bit daunting. :) Is there documentation somewhere that I've just not found? ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
[Bug-gnubg] Neural network symmetry question
Hi Mark, If I take a given board and translate the position into the inputs and then evaluate the network, it gives me a probability of win. If I then flip the board's perspective (ie white vs black) and do the same, I get another probability of win. Those two probabilities should sum to 1, since one or the other player must win (or equivalently, the probability of white winning = probability of black losing = 1 - probability of black winning). I assume your assumption is wrong. IIRC in an earlier paper there was an input to indicate who's on. It is much simpler to present the position from the point of the moving player, because the net has to learn less. I'm not that familiar with the gnubg code, but I think they do it in this way, so you can't just turn the perspective. ciao Frank ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Neural network symmetry question
Thx! Makes sense. Though I wonder if adding back in the whose move is it input and reducing the hidden-output weights by half ends up as a net benefit for training. Maybe I'll test it out. On Dec 10, 2011, at 2:06 PM, Frank Berger fr...@bgblitz.com wrote: Hi Mark, If I take a given board and translate the position into the inputs and then evaluate the network, it gives me a probability of win. If I then flip the board's perspective (ie white vs black) and do the same, I get another probability of win. Those two probabilities should sum to 1, since one or the other player must win (or equivalently, the probability of white winning = probability of black losing = 1 - probability of black winning). I assume your assumption is wrong. IIRC in an earlier paper there was an input to indicate who's on. It is much simpler to present the position from the point of the moving player, because the net has to learn less. I'm not that familiar with the gnubg code, but I think they do it in this way, so you can't just turn the perspective. ciao Frank ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
[Bug-gnubg] Neural network symmetry question
I've been playing around a bit with neural networks for backgammon and found something interesting, and want to see whether this is already part of gnubg. Assume a Tesauro-style network with the usual inputs, and some number of hidden nodes. And for simplicity, just one output representing the probability of win. If I take a given board and translate the position into the inputs and then evaluate the network, it gives me a probability of win. If I then flip the board's perspective (ie white vs black) and do the same, I get another probability of win. Those two probabilities should sum to 1, since one or the other player must win (or equivalently, the probability of white winning = probability of black losing = 1 - probability of black winning). But that constraint isn't satisfied with the usual TD setup. If however you make a few assumptions: * Hidden layer nodes don't include bias weight. * Hidden-input weights have a specific symmetry: weight of the i'th hidden node vs the j'th input node = w(i,j) = -w(i,j*), where j* is the index of the other player's corresponding position. * Output layer node doesn't include a bias weight. Then you can show that, for each set of output-hidden node weights, those weights sum to zero, the flip-the-perspective constraint is satisfied. This seems to reduce the number of weights by about half, since you need only half the middle weights. The network should be more accurate since a known symmetry is respected, and should converge quicker since there are fewer parameters to optimize. You can generalize to a bias weight on the output node; in that case, the constraint is on the bias weight that it = -1/2 sum( output-hidden node weights ). You can generalize as well to including a gammon win output node. In this case there are no constraints on the output-hidden node weights, but the probability of a gammon loss can be calculated from the probability of a gammon win weights, and you don't need to explicitly include an output node for the gammon loss. I googled around a fair bit but couldn't figure out whether this is well known or already included somewhere in gnubg. I took a look through eval.c but it's a bit daunting. :) Is there documentation somewhere that I've just not found? ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Neural network symmetry question
Well, I am not sure how you flip the position, since it matters who is on the move. -Joseph On 10 December 2011 16:17, Mark Higgins migg...@gmail.com wrote: I've been playing around a bit with neural networks for backgammon and found something interesting, and want to see whether this is already part of gnubg. Assume a Tesauro-style network with the usual inputs, and some number of hidden nodes. And for simplicity, just one output representing the probability of win. If I take a given board and translate the position into the inputs and then evaluate the network, it gives me a probability of win. If I then flip the board's perspective (ie white vs black) and do the same, I get another probability of win. Those two probabilities should sum to 1, since one or the other player must win (or equivalently, the probability of white winning = probability of black losing = 1 - probability of black winning). But that constraint isn't satisfied with the usual TD setup. If however you make a few assumptions: * Hidden layer nodes don't include bias weight. * Hidden-input weights have a specific symmetry: weight of the i'th hidden node vs the j'th input node = w(i,j) = -w(i,j*), where j* is the index of the other player's corresponding position. * Output layer node doesn't include a bias weight. Then you can show that, for each set of output-hidden node weights, those weights sum to zero, the flip-the-perspective constraint is satisfied. This seems to reduce the number of weights by about half, since you need only half the middle weights. The network should be more accurate since a known symmetry is respected, and should converge quicker since there are fewer parameters to optimize. You can generalize to a bias weight on the output node; in that case, the constraint is on the bias weight that it = -1/2 sum( output-hidden node weights ). You can generalize as well to including a gammon win output node. In this case there are no constraints on the output-hidden node weights, but the probability of a gammon loss can be calculated from the probability of a gammon win weights, and you don't need to explicitly include an output node for the gammon loss. I googled around a fair bit but couldn't figure out whether this is well known or already included somewhere in gnubg. I took a look through eval.c but it's a bit daunting. :) Is there documentation somewhere that I've just not found? ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
[Bug-gnubg] An important link and a question about using EPC values in deciding cube actions
Hello all, (1) As a sequel to a correspondence some months ago, here is a link for downloading Joachim Matussek's important article about an approximation-formula for EPC values and their use in cube decisions in bearoff positions. This time it's the original article, and in English - not just some section about it in a later article by someone else and moreover in the Danish language. (2) I'd like to ask if there is at present a general formula for deciding cube decisions in bearoff positions *after the correct EPC values are already given*. I mean, does GNU make some particular computation on the EPC values it extracts using its data-bases? For instance, let's say Black has a raw pip count of 57 and EPC=65.41, and White has a raw pip count of 60 pips and EPC=70.55, and it's White's roll. Does GNU use a certain formula with these figures in order to reach its evaluation of the correct cube decision? If so, does GNU use the same formula in any position whatsoever, or is a different variant of a formula needed for each different type of positions? Anyway, even if GNU does not use such formula(s), what are the current most modern approximation formulas (given already the exact EPC values) for humans to use? Thanks, -- Adi ___ Bug-gnubg mailing list Bug-gnubg@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnubg
[Bug-gnubg] Fwd: An important link and a question about using EPC values in deciding cube actions
Oops sorry I forgot to put the link in the last delivery. It's http://home.arcor.de/joachimmatussek/BearoffGWC.zip - Adi -- Forwarded message -- From: Adi Kadmon adi.kad...@gmail.com Date: Fri, Feb 4, 2011 at 3:42 PM Subject: An important link and a question about using EPC values in deciding cube actions To: bug-gnubg@gnu.org Hello all, (1) As a sequel to a correspondence some months ago, here is a link for downloading Joachim Matussek's important article about an approximation-formula for EPC values and their use in cube decisions in bearoff positions. This time it's the original article, and in English - not just some section about it in a later article by someone else and moreover in the Danish language. http://home.arcor.de/joachimmatussek/BearoffGWC.zip (2) I'd like to ask if there is at present a general formula for deciding cube decisions in bearoff positions *after the correct EPC values are already given*. I mean, does GNU make some particular computation on the EPC values it extracts using its data-bases? For instance, let's say Black has a raw pip count of 57 and EPC=65.41, and White has a raw pip count of 60 pips and EPC=70.55, and it's White's roll. Does GNU use a certain formula with these figures in order to reach its evaluation of the correct cube decision? If so, does GNU use the same formula in any position whatsoever, or is a different variant of a formula needed for each different type of positions? Anyway, even if GNU does not use such formula(s), what are the current most modern approximation formulas (given already the exact EPC values) for humans to use? Thanks, -- Adi ___ Bug-gnubg mailing list Bug-gnubg@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnubg
RE: [Bug-gnubg] Fwd: An important link and a question about using EPC values in deciding cube actions
Hi Adi, Gnubg doubling decisions are based on Rick Janowksi's theory, which I don't think any human would want to replicate over the board. Gnubg does not use the epc or any other adjusted pip-count method, which are intended for humans. These are included purely for humans to use as a study aid. The best information I have on epc is in Walter Trice's Backgammon Boot Camp, which is derived from his articles at Gammon Village. There are further articles at GV by Trice and by Douglas Zare that expand on the information found in Boot Camp. Thanks for the link to Joachim's paper, which I'll enjoy reading. I haven't read it yet, so I can't tell whether it adds new information, or summarizes what is already known - a valuable thing in itself. Trice explains that there is no general formula applicable to all situations. This is because the epc only tells you the average rolls to bear off, but not the amount of variance. If one player is stacked, a 65 is about as good as a 21, so there is less variance involved. This effect tends to help the leader, because the trailer is relying on the variance swings to catch up in the race. This means that for equal epc races, the trailer is better off in pips vs. pips races. So. although there is no universal formula, there are different rules that can be applied depending on whether the nature of the race is pips vs. pips, pips vs.. rolls or rolls vs. rolls. Note to developers: It might be a nice touch if Trice's formulae were added to the gnubg race theory tab. It could possibly replace the 8-9-12 rule, which applies in similar situations but is less accurate. -- Ian From: bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org [mailto:bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org] On Behalf Of Adi Kadmon Sent: 04 February 2011 13:45 To: bug-gnubg@gnu.org Subject: [Bug-gnubg] Fwd: An important link and a question about using EPC values in deciding cube actions Oops sorry I forgot to put the link in the last delivery. It's http://home.arcor.de/joachimmatussek/BearoffGWC.zip - Adi -- Forwarded message -- From: Adi Kadmon adi.kad...@gmail.com Date: Fri, Feb 4, 2011 at 3:42 PM Subject: An important link and a question about using EPC values in deciding cube actions To: bug-gnubg@gnu.org Hello all, (1) As a sequel to a correspondence some months ago, here is a link for downloading Joachim Matussek's important article about an approximation-formula for EPC values and their use in cube decisions in bearoff positions. This time it's the original article, and in English - not just some section about it in a later article by someone else and moreover in the Danish language. http://home.arcor.de/joachimmatussek/BearoffGWC.zip (2) I'd like to ask if there is at present a general formula for deciding cube decisions in bearoff positions after the correct EPC values are already given. I mean, does GNU make some particular computation on the EPC values it extracts using its data-bases? For instance, let's say Black has a raw pip count of 57 and EPC=65.41, and White has a raw pip count of 60 pips and EPC=70.55, and it's White's roll. Does GNU use a certain formula with these figures in order to reach its evaluation of the correct cube decision? If so, does GNU use the same formula in any position whatsoever, or is a different variant of a formula needed for each different type of positions? Anyway, even if GNU does not use such formula(s), what are the current most modern approximation formulas (given already the exact EPC values) for humans to use? Thanks, -- Adi ___ Bug-gnubg mailing list Bug-gnubg@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] Question on Luck Analysis
On Thu 16 Dec 2010 (10:09 -), Ian Shaw wrote: Hi Christian, Thanks for the explanation. So, just to clarify, the discrepancy of 0.133 from the theoretical 0 in the result reflects discrepancies in the gnubg evaluation function. To calculate luck, gnubg evaluates the equity after each of the 21 possible dice combinations, and calculates the luck as the difference between the actual roll and the average. Each of these evaluations is likely to have some error, so the luck calculation is inevitably inaccurate for every move. Over a large number of moves, you would expect these discrepancies to cancel out. Over the 51 moves in my sample game, this 0.133 total discrepancy averages out at 0.0026 points per move. Cheers, Ian Maybe I'm missing something here, but gnubg's luck figures apply to each player's rolls separately. Rolling a joker for player A can add 3% to his luck, it does not take 3% away from his opponent's luck, so there's no reason to assume they should be equal. One player, playing perfectly, could have a fairly low luck rating if the spread in possible equities is small for all his rolls. Another player could have a high luck rating if he rolls the least of all evil rolls (the average roll leaves two blots, his roll only leaves one). He's lucky, but he's not all that lucky, he still has a blot. Luck is the measure of getting the most favourable of all possible rolls, not a measure of game winning chances in and of themselves. -- Jim Segrave j...@j-e-s.net ___ Bug-gnubg mailing list Bug-gnubg@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnubg
[Bug-gnubg] A question about the tutorial mode
I have installed GNUBG for use in learning how to play backgammon. I spent about 3 hours and played 20 games or so using the tutorial mode. I lost all the games. All the doubles I was advised to take failed. I kept track of what I called a hit count. The machine hit me about 5 times for every time I could get a hit. My question is what is the tutorial mode actually showing. Thanks :-) ___ Bug-gnubg mailing list Bug-gnubg@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnubg
[Bug-gnubg] Install GNU Backgammon question
Hi, I have bought an a Apple Macbook Pro, running Mac OS X 10.6 Can you please let me know how I can install backgammon on this machine? (If you could point me to a step-by-step guide I'd appreciate it as I am an Apple novice). Many thanks for any assistance. Kevin _ Got more than one Hotmail account? Save time by linking them together http://clk.atdmt.com/UKM/go/186394591/direct/01/___ Bug-gnubg mailing list Bug-gnubg@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnubg
[Bug-gnubg] question for top players
45 24\15 26 24\1813\11 21 24\22 15\14 15 bar\20 6\5 66 22\16(2) 13\7(2) 1313\1011\10 56 16\1116\10 46 24\14*\10 44bar\21 13\9(2) 10\6 54 10\5 8\4 36bar16 15 10\9*\415bar\246\1 46 bar\15 2524\22 6\1 22 ??? this is money session game . i made rollout on 2-2 to see which is the best move i really not agree with gnu rollout gnu choose 13-11 (2)5-3(2) i think 22-20 6-4 5-3(2) in 1 match point gnu agree with me but in money session he think best moves 13-11(2)5-3(2) is gnu rollout wrong or some1 can explain me why its best move for money session? ty -- View this message in context: http://old.nabble.com/question-for-top-players-tp26360207p26360207.html Sent from the Gnu - Backgammon mailing list archive at Nabble.com. ___ Bug-gnubg mailing list Bug-gnubg@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnubg
