Stockfish: SF-zh blundered a mate again

[Vinvin20]

https://fr.lichess.org/BZeuXAlt/black
19.Qxd8???

[ianfab]

That is confusing. Even if we give SF the position after Qxd8 it takes seconds to find a mate in 3.

setoption name UCI_Variant value crazyhouse
position fen 3r4/ppp2krp/3p4/2b3Q1/4Pnn1/3P4/PPP2PPP/R4R1K/BPNqnpbpb w - - 36 19 moves g5d8
go depth 15

info depth 1 seldepth 1 multipv 1 score cp -1452 nodes 808 nps 269333 tbhits 0 time 3 pv Q@e8
info depth 2 seldepth 3 multipv 1 score cp -890 nodes 1399 nps 349750 tbhits 0 time 4 pv Q@e8 R@f5 P@f6
info depth 3 seldepth 5 multipv 1 score cp -743 nodes 2291 nps 458200 tbhits 0 time 5 pv Q@e8 B@b3 f7f8
info depth 4 seldepth 7 multipv 1 score cp -1284 nodes 5077 nps 725285 tbhits 0 time 7 pv Q@e8 d8e8 f7e8 Q@c8 Q@d8 c8d8 e8d8 Q@f8 N@e8 f8f4
info depth 5 seldepth 9 multipv 1 score cp -949 nodes 7700 nps 962500 tbhits 0 time 8 pv Q@e8 N@g5 f7f8 d8e8 f8e8 Q@c8 B@d8 c8g4 d8g5
info depth 6 seldepth 9 multipv 1 score cp -949 nodes 8435 nps 937222 tbhits 0 time 9 pv Q@e8 N@g5 f7f8 d8e8 f8e8 Q@c8 B@d8 c8g4 d8g5
info depth 7 seldepth 11 multipv 1 score cp -1065 nodes 11705 nps 1064090 tbhits 0 time 11 pv Q@e8 N@g5 f7f8 P@e7 g7e7 d8e8 e7e8 Q@f5 N@f6 f5f4 Q@d7 R@h8 f8e7
info depth 8 seldepth 14 multipv 1 score cp -1416 nodes 50197 nps 1356675 tbhits 0 time 37 pv Q@f8 N@g5 f7g8 d8f8 g8f8 Q@d8 B@e8 B@e7 g7e7 R@h8 B@g8 P@f7
info depth 9 seldepth 19 multipv 1 score cp -1704 nodes 127313 nps 1463367 tbhits 0 time 87 pv Q@f8 N@g5 f7g8 d8f8 g8f8 Q@d8 B@e8 R@f5 B@f6 f5f4 Q@e7 f4f6 g4f6
info depth 10 seldepth 19 multipv 1 score cp -1479 nodes 199619 nps 1500894 tbhits 0 time 133 pv Q@e8 N@g5 g7g5 d8g5 N@g6 g5g4 P@e6 N@g5 f7g7 P@f7 e8f7 g5f7 g7f7
info depth 11 seldepth 20 multipv 1 score cp -1859 nodes 382920 nps 1531680 tbhits 0 time 250 pv Q@e8 N@g5 g7g5 d8g5 P@g7 g5f4 N@f6 B@c4 d6d5 c4d5 P@e6 N@g5 f7g8 P@f7 e8f7 d5e6 N@e8 e6f7 g8h8
info depth 12 seldepth 25 multipv 1 score cp -2037 nodes 901040 nps 1430222 tbhits 0 time 630 pv Q@e8 N@g5 g7g5 d8g5 P@g7 g5f4 N@f6 B@c4 d6d5 f4c7 B@d7 c4d5 P@e6 d5e6 e8e6 N@g5 f7g8 g5e6 d7e6 P@f7 e6f7
info depth 13 seldepth 25 multipv 1 score cp -3406 nodes 4401051 nps 1562873 hashfull 990 tbhits 0 time 2816 pv N@e7 R@f8 f7g6 f8f4 Q@h4 B@g3 h4g5 N@e6 P@e5 N@f5 e5f4 f5g7 R@h4 g3h4 g5h4 R@g5 h4g5 e6g5
info depth 14 seldepth 25 multipv 1 score cp -3413 upperbound nodes 4920257 nps 1567460 hashfull 996 tbhits 0 time 3139 pv N@e7 R@f8
info depth 14 seldepth 25 multipv 1 score cp -3420 upperbound nodes 5021322 nps 1567693 hashfull 996 tbhits 0 time 3203 pv N@e7 R@f8
info depth 14 seldepth 25 multipv 1 score cp -3431 upperbound nodes 5087894 nps 1567434 hashfull 996 tbhits 0 time 3246 pv N@e7 R@f8
info depth 14 seldepth 25 multipv 1 score cp -3446 upperbound nodes 5171694 nps 1567180 hashfull 996 tbhits 0 time 3300 pv N@e7 R@f8
info depth 14 seldepth 25 multipv 1 score cp -3467 upperbound nodes 5353098 nps 1567066 hashfull 997 tbhits 0 time 3416 pv N@e7 R@f8
info depth 14 seldepth 25 multipv 1 score cp -3495 upperbound nodes 5551925 nps 1568340 hashfull 997 tbhits 0 time 3540 pv N@e7 R@f8
info depth 14 seldepth 25 multipv 1 score cp -3533 upperbound nodes 5706241 nps 1568510 hashfull 998 tbhits 0 time 3638 pv N@e7 R@f8
info depth 14 seldepth 25 multipv 1 score mate 3 lowerbound nodes 6013224 nps 1570032 hashfull 999 tbhits 0 time 3830 pv N@g3
info depth 14 seldepth 25 multipv 1 score mate 3 nodes 6030821 nps 1570526 hashfull 999 tbhits 0 time 3840 pv N@g3 f2g3 Q@g1 f1g1 g4f2
info depth 15 seldepth 25 multipv 1 score mate 3 nodes 6065935 nps 1571485 hashfull 999 tbhits 0 time 3860 pv N@g3 f2g3 Q@g1 f1g1 g4f2
bestmove N@g3 ponder f2g3

[Vinvin20]

With the SF online, here, SF finds the mate immediately after Qxd8.

[ppigazzini]

mate found at depth=13 using a bigger hash table

Stockfish 250417 64 POPCNT by T. Romstad, M. Costalba, J. Kiiski, G. Linscott
setoption name hash value 128
setoption name UCI_Variant value crazyhouse
info string variant crazyhouse startpos rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR[] w KQkq - 0 1
position fen 3r4/ppp2krp/3p4/2b3Q1/4Pnn1/3P4/PPP2PPP/R4R1K/BPNqnpbpb w - - 36 19 moves g5d8
go depth 15
info depth 1 seldepth 1 multipv 1 score cp -1452 nodes 808 nps 269333 tbhits 0 time 3 pv Q@e8
info depth 2 seldepth 3 multipv 1 score cp -890 nodes 1399 nps 349750 tbhits 0 time 4 pv Q@e8 R@f5 P@f6
info depth 3 seldepth 5 multipv 1 score cp -743 nodes 2291 nps 458200 tbhits 0 time 5 pv Q@e8 B@b3 f7f8
info depth 4 seldepth 7 multipv 1 score cp -1284 nodes 5077 nps 634625 tbhits 0 time 8 pv Q@e8 d8e8 f7e8 Q@c8 Q@d8 c8d8 e8d8 Q@f8 N@e8
 f8f4
info depth 5 seldepth 9 multipv 1 score cp -949 nodes 7700 nps 641666 tbhits 0 time 12 pv Q@e8 N@g5 f7f8 d8e8 f8e8 Q@c8 B@d8 c8g4 d8g5
info depth 6 seldepth 9 multipv 1 score cp -949 nodes 8435 nps 702916 tbhits 0 time 12 pv Q@e8 N@g5 f7f8 d8e8 f8e8 Q@c8 B@d8 c8g4 d8g5
info depth 7 seldepth 11 multipv 1 score cp -1065 nodes 11705 nps 731562 tbhits 0 time 16 pv Q@e8 N@g5 f7f8 P@e7 g7e7 d8e8 e7e8 Q@f5 N
@f6 f5f4 Q@d7 R@h8 f8e7
info depth 8 seldepth 14 multipv 1 score cp -1416 nodes 50197 nps 896375 tbhits 0 time 56 pv Q@f8 N@g5 f7g8 d8f8 g8f8 Q@d8 B@e8 B@e7 g
7e7 R@h8 B@g8 P@f7
info depth 9 seldepth 19 multipv 1 score cp -1704 nodes 127313 nps 943059 tbhits 0 time 135 pv Q@f8 N@g5 f7g8 d8f8 g8f8 Q@d8 B@e8 R@f5
 B@f6 f5f4 Q@e7 f4f6 g4f6
info depth 10 seldepth 19 multipv 1 score cp -1479 nodes 199619 nps 1084885 tbhits 0 time 184 pv Q@e8 N@g5 g7g5 d8g5 N@g6 g5g4 P@e6 N@
g5 f7g7 P@f7 e8f7 g5f7 g7f7
info depth 11 seldepth 20 multipv 1 score cp -1859 nodes 382918 nps 1223380 tbhits 0 time 313 pv Q@e8 N@g5 g7g5 d8g5 P@g7 g5f4 N@f6 B@
c4 d6d5 c4d5 P@e6 N@g5 f7g8 P@f7 e8f7 d5e6 N@e8 e6f7 g8h8
info depth 12 seldepth 23 multipv 1 score cp -1934 nodes 795624 nps 1341693 tbhits 0 time 593 pv Q@e8 N@h8 f7f8 P@e7 g7e7 R@g8 f8g8 d8
e8 R@f8 e8e7 B@f7 h8f7 B@g7 e7f8 g8f8 Q@c8 N@e8 c8g4 P@e5
info depth 13 seldepth 25 multipv 1 score mate 6 nodes 1639927 nps 1457712 hashfull 115 tbhits 0 time 1125 pv Q@g1 h1g1 N@h3 g2h3 g4f2
 P@g6 g7g6 R@g5 g6g5 B@g3 R@h1
info depth 14 seldepth 25 multipv 1 score mate 3 nodes 1712384 nps 1464828 hashfull 117 tbhits 0 time 1169 pv N@g3 f2g3 Q@g1 f1g1 g4f2
info depth 15 seldepth 25 multipv 1 score mate 3 nodes 1735024 nps 1465391 hashfull 119 tbhits 0 time 1184 pv N@g3 f2g3 Q@g1 f1g1 g4f2
bestmove N@g3 ponder f2g3

mate found at depth=2 using also some threads

setoption name hash value 128
setoption name threads value 16
setoption name UCI_Variant value crazyhouse
info string variant crazyhouse startpos rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR[] w KQkq - 0 1
position fen 3r4/ppp2krp/3p4/2b3Q1/4Pnn1/3P4/PPP2PPP/R4R1K/BPNqnpbpb w - - 36 19 moves g5d8
go depth 15
info depth 1 seldepth 1 multipv 1 score cp -1452 nodes 599565 nps 6181082 tbhits 0 time 97 pv Q@e8
info depth 2 seldepth 2 multipv 1 score mate 3 nodes 4059159 nps 8037938 tbhits 0 time 505 pv N@g3 f2g3
info depth 3 seldepth 4 multipv 1 score mate 3 nodes 6482921 nps 8206229 tbhits 0 time 790 pv N@g3 f2g3 Q@g1 f1g1
info depth 4 seldepth 6 multipv 1 score mate 3 nodes 8843106 nps 8233804 hashfull 545 tbhits 0 time 1074 pv N@g3 f2g3 Q@g1 f1g1 g4f2
info depth 5 seldepth 6 multipv 1 score mate 3 nodes 11159651 nps 8211663 hashfull 656 tbhits 0 time 1359 pv N@g3 f2g3 Q@g1 f1g1 g4f2
info depth 6 seldepth 6 multipv 1 score mate 3 nodes 11942109 nps 8213279 hashfull 685 tbhits 0 time 1454 pv N@g3 f2g3 Q@g1 f1g1 g4f2
info depth 7 seldepth 6 multipv 1 score mate 3 nodes 11945840 nps 8210199 hashfull 685 tbhits 0 time 1455 pv N@g3 f2g3 Q@g1 f1g1 g4f2
info depth 8 seldepth 6 multipv 1 score mate 3 nodes 11949640 nps 8212810 hashfull 685 tbhits 0 time 1455 pv N@g3 f2g3 Q@g1 f1g1 g4f2
info depth 9 seldepth 6 multipv 1 score mate 3 nodes 11953536 nps 8209846 hashfull 685 tbhits 0 time 1456 pv N@g3 f2g3 Q@g1 f1g1 g4f2
info depth 10 seldepth 6 multipv 1 score mate 3 nodes 11957459 nps 8212540 hashfull 685 tbhits 0 time 1456 pv N@g3 f2g3 Q@g1 f1g1 g4f2
info depth 11 seldepth 6 multipv 1 score mate 3 nodes 11961215 nps 8209481 hashfull 685 tbhits 0 time 1457 pv N@g3 f2g3 Q@g1 f1g1 g4f2
info depth 12 seldepth 6 multipv 1 score mate 3 nodes 11964831 nps 8206331 hashfull 685 tbhits 0 time 1458 pv N@g3 f2g3 Q@g1 f1g1 g4f2
info depth 13 seldepth 6 multipv 1 score mate 3 nodes 11968473 nps 8208829 hashfull 686 tbhits 0 time 1458 pv N@g3 f2g3 Q@g1 f1g1 g4f2
info depth 14 seldepth 6 multipv 1 score mate 3 nodes 11971927 nps 8205570 hashfull 686 tbhits 0 time 1459 pv N@g3 f2g3 Q@g1 f1g1 g4f2
info depth 15 seldepth 6 multipv 1 score mate 3 nodes 11975763 nps 8208199 hashfull 686 tbhits 0 time 1459 pv N@g3 f2g3 Q@g1 f1g1 g4f2
bestmove N@g3 ponder f2g3

[ianfab]

This seems to be caused by skipping quiet moves during move count pruning. I have submitted a test for a patch that improves mate finding. Here is the output for the position above:

info depth 1 seldepth 1 multipv 1 score cp -1452 nodes 808 nps 115428 tbhits 0 time 7 pv Q@e8
info depth 2 seldepth 3 multipv 1 score cp -890 nodes 1399 nps 155444 tbhits 0 time 9 pv Q@e8 R@f5 P@f6
info depth 3 seldepth 5 multipv 1 score cp -810 nodes 2761 nps 212384 tbhits 0 time 13 pv Q@e8 R@d7 e8d7
info depth 4 seldepth 7 multipv 1 score cp -1683 nodes 11223 nps 431653 tbhits 0 time 26 pv Q@f8 d8f8 f7f8 Q@f5 P@f7 P@f6
info depth 5 seldepth 9 multipv 1 score cp -1231 nodes 16272 nps 524903 tbhits 0 time 31 pv Q@e8 d8e8 f7e8 P@f7 g7f7 Q@c8 Q@d8
info depth 6 seldepth 9 multipv 1 score cp -1206 nodes 19151 nps 563264 tbhits 0 time 34 pv Q@e8 d8e8 f7e8 P@f7 g7f7 B@a4 e8f8 Q@c8 f8g7
info depth 7 seldepth 12 multipv 1 score cp -1403 nodes 46545 nps 788898 tbhits 0 time 59 pv B@e7 R@f5 f7g6 f5f4 e7d8 N@f5 P@g5 f4g4 P@e6
info depth 8 seldepth 15 multipv 1 score cp -2147 nodes 117430 nps 1030087 tbhits 0 time 114 pv Q@e8 N@h8 f7f8 d8e8 f8e8 P@f7 g7f7 Q@c8 Q@d8 c8d8 e8d8 h8f7 d8d7 Q@d8 d7c6 B@d7 c6b6 d7g4
info depth 9 seldepth 20 multipv 1 score cp -1378 nodes 251771 nps 1258855 tbhits 0 time 200 pv B@e7 R@f5 N@f6 N@h8 f7e6 d8c7 Q@d8 c7b7 d8d7 B@b3 d6d5 b7d7 e6d7
info depth 10 seldepth 20 multipv 1 score mate 6 nodes 381351 nps 1396890 tbhits 0 time 273 pv Q@g1 h1g1 N@h3 g2h3 g4f2 P@g6 g7g6 N@g5 g6g5 N@g3 N@e2
info depth 11 seldepth 20 multipv 1 score mate 6 nodes 398208 nps 1407095 tbhits 0 time 283 pv Q@g1 h1g1 N@h3 g2h3 g4f2 P@g6 g7g6 N@g5 g6g5 N@g3 N@e2
info depth 12 seldepth 20 multipv 1 score mate 3 nodes 423132 nps 1419906 tbhits 0 time 298 pv N@g3 f2g3 Q@g1 f1g1 g4f2
info depth 13 seldepth 20 multipv 1 score mate 3 nodes 436983 nps 1423397 tbhits 0 time 307 pv N@g3 f2g3 Q@g1 f1g1 g4f2
info depth 14 seldepth 20 multipv 1 score mate 3 nodes 440106 nps 1424291 tbhits 0 time 309 pv N@g3 f2g3 Q@g1 f1g1 g4f2
info depth 15 seldepth 20 multipv 1 score mate 3 nodes 448983 nps 1429882 tbhits 0 time 314 pv N@g3 f2g3 Q@g1 f1g1 g4f2
bestmove N@g3 ponder f2g3

The upstream patch that introduced skipping quiet moves was commited in the time period covered by the following regression test: http://35.161.250.236:6543/tests/view/58d6dc1c6e23db2fa8080e07 (no crazyhouse patches in this time period).

[ddugovic]

Very interesting patch & I assume it will pass testing.

I look forward to next trying "skip quiets during move count pruning if opponent's hand is empty"!

[ddugovic]

It should be interesting to see how upstream PR#1085 goes...

[Vinvin20]

Bad eval because bad mate evaluation here : https://fr.lichess.org/ncFZPqt9#62

[ddugovic]

@Vinvin20 Upstream has a bug which affects quiet (non-capture, non-check) moves for all positions and they're fixing that.

[ppigazzini]

@ddugovic if I'm not wrong the test failed at STC and at LTC, so the patch it's not an ELO gain. I don't know if reverting an upstream change can be tested as simplification.

In fishcooking forum there are several threads about a mate not found, with some patches proposed that solve that mate, but the patches fail SPRT. There is also a SF fork specialized for mate, Mate Finder.

Mate and endgame seems to share the same problem: from a human POV they show some silly engine mistakes (often solved at LTC), but it's not easy to find a general patch ELO gaining.

[ddugovic]

@ppigazzini It's true that particular patch is not an Elo gain. Currently I am interested in seeing upstream PR#1085 resolved since in general crazyhouse drop moves are quiet moves.

With regard to "reverting" upstream changes, if done that would need to be conditioned based on the game variant. But again if the move selector is broken for forcing non-check moves, it's difficult to propose search changes when searches are move-based.

[ppigazzini]

@ddugovic suggest the type of test to be used when reverting an upstream patch, IMO this case is missing in the wiki:

• SPRT(0, 10): standard
• SPRT(-10, 5): no-regression
• SPRT(?, ?): others bounds

[ianfab]

IMO reverting an upstream change should be treated like any other change, and since we want to retain identical functionality for standard chess, such a change will always add code and hence should usually be tested with [0,10] bounds (if it is not a bugfix or the like).

[Vinvin20]

Mate and endgame seems to share the same problem: from a human POV they show some silly engine mistakes (often solved at LTC), but it's not easy to find a general patch ELO gaining.

Yes, that's a big problem linked to current testing.
Example : If a player 1000 Elo below you can use some tricks (mate threats, specific opening preparations, ...) to score 5% against you, your rating will become incorrect.
The self-testing used by SF team hide this possible tricks.

[ppigazzini]

@ianfab from another point of view, it's the upstream patch that add the code to our master. Obviously we cannot retest all the upstream patches, but for a dubious patch a possible test could be a standard SPRT with test=upstream patch and base=our master or a milder test.

[ddugovic]

1. Bugs which affect standard chess should be fixed upstream.
2. Other bugs (which are variant-specific) are treated just like any other issue. Until #278 is solved (which as a practical matter might require revising the C++ specification!) we are not prepared to use other bounds for variant-specific changes.

[ppigazzini]

@Vinvin20

1. fishtest has proved to work very well, 3-4 years ago there were many doubts respect to the self playing testing
2. fishtest seeks ELO improvement on big number of games, there is the price that sometimes it's not easy to win a won game. Customized code for mate and end game often is a ELO loss
3. crazyhouse gained 780 ELO from November 2016, the last regression test showed 110 ELO gain in 20 days. Obviously crazyhouse is still far away from perfection.
4. ELO cannot be negative (IIRC), there is not a player 1000 ELO below me :)

[ianfab]

@ppigazzini What we should compare are the available options. Changing the standard chess code is not an option (IMO), so there basically are two viewpoints:

1. Reverting an upstream change for one or more variants adds code and should tested with [0, 10] bounds.
2. Undoing the reversion for one or more variants is a simplification, so we use the reversion if undoing it does not pass with [-10, 5] bounds.

So the reversion has to pass either [0, 10] or [-5, 10] (inverse simplification) depending on the viewpoint.

[ppigazzini]

@ianfab @ddugovic to be clear: I'm asking the rules of the project (also to update the documentation), I'm not disputing your choices.
I agree that standard must be up to date with upstream.

@ianfab Your two viewpoints are the children of the same viewpoint: a variant add code (add complexity) respect to the standard.
Simply a variant could have a different definition e.g. a single entity without bound to standard but some shared code. In this case each upstream patch should be pass a standard test for each variant, so this definition should be effectively a bit impractical :)

Anyway, within the context of your viewpoint, IMO better to use a standard test [0, 10]:

1. A simplification should be used with caution according Creating my first test, and according the praxis on fishcooking, where the proposed simplifications are often debated at long.
2. negate a simplification is a complication (standard test) and this open the question: why aren't the bound specular?

@Vinvin20 engines look silly also with fortress, with closed position & 50 moves rule

[ddugovic]

@ppigazzini : You are suggesting that we update "Creating my first test" to discuss "inverse simplifications" or "complications"? I think I've seen those done to identify possible causes of regression, but I don't recall any patch having been submitted by an inverse simplification test (though I could be mistaken).

[stockfishdeveloper]

I don't think that at this early point in SF-zh it is necessary to apply Stockfish's rule(or more accurately, Marco Costalba's rule) for simplifications.

Personally It's too early for simplifications--I would say stick with functional changes until simplifications are needed.

[ppigazzini]

@ddugovic simply I suggested to write the logic used in multi variant SF:

1. standard chess is up to date with upstream
2. a variant add code respect to standard chess
3. a patch must pass a standard test [0, 10] to be commitable

Those are sufficient to explains that:

1. all the new upstream patches are accepted as default also for variants
2. reverting an upstream patch for a variant requires to pass a standard test [0, 10]

@stockfishdeveloper IMO to attract others contributors the project must be simple and clear. I copied and edited the official SF rules as a starting point, any suggestion/review is a good thing.

[ddugovic]

@ppigazzini The problem is that this is not simple and in fact all of these statements are inaccurate:

1. standard chess is currently two commits behind upstream
2. variants don't necessarily add code, though often in practice this is the case
3. patches for variants sometimes (rarely) are simplifications or bugfixes based on improved understanding or improved upstream code; the guidelines are accurate & unless I'm overlooking something are sufficient for "my first test".

[ppigazzini]

@ddugovic I'm not writing in this issue the content to be added to the wiki (and not at 03:48 AM :) ). I'm thinking to add a FAQ page where describe, in not strictly formal way, the workflow and the logic behind the workflow. Simply to give some information to newcomers, e.g.:

• master synchronization every xx days (at only maintainers' will; so, newcomer, don't ask for a new resync)
• regression tests
• etc.

About your questions:

1. IMO already answered
2. "add code" intended as "code modification that requires a standard test": both colloquial, I need to study the wiki to chose the correct words and avoid inconsistency
3. simplification is a matter regarding the maintainers

[ianfab]

Let's submit tests instead of having a theoretical discussion (the queue is almost empty at the moment). To put it simple: Unless a patch is a clear simplification, submit tests with [0,10] bounds. If you think other bounds are more appropriate for your test, state good reasons for your choice or otherwise the test won't be approved.

@ppigazzini I think it is safe to say that syncs with upstream and regression tests are usually done at least once a month.

[ddugovic]

@ppigazzini That sounds almost like a CLA, but I suppose given the fact that this project frequently merges from upstream but upstream does not accept changes from this fork, new contributors could be easily confused by how this repository differs from upstream.

[ppigazzini]

@ddugovic help on CLA (???): I haven't found any acronym applicable. Smart suggestion to highlight that the development is only for variants, signed in my todo.

[ddugovic]

I meant Contributor License Agreement (which I would oppose) which formalizes a contract between developers & maintainers (both in terms of maintainer rights as well as stating how maintainers use contributions).

[ddugovic]

To my surprise a STC test passed despite a similar STC test failing. Onward to LTC!

[ddugovic]

EDIT: As of 9c5145ce323456ec6bccea08319d579d4ab8bdb0 this was working.

From latest master, compiled with debug=yes, bench crazyhouse fails:

Position: 5/11
info depth 1 seldepth 2 multipv 1 score cp 1691 nodes 332 nps 166000 tbhits 0 time 2 pv P@g2 f1g2 N@f4 g2g1 f4d3 c2d3 c8h3
info depth 2 seldepth 4 multipv 1 score cp 2170 nodes 1359 nps 453000 tbhits 0 time 3 pv P@g2 f1e2 N@f4 e2d2 g2h1q
info depth 3 seldepth 5 multipv 1 score cp 2170 nodes 1579 nps 526333 tbhits 0 time 3 pv P@g2 f1e2 N@f4 e2d2 g2h1q
info depth 4 seldepth 7 multipv 1 score cp 2555 nodes 2397 nps 599250 tbhits 0 time 4 pv P@g2 f1e2 N@f4 e2d2 g2h1q B@f7 e8f7 N@g5 f7g8
info depth 5 seldepth 9 multipv 1 score cp 2141 nodes 3400 nps 680000 tbhits 0 time 5 pv P@g2 f1e2 N@f4 e2d2 g2h1q B@f7 e8f7 N@g5 f7g6
info depth 6 seldepth 11 multipv 1 score cp 2159 nodes 4587 nps 764500 tbhits 0 time 6 pv P@g2 f1e2 N@f4 e2d2 g2h1q B@f7 e8f7 N@g5 f7g6 Q@f7 g6g5
info depth 7 seldepth 12 multipv 1 score cp 2510 nodes 6301 nps 787625 tbhits 0 time 8 pv P@g2 f1e2 N@f4 e2d2 g2h1q B@f7 e8f7 N@g5 f7g6 g5f3 f4d3
info depth 8 seldepth 16 multipv 1 score cp 1952 nodes 25374 nps 1057250 tbhits 0 time 24 pv P@g2 f1e2 N@f4 e2d2 g2h1q B@f7 e8f7 N@g5 f7g6 Q@f7 g6g5 f7f4 g5f4 N@f7 N@f1 d2c1
info depth 9 seldepth 21 multipv 1 score cp 3890 nodes 249486 nps 1043874 tbhits 0 time 239 pv P@g2 f1e2 N@f4 e2e3 g2h1q B@f7 e8f7 N@d8 f7e8 B@f7 e8e7 Q@h4 B@f6 h4f4 e7d8
stockfish: search.cpp:1615: Value {anonymous}::qsearch(Position&, Search::Stack*, Value, Value, Depth) [with {anonymous}::NodeType NT = (<unnamed>::NodeType)0u; bool InCheck = true]: Assertion `value > -VALUE_INFINITE' failed.
Aborted (core dumped)

[ianfab]

@ddugovic I have an idea regarding the bug, but I am not entirely sure yet. It might be that removing the king danger cap in the last merge can lead to position evaluations below -VALUE_INFINITE, since there can be a huge number of attacking pieces in crazyhouse and the king danger malus increases quadratically. A test already showed that removing the cap is bad for performance in crazyhouse.

[ddugovic]

@ianfab Yes, that's exactly the nature of the bug. Surely my patch will fail testing... I'll see if I can improve it.

[ddugovic]

Fixed via 2184f4eb5c76b85c7b3aeba5fd7921a8ace599e7 .