My 2 cents, for a few years now, is that you can't measure luck unless the two opponents are of exactly the same strength.
With two equally skilled players, the luckier will always win. [luck = sum over all throws of (expected equity - equity after roll)] With non-equal players luck is always on the side of the stronger player, because better moves reduce opponent luck. A good move, by definition, gives less lucky rolls for the opponent. I can show this easily with games that I actually "solved", that is, games for which a perfect player exists. I can't prove it for Backgammon, but I believe the general argument holds in an two player game. -Joseph On Mon, 19 Sept 2022 at 08:06, <[email protected]> wrote: > Thanks for the interest. It's encouraging. Also encouraging was that > after looking at the eval.c I had a better vision of how to go about > it and that it will probably be even easier than I had first dreaded. > So, let me try to explain in more detail and hopefully more clearly > for you/all. > > The purpose is not to prove any one thing but to create a tool for > people to experiment with "what if" scenarios, in order to explore > and discover for themselves things about checker/cube skills and > luck, instead of having to take someone else's word for them. The > usefulness of what I'm proposing will become clearer as you read. > > I think the easiest and best approach would be to add a new entry > to the list of players, called "mutant" (or such), with the advanced > settings to include a predefined setting as "random" and some more > user defined settings as described below. > > If only the predefined setting is selected, then in the eval.c a few > lines of code will be added for cube and for checker decisions. > > For cube, after determining what kind of cube access the "mutant" > has, it will flip a coin and make a random decision. Nothing else. > > For checker, after the filling of the legal moves array, the "mutant" > will randomly play an entry from the array. Nothing else. > > For now I'll just give one example of usefulness per feature. I think > I have been the only one who argued for years that cube magnifies > luck against everyone else who claimed the opposite. With this, we > can settle the debate by making "grandmaster" play 10,000 cubeless > games against "mutant" random and see how much pure luck wins. > > Then we can let them play 10,000 cubeful games with both playing > at "grandmaster" cube skill level. The difference between the two > results will indicate whether the "mutant" will win more or less with > the cube than without the cube. > > The next part will take a little more work but nothing complicated. > > For cube, under a new "advanced settings" window to be created, > there will be arbitrary values to be input by the user, for winning > chance percents for doubling, taking, beavering, dropping, etc. > > Then in the eval.c after calculation of equities/winning chances, > the "mutant" will make a cube decision by comparing it to the > user selected value for the applicable cube action. Nothing else. > > For checker, the user may select options like "always make the > worst move", "always make second best move", "always make > middle move", etc. (I just came up with this and haven't thought > about what other useful selections can be added.) > > Then in the eval.c after the filling of the legal moves array, the > "mutant" will play an entry from the array according to the user > selected option. Nothing else. > > With these, we can accomplish better at running experiments like > Axel's, where "mutant" doubled at >50% and took at >0% winning > chances. > > We can talk later more about all the various experiments we can > run by mixing and matching checker and cube settings for Gnubg > and the "mutant". > > Some results may come out as expected and may reinforce what > we already know but I promise you that many of the results will be > nothing less than unsettling for you all. > > I think this much should be enough for now to raise interests interest. > Implementing this feature should not be any more difficult than the > "Dice manipulation" feature, (which I always saw as useless for anything > other than to unecessarily spite some players who may not trust the > bot's dice), but this utility will probably keep many inquiring minds > busy running and enjoying experiments for hours and days... > > Murat > On Saturday, September 17, 2022, 07:21:50 PM MDT, Joseph Heled < > [email protected]> wrote: > > > It would help if you can clearly state what you want to prove. One > specific statement > that I can understand. > > -Joseph > > On Sun, 18 Sept 2022 at 12:40, <[email protected]> wrote: > > Greetings, > > Some of you who follow RGB may already know about my > decades long arguments that equity, cube decision, error > rate, ELO ranking, etc. calculations are all tainted by arbitrary > constants, unumpirical and inaccurate of unknown degrees > which are magnified by their being circular independently > each and/or in groups, effecting one another. > > Cube skill being the most hyped but inaccurate would also > be the easiest to debunk by running a few simple experiments. > > After my daring the mathematicians, programmers, etc. for > years, finally Axel ran some crude experiments that were very > revealing, even if somewhat botched and incomplete. You can > read about them in RGB if you want. > > What I want to do is run better experiments using Gnubg. I > considered various ways like using gnubg.dll, CLI scripts or > modifying the eval code of Gnubg. After poking around in > the source code, I concluded that the easiest, most flexible > and reusable would be the latter. (If people find it useful, > it can even be left in as a permanently added feature). > > The cube decision points will be in a text format config file > containing user decided arbitrary values for double/beaver, > /take/drop, etc. with negative numbers indicating purely > random decisions. (Again these may be read from existing > cinfig files for ease and/or if made a permanent feature). > > The eval logic will be modified by adding a few lines, after > the winning chances are normally calculated, to check if > the player2's name is "mutant" and to substitute the cube > decisions for that player from the config file. Nothing else > will be modified. > > How the results of long trials can debunk the so-called > "cube skill theory" can be discussed separately, before > and/or after running the experiments. > > I realize that this is like walking into a church and asking > the flock for help to prove that there is no god. But one > never knows unless one asks. So, I am asking.. ;) > > The best that I am hoping is that someone open-minded > and familiar with the code will volunteer to do this. If not, > maybe someone will offer me help to suggest/locate the > best section of code to modify and maybe offer alternative > ideas about doing it better, more efficiently, to be more > expandable later, etc. > > Alternatively, I can create a separate process to make calls > to gnubg.dll but that would take much more work, unless > someone is willing to share his existing code using gnubg.dll > BTW: is there a gnubg.dll newer than Mike Rudman's? > > I guees a Python script can accomplish the same thing but > I'm not familiar with it at all, and I don't know if anyone > would be willing to do it, considering it would take more > work than the first option above. > > Any benevolent agnostics or even good samaritan believers?? > > MK > > >
