Understanding PDN 3.0

[TAILLE]

Hi,

I am currently developping the new PDN 3.0 standard but some points stay rather unclear.
I understood that the FEN command allows to code any sequence of positions.
How do you code the sequence made of the the three following positions?


Damy curent coding is the following:
[Event "Evenement"][Date "Date"][White "Damy"][Black ""][Result "Résultat"][SetUp "1"]
/FEN "W:W31-50:B1-20"/
/FEN "B:W28,31,33-50:B1-18,20"/
01... 14-19*

It is rather strange to begin with a FEN concerning the initial position and to continue with another FEN command but at least it looks logic.
What is your undertanding of the PDN 3.0 on this point?

[Wieger Wesselink]

Hi,

I am currently developping the new PDN 3.0 standard but some points stay rather unclear.
I understood that the FEN command allows to code any sequence of positions.
How do you code the sequence made of the the three following positions?


Damy curent coding is the following:
[Event "Evenement"][Date "Date"][White "Damy"][Black ""][Result "Résultat"][SetUp "1"]
/FEN "W:W31-50:B1-20"/
/FEN "B:W28,31,33-50:B1-18,20"/
01... 14-19*

It is rather strange to begin with a FEN concerning the initial position and to continue with another FEN command but at least it looks logic.
What is your undertanding of the PDN 3.0 on this point?

Hi Gérard,

The PDN that you generate looks correct to me. Note that the SetUp tag is not needed. The setup command of the initial position can also be left out, since by default a PDN game starts from the initial position.

I'd like to understand what it is that causes confusion for you. The PDN grammar defines exactly where setup commands may appear, so this is probaby not the issue(?) The interpretation of a setup command is that the move that appears directly after it should be applied to the position contained in the setup. Would some examples be enough to clarify things?

It is possible to formalize what position corresponds to each location in the game body of a PDN game. Moreover it is possible to formalize when the moves of a PDN games are valid (i.e. they must be legal in the position that precedes the move), and when the move numbering of a PDN game is valid. This will take some effort though. Especially formalizing valid moves is not a simple task, since it requires a thorough understanding of the rules of the different draughts variants. And I learned from Rein that the capture rules of Italian draughts are very tricky.

Regards,

Wieger

[TAILLE]

Hi,

I am currently developping the new PDN 3.0 standard but some points stay rather unclear.
I understood that the FEN command allows to code any sequence of positions.
How do you code the sequence made of the the three following positions?


Damy curent coding is the following:
[Event "Evenement"][Date "Date"][White "Damy"][Black ""][Result "Résultat"][SetUp "1"]
/FEN "W:W31-50:B1-20"/
/FEN "B:W28,31,33-50:B1-18,20"/
01... 14-19*

It is rather strange to begin with a FEN concerning the initial position and to continue with another FEN command but at least it looks logic.
What is your undertanding of the PDN 3.0 on this point?

Hi Gérard,

The PDN that you generate looks correct to me. Note that the SetUp tag is not needed. The setup command of the initial position can also be left out, since by default a PDN game starts from the initial position.

I'd like to understand what it is that causes confusion for you. The PDN grammar defines exactly where setup commands may appear, so this is probaby not the issue(?) The interpretation of a setup command is that the move that appears directly after it should be applied to the position contained in the setup. Would some examples be enough to clarify things?

It is possible to formalize what position corresponds to each location in the game body of a PDN game. Moreover it is possible to formalize when the moves of a PDN games are valid (i.e. they must be legal in the position that precedes the move), and when the move numbering of a PDN game is valid. This will take some effort though. Especially formalizing valid moves is not a simple task, since it requires a thorough understanding of the rules of the different draughts variants. And I learned from Rein that the capture rules of Italian draughts are very tricky.

Regards,

Wieger

Hi Wieger,

Thank you for your answer.
My point concerns precisely your following statement:
The setup command of the initial position can also be left out, since by default a PDN game starts from the initial position
If you simply write:
/FEN "B:W28,31,33-50:B1-18,20"/
01... 14-19*
my understanding is that the PDN files describes only 2 positions; the initial position seems not part of the file is it?

On the other if you write
/FEN "W:W31-50:B1-20"/
/FEN "B:W28,31,33-50:B1-18,20"/
01... 14-19*
you really described 3 positions (with obviously a strange move between the first (intitial) position and the second position) and this is very different for me.

For this reason the FEN command /FEN "W:W31-50:B1-20"/ seems mandatory for describing these 3 positions. Here is my point. Don't you agree?

[Wieger Wesselink]

Hi,

I am currently developping the new PDN 3.0 standard but some points stay rather unclear.
I understood that the FEN command allows to code any sequence of positions.
How do you code the sequence made of the the three following positions?


Damy curent coding is the following:
[Event "Evenement"][Date "Date"][White "Damy"][Black ""][Result "Résultat"][SetUp "1"]
/FEN "W:W31-50:B1-20"/
/FEN "B:W28,31,33-50:B1-18,20"/
01... 14-19*

It is rather strange to begin with a FEN concerning the initial position and to continue with another FEN command but at least it looks logic.
What is your undertanding of the PDN 3.0 on this point?

Hi Gérard,

The PDN that you generate looks correct to me. Note that the SetUp tag is not needed. The setup command of the initial position can also be left out, since by default a PDN game starts from the initial position.

I'd like to understand what it is that causes confusion for you. The PDN grammar defines exactly where setup commands may appear, so this is probaby not the issue(?) The interpretation of a setup command is that the move that appears directly after it should be applied to the position contained in the setup. Would some examples be enough to clarify things?

It is possible to formalize what position corresponds to each location in the game body of a PDN game. Moreover it is possible to formalize when the moves of a PDN games are valid (i.e. they must be legal in the position that precedes the move), and when the move numbering of a PDN game is valid. This will take some effort though. Especially formalizing valid moves is not a simple task, since it requires a thorough understanding of the rules of the different draughts variants. And I learned from Rein that the capture rules of Italian draughts are very tricky.

Regards,

Wieger

Hi Wieger,

Thank you for your answer.
My point concerns precisely your following statement:
The setup command of the initial position can also be left out, since by default a PDN game starts from the initial position
If you simply write:
/FEN "B:W28,31,33-50:B1-18,20"/
01... 14-19*
my understanding is that the PDN files describes only 2 positions; the initial position seems not part of the file is it?

On the other if you write
/FEN "W:W31-50:B1-20"/
/FEN "B:W28,31,33-50:B1-18,20"/
01... 14-19*
you really described 3 positions (with obviously a strange move between the first (intitial) position and the second position) and this is very different for me.

For this reason the FEN command /FEN "W:W31-50:B1-20"/ seems mandatory for describing these 3 positions. Here is my point. Don't you agree?

Hi Gérard,

Yes, I completely agree with your observations. So the interpretation is that a PDN game starts in the initial position, unless the game body starts with a FEN setup command, or the header contains a FEN tag. In those cases it starts with the FEN position. I will clarify this in the standard, since it is not obvious.

Regards,

Wieger

[TAILLE]

Hi Gérard,

Yes, I completely agree with your observations. So the interpretation is that a PDN game starts in the initial position, unless the game body starts with a FEN setup command, or the header contains a FEN tag. In those cases it starts with the FEN position. I will clarify this in the standard, since it is not obvious.

Regards,

Wieger

Hi Wieger,

What do you mean by FEN tag? I understood that the FEN tag disappeared from the standard and it was identified as a backward compatibility problem. Do you want to allow both the FEN tag and the FEN command?

Now we agreed with my first point I have another one still concerning the FEN command. How do you handle the numbering of the moves when FEN command are inserted?
My view is the following: normally the sequence of moves is one white move, one black move, one white move, one black move ....If a FEN command continue to respect this sequence then I count a FEN command as a ply. If a FEN command does not respect this sequence then I count the FEN command as two plies (in other word a null move followed by another move).

Exemples:
01.32-28
/FEN "W:W28,33-50:B1-16,18-21"/
/FEN "B:W28,32-36,38-50:B1-11,13-16,18-21"/
02... 7-12 03.41-37 1-7 04.46-41*

but:

01.32-28
/FEN "B:W28,33-50:B1-16,18-21"/
/FEN "B:W28,32-36,38-50:B1-11,13-16,18-21"/
03... 7-12 04.41-37 1-7 05.46-41*

What is your interpretation?

Regards
Gérard

[Wieger Wesselink]

Hi Wieger,

What do you mean by FEN tag? I understood that the FEN tag disappeared from the standard and it was identified as a backward compatibility problem. Do you want to allow both the FEN tag and the FEN command?

Now we agreed with my first point I have another one still concerning the FEN command. How do you handle the numbering of the moves when FEN command are inserted?
My view is the following: normally the sequence of moves is one white move, one black move, one white move, one black move ....If a FEN command continue to respect this sequence then I count a FEN command as a ply. If a FEN command does not respect this sequence then I count the FEN command as two plies (in other word a null move followed by another move).

Exemples:
01.32-28
/FEN "W:W28,33-50:B1-16,18-21"/
/FEN "B:W28,32-36,38-50:B1-11,13-16,18-21"/
02... 7-12 03.41-37 1-7 04.46-41*

but:

01.32-28
/FEN "B:W28,33-50:B1-16,18-21"/
/FEN "B:W28,32-36,38-50:B1-11,13-16,18-21"/
03... 7-12 04.41-37 1-7 05.46-41*

What is your interpretation?

Regards
Gérard

Hi Gérard,

The FEN tag is still present, see http://pdn.fmjd.org/pdntags.html under Game related tags. But this is only for backward compatibility. I would say that using a FEN setup command is the preferred way of specifying the initial position.

The move numbering has not been specified in the standard. For move numbering I would handle a FEN setup as a normal move as long as the player to move in the FEN position is as expected, and add a ply if there is a conflict (for example if the last move was a white move, and white is to move in the FEN position).

So in your first example I would prefer to do it like this:

01.32-28
02./FEN "W:W28,33-50:B1-16,18-21"/
/FEN "B:W28,32-36,38-50:B1-11,13-16,18-21"/
03... 7-12 04.41-37 1-7 05.46-41*

The reason I prefer it like this, is that I want to avoid that the same player is to move in more than one position corresponding to the same move number. But this is not a very convincing argument.

It does happen in practice that a player moves twice. I remember that Jannes van der Wal has won an important game like this. This is of course illegal, but nevertheless the official rules should specify whether this counts for one or two moves. I will aks in the general forum what people think about this.

Regards,

Wieger

[TAILLE]

Hi Wieger,

Hi Gérard,

The FEN tag is still present, see http://pdn.fmjd.org/pdntags.html under Game related tags. But this is only for backward compatibility. I would say that using a FEN setup command is the preferred way of specifying the initial position.

The move numbering has not been specified in the standard. For move numbering I would handle a FEN setup as a normal move as long as the player to move in the FEN position is as expected, and add a ply if there is a conflict (for example if the last move was a white move, and white is to move in the FEN position).

So in your first example I would prefer to do it like this:

01.32-28
02./FEN "W:W28,33-50:B1-16,18-21"/
/FEN "B:W28,32-36,38-50:B1-11,13-16,18-21"/
03... 7-12 04.41-37 1-7 05.46-41*

Regards,

Wieger

Oops I do not understand your numbering. For my first exemple I expected something like:
01.32-28
/FEN "W:W28,33-50:B1-16,18-21"/ {instead of a black move}
02./FEN "B:W28,32-36,38-50:B1-11,13-16,18-21"/ {instead of a white move}
02... 7-12 04.41-37 1-7 05.46-41*

and for my second example
01.32-28
02./FEN "B:W28,33-50:B1-16,18-21"/ {instead of NULL move followed by a white move}
03./FEN "B:W28,32-36,38-50:B1-11,13-16,18-21"/ {instead of NULL move followed by a white move}
03... 7-12 04.41-37 1-7 05.46-41*

Could you clarify your view?

Regards
Gérard

[Wieger Wesselink]

Hi Wieger,

Hi Gérard,

The FEN tag is still present, see http://pdn.fmjd.org/pdntags.html under Game related tags. But this is only for backward compatibility. I would say that using a FEN setup command is the preferred way of specifying the initial position.

The move numbering has not been specified in the standard. For move numbering I would handle a FEN setup as a normal move as long as the player to move in the FEN position is as expected, and add a ply if there is a conflict (for example if the last move was a white move, and white is to move in the FEN position).

So in your first example I would prefer to do it like this:

01.32-28
02./FEN "W:W28,33-50:B1-16,18-21"/
/FEN "B:W28,32-36,38-50:B1-11,13-16,18-21"/
03... 7-12 04.41-37 1-7 05.46-41*

Regards,

Wieger

Oops I do not understand your numbering. For my first exemple I expected something like:
01.32-28
/FEN "W:W28,33-50:B1-16,18-21"/ {instead of a black move}
02./FEN "B:W28,32-36,38-50:B1-11,13-16,18-21"/ {instead of a white move}
02... 7-12 04.41-37 1-7 05.46-41*

and for my second example
01.32-28
02./FEN "B:W28,33-50:B1-16,18-21"/ {instead of NULL move followed by a white move}
03./FEN "B:W28,32-36,38-50:B1-11,13-16,18-21"/ {instead of NULL move followed by a white move}
03... 7-12 04.41-37 1-7 05.46-41*

Could you clarify your view?

Regards
Gérard

Hi Gérard,

I mixed up black and white in a FEN setup. The player to move in a FEN setup should be the same as the color of the preceding move, otherwise there is a conflict. So I believe we have the same opinion on how to number the moves.

Regards,

Wieger

[TAILLE]

Hi Wieger,

I have a third point and it concerns the variants. How do you code several variants for the same move?
For exemple you would like to show the main line 1.32-28 16-21 and the variants 1.33-28, 1.33-29 and 1.34-30
Several solutions are possible according to the current PDN 3. 0 standard:

1.32-28 (1.33-28 (1.33-29 (1.34-30))) 1...16-21
or
1.32-28 (1.33-28) (1.33-29) (1.34-30) 1...16-21
or a mixure like the following
1.32-28 (1.33-28 (1.33-29) (1.34-30)) 1...16-21

What is your recommendation for building a PDN file?
My preference is the second form above because it is the easiest for me to read as a human and it would be a pity to have several possibilities here. Anyway Damy accepts all these forms so it is not a real issue providing you confirm that all these forms are valid.

Regards

[Wieger Wesselink]

Hi Wieger,

I have a third point and it concerns the variants. How do you code several variants for the same move?
For exemple you would like to show the main line 1.32-28 16-21 and the variants 1.33-28, 1.33-29 and 1.34-30
Several solutions are possible according to the current PDN 3. 0 standard:

1.32-28 (1.33-28 (1.33-29 (1.34-30))) 1...16-21
or
1.32-28 (1.33-28) (1.33-29) (1.34-30) 1...16-21
or a mixure like the following
1.32-28 (1.33-28 (1.33-29) (1.34-30)) 1...16-21

What is your recommendation for building a PDN file?
My preference is the second form above because it is the easiest for me to read as a human and it would be a pity to have several possibilities here. Anyway Damy accepts all these forms so it is not a real issue providing you confirm that all these forms are valid.

Regards

Hi Gérard,

I also prefer the second form 1.32-28 (1.33-28) (1.33-29) (1.34-30) 1...16-21, since to me this is the most readable.

It might be interesting to know how other programs handle this. For example TurboDambase supports variations, but I have no idea how they are printed in PDN format.

Regards,

Wieger

[Wieger Wesselink]

It does happen in practice that a player moves twice. I remember that Jannes van der Wal has won an important game like this. This is of course illegal, but nevertheless the official rules should specify whether this counts for one or two moves. I will aks in the general forum what people think about this.

It turns out that the regulations of the KNDB pay attention to this case, but unfortunately they do not give a conclusive answer. Such a case can be interpreted as two regular moves with an illegal null move inbetween, or as one illegal move consisting of two moves. Which of the two interpretations should be chosen depends on whether the opponent "acted as if he played a move".

[TAILLE]

Hi Wieger,

It does happen in practice that a player moves twice. I remember that Jannes van der Wal has won an important game like this. This is of course illegal, but nevertheless the official rules should specify whether this counts for one or two moves. I will aks in the general forum what people think about this.

It turns out that the regulations of the KNDB pay attention to this case, but unfortunately they do not give a conclusive answer. Such a case can be interpreted as two regular moves with an illegal null move inbetween, or as one illegal move consisting of two moves. Which of the two interpretations should be chosen depends on whether the opponent "acted as if he played a move".

I also pay a lot of attention to NULL moves.
Here is an example of coding made by Damy. In this sequence you can see two NULL moves : the second white move and the 5th black move.
01.32-28 17-21 02... 21-26 03.37-32 26x37 04.42x31 11-17 05.41-37 06.46-41 6-11 07.31-27*
I guess a strict application of PDN 3.0 will lead to the use of the FEN command to resolve the problem but I prefer to use the numbering of moves to show a NULL move.
The main advantage being that it is very easy to read for a human.
In any case the previews PDN standard does not deal with NULL moves. That means that in any case the coding of a null move (whatever the choice for the coding) will create a backward compatibility problem. It will be a pity the new PDN 3.0 standard does not deal with them.
What do you think about Damy coding?

BTW how do you code an empty board with black to play? Damy coding is
/FEN "B::"/
Do you agree with this coding?

[Wieger Wesselink]

I also pay a lot of attention to NULL moves.
Here is an example of coding made by Damy. In this sequence you can see two NULL moves : the second white move and the 5th black move.
01.32-28 17-21 02... 21-26 03.37-32 26x37 04.42x31 11-17 05.41-37 06.46-41 6-11 07.31-27*
I guess a strict application of PDN 3.0 will lead to the use of the FEN command to resolve the problem but I prefer to use the numbering of moves to show a NULL move.
The main advantage being that it is very easy to read for a human.
In any case the previews PDN standard does not deal with NULL moves. That means that in any case the coding of a null move (whatever the choice for the coding) will create a backward compatibility problem. It will be a pity the new PDN 3.0 standard does not deal with them.
What do you think about Damy coding?

BTW how do you code an empty board with black to play? Damy coding is
/FEN "B::"/
Do you agree with this coding?

Sorry for my late reply. I agree that a null move notation could be useful, and your proposed notation looks fine with me. For the moment I have added it as a proposal to the standard. In a next version of the standard, this could become an official notation. I also added your setup example to the standard.