About a week ago, I had asked for help with a Python script
in the GnuBG mail-list but received no responses. There was
a bug in Noo-BG that I couldn't figure out easily but I was
able to find a solution after a little effort on my own.

After that, I kept improving on my basic test script until
it became a general "mutant against bot experiment script"
which worked well enough that I decided to just do it all
on my own and create various experiment scripts based on it.

Learning the Python syntax and the functions that I needed
was a breeze but dealing with numerous Noo-BG bugs that I
kept discovering along the way was a real pain in the ass. :(
But in a few days, I had a set of scripts that worked well
enough, which I will share here soon, after I improve them
further and test them some more.

The first script doubles and takes randomly but never drops.

The second script tries to replicate Axel's experiment by
doubling at >50%, taking at >0% and never dropping.

The third script handles cube decisions as described in my
recent post titled: "Another Murat mutant cube skill
experiment based on game stages".

One problem with all scripts is that Noo-BG has a hard-coded
maximum cube limit of 4096 that you may remember from Axel's
experiment, in which he had extrapolated higher cube values,
etc. but I want to be able to do better. Axel had asked for
max-cube 15 limit instead of 12 in Noo-BG and I want's to be
able to handle more than 15 if it ever happens.

One way to possibly handle this without begging the Noo-BG
team for anything, may be to have the script do something
like this: when the cube reaches 4096, set a flag and set
the cube down to 2 and keep going. During the second cycle,
when cube reaches 8, for example, it will mean 32,768 as
follows: (and let the so-called "cube skill theory" go to
St. Petersburg, La La Land, heaven, hell, wherever... ;)

2 8192
4 16384
8 32768
16 65536
32 131072
64 262144
128 524288
256 1048576
512 2097152
1024 4194304
2048 8388608
4096 16777216

I may be able to figure out how to accomplish this but it may
take a lot of effort and time for a tangled solution at best,
if at all.

So now, here is an opportunity for the math PHD's of RGB to
show off their knowledge and creativity to come up with an
elegant solution...

In fact, I have another opportunity for them to show off not
only their math but also their knowledge of equities, errors,
etc. which I surely don't know about to do what I have in mind.

Ex-Gee has a "should have won" feature that Noo-BG doesn't have.
One solution could be to import the Noo-BG session into Ex-Gee
and let it calculate the "should have won" based on error rate
but unfortunately Ex-Gee has even a lower maximum cube value
limit set at 1024. Thus, importing fails as soon as a cube value
higher than that is encountered in a game record.

Can any of you math PHD's figure out the formula to calculate
the "should have won" number based on error rate? that can be
used in scripts, again without begging the Noo-BG team for it?

BTW: Contrary to my earlier impression that they weren't willing
to help (especially me, out of spite), I came to conclude that
they are probably mediocre programmers who couldn't be able to,
even if they wanted to implement some fixes and improvements.

Anyway, I'll be working on bettering and testing my scripts while
waiting to see if anyone can help with the above two problems.

MK

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/26/2024 6:56 PM, MK wrote:

One way to possibly handle this without begging the Noo-BG
team for anything, may be to have the script do something
like this: when the cube reaches 4096, set a flag and set
the cube down to 2 and keep going. During the second cycle,
when cube reaches 8, for example, it will mean 32,768 as
follows: (and let the so-called "cube skill theory" go to
St. Petersburg, La La Land, heaven, hell, wherever... ;)

2    8192
4    16384
8    32768
16    65536
32    131072
64    262144
128    524288
256    1048576
512    2097152
1024    4194304
2048    8388608
4096    16777216

I may be able to figure out how to accomplish this but it may
take a lot of effort and time for a tangled solution at best,
if at all.

So now, here is an opportunity for the math PHD's of RGB to
show off their knowledge and creativity to come up with an
elegant solution...

Come on frogs! Are you all afraid that I'll sting you...?

Here is my solution in pseudocode:

if cubevalue == 4096: gnubg.command('set cube value 2')

(without changing cube owner, let the game continue and
come to an end, calculate the actual final cube value)

power = math.log(cubevalue, 2) + 12 - 1
cubevalue = math.pow(2, power)

Easy-peasy, eh...? ;)

I think setting power to the number of cube actions by
counting using my fingers would have been more funnier,
if not more easier ;)

BTW: I'm starting to really like Python

MK

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/26/2024 6:56 PM, MK wrote:

Ex-Gee has a "should have won" feature that Noo-BG doesn't have.

Can any of you math PHD's figure out the formula to calculate
the "should have won" number based on error rate?

I think I have by now encountered and have dealt with every
possible idiosyncrasy effecting my scripts. I am patiently
running them, saving all games and stats that I will share
with you all, along with my scripts.

To make sense out of the results in terms relative to error
rates, I'll need the "should have won" figures like in XG.
I didn't get any help from the Noo-BG people. Is it that you
guys don't know either or that you are refusing to help me?

MK

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)