XG kicks itself for a whopper

[Timothy Chow]

XG has a certain bug that manifests itself in an unpredictable manner.
Here is one example that I found particularly hilarious. XG told
itself that its cube action was a whopper, when in fact there was
exactly zero equity at stake.

http://timothychow.net/cg/whopper.jpg

---
Tim Chow

[Stick Rice]

My XG does not do this. My guess is during the game your computer was doing other things and caused the hiccup as we've seen many times before. Always have to double check oddities like this in another instance of XG.

Stick

[MK]

On July 21, 2022 at 10:28:46 PM UTC-6, Stick Rice wrote:

> On July 21, 2022 at 10:31:46 PM UTC-4, Tim Chow wrote:

>> XG has a certain bug that manifests itself in .....
>> http://timothychow.net/cg/whopper.jpg

> My XG does not do this.

Hmmm. Maybe there are some undocumented versions
of XG out there just like I had suspected once ago... :)

> My guess is during the game your computer was doing
> other things and caused the hiccup as we've seen many
> times before. Always have to double check oddities like
> this in another instance of XG.

It's not a hiccup. It's actually worse than how Tim put it.
You may need to do more than double check "your XG".

Here are a series of checks:
========================================
Analyzed in 2-ply
Player Winning Chances: 0.02% (G:0.00% B:0.00%)
Opponent Winning Chances: 99.98% (G:99.98% B:6.02%)
Cubeless Equities: No Double=-2.963, Double=-2.962
Cubeful Equities:
No redouble: -2.963 (0.000)
Redouble/Take: -2.962
Redouble/Pass: +1.000 (+3.962)
Best Cube action: Redouble / Take
========================================
Analyzed in 3-ply
Player Winning Chances: 0.00% (G:0.00% B:0.00%)
Opponent Winning Chances: 100.00% (G:99.98% B:6.02%)
Cubeless Equities: No Double=-2.963, Double=-2.964
Cubeful Equities:
No redouble: -2.963
Redouble/Take: -2.964 (0.000)
Redouble/Pass: +1.000 (+3.963)
Best Cube action: No redouble / Take
========================================
Analyzed in XG Roller
Player Winning Chances: 0.00% (G:0.00% B:0.00%)
Opponent Winning Chances: 100.00% (G:100.00% B:0.00%)
Cubeless Equities: No Double=-2.964, Double=-2.964
Cubeful Equities:
No redouble: -2.964 (0.000)
Redouble/Take: -2.964
Redouble/Pass: +1.000 (+3.964)
Best Cube action: No redouble / Take
========================================
Analyzed in 4-ply
Player Winning Chances: 0.02% (G:0.00% B:0.00%)
Opponent Winning Chances: 99.98% (G:99.98% B:6.02%)
Cubeless Equities: No Double=-2.963, Double=-2.963
Cubeful Equities:
No redouble: -2.963 (0.000)
Redouble/Take: -2.963
Redouble/Pass: +1.000 (+3.963)
Best Cube action: Redouble / Take
========================================
Analyzed in XG Roller+
Player Winning Chances: 0.00% (G:0.00% B:0.00%)
Opponent Winning Chances: 100.00% (G:100.00% B:2.31%)
Cubeless Equities: No Double=-2.964, Double=-2.964
Cubeful Equities:
No redouble: -2.964
Redouble/Take: -2.964
Redouble/Pass: +1.000 (+3.964)
Best Cube action: No redouble / Take
========================================

In this instance, Gnubg seems to be the better bot. Even
though it estimates backgammon chances increasingly
at higher levels, (from 5.6 to 5.7 to 5.9 to 6.0), at least it
consistently says "Optional redouble, take" at all of its
preset levels, from the lowest to the highest.

Even if referring to what he calls a "bug", Tim's using the
word "unpredictable" talking about a gamblegammon bot
is noteworthy! You all should ponder on how far can the
implications of it go in destroying your fantasies about
super-human bots along with cube skill, PR, etc. bullshit...

MK

[Timothy Chow]

As is so often the case, we've been through this before. My copy of
XG doesn't do this consistently either. That's why I said
"unpredictable." You've also presented your theory about the
"computer doing other things." The computer is always doing
"other things." I do very little on my computer, especially when
I'm running an analysis. Do you know anything about how modern
computer operating systems handle multitasking? I suspect that you
know much less than I do. That is not a credible explanation of
this XG bug.

---
Tim Chow

[Stick Rice]

"Suspect" - have an idea or impression of the existence, presence, or truth of (something) without certain proof. Synonym: Assume.

Stick

[Nasti Chestikov]

On Friday, 22 July 2022 at 14:08:51 UTC+1, Tim Chow wrote:

> As is so often the case, we've been through this before. My copy of
> XG

> ---
> Tim Chow

The only available version of XG I can find is 2.10...........how do you guys manage to run with a version of 2.19 beta?

[MK]

On September 3, 2022 at 11:28:03 AM UTC-6, Nasti Chestikov wrote:

> The only available version of XG I can find is 2.10 how

> do you guys manage to run with a version of 2.19 beta?

It was announced in some forums over 7 years ago.

http://www.bgonline.org/forums/webbbs_config.pl?read=174103

It provided a direct link to download 2.19.208 beta.

I just tried it. It still works but may not in the future.
So I suggest anyone interested should download it
for archival purposes, if nothing else, before Trump
takes it to Mar-a-Swampo... ;)

MK

[Nasti Chestikov]

Thanks, I have snagged it, I think I have used up my trial period on this pc so will need the help of TimeFreeze to be able to run it forever on my other device.

When the author gets around to releasing a 2022 version I'll buy it.

[Frank Berger]

smells like a race condition (or the like). For non programmers: if you use several cores you have to carefully control that writing of values is strictly coordinated. Human brains are not good at writing concurrennt code. It happens unpredictable, what makes it a night mare to find the reason. The more cores your computer has and the more agressive the CPU optimizes (e.g. ARM is far more agressive than X64) the more often it happens.

best
Frank

[MK]

On September 4, 2022 at 8:17:23 AM UTC-6, Nasti Chestikov wrote:

> Thanks, I have snagged it, I think I have used up my
> trial period on this pc so will need the help of Time
> Freeze to be able to run it forever on my other device.

It uses a common protection software called Asprotect
which functions by leaving hidden registry keys behind
after expiration and uninstalling, which I consider breach
of trust and invasion of privacy by a sort of "wiretapping".

Without being specific about XG, I explained in the past
how to delete those keys in general. After that, one can
keep "trying" a software protected by Asprotect forever
without repeating the entire process but by just deleting
two registry keys. Search RGB for "Asprotect". Fins and
download Trashreg previous v.3.9.3 which I used without
issues but my virus scan says that the latest v.3.9.4 may
have malware. Use any such software at your own risk!

> When the author gets around to releasing a 2022 version
> I'll buy it.

I intend to do the same ;) but many years ago I had already
predicted that there would never be another release of XG.
So, I set aside my $50 but I'm not holding my breath... :( It
seems to be abandoned like all other gamblegammon bots
have been thus far. (Contrast that to chess bots that have
been around and been updated for many decades. It must
be something to do with gg bots being gambling tools.(?))

MK

[MK]

On September 4, 2022 at 1:13:36 PM UTC-6, bgbl...@googlemail.com wrote:

> Tim Chow schrieb am Freitag, 22. Juli 2022 um 04:31:46 UTC+2:

>> XG has a certain bug that manifests itself in an unpredictable
>> manner. Here is one example that I found particularly hilarious.

>> http://timothychow.net/cg/whopper.jpg

I would like to understand this. Do you mean you have set up
the same position several times and got different results?

> smells like a race condition (or the like). For non programmers:
> if you use several cores you have to carefully control that writing
> of values is strictly coordinated. Human brains are not good at
> writing concurrennt code. It happens unpredictable, what makes
> it a night mare to find the reason. The more cores your computer
> has and the more agressive the CPU optimizes (e.g. ARM is far
> more agressive than X64) the more often it happens.

Can you summarize your blabber in an answer to the same/similar
question to you: If you set up the same position several times on a
X64 or ARM CPU, using the same version of XG as Chow, are you
getting different/unpredictable results each time?

MK

[Timothy Chow]

Almost all the time, the same evaluation is obtained. Once in a very
long while, usually when I ask XG to analyze an entire match, a
different evaluation emerges. Frank's suggestion of a race condition
is a plausible one. It wouldn't shock me if Xavier deliberately wrote
some non-thread-safe code in order to achieve faster performance,
figuring that the occasional "misevaluation" would not be a disaster,
and would be worth the extra speed.

---
Tim Chow

[MK]

On September 5, 2022 at 8:01:20 AM UTC-6, Tim Chow wrote:

> On 9/5/2022 6:04 AM, MK wrote:

>> On September 4, 2022 at 1:13:36 PM UTC-6, bgbl...@googlemail.com wrote:

>>> Tim Chow schrieb am Freitag, 22. Juli 2022 um 04:31:46 UTC+2:

>>>> http://timothychow.net/cg/whopper.jpg

>> I would like to understand this. Do you mean you have set up
>> the same position several times and got different results?

>>> smells like a race condition (or the like). For non programmers:

>>> if you use several cores you have to carefully control that.....

>> Can you summarize your blabber in an answer to the same/
>> similar question to you: If you set up the same position several
>> times on a X64 or ARM CPU, using the same version of XG as
>> Chow, are you getting different/unpredictable results each time?

> Almost all the time, the same evaluation is obtained.
> Once in a very long while, usually when I ask XG to
> analyze an entire match, a different evaluation emerges.

Evaluating a position during a game is different than
analysing an entire match. It looks like you are trying to
muddy the subject by blending the two.

Does the "almost all the time" apply separately to each
or to both? (i.e. "all the time" evaluating the position and
"almost all the time" analysing the entire match, so that
by mixing up the two it becomes true to say "almost all
the time" about evaluating the position also??)

> Frank's suggestion of a race condition is a plausible one.

It's nice of you to answer for him too... ;)

> It wouldn't shock me if Xavier deliberately wrote some
> non-thread-safe code in order to achieve faster performance,

Instead of inventing stories, it would be very easy to test
this with a simple position evaluation like this one which
takes a fraction of a second. You can just set XG's number
of threads to 1 and click click click a few dozen times in a
few minutes to find out the answer.

Being the one who instigated this discussion, I expect you
would want to know, right?

> figuring that the occasional "misevaluation" would not be
> a disaster, and would be worth the extra speed.

While placing so much trust in XG's evaluations/rollouts,
and occasionally pointing out errors like this one, I can't
believe that you can shrug it off so easily. Especially when
apparently you guys even do bet money on guessing the
best moves in some positions and settling the bet based
on XG's evaluations...

Who knows how many more such "hiccups" you guys never
get to notice? Regardless of the actual reason/s for such
errors, for a commercial product with big promises, claims
and so much hype, they should be unacceptable.

But amazingly, your brains activate mechanisms of denial
and self-deception in order to maintain your addictions... :(

MK

[peps...@gmail.com]

Which books (or websites) on operating systems do you recommend?
Have you read Tannenbaum/Bos (or something similar)?

How about Computer Systems: A programmer's perspective by Bryant and O'Halloran?
Is that a good book? It has been highly recommended to me.

Can you provide some indication of your level of knowledge and what you did to reach it?
I feel it's a near certainty that you know more about this than me and I feel it would help my career to know it.

Paul

[peps...@gmail.com]

Would it be worth Xavier's while to pay someone to fix the bug?
(That person wouldn't be me or anyone else I know -- it's just what people
often do, if it's economically feasible).

Paul

[Timothy Chow]

On 9/6/2022 6:45 AM, peps...@gmail.com wrote:
> Which books (or websites) on operating systems do you recommend?
> Have you read Tannenbaum/Bos (or something similar)?
>
> How about Computer Systems: A programmer's perspective by Bryant and O'Halloran?
> Is that a good book? It has been highly recommended to me.
>
> Can you provide some indication of your level of knowledge and what you did to reach it?
> I feel it's a near certainty that you know more about this than me and I feel it would help my career to know it.

Unfortunately I don't have good books to recommend. I learned
most of what I learned from lectures and tutorials provided by
colleagues, and indirectly from participating in programming
projects.

My forte is math and not software engineering or operating systems,
but I know enough to recognize that a bug like this is not caused
by the computer "doing other things."

---
Tim Chow

[Timothy Chow]

On 9/5/2022 10:15 PM, MK wrote:
> Instead of inventing stories, it would be very easy to test
> this with a simple position evaluation like this one which
> takes a fraction of a second. You can just set XG's number
> of threads to 1 and click click click a few dozen times in a
> few minutes to find out the answer.

Please go ahead and tell me the answer. It would take less time
for you than typing out your post.

---
Tim Chow

[Frank Berger]

MK schrieb am Montag, 5. September 2022 um 12:04:54 UTC+2:

> Can you summarize your blabber in an answer to the same/similar
> question to you: If you set up the same position several times on a
> X64 or ARM CPU, using the same version of XG as Chow, are you
> getting different/unpredictable results each time?

Given that you claimed yourself recently a top SW developer (I don't remeber the exact words but that was the meaning) this post seems a bit weird (and a we very funny communication style). At least I thought it wouldn't be to difficult to google or look at wikipedia ( https://en.wikipedia.org/wiki/Race_condition ).

It means if you setup the position a thousand times you might get 1000 times the same result... or only 999 times or 998 times. That makes it a nightmare to fix. I had such an issue a long time ago where it happened to every 1 or 2 month. Fortunately (for me not for him) I had an user where it happened several times a day so I could find out what happens.

[Frank Berger]

peps schrieb am Dienstag, 6. September 2022 um 12:45:22 UTC+2:

> Which books (or websites) on operating systems do you recommend?
> Have you read Tannenbaum/Bos (or something similar)?

All Tanenbaum books I read were good reads.

> How about Computer Systems: A programmer's perspective by Bryant and O'Halloran?
> Is that a good book? It has been highly recommended to me.

I just checked it, seems like a very interesting book, but doesn't look that it addresses that issues.
If you programm Java this would be my recommendation: Brian Goetz: "Java Concurrency in Practice " Even old (2006) it is an recellent read, thorough AND easy to understand, a rare combination. One of the best books in that decade for the Java stuff.

> Can you provide some indication of your level of knowledge and what you did to reach it?
> I feel it's a near certainty that you know more about this than me and I feel it would help my career to know it.

Several books. Books seems to be very old school nowaydays, but you can't get deep knowledge by a 15 minute youtube lesson.

[MK]

On September 6, 2022 at 6:56:49 AM UTC-6, Tim Chow wrote:

> On 9/5/2022 10:15 PM, MK wrote:

>> Instead of inventing stories, it would be very easy

>> ..... few minutes to find out the answer.

> Please go ahead and tell me the answer. It would
> take less time for you than typing out your post.

True but it would have taken you even lesser time
than inventing your stories.

Let me ask you a different question: if I know the
answer but I don't want to tell you, will you then
never be able to know it and share it with your ilk?

MK

[MK]

On September 6, 2022 at 12:21:32 PM UTC-6, bgbl...@googlemail.com wrote:

> MK schrieb am Montag, 5. September 2022 um 12:04:54 UTC+2:

>> If you set up the same position several times on a X64
>> or ARM CPU, using the same version of XG as Chow,
>> are you getting different/unpredictable results each time?

> Given that you claimed yourself recently a top SW developer

Irrelevant to what asked you.

> wikipedia ( https://en.wikipedia.org/wiki/Race_condition ).

Definition of race condition doesn't answer my question as
to whether it is indeed causing the XG "bug".

> It means if you setup the position a thousand times you might
> get 1000 times the same result... or only 999 times or 998 times.

I already knew that also. I asked if you ran Chow's position
1,000 times to see how many times it happens.

> That makes it a nightmare to fix. I had such an issue a long
> time ago where it happened to every 1 or 2 month. Fortunately
> (for me not for him) I had an user where it happened several
> times a day so I could find out what happens.

Okay, now, this can be useful if you could tell more about it,
i.e. what was the bug? what was the cause you had found?
were you able to fix it? if yes, how did you fix it? etc. I would
be willing to spend time to learn from specific examples but
not to waste time on vague bullshit (beyond the time I waste
to expose it).

MK

[Timothy Chow]

Ilks.

---
Tim Chow

[MK]

On September 6, 2022 at 8:59:39 PM UTC-6, Tim Chow wrote:

> Ilks.

A+

You passed the test :)

MK

[Frank Berger]

MK schrieb am Mittwoch, 7. September 2022 um 02:49:40 UTC+2:

> > Given that you claimed yourself recently a top SW developer
> Irrelevant to what asked you.

Maybe for you, but for others this might be an interesting information

> > It means if you setup the position a thousand times you might
> > get 1000 times the same result... or only 999 times or 998 times.
> I already knew that also.

You hid that at least to me...

>I asked if you ran Chow's position
> 1,000 times to see how many times it happens.

Why I should waste my time for that? It could easily be once in 10.000 or 100.000. I had once an error that occured once in 6,500,000 cases (luckily reproducable). Testing manually doesn't seems to be a clever way to collect that kind of information.
And even if you find out that this position is wrongly evaluated 3 in 10.000 times (ignoring that other influences in a multitasking OS can influence that, an incoming mail, the movement of the mouse etc.) what do you learn from that?

> Okay, now, this can be useful if you could tell more about it,
> i.e. what was the bug? what was the cause you had found?
> were you able to fix it?

Sure. I fix every bug I can reproduce. The cause was the usual: unsynchronized writing acces to a memory location. (A bit more useless information: I did understand the need to snchronize access quite well, but I grossly underestimated visibilty issues (i.e. thread 1 write a variable but thread 2 never sees the value). When I learned about concurrent programming you usually had or or at most 2 cores and old non aggressive x64 architectures. There visibility issues happens never (1 core) or very very rare. With 24 cores on todays x64 or ARM-CPUs this happens much more often...

> if yes, how did you fix it? etc. I would
> be willing to spend time to learn from specific examples but
> not to waste time on vague bullshit (beyond the time I waste
> to expose it).

I'm a bit puzzled? What would you learn from one specific bug in my code that wont occur in any other program? If you want to learn about concurrent programming a textbook (like the one I mentioned) is the way to go.

[peps...@gmail.com]

On Tuesday, September 6, 2022 at 1:54:36 PM UTC+1, Tim Chow wrote:
> On 9/6/2022 6:45 AM, peps...@gmail.com wrote:
> > Which books (or websites) on operating systems do you recommend?
> > Have you read Tannenbaum/Bos (or something similar)?
> >
> > How about Computer Systems: A programmer's perspective by Bryant and O'Halloran?
> > Is that a good book? It has been highly recommended to me.
> >
> > Can you provide some indication of your level of knowledge and what you did to reach it?
> > I feel it's a near certainty that you know more about this than me and I feel it would help my career to know it.

....

>
> My forte is math and not software engineering or operating systems,

...

Do you often feel overwhelmed with a penchant to delve into the more mathematical aspects of computing then --
for example Knuth's Art of Computer Programming, Von Neumann's monograph The Computer and The Brain,
and John Conway's book, Regular Algebra and Finite Machines?
As for me, I haven't read any of these three, but I've dipped into them.

Paul

[Timothy Chow]

On 9/7/2022 3:58 PM, peps...@gmail.com wrote:
> Do you often feel overwhelmed with a penchant to delve into the more mathematical aspects of computing then --
> for example Knuth's Art of Computer Programming, Von Neumann's monograph The Computer and The Brain,
> and John Conway's book, Regular Algebra and Finite Machines?

I do consult Knuth's TAOCP from time to time. I have a couple
of publications in theoretical computer science.

---
Tim Chow

[MK]

I was trying to make you see your problem with irrelevantly
questioning my knowledge and abilities, instead of proving
your own knowledge and abilities by giving relevant answers
to my questions.

Everything you said in your response was general, generic
stuff. Considering the number of computers and software
out there, if thread safety, etc. were as common problems
as before or as you guys are trying to depict, there would
be constant malfuntioning and a total mess in the IT world.

Fortunately, modern processors, operating systems and
languages are as thread safe as they can be, except maybe
for the sloppy, hacky programming by people like you, in
order to compromise safety for speed, so that you can claim
that your bot or someone else's bot is faster than some others.

At this stage, I really don't have much to benefit from learning
from wiki definitions or books about programming. I asked
you about a specific bug in your program for what it would
expose about you, not for what I would learn from it...

MK

[Timothy Chow]

On 9/12/2022 4:33 AM, MK wrote:
> Everything you said in your response was general, generic
> stuff. Considering the number of computers and software
> out there, if thread safety, etc. were as common problems
> as before or as you guys are trying to depict, there would
> be constant malfuntioning and a total mess in the IT world.

There *is* constant malfunctioning and a total mess in the
IT world. What rock have you been living under?

> Fortunately, modern processors, operating systems and
> languages are as thread safe as they can be, except maybe
> for the sloppy, hacky programming by people like you, in
> order to compromise safety for speed, so that you can claim
> that your bot or someone else's bot is faster than some others.

The tools for thread safety are certainly there. But operating
systems and software are getting increasingly complicated, so
the potential for bugs remains high.

Having said that, I do agree that for an individual application
like a backgammon bot, implementing thread safety should not be
hugely difficult, *if* you make it a top priority.

---
Tim Chow

[MK]

On September 12, 2022 at 7:01:49 AM UTC-6, Tim Chow wrote:

> On 9/12/2022 4:33 AM, MK wrote:

>> Considering the number of computers and software
>> out there, if thread safety, etc. were as common
>> problems as before or as you guys are trying to depict,
>> there would be constant malfuntioning and a total
>> mess in the IT world.

> There *is* constant malfunctioning and a total mess in
> the IT world. What rock have you been living under?

Do you mean for other than thread safety type problems,
like data security holes, googols of Android apps spewed
by teenage "software developers", etc. If you can expand
on it a little, I mat very well agree with you at least in part.

>> Fortunately, modern processors, operating systems
>> and languages are as thread safe as they can be,

>> except maybe for the sloppy, hacky programming .....

> The tools for thread safety are certainly there.

Yes, one almost needs to try on purpose to break them.

> operating systems and software are getting increasingly
> complicated, so the potential for bugs remains high.

The problem is not the complexity. As practically unlimited
memory and storage became cheaply available, almost all
software became "bloatware" (i.e. piles of mess) to various
degrees, along with "too many cooks in the kitchen".

Take Gnubg, for example. The installation has almost 7,000
files in about 700 folders. Among the so many people who
contribute to the project, none appear to have a sufficient
general understanding of the code, let alone mastery of it.
(I'm not trying to fault them but just making an observation)

> Having said that, I do agree that for an individual application
> like a backgammon bot, implementing thread safety should
> not be hugely difficult, *if* you make it a top priority.

Many people, including you, repeatedly argued over the years
that accuracy should be the most important thing in bots
because the "gamblegammon giants" are measured against
them, if for no other better reason.

It looks like bot developers made efforts to the opposite. For
example, I repeatedly questioned XG's making multi-threaded
calls to external dice DLL's but we haven't heard a peep from
any of the amateur/professional programmers, especially bot
developers. Yet, they don't miss any opportunity to accuse me
of conspiracy theories because I raise such questions.

MK

[Timothy Chow]

On 9/13/2022 5:43 AM, MK wrote:
> Many people, including you, repeatedly argued over the years
> that accuracy should be the most important thing in bots
> because the "gamblegammon giants" are measured against
> them, if for no other better reason.

Show me when I have argued this.

If you actually look up what I have said, you'll see that I have
repeatedly argued *against* taking PR too seriously.

I'm quite sure that I have *never* argued that "accuracy should be
the most important thing in bots."

---
Tim Chow

[MK]

On September 13, 2022 at 6:24:29 AM UTC-6, Tim Chow wrote:

> On 9/13/2022 5:43 AM, MK wrote:

>> Many people, including you, repeatedly argued over the
>> years that accuracy should be the most important thing
>> in bots because the "gamblegammon giants" are
>> measured against them, if for no other better reason.

> If you actually look up what I have said, you'll see that I
> have repeatedly argued *against* taking PR too seriously.

Yes, you have repeatedly said that also but it's a different
matter. You never acknowledged underlying reasons that
make PR "something to be not taken seriously" (I consider
PR to be less than that, in fact, totally meaningless/useless
but I didn't want to put words in your mouth).

> I'm quite sure that I have *never* argued that "accuracy
> should be the most important thing in bots."

I wasn't quoting anyone but was trying to make a cover-all
statement, in one sentence, about many comments made
by many people, including you and your comments along
the same lines.

Still, I felt I owed you a response. I don't have photographic
memory to remember who all said exactly what but here is
a thread I found in a quick minute, in which several people
made comments indicating that they took it seriously and
thought the bug should be fixed:

http://www.bgonline.org/forums/webbbs_config.pl?read=184518

Your comments in this post and the fact that you bothered
to report it are interesting:

http://www.bgonline.org/forums/webbbs_config.pl?read=184547

But what is more relevant as an answer to your request is
what you said in this post:

http://www.bgonline.org/forums/webbbs_config.pl?read=184523

Let me quote for readers' covenience:

"This bug is nothing more than a minor annoyance to me
"personally, but nowadays when people are using XG to
"award master/grandmaster titles and such, probably this
"bug should be fixed.

I hope you will agree that this (deja-vue) is good enough for my
bundling you in my cover-all statement...?

I won't spend more time on this but let us know if you happen
to remember more examples yourself.

MK

[Timothy Chow]

On 9/13/2022 3:22 PM, MK wrote:
> On September 13, 2022 at 6:24:29 AM UTC-6, Tim Chow wrote:
>
>> On 9/13/2022 5:43 AM, MK wrote:
>
>>> Many people, including you, repeatedly argued over the
>>> years that accuracy should be the most important thing
>>> in bots because the "gamblegammon giants" are
>>> measured against them, if for no other better reason.

>> I'm quite sure that I have *never* argued that "accuracy
>> should be the most important thing in bots."

> Let me quote for readers' covenience:
>
> "This bug is nothing more than a minor annoyance to me
> "personally, but nowadays when people are using XG to
> "award master/grandmaster titles and such, probably this
> "bug should be fixed.
>
> I hope you will agree that this (deja-vue) is good enough for my
> bundling you in my cover-all statement...?

I still think your original statement is misleading, because I
have never argued (much less "repeatedly") that accuracy
should be "the most important thing." But thank you for
taking the time to clarify your statement. The quote you found,
I still stand by.

---
Tim Chow

[MK]

On September 14, 2022 at 3:48:12 AM UTC+2, Tim Chow wrote:

> I still think your original statement is misleading,

Okay, I'll give in. Trying to say too much in too few
words wasn't so bad but I'll agree that naming you
among a crowd of many made it confusing as to
what you said. Happy now?

> because I have never argued (much less "repeatedly")
> that accuracy should be "the most important thing."
> But thank you for taking the time to clarify your
> statement. The quote you found, I still stand by.

Good enough.

MK

[Frank Berger]

MK schrieb am Montag, 12. September 2022 um 10:33:39 UTC+2:
> On September 7, 2022 at 1:52:57 PM UTC-6, bgbl...@googlemail.com wrote:
>
> Everything you said in your response was general, generic
> stuff.

Sure. I don't have access to XG source code so how can I more specific? To my code see below.

>Considering the number of computers and software
> out there, if thread safety, etc. were as common problems
> as before or as you guys are trying to depict, there would
> be constant malfuntioning and a total mess in the IT world.

If you don't use multiple threads you don't run in problems and astonshingly many programs don't use multiple threads. E.g. take GnuBG, set ply to 4 and look how many cores are used. (game play, not analysis: spoiler 1)

>
> Fortunately, modern processors, operating systems and
> languages are as thread safe as they can be,

If that statement would be true, why there are lots of buffer overruns, use after free and the like, errors much easier to avoid then a race condition?
And C, as an example is thread safe? ROTFL. This are the statements that make me recommend you a text book.

>except maybe
> for the sloppy, hacky programming by people like you,

Did you made a code review? Oh I forgot, to take your offending communication style into account.

> in
> order to compromise safety for speed, so that you can claim
> that your bot or someone else's bot is faster than some others.

If synchronization is done right it often doesn't cost much performance(more or less, very context specific). I strongly assume that Xavier wont do such a stupid thing (like gaining 1% perfomance for a bug) and I know I wouldn't do it either.

> At this stage, I really don't have much to benefit from learning
> from wiki definitions or books about programming.

Your comments show you're wrong, see above.

>I asked
> you about a specific bug in your program for what it would
> expose about you, not for what I would learn from it...

I simply see no sense to waste time, dig in my records, what bug I fixed a couple of years ago nor how you would gain about that description.

[MK]

On September 15, 2022 at 12:29:19 AM UTC+2, bgbl...@googlemail.com wrote:

> MK schrieb am Montag, 12. September 2022 um 10:33:39 UTC+2:

>> Everything you said in your response was general,
>> generic stuff.

> Sure. I don't have access to XG source code so how
> can I more specific? To my code see below.

You can't see XG code but you can see Tim's example,
can't you? Here it is for you again:

http://timothychow.net/cg/whopper.jpg

The problem (or bug) is very specific. XG's wrong cube
advice and cube error don't match the winning chance
of 0.00% which correct.

But that didn't keep you from carelessly speculating that
it could be due to race condition.

Have you looked at the 5 examples of evaluations of the
same position at different ply levels? Two of them give
the same cube advice but don't duplicate Tim's example.
To the contrary, the bad cube advice there are due to the
winning chances being calculated wrongly as 0.02%

Those could be due to race condition, except that they
could be duplicated consistently.

Without knowing what you were talking about, (whether
you make any efforts to do or not), you just muddied the
discussion.

Tim's example may be due to XG's comparing the winning
chance before rounding (which may be >0) and displaying
it after rounding (to 0.00)

My examples may be the wrong cube decisions based on
bad formulas giving inconsistent results at different plies.

It was claimed that XG was initially based on Gnubg code
but that later it was completely reprogrammed in Delphi.
Personally I'd never believe that any software developer
would throw away an entire code and start from zero. My
guess is that XG's bugs (many others like inconsistent
resigning, etc.) may be due to bad blending of borrowed
code and later translating it to another language which
could make the old bugs worse and introduce new ones.

> If you don't use multiple threads you don't run in problems
> and astonshingly many programs don't use multiple threads.

Maybe they don't need to.

> E.g. take GnuBG, set ply to 4 and look how many cores are
> used. (game play, not analysis: spoiler 1)

So? Maybe they don't do it because they can't do it safely
or for any other reasons that they may have. Contrast it
to XG's making multiple, multi-threaded calls to external
dice DLL's (Which all of you have so far avoided saying a
single word about it, despite my bringing it up repeatedly.
Maybe it's an undocumented feature of the Delphi..? :)

>> Fortunately, modern processors, operating systems
>> and languages are as thread safe as they can be,

> If that statement would be true, why there are lots of buffer
> overruns, use after free and the like, errors much easier to
> avoid then a race condition?

You said it. Buffer overruns, use after free and the like can
be avoided by good coding which is the programmer's job.

> And C, as an example is thread safe? ROTFL. This are the
> statements that make me recommend you a text book.

No tool is safe in the hands of the people who don't know
how to use them. Take your advice and read those books.

Your attitude is typical of some people who cause a car
accident and blame the car, the road, the weather, etc.
but never their own bad driving...

MK

[Frank Berger]

This advice seems a little bizarre for someone who claimed: "I really don't have much to benefit from learning

from wiki definitions or books about programming"

Reading textbooks may be old fashioned, but the only way I see to get thorough understanding, therefore I might have read more than 800-1000 CS-textbooks in my life but at least 600+

BTW I know what IEEE-format is and I was only surprised that 12/6 in C++ is 1.99999.. in the very early years in my professional life.
The textbook I would recommend: Mak: The Java Programmer's Guide to Numerical Computing . Very interesting, not to dry, but sure in this stage....

> Your attitude is typical of some people who cause a car
> accident and blame the car, the road, the weather, etc.
> but never their own bad driving...

I don't know what goes wrong between your reading and your understanding, but I know that the errors in my programs are 99,999% my fault and I'm the only one to blame and I can't see that I have anyone else blamed. Omitting Quick-C from Microsoft and Notes Lotusscript on OS/2 which were very buggy, I believe at most I need one hand where the fault was in OS, compiler, libs and the like....

[Timothy Chow]

On 7/21/2022 10:31 PM, I wrote:
> XG has a certain bug that manifests itself in an unpredictable manner.

> Here is one example that I found particularly hilarious.  XG told

> itself that its cube action was a whopper, when in fact there was
> exactly zero equity at stake.
>
> http://timothychow.net/cg/whopper.jpg

Here's another instance of the same phenomenon. Zero equity at stake,
but XG says it made a 0.186 error.

http://timothychow.net/cg/whopper2.jpg

---
Tim Chow

[Philippe Michel]

Are these errors unpredictable but reproducible: the same position
always gets the same wrong evaluations ?

If this is the case you may want to check the detailed single wins /
gammons / backgammon numbers. It looks like the "wrong" moves in
this second position are evaluated as if they lose some backgammons.

From what I can see with gnubg, it seems difficult (and not necessarily
worth trying) for the race neural net to evaluate these very unbalanced
positions. In fact, backgammons (in non-contact positions) are computed
explicitly instead of using the neural net. Moreover there is a serie
of sanity checks to detect certain win / certain loss / certain gammon /
impossible gammon situations and override the neural net outputs if
needed.

[Frank Berger]

Tim Chow schrieb am Mittwoch, 19. Oktober 2022 um 05:08:39 UTC+2:

> http://timothychow.net/cg/whopper2.jpg
is it always misevaluating or only sometimes? (XGID would be easier to check).

best
Frank

[Simon Woodhead]

XGID=-A----------a--b-c-gb-----:0:0:-1:25:1:2:0:7:10
AQAAwP6cEQAAAA:MAH1ACAACAAE

[Timothy Chow]

On 10/19/2022 5:55 PM, Philippe Michel wrote:
> Are these errors unpredictable but reproducible: the same position
> always gets the same wrong evaluations ?

The errors are not reproducible.

---
Tim Chow

[Timothy Chow]

Actually, there's one thing I haven't tried.

When I play against XG, I turn off the evaluations so that I get as
little info as possible about the bot's beliefs about my play while
the match is in progress. Then I click "Analyze Session" at the end,
and the errors I've seen always seem to occur as a result of such
analysis.

I haven't tried saving the match before clicking "Analyze Session"
and then reloading the saved match and clicking "Analyze Session"
again to see if the same error occurs. I'm not sure I'm going to
bother doing this in the future, either, since the errors occur
rarely and it seems like too much trouble, but maybe I will.

---
Tim Chow

[MK]

On October 19, 2022 at 3:55:23 PM UTC-6, Philippe Michel wrote:

> On 2022-10-19, Timothy Chow <tchow...@yahoo.com> wrote:

>>> http://timothychow.net/cg/whopper.jpg

>> http://timothychow.net/cg/whopper2.jpg

> Are these errors unpredictable but reproducible: the
> same position always gets the same wrong evaluations?

> .....

> It looks like the "wrong" moves in this second position
> are evaluated as if they lose some backgammons.

In his latest example backgammons aren't involved.

In his previous exame backgammon is possible and
GNUBG backgammon estimates increase at higher
levels from 5.6 to 5.7 to 5.9 to 6.0 but it consistently
says "Optional redouble, take", while XG's wrong cube
advice only happens on certain (even?) plies (see my
first response to Tim's original article).

Your mis-explanations don't make sense for either bot.

MK

[MK]

On October 19, 2022 at 3:57:30 PM UTC-6, bgbl...@googlemail.com wrote:

> is it always misevaluating or only sometimes?

Several other people asked this same question also.
Can you tell us the reason/s behind at least why you
are asking it?

I assume that you will offer different explanations
depending on the answer. Tim said he's not sure if
it's consistent but I would like to know what would
your explanations (speculations) be for each case?

MK

[MK]

This makes it easy but what happens to the argument
that the bots always make the same decisions at any
given position and dice roll..?

It looks like we will have to choose between "bots may
indeed be cheating" or "bots aren't worth shit"... :( ;)

MK

[MK]

On October 19, 2022 at 6:20:32 PM UTC-6, Tim Chow wrote:

> I haven't tried saving the match before clicking "Analyze
> Session" and then reloading the saved match and clicking
> "Analyze Session" again to see if the same error occurs.

> I'm not sure I'm going to bother doing this in the future,
> either, since the errors occur rarely and it seems like too
> much trouble, but maybe I will.

I would encourage you to do it for the benefit of the people
who are looking up to you.

You seem to have a keen eye for this kind of "errors" in late
positions and you think they occur rarely but unless you are
constantly looking out for them, they may be occurring way
more often than you catch.

Also they may be occurring at all stages of games, in more
complicated positions where they would be ultimately hard
to detect "even for you"... ;)

But before you put any effort into it, you need to decide why
would you be doing it (and also perhaps tell us in advance).

Would it be to help XG developers to debug and improve their
product? If not for that, I can think of reasons for why I would
do it :) but not why else you would do it...? Surely not to show
that XG may be cheating or worse that it may not be a better
than human bot (not even better than you ;) or worse yet that
it may indeed be a bad teacher for gamblegammon players...??

MK

[Frank Berger]

MK schrieb am Samstag, 22. Oktober 2022 um 00:03:29 UTC+2:

> Several other people asked this same question also.
> Can you tell us the reason/s behind at least why you
> are asking it?

If you would have looked at the timestamps, you'll see that Michaels and my question was posted with only 90 seonds difference.
When I started my post Michaels wasn't online yet. I'm always glad if I can help you.

[Frank Berger]

MK schrieb am Samstag, 22. Oktober 2022 um 00:10:06 UTC+2:

> This makes it easy but what happens to the argument
> that the bots always make the same decisions at any
> given position and dice roll..?
>
> It looks like we will have to choose between "bots may
> indeed be cheating" or "bots aren't worth shit"... :( ;)

In a world with only two colours you would be right. You seems to be unable or unwilling to understand the nature of a concurrency issue. I wont waste my time trying again to explain or give links.....

[Philippe Michel]

On 2022-10-21, MK <mu...@compuplus.net> wrote:
> On October 19, 2022 at 3:55:23 PM UTC-6, Philippe Michel wrote:
>
>> On 2022-10-19, Timothy Chow <tchow...@yahoo.com> wrote:
>
>>>> http://timothychow.net/cg/whopper.jpg
>>> http://timothychow.net/cg/whopper2.jpg
>
>> Are these errors unpredictable but reproducible: the
>> same position always gets the same wrong evaluations?
>> .....
>> It looks like the "wrong" moves in this second position
>> are evaluated as if they lose some backgammons.
>
> In his latest example backgammons aren't involved.

This is true, and you and I see it easily, but a pure neural network
evaluation may not. That was my point.

> In his previous exame backgammon is possible and
> GNUBG backgammon estimates increase at higher
> levels from 5.6 to 5.7 to 5.9 to 6.0 but it consistently
> says "Optional redouble, take", while XG's wrong cube
> advice only happens on certain (even?) plies (see my
> first response to Tim's original article).

With my installation of gnubg I get 6% backgammon at all levels, but
this is not really relevant. The player on roll will lose a doubled
gammon and, at score -4:-4 the match, 100% of the time.

Gnubg's numbers are exact and its assessment is mathematically right but
pedagogically inept (and since it is an analysis, it matters and is
arguably a bug). XG is grossly wrong on all counts.

[MK]

I was neither referring to his post alone nor specifically.

How couldn't your remember that the same questions
were asked about Tim's first example and that, in fact,
you and I had discussed at length what it would take to
determine if it happens always or sometimes...?

Now let me ask again, trying to do it more clearly:

Case 1: Tim's second example happens always, i.e.
is reproducible.

What would you say the reason for it is?

Case 2: Tim's second example happens sometimes,
i.e. is not reproducible.

What would you say the reason for it is?

Preferably answer both but at least either one of these
questions.

After asking if it was reproducible, Philippe Michel (not
Michaels) has at least offered a provisional explanation
starting with "If this is the case you may want to.....".

If you aren't willing or capable of offering some sorts of
explanations, why did you ask the questions?!

MK

[MK]

On October 22, 2022 at 8:30:22 AM UTC-6, bgbl...@googlemail.com wrote:

> MK schrieb am Samstag, 22. Oktober 2022 um 00:10:06 UTC+2:

>> This makes it easy but what happens to the argument
>> that the bots always make the same decisions at any
>> given position and dice roll..?

>> It looks like we will have to choose between "bots may
>> indeed be cheating" or "bots aren't worth shit"... :( ;)

> In a world with only two colours you would be right. You
> seems to be unable or unwilling to understand the nature
> of a concurrency issue.

Thanks for making me realise that I don't need to choose
but can have both. What was I thinking...? :)) Surely, bots
can be cheating and be pieces of shit at the same time.

> I wont waste my time trying again to explain or give links.....

You no longer need to. You did well enough already. ;)

MK

[MK]

On October 22, 2022 at 10:11:05 AM UTC-6, Philippe Michel wrote:

> On 2022-10-21, MK <mu...@compuplus.net> wrote:

>> In his latest example backgammons aren't involved.

> This is true, and you and I see it easily, but a pure neural
> network evaluation may not. That was my point.

Okay. I'm fine with that.

>> In his previous exame backgammon is possible and
>> GNUBG backgammon estimates increase at higher
>> levels from 5.6 to 5.7 to 5.9 to 6.0 but it consistently
>> says "Optional redouble, take", while XG's wrong cube
>> advice only happens on certain (even?) plies (see my
>> first response to Tim's original article).

> With my installation of gnubg I get 6% backgammon at
> all levels, but this is not really relevant.

I checked again and I get 5.6 at "beginner", 5.7 at "casual
play" and "intermediate", 5.9 at "advanced", 6.0 at "expert",
"world class", "supremo", "grandmaster" and "4 ply".

Just to make sure we are on the same page, I'm using the
GNUbg ID: BwAAwLZJGggBAA:AQHgADAAGAAE

Also, can you explain why do you say this is not relevant?

> Gnubg's numbers are exact and its assessment is
> mathematically right but pedagogically inept (and
> since it is an analysis, it matters and is arguably a bug).

Are you referring to "optional double"? If so, personally I
have no problem with it. But maybe you mean something
else..?

> XG is grossly wrong on all counts.

I'm glad we agree on one more thing... ;)

MK

[Philippe Michel]

On 2022-10-22, MK <mu...@compuplus.net> wrote:
> On October 22, 2022 at 10:11:05 AM UTC-6, Philippe Michel wrote:

>> With my installation of gnubg I get 6% backgammon at
>> all levels, but this is not really relevant.
>
> I checked again and I get 5.6 at "beginner", 5.7 at "casual
> play" and "intermediate", 5.9 at "advanced", 6.0 at "expert",
> "world class", "supremo", "grandmaster" and "4 ply".

Advanced and lower are levels where the evaluation is artificially
weakend by adding random noise. I didn't even think about checking
them but they are useless for analysis anyway.

> Also, can you explain why do you say this is not relevant?

The score is -4:-4 and the cube at 2. Whether the player loses a
backgammon instead of a gammon doesn't matter.

>> Gnubg's numbers are exact and its assessment is
>> mathematically right but pedagogically inept (and
>> since it is an analysis, it matters and is arguably a bug).
>
> Are you referring to "optional double"? If so, personally I
> have no problem with it. But maybe you mean something
> else..?

No, that's what I meant. Doubling when you are certain to lose the game
just because it makes no difference due to the match score seems silly
or even arguably rude (Huh ? Are you fishing for a misclick or what ?)

[MK]

On October 23, 2022 at 3:36:34 PM UTC-6, Philippe Michel wrote:

> On 2022-10-22, MK <mu...@compuplus.net> wrote:

>> I checked again and I get 5.6 at "beginner", 5.7 at "casual
>> play" and "intermediate", 5.9 at "advanced", 6.0 at "expert",
>> "world class", "supremo", "grandmaster" and "4 ply".

>> Also, can you explain why do you say this is not relevant?

> The score is -4:-4 and the cube at 2. Whether the player
> loses a backgammon instead of a gammon doesn't matter.

Ah, okay, I had misunderstood that you meant it wasn't
relevant that Gnubg came up with different numbers at
different levels.

>> Are you referring to "optional double"? If so, personally I
>> have no problem with it. But maybe you mean something
>> else..?

> No, that's what I meant. Doubling when you are certain to
> lose the game just because it makes no difference due to
> the match score seems silly or even arguably rude (Huh ?
> Are you fishing for a misclick or what ?)

I agree it would be considerate of a bot to not do that but I
sure would try it even myself when playing against humans,
if "I were" a mentally ill gambler playing gamblegammon
"for blood"...

MK