Re: Request for help or advice for cube skill experiment using Gnubg

[playbg-rgb]

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 <jheled@gmail.com> 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, <playbg-rgb@yahoo.com> 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