TalkChess.com

Same promotion move may appear twice in a variation or move sequence.
So when you restore the promoted pawn (during unmake move) be sure you have the right one.

I was not aware of that and I spent at least one day on fixing bugs with suddenly disappearing pawns in the endgame. Reproducing those bugs wasn't that easy.

I fixed it by saving the promoted pawns on a stack. [For now I assigned a promoted pawn stack to promotion move ]

Henk wrote:Same promotion move may appear twice in a variation or move sequence.
So when you restore the promoted pawn (during unmake move) be sure you have the right one.

How can I possibly restore "the wrong one"??

Unmaking a promotion move means
- to change back the promotion piece into a pawn of the same colour, and
- to move back the pawn from 8th to 7th (resp. 1st to 2nd) rank, and optionally
- to restore any captured piece if it was a promotion with capture.

What else?

A stack of promoted pawns should not be necessary. I guess that the reason why such a concept is necessary in your engine may also be the reason for other serious problems.

Sven

Sven Schüle wrote:

Henk wrote:Same promotion move may appear twice in a variation or move sequence.
So when you restore the promoted pawn (during unmake move) be sure you have the right one.

How can I possibly restore "the wrong one"??

Unmaking a promotion move means
- to change back the promotion piece into a pawn of the same colour, and
- to move back the pawn from 8th to 7th (resp. 1st to 2nd) rank, and optionally
- to restore any captured piece if it was a promotion with capture.

What else?

A stack of promoted pawns should not be necessary. I guess that the reason why such a concept is necessary in your engine may also be the reason for other serious problems.

Sven

Yes you're probably right (if you do not change back the promotion piece into the same pawn as the pawn of the previous restored identical promotion move).


My implementation before was far worse. I stored only one promoted pawn in the promotion move.

For instance after unmaking that move I set promoted pawn back to null. But when unmaking the previous identical promotion move it failed for promoted pawn is null.

By the way I just encountered an en passent bug. In a certain position it thinks it's an invalid move while it isn't.

I didn't understand anything

elcabesa wrote:I didn't understand anything

If it would be simple or understandable there probably were not bugs.
Just forget it, I found out myself. Just a bad implementation.

elcabesa wrote:I didn't understand anything

Nor I....

JVMerlino wrote:

elcabesa wrote:I didn't understand anything

Nor I....

Join the club. If I try to explain it, it probably won't help I I'll be busy the next two hours talking about things no one understands.

What's easy to understand is this:
If you play pawn moves d3-d2 .. d2-d1 .. Qd1-a1 and later with another pawn e3xd2 and later d2-d1. You have two identical promotion moves (d2-d1)
played one stems from the d-pawn and the other from the e-pawn.

My opinion is that storing prior state data in a played move is a bad idea and leads to bugs. Better is to store this data in a separate structure, stacking one new entry prior to move execution and restoring from that entry (unstacking it) on move retraction.

There are several reasons for this, one of them being that you don't want the structure of a move to be excessively complicated or large.

sje wrote:My opinion is that storing prior state data in a played move is a bad idea and leads to bugs. Better is to store this data in a separate structure, stacking one new entry prior to move execution and restoring from that entry (unstacking it) on move retraction.

There are several reasons for this, one of them being that you don't want the structure of a move to be excessively complicated or large.

Problem with that is that you don't want overhead for every move because of the promotion move special case (treatment). I do not want to check for every move if it is a promotion move or not when making and unmaking moves.

Henk wrote:

sje wrote:My opinion is that storing prior state data in a played move is a bad idea and leads to bugs. Better is to store this data in a separate structure, stacking one new entry prior to move execution and restoring from that entry (unstacking it) on move retraction.

There are several reasons for this, one of them being that you don't want the structure of a move to be excessively complicated or large.

Problem with that is that you don't want overhead for every move because of the promotion move special case (treatment). I do not want to check for every move if it is a promotion move or not when making and unmaking moves.

There is always going to be a need for a save/restore of state data regardless of whatever the move might be. This includes the en passant target square and the halfmove counter at the very minimum.

If you are unclear as to why this is so, you should first examine some open source programs and see how they treat the problem before continuing with your coding.

Also, you should first get your program to do absolutely correct perft() operations on all the usual test positions before writing a single line of the search.