Is modern chess software lossless or lossy?

[Robert Pope]

But then people started to add pruning and reduction heuristics like the null-move pruning and late-move reductions, which again made the search selective.

Modern top engines are very selective, but they are very different from the early Type B programs in that they use information gathered during the search to make pruning and reduction decisions.

Presumably though the situation is bound by time rather than in principle. Meaning, if the modern engine was given infinite time, the moves it had pruned out would eventually be searched and thus it would revert back to true Brute Force.

Is that correct?

Ideally, yes. In practice, there will be moves that cannot be found within MAX_PLY depth.

What about zugzwang? If an engine uses null move to reduce, and that causes it to miss a key variation, that doesn't ever get solved by higher depth searches, does it?

[syzygy]

I don't know how hard is to enclose that code inside #ifdef sections, allowing to compile a non-selective version of the engine.
But it would be interesting to see how engines play against their "complete" version.

This crippled version will be terrible weak. Has been done many times.

I have just created Cripplefish. No pruning, no reductions.

Its nps is more than twice that of Cfish. But a bench to depth 7 still takes more than twice as long as a Cfish bench to depth 13.

Of course this is irrelevant. How well does it play?

Code: Select all

Score of cripplefish vs cfish: 0 - 98 - 2  [0.010] 100
Elo difference: -798.25 +/- nan

Hmm...

[pgn][White "cfish"]
[Black "cripplefish"]
[Result "1/2-1/2"]
[FEN "rn1qkbnr/p1pppppp/b7/1p6/8/N6P/PPPPPPP1/R1BQKBNR w KQkq - 0 1"]
[PlyCount "176"]
[SetUp "1"]
[TimeControl "10+0.1"]

1. e4 {+0.65/16 0.34s} c6 {-0.68/9 1.1s} 2. d4 {+0.70/16 0.14s} e6 {-0.46/9 1.1s} 3. Nf3 {+0.58/19 1.1s} d5 {-0.28/7 0.11s} 4. e5 {+0.57/19 0.79s} Qa5+ {-0.67/9 1.1s} 5. Bd2 {+0.37/20 0.51s} b4 {-0.90/8 0.14s} 6. c4 {+0.41/18 0.077s} bxc3 {-0.87/8 0.57s} 7. Bxc3 {+0.23/21 0.25s} Bb4 {-0.90/8 0.13s} 8. Qb3 {+0.17/20 0.37s} Bxc3+ {-0.67/8 0.29s} 9. Qxc3 {+0.20/19 0.26s} Qxc3+ {-0.59/9 0.34s} 10. bxc3 {+0.39/21 0.11s} Bxf1 {-0.58/9 0.29s} 11. Kxf1 {+0.48/20 0.17s} Ne7 {-0.49/9 0.39s} 12. Rb1 {+0.82/16 0.12s} Nd7 {-0.51/9 0.68s} 13. Rb7 {+0.29/17 0.29s} O-O-O {-0.17/9 0.75s} 14. Rxa7 {+0.22/20 0.42s} Kb8 {-0.02/9 0.27s} 15. Ra4 {+0.03/19 0.16s} Kc7 {-0.27/9 0.86s} 16. Nc2 {+0.15/20 0.23s} Ra8 {-0.34/9 0.95s} 17. Rxa8 {+0.08/21 0.35s} Rxa8 {-0.23/9 0.43s} 18. a3 {+0.10/20 0.16s} Rb8 {-0.19/9 1.0s} 19. Ke2 {+0.08/20 0.66s} Rb3 {-0.12/9 0.90s} 20. Ng5 {+0.30/15 0.087s} Rxc3 {+0.02/7 0.044s} 21. Kd2 {+0.08/19 0.29s} Rb3 {-0.51/9 0.46s} 22. Nxf7 {+0.08/18 0.19s} Nb6 {-0.27/8 0.099s} 23. Nd6 {+0.08/19 0.24s} Nc4+ {-0.28/7 0.052s} 24. Nxc4 {+0.27/20 0.26s} dxc4 {-0.19/8 0.12s} 25. Ne3 {+0.16/20 0.24s} Rxa3 {-0.15/8 0.13s} 26. Nxc4 {+0.23/18 0.15s} Ra2+ {-0.02/7 0.031s} 27. Ke3 {+0.10/19 0.28s} Nf5+ {-0.13/8 0.17s} 28. Kd3 {0.00/24 1.1s} Rxf2 {-0.15/8 0.098s} 29. g4 {0.00/26 0.38s} Ne7 {-0.15/8 0.088s} 30. Nd6 {+0.08/17 0.20s} Nd5 {-0.07/8 0.11s} 31. Ne8+ {+0.09/17 0.19s} Kd7 {-0.03/8 0.077s} 32. Nxg7 {+0.08/19 0.18s} Rf3+ {-0.09/7 0.091s} 33. Ke2 {+0.08/20 0.17s} Ra3 {-0.16/8 0.13s} 34. Rf1 {+0.08/20 0.28s} Ra2+ {-0.08/7 0.061s} 35. Ke1 {+0.49/16 0.24s} Ke7 {-0.09/8 0.14s} 36. Rf3 {+0.10/17 0.15s} Nb4 {-0.09/7 0.038s} 37. Kd1 {+0.54/15 0.099s} Ra1+ {-0.08/8 0.16s} 38. Kd2 {+0.13/17 0.27s} Ra2+ {-0.08/8 0.092s} 39. Kc1 {+0.08/17 0.23s} Rc2+ {-0.02/8 0.10s} 40. Kb1 {+0.03/16 0.15s} Rc4 {-0.07/9 0.10s} 41. Rf6 {0.00/16 0.17s} Rxd4 {-0.17/8 0.075s} 42. Rh6 {+0.40/14 0.28s} Rd1+ {-0.41/8 0.13s} 43. Kb2 {+0.42/1 0s} Re1 {-0.71/9 0.099s} 44. Nxe6 {+0.76/12 0.051s} Nd3+ {-0.73/8 0.10s} 45. Kc3 {+1.09/14 0.15s} Nxe5 {-0.89/7 0.031s} 46. Ng5 {+1.01/17 0.17s} Kd7 {-0.80/7 0.075s} 47. Kd4 {+1.10/16 0.27s} Kc7 {-0.95/8 0.12s} 48. Rxh7+ {+1.30/13 0.085s} Kb6 {-1.12/9 0.17s} 49. Nf7 {+1.15/15 0.18s} Nf3+ {-0.79/6 0.020s} 50. Kd3 {+0.91/16 0.42s} Re7 {-0.95/8 0.18s} 51. Ng5 {+1.20/14 0.11s} Ne1+ {-0.98/8 0.10s} 52. Kc3 {+1.40/16 0.10s} Re5 {-1.10/9 0.096s} 53. Kd2 {+1.49/15 0.14s} Ng2 {-1.16/9 0.10s} 54. Nf3 {+1.44/14 0.091s} Ra5 {-1.36/8 0.10s} 55. Rf7 {+1.44/12 0.076s} Ra2+ {-1.25/7 0.030s} 56. Kc3 {+1.57/13 0.069s} Ra8 {-1.38/9 0.17s} 57. g5 {+1.04/14 0.38s} Rh8 {-1.32/8 0.098s} 58. g6 {+1.11/12 0.030s} Rxh3 {-1.42/7 0.039s} 59. Kc4 {+0.01/14 0.60s} Rg3 {-1.15/6 0.017s} 60. Ne5 {0.00/14 0.046s} Ka6 {-0.99/7 0.11s} 61. Rf3 {0.00/13 0.13s} Rg5 {-0.08/7 0.026s} 62. g7 {0.00/15 0.037s} Rxg7 {-0.06/6 0.041s} 63. Nxc6 {0.00/24 0.050s} Kb6 {0.00/8 0.18s} 64. Ne5 {0.00/13 0.093s} Rh7 {0.00/7 0.093s} 65. Kd5 {0.00/13 0.16s} Rh5 {0.00/8 0.29s} 66. Ke4 {0.00/12 0.16s} Rh4+ {0.00/7 0.077s} 67. Kf5 {0.00/15 0.29s} Rh5+ {0.00/8 0.12s} 68. Kf6 {0.00/15 0.21s} Ka6 {0.00/7 0.083s} 69. Ke6 {0.00/12 0.071s} Kb5 {0.00/7 0.071s} 70. Kf6 {0.00/17 0.37s} Rh6+ {0.00/7 0.052s} 71. Kg5 {0.00/11 0.024s} Re6 {0.00/7 0.030s} 72. Kf5 {0.00/13 0.045s} Re8 {0.00/9 0.27s} 73. Rg3 {0.00/14 0.074s} Nh4+ {0.00/7 0.019s} 74. Ke4 {0.00/13 0.033s} Kc5 {0.00/8 0.18s} 75. Rc3+ {0.00/16 0.22s} Kb4 {0.00/8 0.036s} 76. Rg3 {0.00/18 0.051s} Ra8 {0.00/9 0.17s} 77. Kd5 {0.00/13 0.090s} Ra5+ {0.00/6 0.021s} 78. Ke4 {0.00/13 0.064s} Ra6 {0.00/7 0.042s} 79. Nd3+ {0.00/13 0.089s} Kb5 {0.00/7 0.035s} 80. Rg5+ {0.00/12 0.039s} Kb6 {0.00/8 0.065s} 81. Nb2 {0.00/12 0.061s} Kc7 {0.00/8 0.24s} 82. Rh5 {0.00/14 0.23s} Ng6 {0.00/7 0.060s} 83. Kd4 {0.00/14 0.078s} Rd6+ {0.00/7 0.12s} 84. Kc5 {0.00/16 0.12s} Nf4 {0.00/8 0.22s} 85. Rh7+ {0.00/11 0.024s} Rd7 {0.00/8 0.032s} 86. Rxd7+ {0.00/17 0.16s} Kxd7 {0.00/8 0.029s} 87. Kc4 {0.00/18 0.12s} Kc6 {0.00/10 0.14s} 88. Nd3 {0.00/19 0.12s} Nxd3 {0.00/10 0.020s, Draw by insufficient mating material} 1/2-1/2[/pgn]

[pgn][White "cfish"]
[Black "cripplefish"]
[Result "1/2-1/2"]
[FEN "rnbqkb1r/ppppppp1/5n1p/8/8/4P2P/PPPP1PP1/RNBQKBNR w KQkq - 0 1"]
[PlyCount "201"]
[SetUp "1"]
[TimeControl "10+0.1"]

1. d4 {+0.12/18 0.48s} d5 {-0.37/8 0.37s} 2. c4 {+0.07/16 0.20s} e6 {-0.15/7 0.19s} 3. Nf3 {+0.06/17 0.52s} c5 {-0.05/7 0.33s} 4. cxd5 {+0.10/16 0.28s} exd5 {-0.03/7 0.28s} 5. Bb5+ {+0.09/16 0.17s} Bd7 {-0.07/9 1.3s} 6. Bxd7+ {+0.25/14 0.084s} Nbxd7 {-0.22/8 0.21s} 7. dxc5 {+0.32/18 0.32s} Bxc5 {+0.17/7 0.15s} 8. O-O {+0.59/18 0.84s} O-O {+0.12/7 0.23s} 9. Nc3 {+0.68/16 0.28s} Nb6 {-0.33/9 1.3s} 10. b3 {+0.72/15 0.17s} Rc8 {-0.43/8 0.42s} 11. Bb2 {+0.46/17 0.79s} Ne4 {-0.13/7 0.23s} 12. a4 {+0.68/16 0.097s} Bxe3 {-0.48/8 1.2s} 13. Nxe4 {+0.33/18 0.35s} dxe4 {-0.34/7 0.066s} 14. fxe3 {+0.45/19 0.17s} Qxd1 {-0.68/8 0.30s} 15. Raxd1 {+0.57/18 0.10s} exf3 {-0.47/8 0.18s} 16. gxf3 {+0.49/19 0.48s} Rfd8 {-0.57/9 0.98s} 17. Bd4 {+0.66/17 0.20s} f6 {-0.55/9 1.2s} 18. Kf2 {+0.55/15 0.22s} Kf7 {-0.66/8 0.45s} 19. a5 {+0.30/19 1.1s} Nd5 {-0.53/9 1.1s} 20. Bxa7 {+0.41/17 0.14s} Ra8 {-0.53/8 0.22s} 21. e4 {+0.30/19 0.24s} Rxa7 {-0.40/8 0.13s} 22. b4 {+0.37/20 0.36s} b6 {-0.25/8 0.078s} 23. axb6 {+0.12/21 0.32s} Ra2+ {-0.53/8 0.29s} 24. Kg1 {+0.19/20 0.10s} Ra6 {-0.47/9 0.91s} 25. exd5 {+0.13/20 0.27s} Rxb6 {-0.52/8 0.16s} 26. Rd4 {+0.05/22 0.39s} Rdb8 {-0.37/8 0.16s} 27. Rb1 {+0.02/20 0.16s} Ke7 {-0.38/7 0.029s} 28. Rg4 {+0.04/20 0.29s} Kd6 {-0.19/8 0.11s} 29. Rxg7 {+0.15/16 0.058s} Rxb4 {-0.26/8 0.11s} 30. Rxb4 {0.00/26 0.63s} Rxb4 {-0.08/9 0.060s} 31. Kg2 {0.00/28 0.18s} h5 {-0.08/10 0.19s} 32. Rh7 {+0.08/23 0.078s} h4 {-0.08/9 0.056s} 33. Rh5 {+0.08/27 0.13s} Rb2+ {-0.08/9 0.098s} 34. Kg1 {0.00/37 0.74s} Ra2 {-0.08/10 0.15s} 35. Rxh4 {+0.08/21 0.051s} Kxd5 {-0.38/8 0.056s} 36. Re4 {0.00/33 0.35s} f5 {-0.37/9 0.13s} 37. Re8 {0.00/40 0.31s} Rc2 {-0.39/9 0.11s} 38. h4 {0.00/42 0.36s} Rb2 {-0.22/10 0.10s} 39. h5 {0.00/30 0.069s} Rb7 {-0.22/9 0.042s} 40. Kf2 {0.00/36 0.097s} Rh7 {0.00/9 0.030s} 41. f4 {0.00/45 0.097s} Rxh5 {0.00/10 0.062s} 42. Kg3 {0.00/35 0.37s} Kd6 {0.00/10 0.17s} 43. Re5 {0.00/29 0.28s} Kd7 {0.00/10 0.12s} 44. Kf3 {0.00/33 0.32s} Kd6 {0.00/9 0.044s} 45. Ke3 {0.00/34 0.38s} Rh3+ {0.00/9 0.046s} 46. Kd4 {0.00/34 0.20s} Ra3 {0.00/9 0.040s} 47. Rxf5 {0.00/32 0.15s} Ke6 {0.00/8 0.050s} 48. Rb5 {0.00/34 0.14s} Ra4+ {0.00/8 0.053s} 49. Ke3 {0.00/36 0.14s} Ra3+ {0.00/9 0.11s} 50. Ke4 {0.00/38 0.17s} Ra6 {0.00/9 0.043s} 51. f5+ {0.00/24 0.038s} Kf7 {0.00/9 0.073s} 52. Ke5 {0.00/21 0.029s} Kf8 {0.00/9 0.045s} 53. Rb8+ {0.00/25 0.22s} Ke7 {0.00/10 0.11s} 54. Rb7+ {0.00/27 0.032s} Kf8 {0.00/11 0.11s} 55. Rc7 {0.00/31 0.047s} Rh6 {0.00/10 0.056s} 56. Rb7 {0.00/28 0.056s} Ra6 {0.00/10 0.055s} 57. Rc7 {0.00/34 0.047s} Rh6 {0.00/11 0.27s} 58. Rd7 {0.00/32 0.050s} Ke8 {0.00/11 0.12s} 59. Ra7 {0.00/33 0.055s} Rb6 {0.00/10 0.054s} 60. Kd5 {0.00/33 0.052s} Rh6 {0.00/10 0.13s} 61. Ke4 {0.00/33 0.056s} Rf6 {0.00/9 0.064s} 62. Kd5 {0.00/29 0.055s} Rb6 {0.00/11 0.097s} 63. Ke4 {0.00/33 0.062s} Rh6 {0.00/10 0.12s} 64. Rb7 {0.00/32 0.057s} Rf6 {0.00/10 0.067s} 65. Ra7 {0.00/34 0.071s} Rb6 {0.00/11 0.15s} 66. Rg7 {0.00/34 0.079s} Rc6 {0.00/10 0.088s} 67. Rb7 {0.00/31 0.061s} Rf6 {0.00/11 0.25s} 68. Ra7 {0.00/35 0.057s} Rb6 {0.00/11 0.046s} 69. Rg7 {0.00/37 0.080s} Ra6 {0.00/11 0.23s} 70. Rc7 {0.00/33 0.069s} Rb6 {0.00/10 0.091s} 71. Rh7 {0.00/33 0.071s} Rc6 {0.00/10 0.040s} 72. Rg7 {0.00/35 0.082s} Rb6 {0.00/11 0.098s} 73. Rh7 {0.00/34 0.099s} Rf6 {0.00/11 0.25s} 74. Rb7 {0.00/33 0.057s} Ra6 {0.00/10 0.030s} 75. Rg7 {0.00/35 0.071s} Kf8 {0.00/11 0.095s} 76. Rh7 {0.00/35 0.084s} Kg8 {0.00/10 0.042s} 77. Rc7 {0.00/32 0.11s} Kf8 {0.00/10 0.081s} 78. Ke3 {0.00/35 0.077s} Ke8 {0.00/10 0.13s} 79. Kf4 {0.00/37 0.091s} Kf8 {0.00/10 0.070s} 80. Rb7 {0.00/35 0.073s} Rc6 {0.00/10 0.080s} 81. Ra7 {0.00/35 0.075s} Rb6 {0.00/10 0.092s} 82. Kf3 {0.00/35 0.11s} Kg8 {0.00/10 0.13s} 83. Kg4 {0.00/35 0.077s} Kf8 {0.00/9 0.036s} 84. Kg5 {0.00/35 0.16s} Kg8 {0.00/10 0.056s} 85. Kf4 {0.00/35 0.095s} Kf8 {0.00/11 0.16s} 86. Ke5 {0.00/36 0.073s} Rb5+ {0.00/10 0.095s} 87. Kf6 {0.00/32 0.076s} Rb6+ {0.00/12 0.17s} 88. Ke5 {0.00/34 0.21s} Rb5+ {0.00/10 0.039s} 89. Ke6 {0.00/30 0.17s} Rb6+ {0.00/11 0.16s} 90. Kd5 {0.00/30 0.67s} Rf6 {0.00/11 0.15s} 91. Ke5 {0.00/30 0.25s} Rb6 {0.00/11 0.19s} 92. Kd5 {0.00/31 0.15s} Rh6 {0.00/11 0.056s} 93. Rd7 {0.00/29 0.13s} Ke8 {0.00/10 0.065s} 94. Rc7 {0.00/28 0.14s} Kf8 {0.00/10 0.085s} 95. Ke5 {0.00/35 0.21s} Ra6 {0.00/10 0.059s} 96. Rc8+ {0.00/30 0.038s} Ke7 {0.00/9 0.037s} 97. Ke4 {0.00/26 0.041s} Kf6 {0.00/9 0.22s} 98. Rf8+ {0.00/39 0.18s} Kg7 {0.00/11 0.077s} 99. Rc8 {0.00/48 0.28s} Ra4+ {0.00/11 0.15s} 100. Kd3 {0.00/49 0.031s} Ra3+ {0.00/19 0.041s} 101. Kc2 {0.00/127 0.001s, Draw by fifty moves rule} 1/2-1/2[/pgn]

[Ovyron]

Can you release Cripplefish?

[Dann Corbit]

But then people started to add pruning and reduction heuristics like the null-move pruning and late-move reductions, which again made the search selective.

Modern top engines are very selective, but they are very different from the early Type B programs in that they use information gathered during the search to make pruning and reduction decisions.

Presumably though the situation is bound by time rather than in principle. Meaning, if the modern engine was given infinite time, the moves it had pruned out would eventually be searched and thus it would revert back to true Brute Force.

Is that correct?

Ideally, yes. In practice, there will be moves that cannot be found within MAX_PLY depth.

What about zugzwang? If an engine uses null move to reduce, and that causes it to miss a key variation, that doesn't ever get solved by higher depth searches, does it?

Null move reductions reduce the depth for a particular move. Sometimes, dramatically, when special heuristics are applied (based on current depth and distance between the current evaluation and the current score, for instance). If a pruned move is actually winning, we will fail to search it properly.

But eventually, the move would probably be found anyway though it may take a very long time.

Suppose that a move is reduced 7 plies, and it would have been found without the reduction.

If there are no further reductions, then we will search the reduced path the to the proper depth 7 plies later. If there are 3 more plies of reductions for the zugzwang key move, then we will search the proper depth 10 plies later. Unfortunately, with a branching factor of 2, that would mean it takes 1000 times longer to find the right move if the move were pruned a full ten plies. Now, some engines have a branching factor close to 1.5 which means it would take about 60 times longer to find the right move.

There are special tests to verify null move reductions used by some engines (Idea from Omid David).

It is also not uncommon to not allow two null moves (Idea from Vincent Diepeveen).

That is why null move reduction is classified as "unsound". Same goes for LMR and every other reduction I know of besides Alpha-Beta, for that matter.

It really boils down to having computers play more like we do.

In a real game, if we see that putting our queen on a square guarded by an enemy pawn is going to cost us the queen, we do not explore it as deeply. That's because most of the time, it won't turn out well if we toss the queen. Still, we might look ahead a few plies if we see something interesting about the move. Same for chess engines.

[cdani]

For the curious, if you play Cripplefish with Cfish at fixed depth, Cripplefish will be much stronger. I tried some time ago with Andscacs and if I remember well at depth 10 was maybe 200 elo stronger. But only that you play Cripplefish at depth 10 and Cfish at depth 12-13, Cfish will win.
I tried also at higher depths, and the difference of strength at the same depth diminishes.

[syzygy]

Ideally, yes. In practice, there will be moves that cannot be found within MAX_PLY depth.

What about zugzwang? If an engine uses null move to reduce, and that causes it to miss a key variation, that doesn't ever get solved by higher depth searches, does it?

Stockfish's null-move implementation performs a verification search that is supposed to catch zugzwang situations, but it takes a lot of depth before it kicks in.

[Dann Corbit]

For the curious, if you play Cripplefish with Cfish at fixed depth, Cripplefish will be much stronger. I tried some time ago with Andscacs and if I remember well at depth 10 was maybe 200 elo stronger. But only that you play Cripplefish at depth 10 and Cfish at depth 12-13, Cfish will win.
I tried also at higher depths, and the difference of strength at the same depth diminishes.

I guess that everyone expected that, but it is good to have actual verification.

[syzygy]

Can you release Cripplefish?

If you know how to compile it:
https://github.com/syzygy1/Cfish/tree/cripplefish
https://github.com/syzygy1/Cfish/archiv ... lefish.zip

[Uri Blass]

This is not really true. In huge majority of the cases it is really hard for software to find the best move because of the horizon effect and not because the best move has been pruned.
The most you can say is that potential threats that show the current best move is not the best are pruned due to LMR or null-move heuristics.

The horizon effect can be tested by making the move and seeing if the engine does not like it still. If it sees that the move was clearly best, it missed it because of prunning. If it still does not like it, and it takes a similar long time to like it as when missing it from the root, then it's the horizon effect.

I do not agree.

The program may get easily high depth after making the move and see that the move is bad but not get depth that is big enough to see that the move is bad before making the move.


Another point is that it is possible that the engine see easily that the move is the best after the move but miss the move also without pruning.

The point is that thanks to pruning the engine can get depth 20 in 1 second after the move so it easily see that the move was clearly best.

Without pruning the engine cannot get depth 20 in a reasonable time so it practically miss the move.

[Ovyron]

The program may get easily high depth after making the move and see that the move is bad but not get depth that is big enough to see that the move is bad before making the move.

For the cases that I've seen, how slow or fast the engine reaches some depth doesn't matter, it's just that it was reducing the critical line (which I call prunning; i.e. it's not prunning the entire branch, just some part of it), it is extended (i.e. not prunned) one the engine has the position on their face. The engine sees the move is bad at low depth, not just at a faster time frame.

Komodo allows one to play with this with its Reduction parameter, Komodo with Reduction -1000 will prune a lot less lines, getting closer to brute force (approaching lossless), and with Reduction=150 it will prune most of the tree, so it is tall but slim, having no problem reaching depth 40 in one minute, but with low quality moves.

Another point is that it is possible that the engine see easily that the move is the best after the move but miss the move also without pruning.

I agree, but the question is how often is it because of the horizon effect.

The point is that thanks to pruning the engine can get depth 20 in 1 second after the move so it easily see that the move was clearly best.

I haven't seen the engine being much faster when the move is played, it doesn't need so much depth to see the plan. If there's a sweet spot that allows the engine to find those best moves, it may be a good idea to prune less at low depths, and prune as normal after a few seconds, at least for analysis because in practice this idea should lost elo.