EPD destruction tests

[bob]

First two are NOT correct. White or black can never have more that 16 pieces counting king. Not 17 or 18. The rules of chess say 16 pieces. 8 pawns, two rooks, bishops and knights, queen and king. The pawns can promote into 8 pieces excluding kings So 16 is it unless you are doing non-chess.

For the move number, I don't ignore it. It makes the output match whatever the user is analyzing so that 50. Ng6 Bg2 51. xxx can be displayed.

Here's the FIDE rule for pieces:

2.2 At the beginning of the game one player has 16 light-coloured pieces (the ‘white’ pieces); the other has 16 dark-coloured pieces (the ‘black’ pieces). They then specify number of each piece type, same as always. Any exceptions violate the rules of chess (30 queens for example).

[bob]

That tweaked my interest. Later tonight (assuming no interruptions) I am going to compare two versions of Crafty. One with castle status for hash table probes, one without. I suspect all that will change will be node counts, but I am now curious as to what this actually saves in terms of accuracy.

OK, was an easy test, I just zeroed the Zobrist numbers for castling. Does make a difference in node counts. In fact, made a slight difference in PV and score. So it does matter. This with a 25 ply search from a position where both sides can castle immediately or later...

Probably not something to do for real...

[lucasart]

First two are NOT correct. White or black can never have more that 16 pieces counting king. Not 17 or 18. The rules of chess say 16 pieces. 8 pawns, two rooks, bishops and knights, queen and king. The pawns can promote into 8 pieces excluding kings So 16 is it unless you are doing non-chess.

For the move number, I don't ignore it. It makes the output match whatever the user is analyzing so that 50. Ng6 Bg2 51. xxx can be displayed.

Here's the FIDE rule for pieces:

2.2 At the beginning of the game one player has 16 light-coloured pieces (the ‘white’ pieces); the other has 16 dark-coloured pieces (the ‘black’ pieces). They then specify number of each piece type, same as always. Any exceptions violate the rules of chess (30 queens for example).

True.

OTOH, it's a shame to artificially prevent the engine from analyzing non-FIDE-chess positions that it's capable of handling.

But that means one has to define precisely, for a given engine, what the limits are. Demolito doesn't care about piece counts (except kings), but will crash with pawns on ranks 1/8. I need to think about it…

[lucasart]

First two are NOT correct. White or black can never have more that 16 pieces counting king. Not 17 or 18. The rules of chess say 16 pieces. 8 pawns, two rooks, bishops and knights, queen and king. The pawns can promote into 8 pieces excluding kings So 16 is it unless you are doing non-chess.

For the move number, I don't ignore it. It makes the output match whatever the user is analyzing so that 50. Ng6 Bg2 51. xxx can be displayed.

Here's the FIDE rule for pieces:

2.2 At the beginning of the game one player has 16 light-coloured pieces (the ‘white’ pieces); the other has 16 dark-coloured pieces (the ‘black’ pieces). They then specify number of each piece type, same as always. Any exceptions violate the rules of chess (30 queens for example).

True.

OTOH, it's a shame to artificially prevent the engine from analyzing non-FIDE-chess positions that it's capable of handling.

But that means one has to define precisely, for a given engine, what the limits are. Demolito doesn't care about piece counts (except kings), but will crash with pawns on ranks 1/8. I need to think about it…

I've made my assert code more pedantic regarding piece counts, and (more importantly) pawns on forbidden ranks! Still these are fine for Demolito, which will not fire an assert in debug. I see no reason to reject them:

Code: Select all

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 10 5; movenums => don't care
4r1k1/p1qr1p2/2pb1Bp1/1p5p/3P1n1R/1B3P2/PP3PK1/2Q4R w - -; no movenums => don't care
    rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR    w   KQkq  -   0    1 ; extra white space => don't care
nrbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1; castle status => valid Chess960 position
rnbqkbnr/nnnnnnnn/8/8/8/8/NNNNNNNN/RNBQKBNR w KQkq - 0 1; 18 knights => no more than 10 per side
rnbqkbnr/bbbbbbbb/8/8/8/8/BBBBBBBB/RNBQKBNR w KQkq - 0 1; 18 bishops => no more than 10 per side
rnbqkbnr/rrrrrrrr/8/8/8/8/RRRRRRRR/RNBQKBNR w KQkq - 0 1; 18 rooks => no more than 10 per side
rnbqkbnr/qqqqqqqq/8/8/8/8/QQQQQQQQ/RNBQKBNR w KQkq - 0 1; 18 queens => no more than 9 per side 
8/PPPPPPPP/rnbqkbnr/8/8/RNBQKBNR/pppppppp/8 w - - 0 1; lots of promotions => don't care

And more cases of broken castlings positions, not covered by the list from Chris, which Demolito still fails to detect:

Code: Select all

krr5/8/8/8/8/8/8/4K3 w kq - 0 1; two castling rooks on same side of black king
krr5/8/8/8/8/8/8/4K3 w bc - 0 1; same as above Shredder-FEN version
r3k2r/8/8/8/8/8/8/4K3 w bg - 0 1; black's castling rooks aren't on files 'b' and 'g'. Shredder-FEN made this bug possible, it can't even happen with X-FEN.

Seriously, why was Shredder-FEN even invented (Chess960) ? X-FEN is just fine, and Shredder-FEN just means more code, and more possibility of bugs, for zero benefit.

[chrisw]

First two are NOT correct. White or black can never have more that 16 pieces counting king. Not 17 or 18. The rules of chess say 16 pieces. 8 pawns, two rooks, bishops and knights, queen and king. The pawns can promote into 8 pieces excluding kings So 16 is it unless you are doing non-chess.

For the move number, I don't ignore it. It makes the output match whatever the user is analyzing so that 50. Ng6 Bg2 51. xxx can be displayed.

Here's the FIDE rule for pieces:

2.2 At the beginning of the game one player has 16 light-coloured pieces (the ‘white’ pieces); the other has 16 dark-coloured pieces (the ‘black’ pieces). They then specify number of each piece type, same as always. Any exceptions violate the rules of chess (30 queens for example).

True.

OTOH, it's a shame to artificially prevent the engine from analyzing non-FIDE-chess positions that it's capable of handling.

But that means one has to define precisely, for a given engine, what the limits are. Demolito doesn't care about piece counts (except kings), but will crash with pawns on ranks 1/8. I need to think about it…

Agree with the red. Happened with my stuff on several occasions when licencing an engine for inclusion into a "new" GUI for some fancy product. Play test for large co. quite often can't play chess at all, but their job is to throw all kind of end user inputs at the program and try to break it. They also get to have some input on design (NB design of this type of product GUI is almost certainly done by graphics people, not chess players), and there will be a module of "set up board". If they can't set everything to whatever they want, they'll put in a 'bug report'. If your search breaks on some piece combination, that's another bug report. One can fight them on allowing 32 queens and no kings, but it really isn't worth fighting them over 30 queens, or 30 knights, especially if your program can handle it.

[hgm]

That tweaked my interest. Later tonight (assuming no interruptions) I am going to compare two versions of Crafty. One with castle status for hash table probes, one without. I suspect all that will change will be node counts, but I am now curious as to what this actually saves in terms of accuracy.

OK, was an easy test, I just zeroed the Zobrist numbers for castling. Does make a difference in node counts. In fact, made a slight difference in PV and score. So it does matter. This with a 25 ply search from a position where both sides can castle immediately or later...

Probably not something to do for real...

In micro-Max I don't work the castling rights in the hash key. It wasn't worth enough Elo to justify the extra code.

[Michel]

First two are NOT correct. White or black can never have more that 16 pieces counting king. Not 17 or 18. The rules of chess say 16 pieces. 8 pawns, two rooks, bishops and knights, queen and king. The pawns can promote into 8 pieces excluding kings So 16 is it unless you are doing non-chess.

For the move number, I don't ignore it. It makes the output match whatever the user is analyzing so that 50. Ng6 Bg2 51. xxx can be displayed.

Here's the FIDE rule for pieces:

2.2 At the beginning of the game one player has 16 light-coloured pieces (the ‘white’ pieces); the other has 16 dark-coloured pieces (the ‘black’ pieces). They then specify number of each piece type, same as always. Any exceptions violate the rules of chess (30 queens for example).

True.

OTOH, it's a shame to artificially prevent the engine from analyzing non-FIDE-chess positions that it's capable of handling.

But that means one has to define precisely, for a given engine, what the limits are. Demolito doesn't care about piece counts (except kings), but will crash with pawns on ranks 1/8. I need to think about it…

I've made my assert code more pedantic regarding piece counts, and (more importantly) pawns on forbidden ranks! Still these are fine for Demolito, which will not fire an assert in debug. I see no reason to reject them:

Code: Select all

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 10 5; movenums => don't care
4r1k1/p1qr1p2/2pb1Bp1/1p5p/3P1n1R/1B3P2/PP3PK1/2Q4R w - -; no movenums => don't care
    rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR    w   KQkq  -   0    1 ; extra white space => don't care
nrbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1; castle status => valid Chess960 position
rnbqkbnr/nnnnnnnn/8/8/8/8/NNNNNNNN/RNBQKBNR w KQkq - 0 1; 18 knights => no more than 10 per side
rnbqkbnr/bbbbbbbb/8/8/8/8/BBBBBBBB/RNBQKBNR w KQkq - 0 1; 18 bishops => no more than 10 per side
rnbqkbnr/rrrrrrrr/8/8/8/8/RRRRRRRR/RNBQKBNR w KQkq - 0 1; 18 rooks => no more than 10 per side
rnbqkbnr/qqqqqqqq/8/8/8/8/QQQQQQQQ/RNBQKBNR w KQkq - 0 1; 18 queens => no more than 9 per side 
8/PPPPPPPP/rnbqkbnr/8/8/RNBQKBNR/pppppppp/8 w - - 0 1; lots of promotions => don't care

And more cases of broken castlings positions, not covered by the list from Chris, which Demolito still fails to detect:

Code: Select all

krr5/8/8/8/8/8/8/4K3 w kq - 0 1; two castling rooks on same side of black king
krr5/8/8/8/8/8/8/4K3 w bc - 0 1; same as above Shredder-FEN version
r3k2r/8/8/8/8/8/8/4K3 w bg - 0 1; black's castling rooks aren't on files 'b' and 'g'. Shredder-FEN made this bug possible, it can't even happen with X-FEN.

Seriously, why was Shredder-FEN even invented (Chess960) ? X-FEN is just fine, and Shredder-FEN just means more code, and more possibility of bugs, for zero benefit.

I am surprised you write this. S-FEN is much more logical than X-FEN.

X-FEN is basically S-FEN with some special cases treated differently for backward compatibility. If you can parse X-FEN then you can parse S-FEN.

[bob]

I consider non-FIDE chess as something other than chess. Why let a user have 20 queens? Can't happen in a real game. Crafty COULD handle as many pieces as you want, of any type, except a king. Too many problems with multiple kings to worry about. But I received bug reports about Crafty allowing bogus FEN. I fixed it and got complaints because they could use what I did and did not accept to recognize Crafty and the many clones it spawned. But I go with the rules of chess which I would think would an implied part of ANY commercial (or non-commercial) chess engine.

[lucasart]

And more cases of broken castlings positions, not covered by the list from Chris, which Demolito still fails to detect:

Code: Select all

krr5/8/8/8/8/8/8/4K3 w kq - 0 1; two castling rooks on same side of black king
krr5/8/8/8/8/8/8/4K3 w bc - 0 1; same as above Shredder-FEN version
r3k2r/8/8/8/8/8/8/4K3 w bg - 0 1; black's castling rooks aren't on files 'b' and 'g'. Shredder-FEN made this bug possible, it can't even happen with X-FEN.

Seriously, why was Shredder-FEN even invented (Chess960) ? X-FEN is just fine, and Shredder-FEN just means more code, and more possibility of bugs, for zero benefit.

Fixed. Now Demolito validates castling permissions (in debug compiles). I think (hope?) that this code is 100% correct:

Code: Select all

    // Only white|black rooks on rank1|8, can be castle rooks
    assert(!(pos->castleRooks & ~((Rank[RANK_1] & pos_pieces_cp(pos, WHITE, ROOK))
        | (Rank[RANK_8] & pos_pieces_cp(pos, BLACK, ROOK)))));

    // No more than 2 castle rooks per color. And when there are 2, the king (of that color) must be in-between
    for (int color = 0; color < NB_COLOR; color++) {
        const bitboard_t b = pos->castleRooks & pos->byColor[color];

        if (bb_count(b) == 2)
            assert(Segment[bb_lsb(b)][bb_msb(b)] & pos_pieces_cp(pos, color, KING));
        else
            assert(bb_count(b) <= 1);
    }

Last thing on my to do list is to validate en-passant.

[Ras]

Now Demolito validates castling permissions (in debug compiles). [...] Last thing on my to do list is to validate en-passant.

I always validate EP and castling in FEN, but sanitise instead of rejection. E.g. castling rights withoout king on origin square gets castling rights silently removed. Similarly with EP when it doesn't make sense.