EPD destruction tests

[chrisw]

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.

I think that's the right approach, as long as the integrity of the pieces/board coming out of the first field are good, then ep and castling rights fields can be overruled if necessary, likewise the 50 movenum if too large. I doubt many engines use the actual game movenum field in their AI (some used to use it in old days as a lazy indicator of game phase, but probably not since Fruit, if not before).

Python-Chess, which seems fairly robust on reading EPDs, used to insist on all 6 fields, now it accepts 4 or 6, but I think it will complain if a field is missing. In real, it should be possible to just read in the piece-square field and the stm field and guess the rest if lacking.

[chrisw]

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.

That looks like 960 compatible code, but if FIDE chess would be broken, unless ...... I guess you got that covered by not assuming rook necessarily on a corner square in your movegen-move-eval code? Ie. Demolito is integrally-designed as 960 compatible?

Other tests:
stm actually does have a move (possibly depends on main search knowing what to do in that case), especially if a BM follows, eg the EPD was designed to have, and assumes, a continuation. In a test position, it is also a verification of the EPD that there is more than one move available, else dumb test position. Ok, overkill could be argued here.
not stm is not incheck

[Ras]

as long as the integrity of the pieces/board coming out of the first field are good

Yes, when there are fundamental problems like too many kings or STM giving check, I reject the position with an "info string" error message so that the user can know what exactly the problem is. This helps also in troubleshooting. Upon a "go" command with rejected position, my engine replies with another "info string" error message and "bestmove 0000" instead of using the previous position. This avoids GUI and engine getting out of sync and is well defined program behaviour.

[Dann Corbit]

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.

That's even better.

[bob]

I decided to slightly modify my FEN parsing. I now only require the Forsythe board description and side to move. The remaining 4 fields no longer abort processing the FEN string, but do produce warnings if they are invalid or missing. If one is either invalid or missing, the corresponding internal values are set to zero so that the position is still OK for searching, maybe with restricted moves if castling status or ep status are missing or invalid.

[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…

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.

Even more pedantically ...

assert(bb_count(pos_pieces_cp(pos, color, QUEEN)) <= 9)

would be rendered even more chess legal if the 9 were substituted with 9 - popcount(pawns same color))
and the other pieces with 10 minus etc.

and ...

assert(pos->rule50 < 100);

with
assert((pos->rule50 < 100) && (pos->rule50 >= 0));

to prevent a nasty negative number which I think can creep past the atoi string convert

[bob]

or if the popcnt of the OR of all pieces is < 16 (ignoring king here). So simply test for queens, rooks, bishops, knights <= 9, pawns <= 8, plus total <= 15.

[chrisw]

or if the popcnt of the OR of all pieces is < 16 (ignoring king here). So simply test for queens, rooks, bishops, knights <= 9, pawns <= 8, plus total <= 15.

Your logic is bugged here. Two errors. Brings to mind the question: is it a code bug if the programmer doesn't know what he is doing and codes according to his own mal-thinking.

[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.

That looks like 960 compatible code, but if FIDE chess would be broken, unless ...... I guess you got that covered by not assuming rook necessarily on a corner square in your movegen-move-eval code? Ie. Demolito is integrally-designed as 960 compatible?

Other tests:
stm actually does have a move (possibly depends on main search knowing what to do in that case), especially if a BM follows, eg the EPD was designed to have, and assumes, a continuation. In a test position, it is also a verification of the EPD that there is more than one move available, else dumb test position. Ok, overkill could be argued here.
not stm is not incheck

Demolito is designed to play Chess960 from the ground up. Normal chess is just a particular case. There is zero specific treatement. The only specific treatement is from the stupid UCI specs which mandates e1g1 for standard chess instead of e1h1 that would have allowed consistent treatement. But that's just for display. Internally there is nothing different for normal chess.

Note that 'castleRooks' is a bitboard of all rooks (white and black) that have castling rights. That's really the cleanest design for Chess960 caslting rights in my opinion: attach them to the rooks themselves! Instead of having left/right castling for each color, then having to keep track, for each of the 4 possible castling, where things are (a bad design, which violates the DRY principle for no good reason).

[chrisw]

Did anybody work out the max allowable piece count yet? I’m looking for the shortcut
For each side
King=1
Pawns <= 8

Ah, trying this in my head (Iphone, airport) ...
Pieces <= 7 + (8-pawns)

But you can’t have, say 15 pieces all the same, above a certain count NBRQ have to exist.
Like you can’t have 9Q and 6N.

So the tests
Q <= 1 + 8-pawns
R <= 2 + 8-pawns
And so on, for each piece will not pick up all chess unlawful positions

I want an easy formula, else will end up with spaghetti, or am I missing something dumb?