First, my understanding of how Gnubg does things. Please
feel free to correct/clarify if/as needed.

1) According to Gnubg's Temperature Map, average equity for
opening rolls, (excuding doubles), is 1630 / 30 = +0.0543

2) Gnubg keeps a separate "luck rate" for each player.

3) Gnubg keeps track of equities as maximum gained/lost by
the dice rolled, regardless of how they are played.

4) My comments follow ## signs.

With that said, let's start by looking at the 5-move game at:

https://www.bkgm.com/rgb/rgb.cgi?view+68

======================================
Player1
T-map for 31: +0.218 - +0.106 = +0.112

Hint:
1. Cubeful 0-ply 8/5 6/5 Eq.: +0.218
5. Cubeful 0-ply 13/9 Eq.: -0.026 (-0.244)

Analysis after play:
Luck total EMG (Points) +0.000 ( +0.000) +0.218 ( +0.218)
Luck rate mEMG (Points) n/a +218.2 ( +0.218)
Luck rating n/a Go to Las Vegas

## Gnubg doesn't subract the average eqity from the opening roll
## Luck should be +0.218 - +0.0543 = +0.1637

===============================================
Player2
T-map for 44 : +0.438 - +0.040 = +0.398

Hint:
1. Cubeful 0-ply 24/16* 13/9(2) Eq.: +0.438
11. Cubeful 0-ply 24/16* 13/5 Eq.: +0.188 (-0.250)

Analysis after play:
Luck total EMG (Points) +0.398 ( +0.398) +0.218 ( +0.218)
Luck rate mEMG (Points) +397.6 ( +0.398) +218.2 ( +0.218)
Luck rating Go to Las Vegas Go to Las Vegas

===============================================
Player1
T-map for 32: -0.068 - -0.159 = +0.091

Hint:
1. Cubeful 0-ply bar/20* Eq.: -0.068

Analysis after play:
Luck total EMG (Points) +0.398 ( +0.398) +0.309 ( +0.309)
Luck rate mEMG (Points) +397.6 ( +0.398) +154.5 ( +0.154)
Luck rating Go to Las Vegas Go to Las Vegas

===============================================
Player2
T-map for 31: +0.077- +0.068 = +0.009

Hint:
1. Cubeful 0-ply bar/22 6/5* Eq.: +0.077
6. Cubeful 0-ply bar/24 16/13 Eq.: -0.061 (-0.138)

Analysis after play:
Luck total EMG (Points) +0.407 ( +0.407) +0.309 ( +0.309)
Luck rate mEMG (Points) +203.5 ( +0.204) +154.5 ( +0.154)
Luck rating Go to Las Vegas Go to Las Vegas

===============================================
Player1
T-map for 43: +0.158 - +0.089 = +0.069

Hint:
1. Cubeful 0-ply 24/20 13/10 Eq.: +0.158
7. Cubeful 0-ply 20/13 Eq.: -0.092 (-0.250)

Analysis after play:
Luck total EMG (Points) +0.407 ( +0.407) +0.378 ( +0.378)
Luck rate mEMG (Points) +203.5 ( +0.204) +126.0 ( +0.126)
Luck rating Go to Las Vegas Go to Las Vegas

## So far so good except that Player1's total luck is off by +0.0543
## which is the average equity of opening rolls, excluding doubles
## This error will perpetuate in all subsequent luck calculations, in
## other related calculations or decisions related to it, based on it

===============================================
At this point, we have recycled back to opening position
Now let's look at Nasti's opening 53 again

T-map for 53: +062 - +0.106 = -0.044

Hint:
1. Cubeful 0-ply 8/3 6/3 Eq.: +0.062

Analysis after play:
Rolls marked lucky 1 0
Rolls unmarked 1 4
Luck total EMG (Points) +0.407 ( +0.407) +0.440 ( +0.440)
Luck rate mEMG (Points) +203.5 ( +0.204) +110.0 ( +0.110)
Luck rating Go to Las Vegas Go to Las Vegas

## Gnubg stil thinks this is the opening position/roll...!
## and adds the raw equity +0.062 for 53 without subtracting the
## average opening roll equity +0.106, this time including doubles
## What a pity for anyone who would bet money on these numbers
## with or without the recycling to the opening position... :(

===============================================

I tried to be as sparing with words as I could. If anything isn't
obvious to you, please feel free to ask and I will try to explain.

Merry Gnu-year...! ;)

MK

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

On 12/26/2022 6:30 AM, MK wrote:

Hint:
1. Cubeful 0-ply 8/5 6/5 Eq.: +0.218
5. Cubeful 0-ply 13/9 Eq.: -0.026 (-0.244)

Analysis after play:
Luck total EMG (Points) +0.000 ( +0.000) +0.218 ( +0.218)
Luck rate mEMG (Points) n/a +218.2 ( +0.218)
Luck rating n/a Go to Las Vegas

## Gnubg doesn't subract the average eqity from the opening roll
## Luck should be +0.218 - +0.0543 = +0.1637

The average equity from the opening roll is zero, because it's +0.0543
half the time (when I win the opening roll) and -0.0543 half the time
(when I lose the opening roll).

I suppose you could redefine "MK luck" to be the same as luck, except
that you subtract 0.0543 when you win the opening roll and you add
0.0543 when you lose the opening roll, but that seems confusing and
pointless. It would make it seem that winning the opening roll is
less lucky than it actually is.

---
Tim Chow

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

MK <murat@compuplus.net> writes:

## So far so good except that Player1's total luck is off by +0.0543
## which is the average equity of opening rolls, excluding doubles

Tim (and myself) already corrected you on this one.

## This error will perpetuate in all subsequent luck calculations, in
## other related calculations or decisions related to it, based on it

Apart from it being no error, I am not aware where GNU Backgammon might
use this further downstream. It is just output for someone interested in
dice statistics. This typically holds true for weak wetware, not strong software.

At this point, we have recycled back to opening position

[...]

## Gnubg stil thinks this is the opening position/roll...!

Read the source, Luke. analysis.c, function "LuckAnalysis"

Axel

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

Timothy Chow <tchow12000@yahoo.com> writes:

The average equity from the opening roll is zero, because it's +0.0543
half the time (when I win the opening roll) and -0.0543 half the time
(when I lose the opening roll).

Yes. And by the way, GNU Backgammon allows for more than 0-ply analysis
of luck, though not via its GUI. There is a command that can be given to
it. I have done so, and my suspicion was correct: It is very slow,
because 3-ply luck analysis can be compared to 4-ply move
analysis. Those (not you, Tim) eager to dive into luck instead of moves
will find out for sure. It is in the command help.

Best regards

Axel

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

On December 26, 2022 at 6:44:08 AM UTC-7, Tim Chow wrote:

On 12/26/2022 6:30 AM, MK wrote:

## Gnubg doesn't subract the average eqity
from the opening roll
## Luck should be +0.218 - +0.0543 = +0.1637

The average equity from the opening roll
is zero, because it's +0.0543 half the time
(when I win the opening roll) and -0.0543
half the time (when I lose the opening roll).

It's puzzling to me how seemingly/claimedly
intelligent/educated people, arithmeticians,
mathematicians and all can't grasp such a
simple concept.

Maybe you all confuse yourselves by the way
the opening roll is won and rolled at the same
time in westernized backgammon...?

I suppose you could redefine "MK luck" to be
the same as luck, except that you subtract
0.0543 when you win the opening roll and
you add 0.0543 when you lose the opening
roll, but that seems confusing and pointless.
It would make it seem that winning the
opening roll is less lucky than it actually is.

Yes and I'm glad you caught you own nonsense.

Try to understand it this way: Players toss a
coin to decide who goes first. The winner of
the opening roll is sitting there, shaking the
dice in his cup. His *average* equity at that
moment is +0.0543 before he even rolls the
dice. It should be easy to understand this...

MK

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

On December 26, 2022 at 9:21:03 AM UTC-7, Axel Reichert wrote:

MK <mu...@compuplus.net> writes:

## So far so good except that Player1's total luck
is off by +0.0543
## which is the average equity of opening rolls,
excluding doubles

Tim (and myself) already corrected you on this one.

You can't correct me on something you don't even
understand, yet, but hopefully you will eventually.

## This error will perpetuate in all subsequent luck
calculations, in
## other related calculations or decisions related
to it, based on it

Apart from it being no error,

It is an error.

I am not aware where GNU Backgammon might
use this further downstream.

Frankly, I don't know if it does or not. I just said it
as a comment to cover all possibilities.

It is just output for someone interested in dice
statistics.

Do you mean humans don't look at temperature
maps for deciding how to play in order to avoid
jokers, etc...??

However, I would agree that the "average equity"
may not be of practical use for humans.

This typically holds true for weak wetware, not
strong software.

I don't understand this. Can you explain?

At this point, we have recycled back to opening
position

## Gnubg stil thinks this is the opening

position/roll...!

Read the source, Luke. analysis.c, function
"LuckAnalysis"

Gnubg's behavior looks obvious to me but I will
look at whatever source code you are referring
to, if you bother to quote from it here. Otherwise
we can't know what are you talking about. (But
make sure the "analysis.c" you are looking at is
not obsolete...;)

BTW: "Luke" and "luck" in the same sentence
made me think of "Lucky Luke" and brought
back some childhood memories... :) Thanks.

MK

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

On December 26, 2022 at 9:32:34 AM UTC-7, Axel Reichert wrote:

Timothy Chow <tchow...@yahoo.com> writes:

The average equity from the opening roll is zero,
because it's +0.0543 half the time (when I win
the opening roll) and -0.0543 half the time
(when I lose the opening roll).

Yes.

No. Tim's comment is meaningless, false logic.

He may be confused by XG's keeping track of
luck as the + and - of a single number, adding
up to zero but that doesn't make the equit from
the opening roll zero. Whoever wins the opening
roll gains +0.0543 *average equity*.

And by the way, GNU Backgammon allows for
more than 0-ply analysis of luck, .....

This issue has nothing to do with plies. No need
to waste time and effort going there.

MK

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

On 12/26/2022 4:14 PM, MK wrote:

Try to understand it this way: Players toss a
coin to decide who goes first. The winner of
the opening roll is sitting there, shaking the
dice in his cup. His *average* equity at that
moment is +0.0543 before he even rolls the
dice. It should be easy to understand this...

Yes, of course that's true. But luck isn't calculated
for "the winner of the opening roll." If Alice plays
Bob, luck is calculated for *Alice* or for *Bob*. Half
the time, Alice is the winner of the opening roll, and
in those cases, her average equity is +0.0543, but the
other half of the time, Alice is the *loser* of the opening
roll, and her average equity is -0.0543.

Put another way, if Alice and Bob play 30 games, then for
each player, we should average their luck for the opening
roll over 30 games. Under your scheme, Alice plays 30 games,
but you only average over the 15 games where she wins the
opening roll.

You might object, "No, look, we're talking about *this* game,
and in *this* game, Alice won the opening roll, so that's all
we should be considering." But in *this* game, Alice didn't
gain +0.0543. She rolled some particular roll and gained some
particular equity, different from +0.0543. If you're quoting
the +0.0543 number, you're *averaging* over many hypothetical
games, not just the particular game. If you're going to average
over games, then the logical thing to do is to average over *all*
games. It would make no sense, for example, to observe that the
opening roll was 31, so we should average over all games in which
Alice wins a 3, even though she's sitting there, looking at a 3
on her dice. Similarly, it makes no sense to average over just
the games in which she happens to win the opening roll, even though
in this particular game that's what happened.

---
Tim Chow

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

On December 28, 2022 at 8:16:32 AM UTC-7, Tim Chow wrote:

On 12/26/2022 4:14 PM, MK wrote:

Try to understand it this way: Players toss a
coin to decide who goes first. The winner of
the opening roll is sitting there, shaking the
dice in his cup. His *average* equity at that
moment is +0.0543 before he even rolls the
dice. It should be easy to understand this...

Yes, of course that's true.

I'm glad that you are still pondering the issue.

Okay, then you should also agree that, since "luck
rate" is the "Deviation of equity from average Roll"
and the "average equity" already exists before the
opening roll, +0.0543 (in the case of Gnubg 0-ply)
should be subtracted from (or in effect added to)
the equity of the actual opening roll.

But luck isn't calculated for "the winner of the
opening roll." If Alice plays Bob ... Half the time,
Alice is the winner of the opening roll, and ... her
average equity is +0.0543, but the other half of
the time, Alice is the *loser* of the opening roll,
and her average equity is -0.0543.

Yes and I've never said anything different. You may
have misunderstood because in this thread we are
talking about Gnubg which tallies luck equities of
the players separately and would add/subtract the
average equity, (if it were correctly to do so), to the
column of the winner of the opening roll each game.
(In fact, in the end it doesn't even calculate the net
difference between the players. Users are left to do
that themselves.)

What you are describing is how XG does it but the
end result is the same. BTW: even though a lot of
the same wording appear in my two threads about
Gnubg's and XG's luck calculations, their contents
differ in details. Please read both threads to better
understand my general and specific arguments.

https://groups.google.com/g/rec.games.backgammon/c/RgcdohfwyYs/m/NtnrIaUTCAAJ

You might object, "No, look, we're talking about .....

I really couldn't see the point of this long paragraph.
It sounded like you were elaborating based on your
above misunderstanding. There is no question that
efter a large number of games each side will win the
opening roll close to equally and that their luck rates
will average out, (regardless of how they are tallied).

That's why it's okay to keep one running "net equity"
number like XG does. (On the other hand, since skill
doesn't average out like luck, XG keeps a separate
skill/error equity number for each player, as Gnubg
does also).

Using the 5-roll recycling back to opening position
example I used, if you tally Gnubg's and XG's equity
numbers manually, you get -0.029 and +0.021 net
luck difference between the players in the end. (To
its credit, Gnubg's final result matches the -0.029 but
not only that XG's final result +0.005 is off by +0.016
but the intermediate numbers after all rolls are also
off. I have no idea why that is but I think it reflects
very poorly on XG.)

To recap, what I'm arguing is that the correct equity
numbers should be (-0.029) - (+0.0543) = -0.0833
for Gnubg and (+0.021) - (+0.0547) = -0.0337 for XG,
by correctly taking into account the average equity
gained by winning the opening roll, (along with the
equity gained by the dice of the actual opening roll).

MK

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

On 12/28/2022 11:53 PM, MK wrote:

On December 28, 2022 at 8:16:32 AM UTC-7, Tim Chow wrote:

But luck isn't calculated for "the winner of the
opening roll." If Alice plays Bob ... Half the time,
Alice is the winner of the opening roll, and ... her
average equity is +0.0543, but the other half of
the time, Alice is the *loser* of the opening roll,
and her average equity is -0.0543.

Yes and I've never said anything different. You may
have misunderstood because in this thread we are
talking about Gnubg which tallies luck equities of
the players separately and would add/subtract the
average equity, (if it were correctly to do so), to the
column of the winner of the opening roll each game.

No, I haven't misunderstood anything.

Winning the opening roll is a lucky event (to the tune of
+0.0543). Suppose at the end of the game, I have a conversation
with a reporter about the game, who asks, "How lucky were you?"
I reply, "I was very lucky! First, I won the opening roll.
Then, I rolled a great second roll. My third roll was slightly
unlucky, but then..." What GNUBG and XG are doing is tallying
up all these lucky events. Here's the main point: *They are
including the luckiness of winning the opening roll*.

What you're saying is that since the reporter chose to interview
the winner of the opening roll, we should ignore the luckiness
of winning the opening roll when tallying up the luck. There
is nothing stopping you from doing this, but it's a rather
strange thing to do. That amounts to the following dialogue:

Reporter: How lucky were you?
Me: I was very lucky! First, I won the opening roll. Then...
Reporter: Stop. Don't count the luckiness of winning the opening
roll. Don't you realize that I chose to interview you precisely
because you won the opening roll? I want to know how lucky you
were *after* that.
Me: Oh...uh...all right. If that's what you want to know. But I
thought you were asking for my total luck, and I was lucky to
win the opening roll.
Reporter: Yes, but I already knew that you won the opening roll and
I know how lucky that is, so all I care about is your luck above
and beyond winning the opening roll. And if I interview your
opponent, then all I'm interested is how unlucky your opponent
was, above and beyond the unluckiness of losing the opening roll.

In short, there's certainly nothing wrong with what GNUBG and XG
are doing, and it's a much more natural way to calculate luck than
what you're proposing.

---
Tim Chow

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

On December 29, 2022 at 7:20:49 AM UTC-7, Tim Chow wrote:

On 12/28/2022 11:53 PM, MK wrote:

On December 28, 2022 at 8:16:32 AM UTC-7, Tim Chow wrote:

Half the time, Alice is the winner of the opening
roll, and ... her average equity is +0.0543, but the
other half of the time, Alice is the *loser* of the
opening roll, and her average equity is -0.0543.

Yes and I've never said anything different. You
may have misunderstood because in this thread
we are talking about Gnubg which tallies luck
equities of the players separately ...

No, I haven't misunderstood anything.

Well, then, you haven't understood all of it, yet but
I'm confident that you will because you have been
making an effort and have understood some of it.
So, we will proceed from there and I will be patient
and will keep making an effort also.

Winning the opening roll is a lucky event (to the
tune of +0.0543).

It's good that you acknowledge this. We can try to
build on it.

What GNUBG and XG are doing is tallying up all
these lucky events. Here's the main point: *They are
including the luckiness of winning the opening roll*.

No, neither bot is doing it right. You either didn't read
both my initial post carefully, without skipping lines
or you didn't understand, (or refused to understand),
what you have read. I suggest once more that you go
read them both again, genuinely trying to understand.

What you're saying is that since the reporter chose
to interview the winner of the opening roll, we should
ignore the luckiness of winning the opening roll when
tallying up the luck.

Indeed not! This shows that you're misunderstanding
or not understanding at all what I have been saying,
which is the exact opposite.

Reporter: How lucky were you?
Me: I was very lucky! First, I won the opening roll. Then...
Reporter: Stop. Don't count the luckiness of winning the
opening roll. Don't you realize that I chose to interview
you precisely because you won the opening roll? I want
to know how lucky you were *after* that.

All the while accusing me of focusing only on the luck
of the player who wins the opening roll, (which I'm not
doing), you are doing it yourself.

Luck gained by winning the opening roll is *average".
If you look at the temperature map, 20 of the 30 rolls
possible, (excluding doubles), result in an equity less
than the +0.0543 average. The same is true for XG's
dice distribution, Snowie's dice panel and the rollout
figures at the link I had given previously.

So, when the player who wins the opening roll with a
41, he actually gets quite unlucky because his equity
from the opening roll will be -0.006.

It doesn't matter if your reporter always interviews
the winner of the opening roll, (i.e. Bob, Alice or me),
since 10 out of 30 times +0.0543 will be subtracted
but 20 out of 30 times +0.0543 will be added to the
equity of the actual opening roll.

This is why in my previous post I said:

"Okay, then you should also agree that, since "luck
"rate" is the "Deviation of equity from average Roll"
"and the "average equity" already exists before the
"opening roll, +0.0543 (in the case of Gnubg 0-ply)
"should be subtracted from (or in effect added to)
"the equity of the actual opening roll.

The clarification "(or in effect added to)" was added
exactly for this reason, (i.e. for rolls with less equity
than the average). Either I fail to express myself or
you fail to understand... :(

In short, there's certainly nothing wrong with what
GNUBG and XG are doing,

Maybe you can't understand because the apparent
effort you are making is just to prove yourself right.

Why do you think I used the 5-roll recycling to the
"opening position" in my arguments...?

Because I wanted to clearly illustrate how Gnubg
treats it wrongly both as "opening" and "recycled"
positions, while XG treats it wrongly as "opening"
position but correctly as "recycled" position.

Either you are in denial or you can't understand.

and it's a much more natural way to calculate luck
than what you're proposing.

I'm not trying to redefine "luck rate". I'm going by you
folks' definition that "luck "rate" is the "Deviation of
equity from average Roll"! And I'm demonstrating to
you folks that your garbage bots are implementing it
incorrectly!

MK

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

On 12/29/2022 6:56 PM, MK wrote:

I'm not trying to redefine "luck rate". I'm going by you
folks' definition that "luck "rate" is the "Deviation of
equity from average Roll"! And I'm demonstrating to
you folks that your garbage bots are implementing it
incorrectly!

Let me try one more angle. To make the numbers easier to grasp,
let's pretend that on the opening roll, we throw three-sided dice,
A, B, C, so that only six possible outcomes are possible: AB, AC,
BC, BA, CA, CB. Let's further assume that AB (respectively, AC,
BC) gives the winner an equity of +0.1 (respectively, +0.2, +0.3).
We can summarize this "pretend" version of backgammon in a table.

Roll: AB AC BC BA CA CB
Equity after opening roll: +0.1 +0.2 +0.3 -0.1 -0.2 -0.3
Luck of roll a la GNUBG: +0.1 +0.2 +0.3 -0.1 -0.2 -0.3
Luck of roll a la MK: -0.1 0.0 +0.1 +0.1 0.0 -0.1

The way GNUBG calculates the luck is that is notes that the equity
before the roll is 0.0, and it declares that the luck of (say) AC
is the equity after rolling AC (namely, +0.2) minus the equity before
the roll. It gets an answer of +0.2 - 0.0 = +0.2.

What MK is suggesting is this: we note that, conditioned on winning
the opening roll, the average equity gain is (+0.1+0.2+0.3)/3 = +0.2.
So, from GNUBG's calculation, we subtract 0.2 if we win the opening
roll and we add 0.2 if we lose the opening roll.

One can, of course, compute such a number, but despite MK's insistence,
it does not represent the deviation of equity from the average roll,
because there are *six possible rolls* and not just three. Just because
I win the opening roll in a particular game does not magically make the
three rolls where I didn't win the opening roll disappear, any more than
my rolling AB suddenly makes the winning rolls AC and BC disappear. The average of all six possible rolls is 0.0 and not 0.2.

Maybe the confusion stems from the stated convention that the *sign* of
the luck is chosen to reflect the perspective of the player who won the
opening roll. But all that means is that we have chosen to write the
second row as +0.1 +0.2 +0.3 -0.1 -0.2 -0.3 instead of -0.1 -0.2 -0.3
+0.1 +0.2 +0.3. It does not mean that all the minus signs get turned
into plus signs while the plus signs remain plus signs.

Having said all that, let's say for the sake of argument that there's
some line in the documentation that suggests that the luck is defined
according to the third row ("Luck of roll a la MK"). If that were the
case (which I claim it's not, but let's suppose), then I would argue
that it's the documentation that should be corrected, and not the way
the calculation is actually done. That is, the line "Luck of roll a
la MK" is extremely unintuitive and of no use that I can see. It makes
it seem that winning the opening roll with AB (which confers an equity
of +0.1, but has MK luck -0.1) is unluckier than losing the opening roll
with BA (which confers an equity of -0.1, but has MK luck +0.1). But
that grossly violates common sense. If my equity before the roll is 0.0
then a roll that confers an equity of +0.1 is surely luckier than a roll
that confers an equity of -0.1. Whatever flaws the GNUBG definition of
luck has are not as absurd as the flaws in the MK definition of luck.

---
Tim Chow

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

On December 26, 2022 at 4:30:49 AM UTC-7, MK wrote:

Player1
T-map for 31: +0.218 - +0.106 = +0.112
Luck total EMG (Points) +0.000 ( +0.000) +0.218 ( +0.218)
.....
## Gnubg doesn't subract the average eqity from the opening
## Luck should be +0.218 - +0.0543 = +0.1637
.....
Luck total EMG (Points) +0.407 ( +0.407) +0.378 ( +0.378)
.....
At this point, we have recycled back to opening position
.....
## Gnubg stil thinks this is the opening position/roll...!

Before I reply to anyone else tonight, I want to follow
up to my own article, to further clarify some things.

After recycling to the opening position, if we continue
to reroll the same 5 rolls again, with Player2 on roll at
the current position, at the end both luck rate and skill
rate numbers zero out nicely as they should, like this:

Error total EMG (Points) -0.883 ( -0.883) -0.883 ( -0.883)
Luck total EMG (Points) +0.785 ( +0.785) +0.785 ( +0.785)

So, here is a comparison of Gnubg and XG for fairness:

1- Calculating luck equities for non-opening position rolls.
Gnubg adjusts for average equity of position and the figures
are accurate per its definition of how it calculates luck.
XG doesn't adjusts for average equity of position but the
figures don't seem to be correct per its definition of how it
calculates luck, (i.e. they don't match the ones from its Dice
Distribution table generated using the same ply).

2- Calculating luck equities for initial opening position rolls.
Gnubg fails to adjust for average equity of the opening
position even though it's just like any other position with
an average equity of its own which exists before the roll.
XG correctly doesn't adjusts for average equity as it shouldn't.

3- Calculating luck equities for recycled opening position rolls.
Gnubg fails to realize that it's not the initial opening position
and thus fails again to adjust for average equity, (as a separate
error than for #2 above).
XG erroneously does adjusts for average equity even though it
shouldn't in this case either.

Even though they do it differently, I think that they are both
"garbage generators" causing about similar harmful results.

MK

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

On December 29, 2022 at 7:24:32 PM UTC-7, Tim Chow wrote:

On 12/29/2022 6:56 PM, MK wrote:

I'm not trying to redefine "luck rate". I'm going by you
folks' definition that "luck "rate" is the "Deviation of
equity from average Roll"! And I'm demonstrating to
you folks that your garbage bots are implementing it
incorrectly!

Let me try one more angle. To make the numbers
easier to grasp, let's pretend that on the opening
roll, we throw three-sided dice, A, B, C, so that .....

This is a good sign. :) When you start going berserk
and rampage about imaginary games like coin-toss
football, etc. I can tell you have started to understand
are refusing to accept the reality.

We have now graduated from imaginary interviews to
three-sided dice. If the pattern holds, you will next try
to make less of the subject by saying that everybody
already knew all those that I said, after that you may
even claim that it was all your idea to begin with... ;)

The way GNUBG calculates the luck is that is notes
that the equity before the roll is 0.0, and it ....

It wrongly makes an exception for a certain position
that we call "opening position" which has a non-zero
equity before any roll, based on a widespread fallacy.

What MK is suggesting is this: we note that, .....

Don't speak for me. I'm capable of explaining myself.

One can, of course, compute such a number, but .....

[much incoherent blather, inapplicable to real word
facts of backgammon snipped]

Whatever flaws the GNUBG definition of luck has are
not as absurd as the flaws in the MK definition of luck.

I'm not offering any new definition of luck. Gnubg's luck
definition is fine with me. I'm exposing that the flaw is
in Gnubg's implementing its own definition of luck.

BTW: the "silence of the RGB's sheep" is deafening... :)

MK

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

On 12/31/2022 6:59 AM, MK wrote:

I'm not offering any new definition of luck. Gnubg's luck
definition is fine with me. I'm exposing that the flaw is
in Gnubg's implementing its own definition of luck.

GNUBG is correctly implementing its own definition of luck.

The problem is that you don't understand that definition.

---
Tim Chow

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

On Saturday, 31 December 2022 at 15:17:06 UTC, Tim Chow wrote:

GNUBG is correctly implementing its own definition of luck.

The problem is that you don't understand that definition.

---
Tim Chow

I've posted here previously that when GnuDung doesn't land an 11-in-36 chance it bellyaches how unlucky it was.

No, not landing an 11-in-36 chance is entirely probable by definition. All you bad actors here *can* see that can't you?

Bonus question: how can you tell when GnuDung arrives by airplane? The whining goes on long after the pilot has shut down the engines.

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

On 12/31/2022 11:51 AM, Nasti Chestikov wrote:

No, not landing an 11-in-36 chance is entirely probable by definition. All you bad actors here *can* see that can't you?

If you had attended law school, you would know how to read GNU's
definition of luck, and would know that this situation matches
the definition. The definition may not accord with your common
sense, but the legal code is full of definitions that do not
accord with common sense---again, as you would know if you had
attended law school.

---
Tim Chow

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

On December 31, 2022 at 8:17:06 AM UTC-7, Tim Chow wrote:

On 12/31/2022 6:59 AM, MK wrote:

I'm not offering any new definition of luck.
Gnubg's luck definition is fine with me. I'm
exposing that the flaw is in Gnubg's
implementing its own definition of luck.

GNUBG is correctly implementing its own
definition of luck. The problem is that you
don't understand that definition.

I bothered to give you, (and all the bozos here),
a step by step proof of it because you sounded
like you were trying to understand it. If you are
unwilling or unable to follow my demonstration,
it's your loss and no amount of unsubstantiated,
inconsequential assertions will make up for it. :(

What is more interesting for me, however, is the
lack of any comments from the "Gnubg team"...
I know that many of them follow RBG but they
only respond to my posts to argue against me
and never to agree with me or to acknowledge
the undeniable facts that I present against them
and their bot.

I guess whoever duct taped the mouths of RGB
bozo's must have duct taped the mouths of the
Gnubg team also... ;) Well, actually it is sad... :(

MK

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

On 1/2/2023 8:43 PM, MK wrote:

I bothered to give you, (and all the bozos here),
a step by step proof of it because you sounded
like you were trying to understand it. If you are
unwilling or unable to follow my demonstration,
it's your loss and no amount of unsubstantiated,
inconsequential assertions will make up for it. :(

LOL. You wouldn't know a proof if it hit you in the face.

---
Tim Chow

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

On January 3, 2023 at 6:37:05 AM UTC-7, Tim Chow wrote:

On 1/2/2023 8:43 PM, MK wrote:

I bothered to give you, (and all the bozos here),
a step by step proof of it because you sounded
like you were trying to understand it. If you are
unwilling or unable to follow my demonstration,
it's your loss and no amount of unsubstantiated,
inconsequential assertions will make up for it. :(

LOL. You wouldn't know a proof if it hit you in the face.

What if I stuffed it in your inferiority complexed stupid
ass..? Would you know it then..? Here, (lines 243-246):

https://cvs.savannah.gnu.org/viewvc/gnubg/gnubg/analysis.c?r1=1.240&r2=1.241

After you enjoy it awhile, wipe it and hand it to Axel...

MK

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

On December 31, 2022 at 3:51:36 AM UTC-7, MK wrote:

On December 26, 2022 at 4:30:49 AM UTC-7, MK wrote:

Luck total EMG (Points) +0.407 (+0.407) +0.378 (+0.378)
At this point, we have recycled back to opening position

3- Calculating luck equities for recycled positions ...
Gnubg fails to realize that it's not the initial opening
position and thus fails again to adjust for average
equity, (as a separate error than for #2 above).

To that we need to add "unless the roll is a double!" :)

For example, if you roll a 31, it adds the raw equity of
the roll, i.e. +0.407 + +0.218 = +0.625 but if you roll a
44, it adds the "Deviation of equity from average Roll"
as the manual says, i.e. +0.407 + (+0.426 - +0.106) or
+0.407 + +0.320 = +0.727! Hah haaa! What a farce. :)

MK

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

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.

After discovering by luck :) that Gnubg calculated
the luck rate of rolls at "recycled initial positions",
I decided to take a peek at analysis.c and I couldn't
believe my eyes...! :) It said:

"extern float LuckAnalysis(const TanBoard.....
".....
"if (is_init_board && n0 != n1) /* FIXME: this fails if
"we return to the inital position after a few moves */
"return LuckFirst(anBoard, n0, n1, &ci, &ecLuck);
"else
"return LuckNormal(anBoard, n0, n1, &ci, &ecLuck);

Here, see for yourself (lines 243-246):

https://cvs.savannah.gnu.org/viewvc/gnubg/gnubg/analysis.c?r1=1.240&r2=1.241

An ugly bug waiting to be fixed for over nine years. :(

What is really disgusting, though, is that you had told
me "Read the source, Luke", by naming not only the
filen "analysis.c" but also the function "LuckAnalysis",
which obviously you yourself hadn't read, at least not
carefully, (unless you read but couldn't understand it).

What kind of conceited, arrogant assholes are you all
to talk down to others on subjects that you don't even
know as much about, throw obsolete manuals, source
codes, etc. at others when you haven't even read them
yourselves...!?

But don't you bozos worry none. I will patiently, dutifully
and tirelessly stuff you all where you belong...

MK

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

MK <murat@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.

I never managed to return to the initial position in real play, hence I
do not care about this exotic scenario. 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.

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. Irony now off.

My short collaboration with Philippe, when he implemented my
Isight method and had a couple of questions, was a pleasure and very constructive. It has been a while, Philippe, but thanks again anyway.
(:

Axel

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

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

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

MK <murat@compuplus.net> writes:

"if (is_init_board && n0 != n1)"

[...]

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.

This is clear from the code and means that the luck calculations are off
IFF the game returns to the initial positions AND a non-doublet is
rolled. So the "bug" (I am tempted to call this a limitation) frequency
is reduced by another 25/36.

In any case, Gnubg should calculate luck rate according to its
definition of it

I agree. Please let us know once you encounter this in real play.

Axel

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

On January 4, 2023 at 10:59:13 AM UTC-7, Axel Reichert wrote:

MK <mu...@compuplus.net> writes:

"if (is_init_board && n0 != n1)"

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.

This is clear from the code and means that the
luck calculations are off IFF the game returns to
the initial positions AND a non-doublet is rolled.
So the "bug" (I am tempted to call this a limitation)
frequency is reduced by another 25/36.

You are ridiculing yourself by trying to call a very
significant bug (in what it reveals) a "limitation" :)
in your efforts to make less of it.

You are wrong about the frequency also. Luck rate
calculations are wrong even at first initial position,
since it has an average equity like any other position.

I'm sure you understood what I tried to explain. No
use in playing dumb. My point was that not even a
"school boy of 12 years" would code such nonsense
but maybe there are 11 year olds among the Gnubg
team...

It's asinine to check if it's the initial position and if
the dice is a double because 1) No doubles at the
opening roll can get past Gnubg's dice rolling logic
and 2) There is no need to check for or do anything
special about doubles at any other position.

That's why it looks like a part of code, (with a bug),
which was intending to do something else, such as
calculating the "Deviation of equity from average Roll"
of rolls at different occurrences of the initial position
properly adjusting by either +0.106 or by +0.0543

In any case, Gnubg should calculate luck rate
according to its definition of it

I agree. Please let us know once you encounter
this in real play.

Surely. It happens at every first initial position of all
sessions and matches.

What we refer to as initial position is a position like
any other, with Position ID: 4HPwATDgc/ABMA and
has an average equity of +0.106 or +0.0543 based
on when it occurs during a game.

Since you can't paste just a position ID to Gnubg, add
to it an opening Match ID: cAkAAAAAAAAE and paste.

Do you remember how we were going into edit mode
to look at the temperature map of a first initial position
(because Gnubg is so fucking smart and advanced bot
to implement the fallacy that its equity is zero :) NOT!)
and prevent users from lookin at the equity map...?

Well, when you paste Position ID: 4HPwATDgc/ABMA
Match ID: cAkAAAAAAAAE

Ta da...! Like magic, you can look at the temperature
map like you can at any other position. :)

Making an exception of this position against Gnubg's
own definition of luck rate as the "Deviation of equity
from average Roll" is fallacy that was farted out almost
25 years ago, with its smell still lingering in the air... :(

MK

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

MK <murat@compuplus.net> writes:

What we refer to as initial position is a position like any other,
with Position ID: 4HPwATDgc/ABMA and has an average equity of +0.106
or +0.0543 based on when it occurs during a game.

Since you can't paste just a position ID to Gnubg, add to it an
opening Match ID: cAkAAAAAAAAE and paste.

... which is not the Match ID at the start of a money session, but the
Match ID during play. To see the difference, start new money sessions
until you (the player at the bottom) get the first roll. Then click
twice on the "Go to previous roll" button (blue left arrow). By then the
dice roll has vanished.

You will notice that the Position ID is the same as mentioned by you
above, but the Match ID is

cAgAAAAAAAAA

not

cAkAAAAAAAAE

See

https://www.gnu.org/software/gnubg/manual/html_node/A-technical-description-of-the-Match-ID.html

I suspect that bits 9 to 11 will be responsible for the difference (000
versus 001, but I did not check). Notice also that then no temperature
map is available.

Axel

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

On January 5, 2023 at 1:19:29 AM UTC-7, Axel Reichert wrote:

MK <mu...@compuplus.net> writes:

Since you can't paste just a position ID to Gnubg, add
to it an opening Match ID: cAkAAAAAAAAE and paste.

... which is not the Match ID at the start of a money
session, but the Match ID during play.

It depends on what you mean by "start".

To see the difference, start new money sessions until
you (the player at the bottom) get the first roll. Then
click twice on the "Go to previous roll" button (blue left
arrow). By then the dice roll has vanished.

I don't know how you do it but when I plays with things
like this, I set the dice to "manual" so that I can control
each step. With the dice on "manual", after you start a
session, when the dice dialog appears, just click "close"
or "clear dice" to accomplish the same thing that you
describe without rolling and then going back, etc.

You will notice that the Position ID is the same as
mentioned by you above, but the Match ID is
cAgAAAAAAAAA
not
cAkAAAAAAAAE
See .....
I suspect that bits 9 to 11 will be responsible for the
difference (000 versus 001, but I did not check).

Yes, "g" is game not started, "k" is game started.

Notice also that then no temperature map is available.

Yes, because no game is "not started" yet. When you
"start" a new session, the match ID displayed is
cAgAAAAAAAAA which means no game is started yet.

In the link you provided, they use the word "started". If
you try to paste cAgAAAAAAAAA, Gnubg warns that a
game is not in "progress" yet but complies anyway. The
terminologies they/we use can be/are confusing. :(

At that position, if you go into edit mode, Gnubg "starts"
the game and changes the match ID to cAkAAAAAAAAE
which stays the same after you get out of the edit mode.
That's where I copied the match ID from. Even though
nothing has happened yet, it considers a session/match
"started".

But all these "differences" due to bad/confusing usage
of words are not "real/consequential differences" that
make a difference for the sake of our discussion...

Do you have anything more substantial to say on the issue..?

MK

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

On 1/3/2023 5:08 PM, MK wrote:

On January 3, 2023 at 6:37:05 AM UTC-7, Tim Chow wrote:

On 1/2/2023 8:43 PM, MK wrote:

I bothered to give you, (and all the bozos here),
a step by step proof of it because you sounded
like you were trying to understand it. If you are
unwilling or unable to follow my demonstration,
it's your loss and no amount of unsubstantiated,
inconsequential assertions will make up for it. :(

LOL. You wouldn't know a proof if it hit you in the face.

What if I stuffed it in your inferiority complexed stupid
ass..? Would you know it then..? Here, (lines 243-246):

https://cvs.savannah.gnu.org/viewvc/gnubg/gnubg/analysis.c?r1=1.240&r2=1.241

After you enjoy it awhile, wipe it and hand it to Axel...

Ah, now *that* is interesting! Of course, it has nothing to do
with your "proof."

---
Tim Chow

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

On January 5, 2023 at 6:13:14 AM UTC-7, Tim Chow wrote:

On 1/3/2023 5:08 PM, MK wrote:

On January 3, 2023 at 6:37:05 AM UTC-7, Tim Chow wrote:

LOL. You wouldn't know a proof if it hit you in the face.

What if I stuffed it in your inferiority complexed stupid
ass..? Would you know it then..? Here, (lines 243-246):
https://cvs.savannah.gnu.org/viewvc/gnubg/gnubg/analysis.c?r1=1.240&r2=1.241 >> After you enjoy it awhile, wipe it and hand it to Axel...

Ah, now *that* is interesting! Of course, it has nothing
to do with your "proof."

As you have done dozens, if not hundreds of times
before, when your math leaves you with nothing to
say about the issue on hand, you switch to teaching
English, correcting gammar and pucntuation errors
of errors and such... :(

Okay, start by explaining why you put the word proof
in quotation marks and teach me/us all the different
usages/meanings of "proof" prof...

MK

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

On 1/5/2023 8:39 AM, MK wrote:

On January 5, 2023 at 6:13:14 AM UTC-7, Tim Chow wrote:

On 1/3/2023 5:08 PM, MK wrote:

On January 3, 2023 at 6:37:05 AM UTC-7, Tim Chow wrote:

LOL. You wouldn't know a proof if it hit you in the face.

What if I stuffed it in your inferiority complexed stupid
ass..? Would you know it then..? Here, (lines 243-246):
https://cvs.savannah.gnu.org/viewvc/gnubg/gnubg/analysis.c?r1=1.240&r2=1.241
After you enjoy it awhile, wipe it and hand it to Axel...

Ah, now *that* is interesting! Of course, it has nothing
to do with your "proof."

As you have done dozens, if not hundreds of times
before, when your math leaves you with nothing to
say about the issue on hand, you switch to teaching
English, correcting gammar and pucntuation errors
of errors and such... :(

Okay, start by explaining why you put the word proof
in quotation marks and teach me/us all the different
usages/meanings of "proof" prof...

For once, it has nothing to do with grammar.

What you were initially complaining about, and claimed to have a
"proof" of, had nothing to do with the "FIXME" that you later found.
Your own suggested "bug fix" does not implement the FIXME. You
were suggesting subtracting 0.0543 from the luck of the winner of
the opening roll. This has nothing to do with the FIXME bug, which
concerns what to do should the opening position happen to arise again
in the course of the game.

---
Tim Chow

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

On January 6, 2023 at 5:43:00 AM UTC-7, Tim Chow wrote:

For once, it has nothing to do with grammar.

Not with grammar but with what "proof" means. ;)

What you were initially complaining about, and
claimed to have a "proof" of, had nothing to do
with the "FIXME" that you later found.

Not true. Look at my ariginal post and find where I
had said: "## Gnubg stil thinks this is the opening
position/roll...!" (about 10 lines from the end). So, I
already knew that Gnubg was calculating luck rate
wrong during the game, in addition my argument
that it was calculating wrong during the opening roll.

Your own suggested "bug fix" does not implement
the FIXME. You were suggesting subtracting 0.0543
from the luck of the winner of the opening roll. This
has nothing to do with the FIXME bug, which concerns
what to do should the opening position happen to
arise again in the course of the game.

Both "bugs" were obvious to me and since I was able
to demonstrate them, (to prove my points that Gnubg
was calculating luck rate wrongly in both situations),
I didn't feel a need to look at the code.

When I discovered by chance that it calculated luck
correctly if doubles were rolled at the recycled initial
position, I realized that it was even worse than what
I had thought and only after that did I become curious
enough to look at the code to see how was it possible
for it to be so fascinatingly messed up...

I don't mind you guys' keeping underestimating me. It
makes it so much easier to exceed your expectations. ;)

MK

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

On 1/6/2023 2:08 PM, MK wrote:

On January 6, 2023 at 5:43:00 AM UTC-7, Tim Chow wrote:

What you were initially complaining about, and
claimed to have a "proof" of, had nothing to do
with the "FIXME" that you later found.

Not true. Look at my ariginal post and find where I
had said: "## Gnubg stil thinks this is the opening
position/roll...!" (about 10 lines from the end). So, I
already knew that Gnubg was calculating luck rate
wrong during the game, in addition my argument
that it was calculating wrong during the opening roll.

Ah, I see it now. You are correct. I didn't get as far as
that because I was focusing on the part of your "proof" that
was wrong.

---
Tim Chow

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

On January 7, 2023 at 6:34:46 AM UTC-7, Tim Chow wrote:

On 1/6/2023 2:08 PM, MK wrote:

On January 6, 2023 at 5:43:00 AM UTC-7, Tim Chow wrote:

What you were initially complaining about, and
claimed to have a "proof" of, had nothing to do
with the "FIXME" that you later found.

Not true. Look at my ariginal post and find where I
had said: "## Gnubg stil thinks this is the opening
position/roll...!" (about 10 lines from the end).

Ah, I see it now. You are correct.

Yes I am. And I was from the beginning.

I didn't get as far as that because I was focusing
on the part of your "proof" that was wrong.

When you don't have enough brains to focuc on
what matters, you start focusing on definitions
of words, grammar and punctuation errors, etc.
just like I said before.

Okay, go ahead and knock yourself out. Show
me your superior mastery of English by defining
"proof" however to suit yourself and then show
me "the part of my proof that was wrong" which
you were focusing on... ;)

Inferiority complexed, pathetic prof... :(

MK

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