TalkChess.com

Curious about how others have implemented calculation of how many times each piece has moved since the beginning of the game.

The concern is when a piece has been captured in a make move and then uncaptured and updating the array.

How did you solve this?

smcracraft wrote: ↑Tue Jun 12, 2018 6:08 am Curious about how others have implemented calculation of how many times each piece has moved since the beginning of the game.

The concern is when a piece has been captured in a make move and then uncaptured and updating the array.

If you are just interested in keeping track of which move was made so you can "un-make" it, then you will already have that information available in your tree search. after all, you can't make a move without knowing what it is. when you return from the deeper search, the move that was made will still be on the stack at the original level. The count wouldn't matter.

I use to think that keeping track of the number of times a move was made would be useful for the opening and perhaps keeping track of castling options, but there are other ways to handle those cases more efficiently.

For castling, i keep 4 bits in a byte to indicate if castling is still possible for each of the two ways for each color. This is a pretty common way to do it if you are viewing some open source code. If a move is made from the original king square (E1 for white) or either of the rook squares (A1 or H1), then clear the appropriate bits. same goes for black. Also, if a move is made to one of the rook squares, the appropriate bit is also cleared. These bits are passed down to the next depth and used to guide the code as to whether or not castling is possible (bit set, good to go). They do though have to be set properly at the beginning of the game, or if a new FEN is used to set up a position. I've found that sometimes you can't trust the FEN and the castling flags might not even be present. so I use the positions of the pieces as the guide. if the pieces on the board indicate castling is possible, and the FEN castling flags aren't present, I go with what the pieces say.

Back to keeping track of the number of times a piece has moved, it is kind of a waste of instructions. A good evaluation will kind of, sort of take care of that for you. Others may have other ideas.

Well, that wasn't really the answer to my question now, was it?

Also my engine only keeps track of whether the king or the rooks have moved, maybe a waste of cache or memory but I use 4 bits in a 64 bit word to keep track of this because this maps directly to the rook locations on the bitboards.

smcracraft wrote: ↑Tue Jun 12, 2018 7:44 am Well, that wasn't really the answer to my question now, was it?

To me the answer seemed very clear, I don't think that there are many engines (if any) keeping track of how many times a piece has moved because this is rather useless information.

smcracraft wrote: ↑Tue Jun 12, 2018 6:08 am Curious about how others have implemented calculation of how many times each piece has moved since the beginning of the game.

The concern is when a piece has been captured in a make move and then uncaptured and updating the array.

How did you solve this?

Why do you think anyone has ever solved this? Why is this an interesting problem?

smcracraft wrote: ↑Tue Jun 12, 2018 6:08 am Curious about how others have implemented calculation of how many times each piece has moved since the beginning of the game.

The concern is when a piece has been captured in a make move and then uncaptured and updating the array.

How did you solve this?

I'd do it the same way I handle the 50-move counter, or castling rights.
Question remains, why do you want this information? If it's for something evaluation or move ordering related, you're probably on the wrong track.

None of my engines keep track of that. But it seems trivial to do so: just keep a counter for each piece, as one of the infos in the piece list. Every MakeMove() increments the counter for the moved piece, every UnMake() decrements it. For castling you would have to do that for both K and R, as they are both moved.

smcracraft wrote: ↑Tue Jun 12, 2018 7:44 am Well, that wasn't really the answer to my question now, was it?

You question is "How did you solve this?"

The only answer I can give is "I did not solve it because I have no need whatsoever to know the number of times a piece has been moved since the beginning of the game".

As far as I can tell, the number of times a piece has been moved has no relevance to the game of chess. I doubt that any chess engine exists that keep track of this number.

But if you ask me "how would you solve this?" then my answer would be: just don't zero the number for a piece when the piece is captured. Then when you uncapture it, the number is still there.

syzygy wrote: ↑Tue Jun 12, 2018 8:29 pm But if you ask me "how would you solve this?" then my answer would be: just don't zero the number for a piece when the piece is captured. Then when you uncapture it, the number is still there.

If this is impractical, just save the number of times the captured piece had been moved in the undo stack in the same way as you save the captured piece itself.