I was looking at an old thread today in which I posted the
position below. X has 1 checker on his 5pt, 2 checkers on
his 4pt, 4 checkers on his 3pt, 1 checker on his 2pt, and
1 checker on his 1pt. O has borne off all checkers.

XGID=-AADBA--------------------:0:0:1:51:0:0:0:0:10

Score is X:0 O:0. Unlimited Game
+13-14-15-16-17-18------19-20-21-22-23-24-+
| | | |
| | | |
| | | |
| | | |
| | | |
| |BAR| |
| | | |
| | | X |
| | | X |
| | | X X |
| | | X X X X X |
+12-11-10--9--8--7-------6--5--4--3--2--1-+
Pip count X: 28 O: 0 X-O: 0-0
Cube: 1
X to play 51

eXtreme Gammon Version: 2.19.211.pre-release

The position is "illegal" in the sense that it could never
arise in a real game; after O has borne off all her checkers,
the game is over, and X would not roll the dice. But what I
found interesting is that when I tried to copy and paste the
above XGID into XG, it gave the following error message:
"Invalid position! The position cannot be imported. The
source was not properly formatted." But the XGID was generated
by XG itself, so it's a little bizarre that it would complain
that the string is "not properly formatted."

Arguably the "correct" behavior in this sort of situation is
to issue a *warning* (not an *error*) that the position is
invalid, but then go ahead and produce the position anyway.

---
Tim Chow

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

On November 26, 2022 at 5:59:28 PM UTC-7, Tim Chow wrote:

XGID=-AADBA--------------------:0:0:1:51:0:0:0:0:10

"Invalid position! The position cannot be imported....
issue a *warning* (not an *error*) that the position is
invalid, but then go ahead and produce the position

I pasted it to Gnubg without a problem. Gnubg is
so much superior to XG as an experimenting and
learning tool that it's a shame it's not used more
often and in more beneficial ways.

Editing positions, for example, is so much easier.
It has even an option in settings to allow dragging
to illegal points while considering your move (but,
of course, you can't finalize illegal moves). Etc...

I wish some people who are not such dogmatized
mathematician gamblers could contribute to it, to
make it an even better bot.

MK

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

On 27/11/2022 10:59 am, Timothy Chow wrote:

"Invalid position! The position cannot be imported. The
source was not properly formatted." But the XGID was generated
by XG itself, so it's a little bizarre that it would complain
that the string is "not properly formatted."

XG isn't perfect. It doesn't complain about this: XGID=aCCBBBB------------ccbbbbA:0:0:-1:51:0:0:0:0:10

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

On Sunday, November 27, 2022 at 12:59:28 AM UTC, Tim Chow wrote:

I was looking at an old thread today in which I posted the
position below. X has 1 checker on his 5pt, 2 checkers on
his 4pt, 4 checkers on his 3pt, 1 checker on his 2pt, and
1 checker on his 1pt. O has borne off all checkers.

XGID=-AADBA--------------------:0:0:1:51:0:0:0:0:10

Score is X:0 O:0. Unlimited Game
+13-14-15-16-17-18------19-20-21-22-23-24-+
| | | |
| | | |
| | | |
| | | |
| | | |
| |BAR| |
| | | |
| | | X |
| | | X |
| | | X X |
| | | X X X X X |
+12-11-10--9--8--7-------6--5--4--3--2--1-+
Pip count X: 28 O: 0 X-O: 0-0
Cube: 1
X to play 51

eXtreme Gammon Version: 2.19.211.pre-release

The position is "illegal" in the sense that it could never
arise in a real game; after O has borne off all her checkers,
the game is over, and X would not roll the dice. But what I
found interesting is that when I tried to copy and paste the
above XGID into XG, it gave the following error message:
"Invalid position! The position cannot be imported. The
source was not properly formatted." But the XGID was generated
by XG itself, so it's a little bizarre that it would complain
that the string is "not properly formatted."

Arguably the "correct" behavior in this sort of situation is
to issue a *warning* (not an *error*) that the position is
invalid, but then go ahead and produce the position anyway.

I think that it is actually inarguable that your suggested behaviour
is the best behaviour; I can't imagine a sensible disagreement with that. However, there's the obvious matter of prioritization -- there are far
bigger issues for XG programmers to attend to.

I think your post wrongly elides the distinct concepts of "illegality" and "invalidity". [I just totally love the way the previous sentence displays my writing ability -- in particular, "elides" is absolutely the mot juste, but would be
eluded by many].

An invalid position is one that makes no conceptual sense in the ordinary context of a backgammon game. So your position is indeed invalid, because
it's not clear what rolling after a player has already removed all their checkers
really means.

An illegal position is, by definition, one that can't be reached, but it may (or may not) make sense.
Simon's position is clearly illegal, but I'm not sure whether I'd call it "invalid" or not.
To get a clearer example of a position which is clearly valid but clearly illegal,
consider the position with all 30 checkers on the bar, and where there is no doubt
which player is on roll. A perfectly normal backgammon game can be played from this
position so there is no invalidity, but it's illegal because no possible previous roll exists.

Paul

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

On Saturday, December 3, 2022 at 10:14:28 AM UTC, peps...@gmail.com wrote:
...

Arguably the "correct" behavior in this sort of situation is
to issue a *warning* (not an *error*) that the position is
invalid, but then go ahead and produce the position anyway.

I think that it is actually inarguable that your suggested behaviour
is the best behaviour; I can't imagine a sensible disagreement with that. However, there's the obvious matter of prioritization -- there are far
bigger issues for XG programmers to attend to.

...
Note that warning and reproducing the position, as you suggest, wouldn't be
the end of the matter. Analysing and rolling out invalid positions is meaningless
so we would need designing and coding around this, too.

Paul

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

On 12/3/2022 5:14 AM, peps...@gmail.com wrote:

I think that it is actually inarguable that your suggested behaviour
is the best behaviour; I can't imagine a sensible disagreement with that. However, there's the obvious matter of prioritization -- there are far
bigger issues for XG programmers to attend to.

That's certainly true.

An invalid position is one that makes no conceptual sense in the ordinary context of a backgammon game. So your position is indeed invalid, because it's not clear what rolling after a player has already removed all their checkers
really means.

An illegal position is, by definition, one that can't be reached, but it may (or may not) make sense.
Simon's position is clearly illegal, but I'm not sure whether I'd call it "invalid" or not.
To get a clearer example of a position which is clearly valid but clearly illegal,
consider the position with all 30 checkers on the bar, and where there is no doubt
which player is on roll. A perfectly normal backgammon game can be played from this
position so there is no invalidity, but it's illegal because no possible previous roll exists.

The distinction you're making is an interesting one, although I think
it's difficult to make formally precise. In the chess problem world,
I don't think that two different words are used; people might say that
the illegality of some positions is obvious, while in other cases the illegality is discernible only through retro-analysis, but there's no
formal definition of what sort of observations require retro-analysis.
If White has a bishop on a1 and a pawn on b2, is this obviously illegal
or did you have to use retro-analysis to figure that out?

In any case, what I found odd about the example that I began this thread
with is that XG allowed me to set up the position and *itself generated
the XGID in question*, but then rejected it as invalid. An analogy that
comes to mind is that I fill out a government application for some form
of government ID, and the government accepts the application and issues
me an ID card, but then the moment I try to use it, the government
rejects the card as invalid. If they regard the card as invalid, then
why did they go ahead and issue it in the first place?

---
Tim Chow

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

On 12/3/2022 9:40 AM, I wrote:

In any case, what I found odd about the example that I began this thread
with is that XG allowed me to set up the position and *itself generated
the XGID in question*, but then rejected it as invalid.  An analogy that comes to mind is that I fill out a government application for some form
of government ID, and the government accepts the application and issues
me an ID card, but then the moment I try to use it, the government
rejects the card as invalid.  If they regard the card as invalid, then
why did they go ahead and issue it in the first place?

I forgot to say---remember that the XG error message said not only that
the position was invalid, but that the "source was not properly
formatted." What other authority for proper formatting of an XGID
can there be, other than XG itself? In my government analogy, it would
be akin to the government complaining that the ID cards that it issued
were "not properly formatted."

---
Tim Chow

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

On Saturday, December 3, 2022 at 2:40:11 PM UTC, Tim Chow wrote:

On 12/3/2022 5:14 AM, peps...@gmail.com wrote:

I think that it is actually inarguable that your suggested behaviour
is the best behaviour; I can't imagine a sensible disagreement with that. However, there's the obvious matter of prioritization -- there are far bigger issues for XG programmers to attend to.

That's certainly true.

An invalid position is one that makes no conceptual sense in the ordinary context of a backgammon game. So your position is indeed invalid, because it's not clear what rolling after a player has already removed all their checkers
really means.

An illegal position is, by definition, one that can't be reached, but it may (or may not) make sense.
Simon's position is clearly illegal, but I'm not sure whether I'd call it "invalid" or not.
To get a clearer example of a position which is clearly valid but clearly illegal,
consider the position with all 30 checkers on the bar, and where there is no doubt
which player is on roll. A perfectly normal backgammon game can be played from this
position so there is no invalidity, but it's illegal because no possible previous roll exists.

The distinction you're making is an interesting one, although I think
it's difficult to make formally precise. In the chess problem world,
I don't think that two different words are used; people might say that
the illegality of some positions is obvious, while in other cases the illegality is discernible only through retro-analysis, but there's no
formal definition of what sort of observations require retro-analysis.
If White has a bishop on a1 and a pawn on b2, is this obviously illegal
or did you have to use retro-analysis to figure that out?

In any case, what I found odd about the example that I began this thread
with is that XG allowed me to set up the position and *itself generated
the XGID in question*, but then rejected it as invalid. An analogy that
comes to mind is that I fill out a government application for some form
of government ID, and the government accepts the application and issues
me an ID card, but then the moment I try to use it, the government
rejects the card as invalid. If they regard the card as invalid, then
why did they go ahead and issue it in the first place?

---
Tim Chow

I'd agree that the distinction isn't used in chess, but I think it makes sense there too.
An invalid position would be one in which basic concepts don't even make sense --
for example both players are in check.
Of course, what is "obvious" is hugely determinant on the audience. To a beginner
audience who have recently learned the rules of chess, the white bishop on a1 and white pawn on b2
are not obviously illegal, and retro-analysis is needed.
Your analogy is a close one. However, to me, it simply indicates an imperfection rather than
anything bizarre or anomalous. In the government analogy, the department accepting the
application simply has different standards to the department deciding on card acceptance --
not a very surprising type of bug.
I once worked for a bookmaker whose car park was too small for the number of employees.
Next door to the bookmaker was some type of theme park or amusement park for kids.
I was told very clearly, both informally and in emails, that there was an arrangement between
the two companies which enabled me to park at the amusement park when our own car park was full.
However, when I actually did park there, a guy came irately after me, claiming to know nothing of
any arrangement between our two companies.
Is that odd? No, not really. Life's like that sometimes -- just a normal communications glitch.
The moral was clear -- don't park there.

Paul

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

On 12/3/2022 10:46 AM, peps...@gmail.com wrote:

Your analogy is a close one. However, to me, it simply indicates an imperfection rather than
anything bizarre or anomalous. In the government analogy, the department accepting the
application simply has different standards to the department deciding on card acceptance --
not a very surprising type of bug.

Well, there are lots of different departments in the government.
XG has just a single person who does 100% of the programming.

Obviously, it's not surprising to have minor bugs in any complex
piece of software. However, it seemed particularly ironic to see
XG declaring that a string was improperly formatted when it had
generated the string itself.

---
Tim Chow

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

On December 2, 2022 at 4:58:25 PM UTC-7, Simon Woodhead wrote:

On 27/11/2022 10:59 am, Timothy Chow wrote:

"Invalid position! The position cannot be imported.
XGID=-AADBA--------------------:0:0:1:51:0:0:0:0:10

I had already posted that Gnubg accepts this. What
is interesting is that if you save it from Gnubg as a
Jellyfish position file, (with or without the dice roll),
then XG opens it without any complaints... :o)

XG isn't perfect. It doesn't complain about this: XGID=aCCBBBB------------ccbbbbA:0:0:-1:51:0:0:0:0:10

Very interesting that you could create and save this
which XG accepts back without complaints.

However, unlike Tim's example, this can't be pasted
into Gnubg, (it shows the opening position as with
other positions that it deems "illegal"). In fact, if you
create this position in Gnubg by hand, you can't save
and reopen it in any format.

Most wouldn't make anything out of such idiotic bugs
in bots but I think they, just as any other types of bugs,
do matter because each one makes me wonder what
else may the bots be doing wrong that we may never
come to discover...??

MK

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

On 12/2/2022 6:58 PM, Simon Woodhead wrote:

On 27/11/2022 10:59 am, Timothy Chow wrote:

"Invalid position! The position cannot be imported. The
source was not properly formatted." But the XGID was generated
by XG itself, so it's a little bizarre that it would complain
that the string is "not properly formatted."

XG isn't perfect. It doesn't complain about this: XGID=aCCBBBB------------ccbbbbA:0:0:-1:51:0:0:0:0:10

And then there's this:

XGID=----BDE------------ddbbc--:1:-1:1:51:0:0:0:5:10

X:You O:O
Score is X:0 O:0 5 pt.(s) match.
+13-14-15-16-17-18------19-20-21-22-23-24-+
| | | O O O O O | +---+
| | | O O O O O | | 2 |
| | | O O O | +---+
| | | O O |
| | | |
| |BAR| |
| | | X |
| | | X X |
| | | X X |
| | | X X X |
| | | X X X |
+12-11-10--9--8--7-------6--5--4--3--2--1-+
Pip count X: 58 O: 64 X-O: 0-0/5
Cube: 2, O own cube
X to play 51

1. 4-ply Cannot Move eq:+0.032
Player: 59.53% (G:0.00% B:0.00%)
Opponent: 40.47% (G:0.00% B:0.00%)

2. 3-ply Cannot Move eq:+0.406 (+0.374)
Player: 75.21% (G:0.00% B:0.00%)
Opponent: 24.79% (G:0.00% B:0.00%)

3. 3-ply Cannot Move eq:+0.387 (+0.355)
Player: 74.43% (G:0.00% B:0.00%)
Opponent: 25.57% (G:0.00% B:0.00%)

4. 1-ply Cannot Move eq:+0.407 (+0.375)
Player: 75.21% (G:0.00% B:0.00%)
Opponent: 24.79% (G:0.00% B:0.00%)

5. 1-ply Cannot Move eq:+0.402 (+0.370)
Player: 74.99% (G:0.00% B:0.00%)
Opponent: 25.01% (G:0.00% B:0.00%)


eXtreme Gammon Version: 2.10, MET: Kazaross XG2

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

I can't reproduce ah...Clem's example. How did it arise in the first
place? If I copy and paste the XGID into XG, everything seems normal.

On 12/7/2022 1:16 PM, ah...Clem wrote:

And then there's this:

XGID=----BDE------------ddbbc--:1:-1:1:51:0:0:0:5:10

X:You O:O
Score is X:0 O:0 5 pt.(s) match.
+13-14-15-16-17-18------19-20-21-22-23-24-+
| | | O O O O O | +---+
| | | O O O O O | | 2 |
| | | O O O | +---+
| | | O O |
| | | |
| |BAR| |
| | | X |
| | | X X |
| | | X X |
| | | X X X |
| | | X X X |
+12-11-10--9--8--7-------6--5--4--3--2--1-+
Pip count X: 58 O: 64 X-O: 0-0/5
Cube: 2, O own cube
X to play 51

1. 4-ply Cannot Move eq:+0.032
Player: 59.53% (G:0.00% B:0.00%)
Opponent: 40.47% (G:0.00% B:0.00%)

2. 3-ply Cannot Move eq:+0.406 (+0.374)
Player: 75.21% (G:0.00% B:0.00%)
Opponent: 24.79% (G:0.00% B:0.00%)

3. 3-ply Cannot Move eq:+0.387 (+0.355)
Player: 74.43% (G:0.00% B:0.00%)
Opponent: 25.57% (G:0.00% B:0.00%)

4. 1-ply Cannot Move eq:+0.407 (+0.375)
Player: 75.21% (G:0.00% B:0.00%)
Opponent: 24.79% (G:0.00% B:0.00%)

5. 1-ply Cannot Move eq:+0.402 (+0.370)
Player: 74.99% (G:0.00% B:0.00%)
Opponent: 25.01% (G:0.00% B:0.00%)

eXtreme Gammon Version: 2.10, MET: Kazaross XG2

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

On 12/8/2022 8:50 AM, Timothy Chow wrote:

I can't reproduce ah...Clem's example.  How did it arise in the first place?  If I copy and paste the XGID into XG, everything seems normal.

On 12/7/2022 1:16 PM, ah...Clem wrote:

And then there's this:

XGID=----BDE------------ddbbc--:1:-1:1:51:0:0:0:5:10

I played a match on FIBS, analyzed it as per usual, and that's what XG
spat out. I didn't try pasting the ID into XG. I'll take a look.

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

On 12/8/2022 11:03 AM, ah...Clem wrote:

I played a match on FIBS, analyzed it as per usual, and that's what XG
spat out. I didn't try pasting the ID into XG. I'll take a look.

Ah, yes, I've also experienced bizarre anomalies when XG analyzes
a match. Here's a recent thread on the topic.

https://groups.google.com/g/rec.games.backgammon/c/gG9FF3i3hy0/m/M0ilvaNaAgAJ

Or just look at these two examples for a good laugh.

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

Cue Stick suggesting that these were caused by the computer doing
"other things" while the analysis was running.

---
Tim Chow

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

On Friday, December 9, 2022 at 8:44:09 AM UTC-5, Tim Chow wrote:

On 12/8/2022 11:03 AM, ah...Clem wrote:

I played a match on FIBS, analyzed it as per usual, and that's what XG
spat out. I didn't try pasting the ID into XG. I'll take a look.

Ah, yes, I've also experienced bizarre anomalies when XG analyzes
a match. Here's a recent thread on the topic.

https://groups.google.com/g/rec.games.backgammon/c/gG9FF3i3hy0/m/M0ilvaNaAgAJ

Or just look at these two examples for a good laugh.

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

Cue Stick suggesting that these were caused by the computer doing
"other things" while the analysis was running.

---
Tim Chow

More like cue you to cue me. I already passed on the idea yesterday when I first saw the post. If people want to remain ignorant who am I to constantly try to stop them.

Stick

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