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
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.
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.
On Thursday, July 21, 2022 at 10:31:46 PM UTC-4, Tim Chow 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
---
Tim Chow
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.
On 7/22/2022 12:28 AM, Stick Rice wrote:
On Thursday, July 21, 2022 at 10:31:46 PM UTC-4, Tim Chow 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
---
Tim Chow
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.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
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?
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 howIt was announced in some forums over 7 years ago.
do you guys manage to run with a version of 2.19 beta?
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
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 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
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.
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.
When the author gets around to releasing a 2022 version
I'll buy it.
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?
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.
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.
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:
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/similarAlmost all the time, the same evaluation is obtained. Once in a very
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?
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.
On 7/22/2022 12:28 AM, Stick Rice wrote:
On Thursday, July 21, 2022 at 10:31:46 PM UTC-4, Tim Chow 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
---
Tim Chow
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.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.
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.
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.
Which books (or websites) on operating systems do you recommend?All Tanenbaum books I read were good reads.
Have you read Tannenbaum/Bos (or something similar)?
How about Computer Systems: A programmer's perspective by Bryant and O'Halloran?I just checked it, seems like a very interesting book, but doesn't look that it addresses that issues.
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?Several books. Books seems to be very old school nowaydays, but you can't get deep knowledge by a 15 minute youtube lesson.
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.
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 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
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.
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.
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?
Ilks.
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,...
Maybe for you, but for others this might be an interesting informationGiven that you claimed yourself recently a top SW developerIrrelevant to what asked you.
You hid that at least to me...It means if you setup the position a thousand times you mightI already knew that also.
get 1000 times the same result... or only 999 times or 998 times.
I asked if you ran Chow's positionWhy 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.
1,000 times to see how many times it happens.
Okay, now, this can be useful if you could tell more about 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. 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 wouldI'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.
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).
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?
MK schrieb am Mittwoch, 7. September 2022 um 02:49:40 UTC+2:
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.
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.
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?
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.
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.
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.
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.
I'm quite sure that I have *never* argued that "accuracy
should be the most important thing in bots."
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.
On September 7, 2022 at 1:52:57 PM UTC-6, bgbl...@googlemail.com wrote:Sure. I don't have access to XG source code so how can I more specific? To my code see below.
Everything you said in your response was general, generic
stuff.
Considering the number of computers and softwareIf 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)
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 andIf 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?
languages are as thread safe as they can be,
except maybeDid you made a code review? Oh I forgot, to take your offending communication style into account.
for the sloppy, hacky programming by people like you,
inIf 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.
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 learningYour comments show you're wrong, see above.
from wiki definitions or books about programming.
I askedI 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.
you about a specific bug in your program for what it would
expose about you, not for what I would learn from it...
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.
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.
On September 15, 2022 at 12:29:19 AM UTC+2, bgbl...@googlemail.com wrote:This advice seems a little bizarre for someone who claimed: "I really don't have much to benefit from learning
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 carI 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
accident and blame the car, the road, the weather, etc.
but never their own bad driving...
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
http://timothychow.net/cg/whopper2.jpgis it always misevaluating or only sometimes? (XGID would be easier to check).
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 schrieb am Mittwoch, 19. Oktober 2022 um 05:08:39 UTC+2:
http://timothychow.net/cg/whopper2.jpgis it always misevaluating or only sometimes? (XGID would be easier to check).
Are these errors unpredictable but reproducible: the same position
always gets the same wrong evaluations ?
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.
is it always misevaluating or only sometimes?
On 2022-10-19, Timothy Chow <tchow...@yahoo.com> wrote:
http://timothychow.net/cg/whopper.jpghttp://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.
On 20/10/2022 7:57 am, Frank Berger wrote:
(XGID would be easier to check).
XGID=-A----------a--b-c-gb-----:0:0:-1:25:1:2:0:7:10 AQAAwP6cEQAAAA:MAH1ACAACAAE
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.
Several other people asked this same question also.If you would have looked at the timestamps, you'll see that Michaels and my question was posted with only 90 seonds difference.
Can you tell us the reason/s behind at least why you
are asking it?
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"... :( ;)
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.jpghttp://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).
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.
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.
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 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.
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.....
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".
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..?
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.
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 ?)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 295 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 01:21:17 |
| Calls: | 6,642 |
| Calls today: | 2 |
| Files: | 12,190 |
| Messages: | 5,325,421 |
