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
