Tough promotion bug(s)

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Henk
Posts: 5832
Joined: Mon May 27, 2013 8:31 am

Tough promotion bug(s)

Post by Henk » Tue Aug 20, 2013 4:44 pm

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 ]

Sven
Posts: 3829
Joined: Thu May 15, 2008 7:57 pm
Location: Berlin, Germany
Full name: Sven Schüle
Contact:

Re: Tough promotion bug(s)

Post by Sven » Tue Aug 20, 2013 5:38 pm

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

Henk
Posts: 5832
Joined: Mon May 27, 2013 8:31 am

Re: Tough promotion bug(s)

Post by Henk » Tue Aug 20, 2013 6:12 pm

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.

elcabesa
Posts: 815
Joined: Sun May 23, 2010 11:32 am
Contact:

Re: Tough promotion bug(s)

Post by elcabesa » Tue Aug 20, 2013 6:31 pm

I didn't understand anything

Henk
Posts: 5832
Joined: Mon May 27, 2013 8:31 am

Re: Tough promotion bug(s)

Post by Henk » Tue Aug 20, 2013 6:40 pm

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.

User avatar
JVMerlino
Posts: 1003
Joined: Wed Mar 08, 2006 9:15 pm
Location: San Francisco, California

Re: Tough promotion bug(s)

Post by JVMerlino » Tue Aug 20, 2013 7:12 pm

elcabesa wrote:I didn't understand anything
Nor I.... :?

Henk
Posts: 5832
Joined: Mon May 27, 2013 8:31 am

Re: Tough promotion bug(s)

Post by Henk » Tue Aug 20, 2013 7:28 pm

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.

User avatar
sje
Posts: 4675
Joined: Mon Mar 13, 2006 6:43 pm

Storing prior state data

Post by sje » Tue Aug 20, 2013 7:39 pm

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.

Henk
Posts: 5832
Joined: Mon May 27, 2013 8:31 am

Re: Storing prior state data

Post by Henk » Tue Aug 20, 2013 7:50 pm

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.

User avatar
sje
Posts: 4675
Joined: Mon Mar 13, 2006 6:43 pm

Re: Storing prior state data

Post by sje » Tue Aug 20, 2013 8:03 pm

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.

Post Reply