Author: David Rasmussen
Date: 15:27:10 01/31/03
It doesn't really make sense in FEN to be able to define the halfmove clock (or whatever they call it), without being able to define the positions that went before. For example, in this position: [D]4q1kb/1pr2p1p/p3p1pP/P2pP1N1/3P1QP1/1P3R2/5P1K/8 w - - 27 100 The halfmove clock is 27. I understand that it is important for knowing when the 50 moves limit has been reached, and that's why it's there. But to specify the position, or the "environment" of the game totally, you will have to say what the last 27 positions were too, so you can also detect repetitions. If you just give this FEN to an engine, it might suggest a move that leads to a repetition, without realizing it. Practically, this undefinedness can be a source of bugs in an engine. I know, because I had one :) My program checks for repetition at the root and in search (although differently) by checking at most the last 27 positions in this case (every other, to only check ones with the same player to move etc.). In a normal game started from the initial position, the invariant always hold that the number of halfmoves played over the board, is at least as great as the 50 moves counter. That is, if the halfmove clock is 27, we have at least played 27 moves over the board, of course. When a position like the one above gets loaded, the number of moves over the board is 0. So we check the position with index -2, -4, ... -26, in the array of hashkeys of positions that have already been played. I know that there are ways around this, but only rather meaningless ones, like saying that 27 positions have been encountered in this case, and the hash signature of them was 0 etc. Because we don't know what the positions were. /David
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.