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
