On January 3, 2023 at 11:35:55 PM UTC-7, Axel Reichert wrote:
> MK <
mu...@compuplus.net> writes:
>> On December 26, 2022 at 9:21:03 AM UTC-7, Axel Reichert wrote:
>>> MK <
mu...@compuplus.net> writes:
>>>> ## Gnubg stil thinks this is the opening position/roll...!
>>> Read the source, Luke. analysis.c, function "LuckAnalysis"
>> I was too lazy to do and I thought you would quote
>> from it here for everyone's convenience but I wish
>> I had listened to you. I had assumed I knew what
>> would be in there but I just found out what I have
>> been missing.
> I learned that the luck calculation fails (for a recycled
> initial position) from this very comment in analysis.c
> and wanted you to do your own research, which by
> now you finally did.
Ha ha! :) But you knew... How could you ever not? ;)
If I believed you, then I would say that you are not
discussing openly, in good faith but playing some
weird mind games.
> I never managed to return to the initial position in real
> play, hence I do not care about this exotic scenario.
What you call exotic scenario has been the subject of
many interesting discussions over many decades, (as
have many other "exotic scenario" in backgammon).
Who know, maybe even you may find this article from
25 years ago interesting:
https://groups.google.com/g/rec.games.backgammon/c/8vUhA8fpEN0/m/nXMtpFOrmFoJ
Notice that in that thread I am the only one who goes
beyond your "exotic" by talking about recycling to the
initial position more than once! (and then in only four
rolls) by saying:
"Even for the ones who may want to stick with
"the rule that the first roll cannot be a double, it
"should still qualify as a valid solution at least
"for a "second iteration" of the loop.
Interestingly, Gary Wong already knows at that time
that after recycling to it, rolling doubles is allowed at
what is called the "initial/opening position" and goes
beyond your "exotic" in a different way, by saying:
"Silly me, playing an opening 31 as 8/5 6/5 all
"this time -- it turns out to be better to play 13/9
"so that you have the potential to return to the
"start in 4 more moves. Naturally, it's then not
"the first roll of the game any more, so you're
"free to roll 66 -- a much better number than
"that hopeless 31 opener :-)
That is quite a farseeing intelligence. Unfortunately
he wasn't intelligent enough to also see that after an
odd number of rolls, his opponent would be on roll at
the recycled initial position and be free to roll 66... :(
You mathshiters need to come to terms with the fact
that you are not always the brightest bulbs around.
> Otherwise, GNU Backgammon's luck calculations are
> fine, though not conforming to your own, personal
> definition of luck, but rather to a definition that makes
> perfect sense from a mathematical or game-theoretical
> point of view, see Tim's nice explanations.
Assuming you are referring to you guys' argument that
the equity of the initial position is zero, as I said, I have
no issues with the definition that you are defending. The
issue is that it doesn't (as it shouldn't) make exception
for the initial position.
Now it's your turn to go do your homework, by looking at
all versions of analysis.c starting from the beginning, to
see how Gnubg's luck calculations have evolved. (If you
know how to do it, it's not as difficult as it may sound.)
But even just looking at the last version is enough to see
that you bozos are wrong on this also. Perhaps you are
not as good as paying attention to detail, but the section
of code we are talking about contains this:
"if (is_init_board && n0 != n1)"
Maybe you don't understand what "n0 != n1" is there for?
Gnubg is checking if the dice are the same, (i.e. a double).
Why do you think it does that? To do calculate luck rate
differently when doubles are rolled at the initial position.
If the dice are doubles and you are at the initial position,
it means that you are at a recycled initial position. But if
not, you can't tell if you are at the first initial position or
at a recycled initial position. Thus the comparison fails
at differentiating between the two.
I don't think this piece of logic was initially coded like this
because there are easier and surer ways of differentiating
the first initial position. To me it looks like a remnant of a
code calculating luck rates correctly, (i.e. like Snowie but
with a bug fix to exclude doubles from the average equity
of the initial position). In any case, Gnubg should calculate
luck rate according to its definition of it, without making an
arbitrary and fallacious exceptions.
> And if I were Philippe Michel, I would be terribly motivated
> to fix something that bothers someone with your always
> polite, friendly and almost courteous behaviour.
I couldn't care less if Gnubg's bugs are fixed. I just enjoy
pissing fallacies and garbage bots. :)
Asking Philippe Michel politely didn't help my suggestions
being implemented. Since it won't make a difference, why
not enjoy pissing on him also...? ;)
MK