Chess960 / Fischer Random Perft Wiki Results

[zenpawn]

I did not know that this dataset made its way to the wiki. Cool to know, and hopefully useful.

Definitely useful. Thank you, Andrew. Sorry to have misreported these discrepancies.

I've now corrected the mismatches RM was experiencing.

Drilling down a bit on some of these, you get to positions like:


where castling queenside is illegal.

[jonkr]

This post was useful to me as it turns out I also wasn't checking for this case (even in 960), and was a quick fix to correct.
I guess Stockfish must have a test for this case that's only activated in Chess960 mode, whereas when not in Chess960 mode I assume the castling flags are invalid if rooks aren't on standard start squares and don't allow castling.

[Sesse]

My Chess.js fork seemingly handles this situation correctly, although I have no idea why. =)

[lucasart]

Stockfish 11 disagrees with some of the results reported at https://www.chessprogramming.org/Chess960_Perft_Results

That's because you're doing something wrong!
Can you figure it out?

Hint: do you SF expect to know that you are giving a Chess960 fen?

True. But that's because the SF implementation of casting is clumsy. If you do it well, the code can be 100% FRC agnostic.

In Demolito, everything is written for FRC, and normal chess as just a particular starting position. There is not a single Chess960 in the code, except to deal with the UCI protocol inconsistency. If the UCI protocol could be corrected, there would be no need for it.

[zenpawn]

Stockfish 11 disagrees with some of the results reported at https://www.chessprogramming.org/Chess960_Perft_Results

That's because you're doing something wrong!
Can you figure it out?

Hint: do you SF expect to know that you are giving a Chess960 fen?

True. But that's because the SF implementation of casting is clumsy. If you do it well, the code can be 100% FRC agnostic.

In Demolito, everything is written for FRC, and normal chess as just a particular starting position. There is not a single Chess960 in the code, except to deal with the UCI protocol inconsistency. If the UCI protocol could be corrected, there would be no need for it.

To be fair to Stockfish (and myself), I didn't expect it to know that I wanted Chess960, I just got the UCI syntax wrong for telling it. But, you make a good point that special-casing for Fischer Random is not really necessary. Note: Winboard too has a variant command for "fischerandom".

[AndrewGrant]

Stockfish 11 disagrees with some of the results reported at https://www.chessprogramming.org/Chess960_Perft_Results

That's because you're doing something wrong!
Can you figure it out?

Hint: do you SF expect to know that you are giving a Chess960 fen?

True. But that's because the SF implementation of casting is clumsy. If you do it well, the code can be 100% FRC agnostic.

In Demolito, everything is written for FRC, and normal chess as just a particular starting position. There is not a single Chess960 in the code, except to deal with the UCI protocol inconsistency. If the UCI protocol could be corrected, there would be no need for it.

Likewise for Ethereal. If UCI could handle O-O-O and O-O, there would be no need for any special code at all.

Code: Select all

void moveToString(uint16_t move, char *str, int chess960) {

    int from = MoveFrom(move), to = MoveTo(move);

    // FRC reports using KxR notation, but standard does not
    if (MoveType(move) == CASTLE_MOVE && !chess960)
        to = castleKingTo(from, to);

Above is the only line of code that cares at all about whether its FRC or not.

[Sesse]

I am still running Chess.js on the depth 6 results…

nrbbnk1r/pp2pppq/8/2pp3p/3P2P1/1N6/PPP1PP1P/1RBBNKQR w HBhb - 0 9. Chess.js perf depth 6 on my machine: 2526 seconds. Stockfish 11: Below 9 seconds! Clearly, there is some room for improvement here. =)

[xr_a_y]

I am still running Chess.js on the depth 6 results…

nrbbnk1r/pp2pppq/8/2pp3p/3P2P1/1N6/PPP1PP1P/1RBBNKQR w HBhb - 0 9. Chess.js perf depth 6 on my machine: 2526 seconds. Stockfish 11: Below 9 seconds! Clearly, there is some room for improvement here. =)

SF is fast here ! Mostly because it doesn't apply leaf nodes

Code: Select all

cnt = leaf ? MoveList<LEGAL>(pos).size() : perft<false>(pos, depth - 1);

Minic took 44 sec...

[JohnWoe]

Instead of a big ass list of FRC fens. One could simply play 100000 games against some stable FRC engine to see there's no illegal moves. Some study like positions are ok for unit testing.

About this position:

SF: Need to pipe in stdin and time it because it lacks functionality. But its movegen is fast.

Code: Select all

Nodes searched: 1310683359
real	0m9,890s
user	0m9,863s
sys	0m0,024s

Sapeli 1.89: depth 6 nodes 1310683359 time 34.979 mnps 37.470

LastEmperor:

Code: Select all

[ nrbbnk1r/pp2pppq/8/2pp3p/3P2P1/1N6/PPP1PP1P/1RBBNKQR w HBhb - 0 9 ]
Depth               Nodes        Mnps        Time
    0                   1       0.000       0.000
    1                  29       0.000       0.000
    2               1,036       0.000       0.000
    3              31,344      31.344       0.001
    4           1,139,166      29.978       0.038
    5          35,627,310      43.395       0.821
    6       1,310,683,359      82.113      15.962
=================================================
                    Nodes        Mnps        Time
Total       1,347,482,245      80.102      16.822

Summarum:
SF: 9.8s
LastEmperor: 16.8s
Sapeli: 35.229s