Draw Rules (halfmoveclock,repetition)

[bob]

Perhaps it is good to mention one exception: If the 100th consecutive reversible ply checkmates the opponent, it is a win, not a draw.

Some engines test this in the wrong order, and then let themselves be checkmated on the 50th move, because they think it will be draw anyway!

I've seen that. There is an even uglier case where a program will make _any_ 50th move, such as hanging the queen, but then run into the race condition on FICS and the opponent takes the queen before they can claim the draw and the game is now lost. But even more importantly, if the 100th consecutive move is reversible, it is not necessarily a draw. You do not have to claim it, but of course your opponent can, unless he was checkmated by your 50th move.

[bob]

1.
=========

example:

turn: w hmc: 0 moved: true hmcInc: 1 claimDraw: false PressingClock(switchRightToMove): true
turn: b hmc: 1 moved: true hmcInc: 2 claimDraw: false PressingClock(switchRightToMove): true
...
turn: b hmc: 99 moved: true(*) hmcInc: 100 claimDraw: YES PressingClock(switchRightToMove): FALSE

*: here the move is considered as done(that makes the confusion)!

white doesn t get back the turn.
In other words Black can(has to,if he wants) claim draw,
before giving up the right to move.


2. (to Mike)
==========

That castle is(or counts) a reversible move is new to me !
is that really the case ?

regards.

1. Once you press the clock you've given up the right to claim a draw until your next move.

2. Reversible is really a word that best applies to 3-fold repetition, not the 50 move rule. Castling is not reversible as you cannot possibly repeat a position that occurred prior to castling once you have castled.
For the 50 move rule, however, we're only concerned with captures and pawn pushes. Castling moves, while not reversible, do not reset the 50 move counter, because they are not captures or pawn pushes.

It is easy to repeat the position after you castle, but you can't repeat the position with the same potential moves available. But FIDE doesn't require that. It does for repetition, and for 3-fold repetition, any move in the sequence will break the repetition if it is a castle. But not the 50 move rule. An inconsistency. But there.

[bob]

He had mentioned claiming a draw after 49 moves. That is not exactly correct. Even though you don't play your move on the board (50th move) you do have to write it down and show it to the arbiter/TD, which commits you to playing that move. I was not thinking in the same context he was using, with respect to where you physically make the claim (which is after you have announced your intention to play a specific 50th move).

[Gerd Isenberg]

1. Once you press the clock you've given up the right to claim a draw until your next move.

2. Reversible is really a word that best applies to 3-fold repetition, not the 50 move rule. Castling is not reversible as you cannot possibly repeat a position that occurred prior to castling once you have castled.
For the 50 move rule, however, we're only concerned with captures and pawn pushes. Castling moves, while not reversible, do not reset the 50 move counter, because they are not captures or pawn pushes.

I am probably guilty for the confusion about reversible moves as well, because I called Halfmove Clock the Reversible Halfmove Counter in cpw - corrected

In the past I had (or still have?) a bug in my program concerning this. For "performance considerations" in repetition detection while traversing the zobrist record, I decided to terminate as early as possible and reset the Halfmove Clock also if castle rights changed. Is there any known game where this bug would have caused a different result, e.g. not accepting a draw claim? That would require a game where no pawn move or capture occurred after castling?

[xsadar]

Perhaps it is good to mention one exception: If the 100th consecutive reversible ply checkmates the opponent, it is a win, not a draw.

Some engines test this in the wrong order, and then let themselves be checkmated on the 50th move, because they think it will be draw anyway!

Hmm... I think I have this bug. I'll have to look into it. I've never seen the problem in actual games though. I would imagine it's a fairly rare occurrence.

[hgm]

IIRC I witnessed Arasan lose a game due to this in a prrevious edition of OpenWar.

[xsadar]

1.
=========

example:

turn: w hmc: 0 moved: true hmcInc: 1 claimDraw: false PressingClock(switchRightToMove): true
turn: b hmc: 1 moved: true hmcInc: 2 claimDraw: false PressingClock(switchRightToMove): true
...
turn: b hmc: 99 moved: true(*) hmcInc: 100 claimDraw: YES PressingClock(switchRightToMove): FALSE

*: here the move is considered as done(that makes the confusion)!

white doesn t get back the turn.
In other words Black can(has to,if he wants) claim draw,
before giving up the right to move.


2. (to Mike)
==========

That castle is(or counts) a reversible move is new to me !
is that really the case ?

regards.

1. Once you press the clock you've given up the right to claim a draw until your next move.

2. Reversible is really a word that best applies to 3-fold repetition, not the 50 move rule. Castling is not reversible as you cannot possibly repeat a position that occurred prior to castling once you have castled.
For the 50 move rule, however, we're only concerned with captures and pawn pushes. Castling moves, while not reversible, do not reset the 50 move counter, because they are not captures or pawn pushes.

It is easy to repeat the position after you castle, but you can't repeat the position with the same potential moves available. But FIDE doesn't require that. It does for repetition, and for 3-fold repetition, any move in the sequence will break the repetition if it is a castle. But not the 50 move rule. An inconsistency. But there.

I suppose we're talking about the same thing, just using the terminology differently, as I define the position to include the castling rights and e.p. legality not just the piece arrangement.

[Desperado]

Hi everyone again,

because i felt not very happy about some conclusions, explanations
given in this thread, i decided to call a good friend. He is a strong
chess player,chess trainer and acted as well as arbiter.
It started with the first call,continued with 2nd and ended with a fourth call.
In sum i think we were phoning about an hour.

My intention is to give a summary, where someone can be sure to interpret the fide-rules correctly.

Most of you will have correct implementations , but who knows what the
following summary can be useful for. Maybe only a part is useful, maybe
the complete summary. (for chessplayer + chessprogrammers)

Code: Select all

================================================================================
1: Definitions Move:
================================================================================

the following movetypes are needed for the following explanations.

TYPE_1: executed move (Emove)

	- a move is executed (but not completed) if it is physically done
 	  on the board.

TYPE_2: completed move (Cmove) 

	- a move is completed, if it is executed(type1)
   - the _own_ timer has been stopped.

TYPE_3: intention to move (Imove)

	- a move which s.o. is allowed to make physically on the board.
	- is neither type1 nor (in any case) type2

================================================================================
2: Handle BOARD/POSITION STATUS:
================================================================================


a: Equal position(Repetition)
--------------------

	- castle rights are the same
	- ep-status is the same
	- color to move is the same
	- pieces of the same types occupy the same squares.

b: rule50
--------------------

	- counter = 0 if no _Cmove_ is done so far

	     if - pawn-move(_Cmove_) reset to 1
	else if - capture-move (_Cmove_) reset to 1
	else    - increment counter on _Cmove_

================================================================================
3: Creating Draw Conditions:
================================================================================


a: 3-fold-repetition

	- having an _Imove_ creating a position of 2a
	  occuring 2x before in the gamehistory.

	  (The corresponding _Cmove_ would lead to the physically
           3-fold-repetition)

b: rule50

	- having a counter set to 99, based on the rules 2b
	- having an _Imove_ which corresponding _Cmove_ would set the counter to 100
 
	  (The corresponding _Cmove_ would lead to the physically
           100 plies(50 moves) of both sides)

================================================================================
4: Claim on Draw:
================================================================================


	- having an _Imove_ available of 3a or 3b _createDrawCondition_
	- without any condition if the draw-condition is a _keptDrawCondition_.

	4.1: if all conditions are given on the definitions so far the
	     arbiter has to agree the draw.
	     The game ends immediatelly, without converting the _Imove_ to _Cmove_.
	     (the move won t be executed in any form)

	4.1.1: if the player who is creating the Draw-Condition claims draw,
	       the physically draw-position will never appear on the board.
	

================================================================================
5: Broken Situations
================================================================================

	5.1: broken counter(ex: reset on castle)
	     
	     - _Imove_ becomes _Cmove_ (no other moveChoice possible)
	     - draw offer (through the claim) is kept
	       opponent is able to draw immediatelly.

	5.2: broken repetition (ex: broken ep-status)

	     - like 5.1

	5.3: broken moves (ex: Nf6d4)

	     - another move _has to_ be done.
	     - draw offer (through the claim) is kept
	       opponent is able to draw immediatelly.

================================================================================
6: Programmer Issues:
================================================================================

	6.1 MOVE

		- all moves are _Imoves_ as long the moves dont
		  leave the engine through communiction.
		  
	6.2 Root-Position:

		- Engine = Player
		- Gui	 = Arbiter

		- if at the root an _Imove_ is available which creates the 
		  drawConditionsthe engine should mark the move in some way.

		  example:
			  bestmove e2a6
			  bestmove e2a6C (would be great, C for claim).
		- The gui should immediatelly draw the position,and end the game.
		  The move shouldnt be executed.(Assuming no broken situations).

	6.3 Iternal Search: 

		- moveDo() = player
		- search() = arbiter

		The iternal execution of a move can be seen as combination of
		_Imove_+_Cmove_ type.The halfmoveclock is incremented on the
		above given conditions.(lets say in the moveDo() function)


		Having a position where halfmovelcok is 99, additionaly having
		a move that creates the drawCondition,and executing it(moveDo()),
		the score of the following position (search-call) is 0. 
		In this case _our_ arbiter is adviced on the condition hmc>=100 to
		return the drawScore.
		Same for 3-fold-repetion.We execute our move. _Our_ arbiter
		is detecting the position for the 3rd time and returns the drawScore.

	6.4 Difference to OTB:

		- The point is, we can handle the rules internal in a "physical" way,
		  assuming the executed move is a claim on draw.
		  

		In this manner the search returns 0 when:

		1. hmc >= 100 (rule50)
		2. the current position is found 2x before in the gamehistory.

	6.5 Hashing Equal positions:

		- the hashkey for a position should include the listed
		  board information of 2a.

Some of the definitions given in this text are _combinations_ of fide-rules-articles.
In hope that my english is not to bad, producing some changes in its
content, i hope further the post will help to avoid,find any kind of bugs.

simple: hope it can help

best regards Michael

[xsadar]

Code: Select all

b: rule50
--------------------

	- counter = 0 if no _Cmove_ is done so far

	     if - pawn-move(_Cmove_) reset to 1
	else if - capture-move (_Cmove_) reset to 1
	else    - increment counter on _Cmove_

The counter should reset to 0 not to 1 when a pawn move or capture is made. The counter should count the number of consecutive moves that are not pawn moves or captures. If you reset to 1 instead of 0, you are counting the number of moves since the last pawn move or capture. A subtle but important difference.

In regards to marking a move as a draw claim, I would be very happy if xboard and ics supported that, but currently they don't. UCI interfaces of course will claim it on your behalf -- whether you want them to or not, -- so marking the move in UCI should be unnecessary.

[Desperado]

Code: Select all

b: rule50
--------------------

	- counter = 0 if no _Cmove_ is done so far

	     if - pawn-move(_Cmove_) reset to 1
	else if - capture-move (_Cmove_) reset to 1
	else    - increment counter on _Cmove_

The counter should reset to 0 not to 1 when a pawn move or capture is made. The counter should count the number of consecutive moves that are not pawn moves or captures. If you reset to 1 instead of 0, you are counting the number of moves since the last pawn move or capture. A subtle but important difference.

In regards to marking a move as a draw claim, I would be very happy if xboard and ics supported that, but currently they don't. UCI interfaces of course will claim it on your behalf -- whether you want them to or not, -- so marking the move in UCI should be unnecessary.

Hi Mike,

yes, you are right. counter = 0 after reset !

While writing the post, i noticed that this can be wrong,but was to lazy
to think about , after all the other stuff. First i wrote just _reset_, now i am
happy that i have added reset=1 and i am more happy you could correct
it .

cheers