Why doesn't gnubg resign?

[mu...@compuplus.net]

GNU Backgammon Position ID: BwAAsHoFAAAAAA
Match ID : BQEAACAAAAAE
+-1--2--3--4--5--6-------7--8--9-10-11-12-+ O: gnubg (Cube: 32)
O | O O O O O O | | | 2 points
O | O O | | | On roll
O | O | | |
O | O | | |
O | | | |
| |BAR| |^
XX | | | |
XX | | | |
XX | X | | |
XXX | X | | |
XXX | X | | | 0 points
+24-23-22-21-20-19------18-17-16-15-14-13-+ X: Murat Money

Why doesn't gnubg resign here and goes on to roll instead...?

MK

[Michael Petch]

I pasted this position into GNUBG and asked it to play and it resigned.
It is difficult to tell. Can you send me a copy of your SGF file as an
attachment to mpe...@capp-sysware.com . I don't necessarily call this a
serious bug, but I'm willing to see if it can be confirmed.

[mu...@compuplus.net]

On Friday, October 5, 2012 8:25:16 AM UTC-6, Michael Petch wrote:

> I pasted this position into GNUBG and asked it to play
> and it resigned. It is difficult to tell. Can you send

> me a copy of your SGF file as an attachment to mpetch@

> capp-sysware.com . I don't necessarily call this a
> serious bug, but I'm willing to see if it can be confirmed.

I pasted the position myself and it resigned also. Which
makes it worse for me because then I start looking for any
connections to any specific seeds (in this case I was using
the current date).

I have raised issues with gnubg's resigning "haphazardly"
many times in the past. Not because of my concern that
I want to help with debugging gnubg either...

Unfortunately, I haven't saved this match but I will try
to remember to save them in such questionable situations
so that you guys can look into them.

MK

[mu...@compuplus.net]

On Friday, October 5, 2012 8:25:16 AM UTC-6, Michael Petch wrote:

Okay here is another one:

GNU Backgammon Position ID: kgAA0NY9AAAAAA
Match ID : AgEKACAEoFYE
+-1--2--3--4--5--6-------7--8--9-10-11-12-+ O: gnubg (Cube: 4)
O | O O O O O O | | | 66 points
O | O O O O | | | Rolled 42

| O O | | |
| O | | |
| | | |
| |BAR| |^
XX | | | |
XX | | | |
XX | | | |
XXX | | | |

XXX | X X X | | | 2772 points
+24-23-22-21-20-19------18-17-16-15-14-13-+ X: Murat Money

game 47
move 24

It resigns at its next turn.

I am still playing this money session as we speak, so I
should be able to save it for you.

Notice the score... ;) BTW, is it possible to save a match
or a session in midstream, keep playing and save again at
the end? For some unknown reason I always assumed that it
wasn't and never even tried.

MK

[mu...@compuplus.net]

On Sunday, October 7, 2012 3:50:01 AM UTC-6, (unknown) wrote:

> Notice the score... ;)

It took about 5 hours 45 minutes to finish this 100 game
session, which is about average.

Games 50 to 90 were played while watching "Mission to
Mars", while I was slightly distracted laughing my ass
off to which? I don't know :)

Anyway, final score is 3173 to 329. Started the analysis
before going to bed. Will post more tomorrow.

MK

[Michael Petch]

On 2012-10-07 03:50, mu...@compuplus.net wrote:

> Notice the score... ;) BTW, is it possible to save a match
> or a session in midstream, keep playing and save again at
> the end? For some unknown reason I always assumed that it
> wasn't and never even tried.
>

You can save a match or session at any point. If however you close GNUBG
and restart it, the seed is set to a random value the next time it is
restarted (unless you set it manually to something else when you restart).

[mu...@compuplus.net]

On Sunday, October 7, 2012 9:59:26 AM UTC-6, Michael Petch wrote:

> You can save a match or session at any point.

Thanks for the tip and here is another example below.
Does any other bot even try to resign at all? If not,
gnubg should be praised for at least trying...

GNU Backgammon Position ID: BQAAEN+XgAQAAA
Match ID : MIEFAgAAAAAE
+-1--2--3--4--5--6-------7--8--9-10-11-12-+ O: gnubg
| O O O | | O O | 0 points
| O O | | | Rolled 31

| O O | | |
| O O | | |
| O O | | |

| |BAR| |^ 16 point match (Cube: 1)
XX | | | |
XX | | | |
XXX | | | |
XXX | | | |
XXX | X X | | O O | 0 points
+24-23-22-21-20-19------18-17-16-15-14-13-+ X: Murat Money

MK

[mu...@compuplus.net]

On Friday, October 5, 2012 8:25:16 AM UTC-6, Michael Petch wrote:

> I don't necessarily call this a serious bug,
> but I'm willing to see if it can be confirmed.

So, where are you cocksuckers at with this...?

I can "confirm" it several times a day. Maybe
it's not a bug but a feature...? :))

How long and how many examples will it take
for you cocksuckers to admit gnubg cheats...??

MK

[Michael Petch]

On 2012-10-14 04:48, mu...@compuplus.net wrote:
> So, where are you cocksuckers at with this...?
>
> I can "confirm" it several times a day. Maybe
> it's not a bug but a feature...? :))
>
> How long and how many examples will it take
> for you cocksuckers to admit gnubg cheats...??

lmao, I have asked you for SGF files. I have been unable to reproduce
the behavior. Why haven't you sent any SGF files? I am still waiting.

[mu...@compuplus.net]

On Sunday, October 14, 2012 10:17:29 AM UTC-6, Michael Petch wrote:

> lmao, I have asked you for SGF files. I have been
> unable to reproduce the behavior. Why haven't you
> sent any SGF files? I am still waiting.

Oops, my fault. I forgot to save and send them. But
you can look at the matches that you downloaded from
my site. Below are several examples from the first
21 matches of 25 points, with some comments I added.

I don't care about whether gnubg resigns perfectly
but these examples are a *concrete proof* that, given
the same position, dice and game/match score, gnubg
DOES NOT! always make the same move as you guys have
been claiming.

Apparently using a known seed vs a random seed makes
a difference? Or for whatever other reason.

For me, it's a good enough proof that gnubg cheats
or at least does funky things in trying to cheat...

MK

Here are the examles:

File 25005-mk27-gb12.sgf

Game 3 Move 27

Position ID: 1wAAgN93AAEAAA
Match ID: AQEgA0AAAAAE

Is it waiting to save gammon? I can't gammon. This is
a minor issue compared to others.

Game 5 Move 30

Position ID: AwAAYLtPIAIAAA
Match ID: AwEgA0AAGAAE

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

Here is a huge one. Fails to resign twice in a row.

File 25006-mk36-gb06.sgf

Position ID: DQAAsO1uAQAAAA
Match ID: AwEgA0AAYAAE

Game 8 Move 25

Position ID: AQAA3HYDAAAAAA
Match ID: AwEgA0AAYAAE

Game 8 Move 26

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

File 25008-mk14-gb28.sgf

Position ID: AQAA7G6bAAAAAA
Match ID: AgEgAwAAEAAE

Is it waiting to save gammon? I can't gammon. There
are too many examples of this but I won't post more
since it does resign as soon as it saves the gammon.

Game 2 Move 23

Position ID: BgAAwO0BAAAAAA
Match ID: sAEgA4ABSAAE

Game 14 Move 20

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

Here is another huge one. Fails to resign twice in a row.

File 25009-mk50-gb16.sgf

Position ID: GwAAgNNnMCEAAA
Match ID: AQEgA2AAcAAE

Game 6 Move 24

Position ID: AwAAyOkZTAIAAA
Match ID: AQEgA2AAcAAE

Game 6 Move 25

Here is a strange one. After rolling 22, it knows it
has 0% chance of winning and makes random moves but
doesn't resign. On top of that, it lets me recube to
32 unnecessarily and then takes, still not resigning.

Position ID: CAAAJB0AAAAAAA
Match ID: FAEpAwABkAAE

Game 10 Move 26

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

File 25015-mk29-gb06.sgf

Position ID: AQAAYP2DhQAAAA
Match ID: AQEgA0AAYAAE

Game 5 Move 22

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

File 25017-mk28-gb10.sgf

Position ID: e1sAABB8bhgYAA
Match ID: EQEgA6AAwAAE

Game 9 Move 21

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

Here is a last one for now. Fails to resign twice in a row.
(If you paste the IDs and play the same rolls, it fails to
resign in the first one but resigns in the second position.)

File 25021-mk25-gb12.sgf

Position ID: fgAAgHvPQBAAAA
Match ID: AwEgAwAAAAAE

Game 1 Move 22

Position ID: HgAA4N6zAAQAAA
Match ID: AwEgAwAAAAAE

Game 1 Move 23

[Michael Petch]

On 2012-10-14 15:37, mu...@compuplus.net wrote:
> I don't care about whether gnubg resigns perfectly
> but these examples are a *concrete proof* that, given
> the same position, dice and game/match score, gnubg
> DOES NOT! always make the same move as you guys have
> been claiming.

From GNUBG's perspective resigning or not resigning will end up with the
same result at the end of the game. It doesn't alter the OUTCOME for
either player since playing it until the last chequer is taken off is
the same as a proper resignation of a specific amount.

Here is an experiment, if GNUBG is cheating then use manual dice input
to play all your games. If you encounter the issue it won't be because
GNUBG is looking ahead at future dice since you have to enter them one
by one (so it doesn't know).

The reality is that if GNUBG in some cases doesn't resign early on, it
is because it is a bug. You have provided no evidence that it resigns to
alter based on a future roll (you say this with no evidence). I;m also
surprised a man with such a knowledgeable programming background has yet
to identify the source code that produces this bug. If it is looking
ahead and you know for certain this is occurring I am sure you can point
the GNUBG team to the offending code.

Once the bug is located (assuming there is one), the conditions under
which it doesn't offer a resignation will be known, and hopefully
reproducible.

I don't have time to go through all your matches looking for places it
occurred. However I am more than happy to have you send me a list of
match name / game number / approximate move where the issue occurred. I
do have your match files, and with info you provide it I can look.

You also said "Apparently using a known seed vs a random seed makes
a difference? Or for whatever other reason.". How did you arrive at that
conclusion, my current *guess* is that it has nothing to do with the
source of randomness (and definitely not looking at the upcoming roll)
but it is more than likely a characteristic of the position itself or
something that occurred prior to the event occurring.

I received an email from with one match. I have requested information on
game(s) and move number where the issue exists. I'm not going to hunt
through one hundred games manually. You need to identify the spots.

The only thing you have shown to date is the possibility of a bug
involving something that has no bearing on a match - namely not
resigning. Something that doesn't alter the equity of either side.

[Michael Petch]

On 2012-10-14 17:09, Michael Petch wrote:

> The only thing you have shown to date is the possibility of a bug
> involving something that has no bearing on a match - namely not
> resigning. Something that doesn't alter the equity of either side.
>

I should point out something. I have been unable to have this occur
myself. I also say the possibility of a bug, because the human (murat)
could have also been at fault. How is that? It is possible the computer
resigned and murat rejected so the bot played on. The reason I also want
the SGF files is to see if the bot resigned on the next roll as well.
For instance, in the case of the position that started this thread:
BwAAsHoFAAAAAA:BQEAACAAAAAE I was also curious what the bot did on its
next roll (assuming murat didn't win). Did the bot miss offering up
another resignation?

For all I know Murat rejected a bot resignation to get a better roll for
the start of the next game (easily done if you dump all the rolls for a
seed first), or murat rejected by accident, or that there is a bug and
the bot didn't offer up an early resignation.

I could conclude in the same manner Murat does that there is no bug, and
that Murat was actually the one cheating. But unlike Murat, I'm not
going to say that, I am willing to investigate it under the premise
there is a bug without declaring Murat a cheat (or that he was
responsible). I'd rather gather real facts before making any declaration.

[Michael Petch]

On 2012-10-14 15:37, mu...@compuplus.net wrote:

> Here are the examles:
>
> File 25005-mk27-gb12.sgf

[snip]

Your email to me with the match file attached didn't have the specifics.
I was unaware your post had cited these examples (I read my email before
your post). I missed reading the examples the first time because I
didn't read anything after you signed off as "MK" in the middle of your
post!

I went out of my way to look at the database of all your matches, and
actually did discover something peculiar about each on of these
positions that makes the bot think there isn't a resign. It has nothing
to do with looking ahead, and it appears during a match it is very
consistent. Before I saw your examples I did a query for this anomaly in
my database and generated this file:

http://www.capp-sysware.com/downloads/muratresignbug.txt

At that link the first table is all the resigns that GNUBG actually
made. The 2 tables beneath that are queries for 2 bugs in GNUBG's resign
system that occurred in Murat's 102 matches.

It just so happens that the 2 bug queries picks up all the cases you
have pointed out (and a lot more). I didn't do a query based on
knowledge of future rolls. There is in fact something VERY specific to
each of these cases that you may have missed. Any reader (including
Murat) with 15 minutes to spare should be able to take GNUBG id's from
the first table load(paste) them in GNUBG and compare them to the types
of positions in the second table (bug#1) to determine what one mistake
is in the GNUBG resign code.

The last table are a list of entries that were detected as missed
resigns, that have an identifiable pattern in the underlying data but
you won't be able to see with the GUI. If you review the SGF files for
these positions you will be able to identify what makes the data for
these positions unique as a group.

There is definitely a bug in GNUBG (And I believe 2 separate issues),
and when I fix it, it will be clear that this has nothing to do with
cheating and in fact the bot was consistent in what it did across all
these examples.

This bug also would exist with any type of dice including manual dice.
As for when I get around to looking at it, probably next weekend would
be my earliest opportunity (but not guaranteed).

Michael

[mu...@compuplus.net]

On Sunday, October 14, 2012 5:09:12 PM UTC-6, Michael Petch wrote:

> From GNUBG's perspective resigning or not resigning
> will end up with the same result at the end of the
> game. It doesn't alter the OUTCOME for either player

This is not true for matches and money sessions since
it will alter the beginning dice roll for the ensuing
game.

> Here is an experiment, if GNUBG is cheating then use
> manual dice input to play all your games. If you
> encounter the issue it won't be because GNUBG is
> looking ahead at future dice

Just because the same code is executed in both cases,
you can't argue that the net effect will be the same
in both cases also.

> If it is looking ahead and you know for certain this
> is occurring I am sure you can point the GNUBG team
> to the offending code.

It's not one of my goals to debug gnubg. I observed a
suspicious behavior that I'm trying to explain... You
are not responding to what you quoted from my article.
You are missing my point that what is suspicious isn't
only how gnubg fails to always resign properly but how
it resigns differently if you paste the gnubg IDs and
try to reproduce the same behavior...

> I don't have time to go through all your matches looking
> for places it occurred. However I am more than happy to
> have you send me a list of match name / game number /
> approximate move where the issue occurred. I do have your
> match files, and with info you provide it I can look.

I just did exactly that! I gave you 13 examples with the
SGF match file name, game number and not approximate but
exact move numbers.

When I get into a debate here, I try to my homework as
best as I can. Some readers my have issues with my
mocking profanity, etc. but I don't think anybody would
say that I am unprepared or unfair in what I post here.

I thought you would also know me better by now but it's
never too late for you to give me a little more credit,
in order to not jump the gun and not make an ass out of
yourself...

> I received an email from with one match. I have requested
> information on game(s) and move number where the issue
> exists. I'm not going to hunt through one hundred games
> manually. You need to identify the spots.

I found and emailed that money session to you after I
posted the 13 positions here. I had already specified
game and move number in that session earlier in this
thread so I didn't repeat them. In fact, I emailed it
to you more as an example of a money session for you
to look at, since the 13 sample positions here should
be more than enough for the issue at hand.

MK

[mu...@compuplus.net]

On Sunday, October 14, 2012 5:40:38 PM UTC-6, Michael Petch wrote:

> I have been unable to have this occur myself.

I'm very surprised to hear this and also now realized that
nobody else made an issue out of this in the past either.

In fact, nobody even reacted to my reporting it earlier in
this forum.

Unless everyone else were just ignoring it as not important,
maybe I should start taking credit again for being more
perceptive than some/most of you folks...? (While at it,
try to remember all those rare/critical "bugs" :) that only
I had discovered in Jellyfish and Snowie also).

> I also say the possibility of a bug, because the human
> (murat) could have also been at fault. How is that? It
> is possible the computer resigned and murat rejected so
> the bot played on.

This is again getting amusing... :) Don't you read what I
write carefully ever? I have reported in the past that I
was and I still am occasionally rejecting the bot's
second resignations because I am suspicious about why it
fails to resign when it should the first time... :))

> The reason I also want the SGF files is to see if the bot
> resigned on the next roll as well.

Sometimes it resigns on the next roll, sometimes it fails
to resign on the next roll as well!

> For all I know Murat rejected a bot resignation to get a
> better roll for the start of the next game (easily done
> if you dump all the rolls for a seed first), or murat
> rejected by accident

Fuck off cocksucking asshole... :( You should be grateful
to me for what I am pointing out to you dimwit mother
fuckers... :(( I don't deserve this shit!

> I could conclude in the same manner Murat does that there
> is no bug, and that Murat was actually the one cheating.
> But unlike Murat, I'm not going to say that, I am willing
> to investigate it under the premise there is a bug without
> declaring Murat a cheat (or that he was responsible). I'd
> rather gather real facts before making any declaration.

You should have said "like Murat", not "unlike Murat", since
I had already done my investigation before I opened my mouth
here...!!

You already rang the bell and smeared me with cheating yet
one more time.

After you do your investigation and come back to declare
the fact, will you have undone the damage...? I don't think
so. And so, go fuck yourself any which way you please...!

MK

[Michael Petch]

On 2012-10-15 02:45, mu...@compuplus.net wrote:
> On Sunday, October 14, 2012 5:09:12 PM UTC-6, Michael Petch wrote:
>
>> From GNUBG's perspective resigning or not resigning
>> will end up with the same result at the end of the
>> game. It doesn't alter the OUTCOME for either player
>
> This is not true for matches and money sessions since
> it will alter the beginning dice roll for the ensuing
> game.
>

The only way you can make that argument is if you believe GNUBG is
cheating by looking ahead. Which is exactly the purpose of the experiment.

>> Here is an experiment, if GNUBG is cheating then use
>> manual dice input to play all your games. If you
>> encounter the issue it won't be because GNUBG is
>> looking ahead at future dice
>
> Just because the same code is executed in both cases,
> you can't argue that the net effect will be the same
> in both cases also.
>

Why do I think I asked you to do the experiment. What happens if you
replay all those matches with manual dice, entering all the same dice
rolls you originally played out

I did this with one of the matches and it was interesting that the net
effect was the same. GNUBG made the same resignation plays (or lack of
them in this case). I'm asking you to run an experiment to prove your
case. IF GNUBG is looking ahead, then manual dice can't be known up
front, and if you play everything the same AND all the resignation
decisions are unaltered then it CAN'T be looking ahead.

>> If it is looking ahead and you know for certain this
>> is occurring I am sure you can point the GNUBG team
>> to the offending code.
>
> It's not one of my goals to debug gnubg. I observed a
> suspicious behavior that I'm trying to explain... You
> are not responding to what you quoted from my article.
> You are missing my point that what is suspicious isn't
> only how gnubg fails to always resign properly but how
> it resigns differently if you paste the gnubg IDs and
> try to reproduce the same behavior...
>

Did it occur toy you that the path taken for resignations is not the
same when analysing a position than the actual match? Why do you think I
demanded the SGF files? That was one reason, and the other was to see
what was played before and after.

>> I don't have time to go through all your matches looking
>> for places it occurred. However I am more than happy to
>> have you send me a list of match name / game number /
>> approximate move where the issue occurred. I do have your
>> match files, and with info you provide it I can look.
>
> I just did exactly that! I gave you 13 examples with the
> SGF match file name, game number and not approximate but
> exact move numbers.
>

Please see my followup message where I told you why I asked for this.
Your original email had no info, and I read it before I read here. And
when I read here your post with the examples was appended beneath your
signature "MK" and I missed them. But it didn't matter because in the
mean time I processed all your matches looking at all the resigns that
the bot did make, and all the resigns it didn't make.

Please read that newer post because you may learn that if you take a
close look at most of the resigns you'll discover one of the bugs by not
even looking at the code. You can actually see for 266 missed resigns
they all shared something in common that isn't the case for the 191
resigns that were valid. My post essentially asks you to spend a bit of
time to see if you can understand the one bug (bug #1).

> When I get into a debate here, I try to my homework as
> best as I can. Some readers my have issues with my
> mocking profanity, etc. but I don't think anybody would
> say that I am unprepared or unfair in what I post here.
>
> I thought you would also know me better by now but it's
> never too late for you to give me a little more credit,
> in order to not jump the gun and not make an ass out of
> yourself...
>

Did you see my other post yet?

I haven't posted the solution as to what the one obvious bug is on the
hopes that if you spend 15 mins reviewing some of them YOU would realize
what one of the blatant bugs is yourself! I'd hate to think I would have
to provide the solution because you can't find it yourself.

It is clear I have now done far more analysis of this resign situation
than you have.

[mu...@compuplus.net]

On Sunday, October 14, 2012 10:38:10 PM UTC-6, Michael Petch wrote:

> Your email to me with the match file attached didn't have
> the specifics. I was unaware your post had cited these
> examples (I read my email before your post). I missed
> reading the examples the first time because I didn't
> read anything after you signed off as "MK" in the middle
> of your post!

The first paragraph of my post said:

Oops, my fault. I forgot to save and send them. But
you can look at the matches that you downloaded from
my site. Below are several examples from the first
21 matches of 25 points, with some comments I added.

But if it was confusing to you, then it was my fault.
You don't need to explain or apologize. (just don't
be confused again... ;)

> http://www.capp-sysware.com/downloads/muratresignbug.txt

> It just so happens that the 2 bug queries picks up all
> the cases you have pointed out (and a lot more).

I wouldn't doubt it since I only looked at the first 21
matches and only at games not ending with a cube action.

> There is in fact something VERY specific to each of these
> cases that you may have missed. Any reader (including
> Murat) with 15 minutes to spare should be able to take
> GNUBG id's from the first table load(paste) them in GNUBG
> and compare them to the types of positions in the second
> table (bug#1) to determine what one mistake is in the
> GNUBG resign code.

Whay can't you do all of us a favor and let us in on the
secret...? (I couldn't figure out why, myself).

> The last table are a list of entries that were detected as
> missed resigns, that have an identifiable pattern in the
> underlying data but you won't be able to see with the GUI.

This is not true! The second and third items in your table
are the same as my fourth and sixth examples.

I guess some of us are able to see such thing with the GUI.

> There is definitely a bug in GNUBG (And I believe 2 separate
> issues), and when I fix it, it will be clear that this has
> nothing to do with cheating and in fact the bot was consistent
> in what it did across all these examples.

You still haven't answered, nor even speculated about why it
plays differently when you try to reproduce this behavior...

> This bug also would exist with any type of dice including
> manual dice.

Do you know or are you just speculating...? In any case, you
still haven't answered, nor even speculated about why it
plays differently when you try to reproduce this behavior,
with or without manual dice...

> As for when I get around to looking at it, probably next
> weekend would be my earliest opportunity (but not guaranteed).

Take your time... Don't jump the gun... ;)

MK

[Michael Petch]

On 2012-10-15 03:09, mu...@compuplus.net wrote:
> Unless everyone else were just ignoring it as not important,
> maybe I should start taking credit again for being more
> perceptive than some/most of you folks...? (While at it,
> try to remember all those rare/critical "bugs" :) that only
> I had discovered in Jellyfish and Snowie also).

This bug isn't critical since it doesn't alter the equity of a game. And
it only would make a difference if the bot was looking ahead at future
moves to change how it resigns. I have told you the experiment you need
to run to test your theory out on the 102 matches. Play them all again,
on the same settings, with manual dice (but you reenter all the dice
that were generated). If the bot resigns differently then something is
amiss. If it resigns the same way then you know it wasn't about looking
ahead.

I can already tell you 266 of the missed resigns of 282 are because of
one pretty obvious bug, that you should be able to see given all the
data at the link I provided in my other post on the subject.

> After you do your investigation and come back to declare
> the fact, will you have undone the damage...? I don't think
> so. And so, go fuck yourself any which way you please...!

Have you read my post with the link to the nearly 500 resignation
positions? of your 102 matches. I have not only sought out all the
positions where resignations were missed, but also in 266 of 282 cases
determined that one single obvious bug (Which I am asking you to spend
15 minutes looking for in the data I provided).

After dumping all that data it was pretty damn obvious without looking
at a singe line of code what the primary bug (bug#1) must be.

[Michael Petch]

Murat the post I want you to respond to now is the parent to this post
you are reading.

[Michael Petch]

On 2012-10-15 03:35, mu...@compuplus.net wrote:
> On Sunday, October 14, 2012 10:38:10 PM UTC-6, Michael Petch wrote:
>> http://www.capp-sysware.com/downloads/muratresignbug.txt
>
>> It just so happens that the 2 bug queries picks up all
>> the cases you have pointed out (and a lot more).
>
> I wouldn't doubt it since I only looked at the first 21
> matches and only at games not ending with a cube action.
>

So you mean I have done a more thorough analysis of the resignations on
your matches than you have?

>> There is in fact something VERY specific to each of these
>> cases that you may have missed. Any reader (including
>> Murat) with 15 minutes to spare should be able to take
>> GNUBG id's from the first table load(paste) them in GNUBG
>> and compare them to the types of positions in the second
>> table (bug#1) to determine what one mistake is in the
>> GNUBG resign code.
>
> Whay can't you do all of us a favor and let us in on the
> secret...? (I couldn't figure out why, myself).
>

I will Murat but I am asking you to spend just a little bit of time to
find it yourself. I provided the table of data for Resignations the bot
did make correctly, and in the second table 266 it missed that all have
something in common. You claim the bot is cheating, and in your other
post suggesting the reason for the weird non-resignations is to alter
the dice for the the next game.

That isn't the case at all. Bug #1 is so obvious that someone with
limited experience with Backgammon could see it if they pasted enough
positions from table 1 and table 2 into GNUBG, and they don't need to be
a programmer at all.

I could add 4 more columns to the data, and make it a lot easier for you
to see it but I saw it without the extra 4 columns and pasting positions
into GNUBG.

> I guess some of us are able to see such thing with the GUI.
>

What I am talking about is seeing the PATTERN in the GUI that makes all
those entries relate to one another. Sure you can paste the positions
into the GUI and see it missed the resign (that is easy), but I am
talking about looking at GNUBG's evaluation output and understanding
what the bot may have done wrong to arrive at a no-resignation decision.

>> There is definitely a bug in GNUBG (And I believe 2 separate
>> issues), and when I fix it, it will be clear that this has
>> nothing to do with cheating and in fact the bot was consistent
>> in what it did across all these examples.
>
> You still haven't answered, nor even speculated about why it
> plays differently when you try to reproduce this behavior...
>

I told you I couldn't reproduce it in the matches I played originally.
But you need to get into a particular situation for this to occur. I
just didn't play enough matches originally to see it. After I discovered
the anomaly in the data I am now able to play matches and have been able
to reproduce the issue.

The code that is passed through for pasting a position and playing isn't
the same code path as if you are playing a match or money session from
scratch. Something I was unaware of originally.

>> This bug also would exist with any type of dice including
>> manual dice.
>
> Do you know or are you just speculating...? In any case, you
> still haven't answered, nor even speculated about why it
> plays differently when you try to reproduce this behavior,
> with or without manual dice...
>

I tested it with a bunch of random.org numbers, input them in as manual
dice, and got it into a position similar to that of the 266 entries in
table #2 (bug #1) at my link. Also able to do it with Mersenne Twister.
It is easy (but can take some time) when you know what you have to do.

What is the harm in you looking at the positions in the first two tables
to discover what I found? If you did so I'd consider you a more credible
individual for at least trying to look at patterns in the positions. The
pattern is pretty trivial if you paste enough positions from both tables
into the bot. PS: I ended up automating equity computations to verify
the pattern held true for all the positions not just the 15-20 I chose
at random to find a potential pattern.

My findings for bug #1, and ideas for bug #2 are encrypted below.

To decrypt this part of the message use http://infoencrypt.com/

<Encrypted>
Tk+elMHc0O2Vk/lAyYn7viyBQ6M9OQGCo3N690qyL1wGJ7iUuV/cFgcc/5Lw00qX5njnTBCUMyt/Vvwo
JknsPNuMAGWapqXhWhiinVEqj39WkyPEFl2pIgStlgOs4aNBtc1WuFhMXD7v4q991UHYoNndRdpTm+mH
HfZtJki2Jh3x7Fblbcsuat/2hE0LM4bqcnLgDua93gQkrDOsGPGgFDbLa9MJBBaPxaT9rlWJRfRGrG8e
Cn2buf2U7ulKfIGmbp1dLtZ/WNf4oQIOO75CVGMKdGyGymTSK9kVemb1CY6TrDwz3VcI7311ZVYUpM7k
SvP+If9+9BPNG1ueVOLaZwxV3Srw5kK9i1Gh0iMjN2sr7xW/tZZkXmbvNwZdptB3JwixJ4ZCK7/94aTZ
luVC+3oh2nAWZFl1stSBW8a7rZM2whw/p/Ix85IW1Cp79BvHcaG57NBEO6CSFtQqe/Qbx7FJOYnu2aLH
5ha5LdgueIbs2ey9CtHigPNWSZbwGgdPbGCnkmz9OPcisgEtRYMjrvtDq4z4P1HDhxbHhY0Dtcx9dHyR
jpG5CEDWkE/g7fBZ4unUKHw9sILA9bJERsz0CJAYmN2QsJsZvw9MQdlHKwey9VmSr62YwOaTG19y22IX
18VNaJm9G3iI4FAtiK56ngAz99oyoCC7E3U01+VabNn+cp7WzbsggnRv0qx/CKY4lIWQCe4FvofOWXFs
XaJSQbhv6ilTAOr7yVFZPfpWVz6KKGFwBqFEVUDKht8mEn2iD7KK6fkV892STLksGuwTQEbqNUlZlKHr
x6ptvjrzhsqMOKQAC5qp6NzqYNOKCV0t7OA8iA2JqsLlKmVp1xE7QNvKQeVrNsMVrOPnd5e2Nx9wRyvd
G7eLNiCfmKsSycXkdD1FNH5tW2Pv0HDwa+LPsFByEDwQxGjPQBAG9J4unnAWrG7kBOiy98JkBjtf0DFP
dSGlqzstP9iPDb7pFJuHmMZJ3aPIqZB5maA29VYCG9naHgMxYqdcEupnCZJ2NaD8NdL+oTGhcu62Fyd+
hKcHbyMFt3CJw5Xt7ErwqkN5l8CreXb4udec7FJ5V3+VTIdlPBP1P4FCjMUR0vJ9O/QkMOgmBKH5sVFT
Jeegtm21OX/ZgY4qJzs5IyxgfzoXVn2BZdbUJpCnroBMFncm1gnDYWg0LY4qkzJRR7J8+J6YXKLhm5Cb
AgVSQ+RsZcSmNdQN

</Encrypted>

[Michael Petch]

On 2012-10-14 15:37, mu...@compuplus.net wrote:

> File 25005-mk27-gb12.sgf
>
> Game 3 Move 27
>
> Position ID: 1wAAgN93AAEAAA
> Match ID: AQEgA0AAAAAE
>
> Is it waiting to save gammon? I can't gammon. This is
> a minor issue compared to others.

Actually the bot played this correctly. It wasn't playing to save
gammon, it was playing to win. If it rolls double 6, followed by all mid
range doubles after that and you roll all 21s (for example) you can
still lose. You weren't observant enough to realize that the bots resign
decision in this case is based on getting joker rolls (starting with a
double 6) to outright win the match. If it doesn't get a double 6 it can
no longer win and then it will resign. If it does get adouble 6 it will
continue to play on the chance it will continue to roll the right
doubles and you will roll all 21's (for example)

You used this as an example of doing funky things in trying to cheat. If
cheating means playing the probability that it can still win, then I
guess that is cheating?

> Game 5 Move 30
>
> Position ID: AwAAYLtPIAIAAA
> Match ID: AwEgA0AAGAAE

This is directly related to Bug #1, and if you had discovered the
pattern you'd already know that the bot won't resign this during normal
match/session play.

> Here is a huge one. Fails to resign twice in a row.
>
> File 25006-mk36-gb06.sgf
>
> Position ID: DQAAsO1uAQAAAA
> Match ID: AwEgA0AAYAAE
>

This is actually an interesting one, but the bot did the right thing
from its perspective but highlights an interesting anomaly in the race
neural net. You'll note that GNUBG has one of its checkers outside its
home. The default bearoff database (out to the 6pt) doesn't apply so it
must rely on the race neural net. If you do a "analyse menu/evaluate" on
this position and look at 0 ply you'll see why GNUBG didn't resign. Note
that it still thinks it can be gammoned. This occurs because the neural
net has to make an educated guess as to the gammons/backgammons/wins
associated with a player. The neural net isn't perfect that way. If you
extend the bearoff database to the 7pt then this issue should disappear
since the bearoff database would know the backgammon chances are 0.

This also brings to light something I didn't know before. It seems that
when GNUBG resigns it does its resign calculations at 0 ply and not the
ply level the bot was playing at. What this does mean though is that if
you encounter such situations in the future you should check to see what
0ply says first. Why does 1 ply show everything 0%? Because whatever the
bot rolls this time, he is guaranteed to have all his men in his home at
which point the default bearoff database will be queried directly and
the equities will be known.

Could resigns be more intelligent and compute at a higher ply, sure and
that could be looked at. But it appears that GNUBG is consistent in this
regard.

> Game 8 Move 25
>
> Position ID: AQAA3HYDAAAAAA
> Match ID: AwEgA0AAYAAE
>

I managed to capture this position in my 3rd table bug #2.

> Game 8 Move 26

That move is yours. Maybe you meant that the bot should have resigned
before it rolled double 6. That would be true but just like previously
mentioned check out 0 ply by doing an "analyse"/"evaluate" or
"analyse"/"hint" click 0 ply.

> File 25008-mk14-gb28.sgf
>
> Position ID: AQAA7G6bAAAAAA
> Match ID: AgEgAwAAEAAE
>
> Is it waiting to save gammon? I can't gammon. There
> are too many examples of this but I won't post more
> since it does resign as soon as it saves the gammon.
>
> Game 2 Move 23

This is as discussed previously. race neural net shows that there is a
chance to be gammoned (And the race neural net isn't perfect). Extending
the bearoff database to the 8 pt should allow the bot to resign here.

>
> Position ID: BgAAwO0BAAAAAA
> Match ID: sAEgA4ABSAAE
>
> Game 14 Move 20

I managed to capture this under bug #2.

> Here is another huge one. Fails to resign twice in a row.
>
> File 25009-mk50-gb16.sgf
>
> Position ID: GwAAgNNnMCEAAA
> Match ID: AQEgA2AAcAAE
>
> Game 6 Move 24

Because of obvious bug #1, this will never be resigned during normal
match/session play.

>
> Position ID: AwAAyOkZTAIAAA
> Match ID: AQEgA2AAcAAE
>
> Game 6 Move 25

Because of obvious bug #1, this will never be resigned during normal
match/session play.

> Here is a strange one. After rolling 22, it knows it
> has 0% chance of winning and makes random moves but
> doesn't resign. On top of that, it lets me recube to
> 32 unnecessarily and then takes, still not resigning.
>
> Position ID: CAAAJB0AAAAAAA
> Match ID: FAEpAwABkAAE
>
> Game 10 Move 26

Not completely strange at all. When you play against GNUBG (as a bot
opponent) it won't resign without moving. It rolls the 22 (when it does
have a chance to roll 66 to potentially win if you roll 21 next roll).
It is now your turn. The 16 cube is high enough for both of you to win
already so recubing to 32 is an automatic take. GNUBG does this
consistently since it doesn't resign on cubes even if it has no way to
win. It will always take such cubes.

If you had rolled 21 (after GNUBG took) I suspect from my findings that
the bot may not actually resign at that point because of bug #2 although
I haven't confirmed that behavior, just an educated guess.

> File 25015-mk29-gb06.sgf
>
> Position ID: AQAAYP2DhQAAAA
> Match ID: AQEgA0AAYAAE
>
> Game 5 Move 22

Because of obvious bug #1, this will never be resigned during normal
match/session play.

> File 25017-mk28-gb10.sgf
>
> Position ID: e1sAABB8bhgYAA
> Match ID: EQEgA6AAwAAE
>
> Game 9 Move 21

***************** Great entertainment value ****************

This is in fact the most interesting position you found for reasons
other than what you might think. If you do an evaluate on this position
the race neural net has approximated that it still has about 1 in 20000
(.000050) or worse chances of winning. At first I thought the race
neural net may have overestimated its chance of winning, so I did an
experiment - I wanted to know if the bot got the best possible rolls and
I also played the other side (murat) with the worst possible rolls, was
it possible for GNUBG to get an upset win.

*** Danger, Will Robinson *** (I can hear Murat going aha, the bot cheat
LOL). This is one case where GNUBG's dice cheat facility comes in real
handy. First since I want to play both sides of the table I go to
settings/players and set both players to human. I then go to
settings/options/dice and ask it to roll the best possible rolls for
GNUBG, and the worst possible rolls for Murat.

I then began to play both sides, and amazingly there are sequences of
rolls that can allow GNUBG to win lol. It was right not to resign.

************************************************************

> Here is a last one for now. Fails to resign twice in a row.
> (If you paste the IDs and play the same rolls, it fails to
> resign in the first one but resigns in the second position.)
>
> File 25021-mk25-gb12.sgf
>
> Position ID: fgAAgHvPQBAAAA
> Match ID: AwEgAwAAAAAE
>
> Game 1 Move 22

>
> Position ID: HgAA4N6zAAQAAA
> Match ID: AwEgAwAAAAAE
>
> Game 1 Move 23

I may be missing something but GNUBG but is holding an 8 cube and could
still potentially be gammoned by you (or it could save gammon) in both
positions you listed. I don't see why it would resign here?? The game
and match is far from over.

[Michael Petch]

On 2012-10-14 22:38, Michael Petch wrote:
> I went out of my way to look at the database of all your matches, and
> actually did discover something peculiar about each on of these
> positions that makes the bot think there isn't a resign. It has nothing
> to do with looking ahead, and it appears during a match it is very
> consistent. Before I saw your examples I did a query for this anomaly in
> my database and generated this file:
>
> http://www.capp-sysware.com/downloads/muratresignbug.txt

I am keeping the original link intact however I discovered in table 2
(bug #1) I had inadvertently pulled in positions where Murat didn't
resign in hopeless positions and kept playing. There are in fact only 46
occurrences of bug #1 instead of 266.

I created a new file:
http://www.capp-sysware.com/downloads/muratresignbug-2.txt

I kept the old one in case someone wanted to compare is to the new one
to see the differences if they so choose. I'm not hiding anything in
that regard.

[Michael Petch]

On 2012-10-15 14:55, Michael Petch wrote:
> The neural net isn't perfect that way. If you
> extend the bearoff database to the 7pt then this issue should disappear
> since the bearoff database would know the backgammon chances are 0.

Should have been:

"The neural net isn't perfect that way. If you
extend the bearoff database to the 7pt then this issue should disappear

since the bearoff database would know the GAMMON chances are 0 without
making an educated guess."

[mu...@compuplus.net]

On Monday, October 15, 2012 4:49:39 AM UTC-6, Michael Petch wrote:

> To decrypt this part of the message use http://infoencrypt.com/

Do I need a password?

Why are you playing these childish games anyway??

MK

[mu...@compuplus.net]

On Monday, October 15, 2012 3:03:19 PM UTC-6, Michael Petch wrote:

>> http://www.capp-sysware.com/downloads/muratresignbug.txt

> I am keeping the original link intact however I discovered
> in table 2 (bug #1) I had inadvertently pulled in positions
> where Murat didn't resign in hopeless positions and kept
> playing. There are in fact only 46 occurrences of bug #1
> instead of 266.

> http://www.capp-sysware.com/downloads/muratresignbug-2.txt

Your description of table 2 says:

Bug #1: These all are missed resigns that fail for a reason
that should be obvious to anyone who takes a sample of these
and compares them to positions GNUBG properly resigned (The
table above)

Even though 220 out of 266 cases you detected were actually my
failing to resign properly, by comparing them to 191 cases that
gnubg resigned properly, you were able to a see a pattern...?

Hah hah... :) You really made an ass out of yourself this time,
haven't you... :(

> I kept the old one in case someone wanted to compare is to
> the new one to see the differences if they so choose.

I can't see any differences. Can anyone? How about yourself,
what differences do you see...?

> I'm not hiding anything in that regard.

Small credit for you. You would have to try pretty hard to hide
it... ;)

MK

[mu...@compuplus.net]

On Monday, October 15, 2012 2:55:31 PM UTC-6, Michael Petch wrote:

I appreciate your commenting on every example I posted
but I don't think it's necessary for me to do the same.

I tried to quickly come with some examples for you from
the matches that you already had in your possession. It
took several hundred mouse clicks to open those matches,
scroll though the game record, look at the final moves
in all those games and spot some examples...

I had already commented myself that the bot's failing to
resign while it still had a checker out of its home was

a minor issue compared to others.

The 32 cube example was a side comment in relation to an
earlier discussion in this group about whether cubing
beyond necessary points to win the game was ethical and
that the would not allow it. But you instead focused on
it being an automatic take.

I am fully aware of the bot's not resigning before it moves,
which a total waste of cpu time ;) and an irritant for the
human player to make a few mouse clicks and wait for the bot
to resign before its next roll. I just underlined it as such
before underlining the 32 cube thing. Both of those were odd
examples for your information and as improvement suggestions,
rather than for my main argument.

Then you find entertainment value in my not being observant
enough (i.e. to an accura of .000050). Give me a break dude.
I'm not a robot and my nickname isn't even "stick"... But,
don't feel bad. I am perfectly happy with the accuracy of my
observations, which as far as I can observe, nobody else has
even come close to it regarding the subject at hand...

And you are right about my last example being a false alarm.
I should have quit after looking at 20 matches as I had
intended (and while I was ahead:) I guess I was careless to
find just one more example (thus my looking at the odd number
21 matches).

A friendly advice from me Petch, don't get lost in the petty
details...

As a human being, I made a reasonable effort and even a few
example should gave been enough for you as proof of what I
was talking about. But apparently you can't be appreciative
of that... :(

MK

[Michael Petch]

On 2012-10-16 00:52, mu...@compuplus.net wrote:
> Even though 220 out of 266 cases you detected were actually my
> failing to resign properly, by comparing them to 191 cases that
> gnubg resigned properly, you were able to a see a pattern...?

The data I used was from another query, only the output I released was
wrong. Was how I ended up discovering the issue. However the data I
pulled in from you is identical in nature to the bots. What is more
surprising was that you didn't even catch onto that fact and post about it.

However despite the fact that I posted your data, had you sampled all
those positions too you would have still realized what bug #1 is. A
smart person would realize just from table 1 the rather unique property
of when the bot does resign.

So I'm going to give you a seriously big hint. I'm going to post the
equities of ALL the positions the bot actually resigned (Table 1 with 6
extra columns)

http://www.capp-sysware.com/downloads/muratresignbug-2-evals.txt

Wr=Wins (regular), Wg=Win Gammons, Wbg=Win Backgammons, Lr=Lose
regular,Lg=Lose Gammons,Lbg=Lose Backgammon. A value of 1 is 100%, a
value of 0 = 0%.

And before you ask - there are no other resigns by the bot (you can look
all you want to counter the argument that I some how hand selected these
entries in table 1). Do you see the pattern in the data now? If you can,
can you guess what makes Table 2 different without even knowing the
equities (in Table 2)?

[Michael Petch]

On 2012-10-16 02:01, mu...@compuplus.net wrote:
> A friendly advice from me Petch, don't get lost in the petty
> details...

I believe in due diligence. You posted all those positions to point out
the nefarious nature of the bot cheating, or doing something funky on
its way to cheating. I also was more interested in the positions where
my posted data set didn't include the positions you posted and needed to
know why. However the underlying data told me why. It is not petty to do
thorough analysis to find out if there is something I missed.

The fact I looked at each and every position is an indication I am
actually reading what you write.

As for pointing out about when the bot won't resign (on cubes etc) is to
inform the readers that although it doesn't cube in certain positions,
it does so consistently because it is programmed that way (it isn't
cheating, that is just the way the bot does it). Just because the bot
consistently takes cubes instead of resigning matches is no indication
of cheating (which was the point).

On the point of wasting resources, it is rather interesting how often
you play out hopeless situations for your self (about 200 positions, ~5
times more than the bot). Out of all 100 matches, the bot didn't resign
early in 62 positions where it COULD have. That is 62 out of about 31000
moves by the bot. You may have spent more time playing hopeless position
than the bot did.

I didn't expect you to comment on all the positions I posted. However I
did want you to tell me the pattern that makes up bug #1. I have now
posted in the other thread a major hint (actually I gave it to you on a
silver platter) as to what bug #1 may be by posting the equities for the
places the bot did resign.

[mu...@compuplus.net]

On Tuesday, October 16, 2012 8:23:14 AM UTC-6, Michael Petch wrote:

> although it doesn't cube in certain positions, it does so
> consistently because it is programmed that way (it isn't
> cheating, that is just the way the bot does it). Just
> because the bot consistently takes cubes instead of
> resigning matches is no indication of cheating

It baffles me how can you logically arrive at such a
conclusion...?

By nature, bots do whatever they do consistently. Are
you saying that bots would be incapable of being
consistent at cheating...?

Hah hahh haahhh.... :) If I get a hernia from laughing,
I will hold you responsible for it...!

> On the point of wasting resources, it is rather
> interesting how often you play out hopeless situations
> for your self (about 200 positions, ~5 times more than
> the bot).

Why do you find it interesting...? You tell us first and
then I will tell you why it isn't.

MK