Re: What is "15", "Unknown cube decision"?

[Murat K]

On 4/21/2024 9:51 AM, Philippe Michel wrote:
> On Fri, Apr 12, 2024 at 04:47:31PM -0600, Murat K wrote:
>
> > Since I have been running experiments using my Python
> > scripts that I have shared on my web page, every now
> > and then I get the "unknown cube decision" error when
> > I call the "gnubg.cfevaluate()" function.
> >
> > It's coming from line 3172 of "eval.c" at this link:
> >
> > https://cvs.savannah.gnu.org/viewvc/gnubg/gnubg/eval.c?revision=1.498&view=markup
> >
> > In lines 3131-3172, there are 20 possible cases for
> > cube decisions. They don't seem to be in the same
> > order as "int recommendation" returned by the function
> > since the value returned for the above error is "15".

Hi Philippe,

Since you bothered to give a thoughtful response, I will
tell you why I think it's happening, to help you fix it.

> The 15 corresponds to the "cube not available" case.
> Either there is something in your script that makes it
> occasionally double when it doesn't have cube access

I think GnuBG gives a proper error when one tries this.

> or there is someting wrong in the way gnubg handles
> beavers and raccoons. Do you have the log of a game
> where this happened ?

It's related to beavers and raccoons but it's not GnuBG's
fault. In some of my scripts, when the cube reaches 4096
or even 2048 foreseeing beavers and raccoons, I "recycle"
the cube, i.e. set it to 2, multiple times if needed and
increment a multiplier in order to calculate the effective
cube value at the end of the game.

I encountered this long time ago but never made an issue
out of it because it will never happen in GUI, nor even in
CLI to "normal" users, (unlike me :)

I only posted it in retaliation to Isaac's private email
telling Ian and me to take our discussions elsewhere
because they were becoming off-topic for this forum, which
I completely disagree with but I didn't want to start an
open confrontation. I haven't bothered to respond to his
useless private email to me on this bug either.

> Anyway, even if it cannot happen when gnubg makes the
> cube decisions, it was a bit dumb to pass the opportunity
> to give a more explicit message. This will be fixed in
> the next release.

In case you want to fix this beyond just changing the error
message, it seems to arise from the "set cube" function. In
my script, when I do:

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

the cube appears to be set to 2 but GnuBG somehow still
remembers the 4096 somewhere in there, thus the double is
both allowed and produces an error because the bot sees
the cube 2 in one logical comparison and 4096 in another.

This happened only 3-4 times in 40,000 games during my
"crude" mutant cube skill experiments 9 and 10, where the
cube went over 4096 many times but I think it went at the
most to 65536 and only once. In my later, more elaborate
experiments 11 and 12, I don't remember if the cube has
ever gone over 4096. So, simply increasing the max cube
limit may be the quick and dirty fix, to allow users to
still limit the cube to whatever they want and also run
experiments like mine but without having to mess with
recycling the cube.

MK