Stockfish max seldepth

[zullil]

Is seldepth still capped at 120 (or 121)? Does it need to be?

Seem to be running into a limit when searching this position:

[D]7k/5Bp1/6P1/7K/8/5P2/8/2q5 w - - 1 5

Code: Select all

info depth 85 seldepth 121 score cp -12356 nodes 122378694949 nps 42177893 time 2901489 multipv 1 pv h5g4 c1c2 g4g3 c2d2 g3g4 d2d6 g4f5 d6d4 f5e6 d4d3 e6e5 d3f3 e5d4 f3f1 d4e3 f1e1 e3d3 e1g1 d3c4 g1d1 c4c5 d1d3 c5b6 d3d6 b6b5 d6a3 b5c6 a3a6
info depth 86 currmove h5g4 currmovenumber 1
info depth 86 currmove f3f4 currmovenumber 2
info depth 86 seldepth 121 score cp -12356 nodes 125076224165 nps 41982594 time 2979240 multipv 1 pv h5g4 c1c2 g4g3 c2d2 g3g4 d2d6 g4f5 d6d4 f5e6 d4d3 e6e5 d3f3 e5d4 f3f1 d4e3 f1e1 e3d3 e1g1 d3c4 g1d1 c4c5 d1d3 c5b6 d3d6 b6b5 d6a3 b5c6 a3a6 c6d7 a6d3 d7c8 d3c3 c8b7 c3f3 b7a6 f3e3 a6b7 e3f4 b7c6 f4f6 c6d5 f6a6 d5d4 a6f1
info depth 87 currmove h5g4 currmovenumber 1
info depth 87 currmove f3f4 currmovenumber 2
info depth 87 seldepth 121 score cp -12356 nodes 128870854920 nps 41784492 time 3084179 multipv 1 pv h5g4 c1c2 g4g3 c2d2 g3g4 d2d6 g4f5 d6d4 f5e6 d4d3 e6e5 d3f3
info depth 88 currmove h5g4 currmovenumber 1
info depth 88 currmove f7e8 currmovenumber 3
info depth 88 seldepth 121 score cp -12356 nodes 135481353553 nps 41662675 time 3251864 multipv 1 pv h5g4 c1c2 g4g3 c2d2 g3g4 d2d6 g4f5 d6d4 f5e6 d4d3 e6e5 d3f3 e5d6 f3f1 d6e6 f1e2 e6d6 e2a6 d6e7 a6b6 e7d7 b6b8 d7c6 b8d8 c6c5 d8d3
info depth 89 currmove h5g4 currmovenumber 1
info depth 89 currmove f7e8 currmovenumber 2
info depth 89 seldepth 121 score cp -12356 nodes 137389939578 nps 41475168 time 3312583 multipv 1 pv h5g4 c1c2 g4g3 c2d2 g3g4 d2d6 g4f5 d6d4 f5e6 d4d3 e6e5 d3f3 e5d6 f3f1 d6e6 f1e2 e6d5 e2a6 d5e5 a6a1 e5d5 a1a8 d5c4 a8f3 c4d4 f3f1 d4e3 f1e1 e3d3 e1g1 d3c4 g1d1 c4c5 d1d3 c5b6 d3d6
info depth 90 currmove h5g4 currmovenumber 1
info depth 90 currmove f7a2 currmovenumber 6
info depth 90 seldepth 121 score cp -12356 nodes 138381567698 nps 41377420 time 3344374 multipv 1 pv h5g4 c1c2 g4g3 c2d2 g3g4 d2d6 g4f5 d6d4 f5e6 d4d3 e6e5 d3f3 e5d6 f3f1 d6e6 f1e2 e6d5 e2a6 d5e5 a6a1 e5f4 a1d1 f4e4 d1h1 e4f5 h1c6 f5g4 c6c2 g4f3 c2f5 f3e2 f5e5 e2f3 e5e1 f3f4 e1d1
info depth 91 currmove h5g4 currmovenumber 1
info depth 91 currmove h5h4 currmovenumber 9
info depth 91 seldepth 121 score cp -12356 nodes 154705134416 nps 41722843 time 3707924 multipv 1 pv h5g4 c1c2 g4g3 c2d2 g3g4 d2d6 g4f5 d6d4 f5e6 d4d3 e6e5 d3f3 e5d6 f3f1 d6e6 f1e2 e6d5 e2a6 d5e5 a6f6
info depth 92 currmove h5g4 currmovenumber 1
info depth 92 currmove f7d5 currmovenumber 3
info depth 92 seldepth 121 score cp -12356 nodes 401535345606 nps 45250715 time 8873569 multipv 1 pv h5g4 c1c2 g4g3 c2d2 g3g4 d2d6 g4f5 d6d4 f5e6 d4d3 e6e5 d3f3 e5d6 f3f1 d6e6 f1e2 e6d5 e2a6 d5e5 a6f6 e5e4 f6b2 e4d5 b2b5 d5e4 b5b1 e4e5 b1d3 e5e6 d3c2 e6d7 c2d1
info depth 93 currmove h5g4 currmovenumber 1
info depth 93 currmove f7d5 currmovenumber 3
info depth 93 seldepth 121 score cp -12356 nodes 408452411724 nps 45086093 time 9059388 multipv 1 pv h5g4 c1c2 g4g3 c2d2 g3g4 d2d6 g4f5 d6d4 f5e6 d4d3 e6e5 d3f3 e5d6 f3f1 d6e6 f1e2 e6d5 e2a6 d5e5 a6f6 e5e4 f6b2 e4d5 b2b5 d5d4 b5g5 d4c4 g5c1 c4d5 c1d2
info depth 94 currmove h5g4 currmovenumber 1
info depth 94 currmove f7e6 currmovenumber 7
info depth 94 seldepth 121 score cp -12356 nodes 413731594955 nps 45054798 time 9182853 multipv 1 pv h5g4 c1c2 g4g3 c2d2 g3g4 d2d6 g4f5 d6d4 f5e6 d4d3 e6e5 d3f3 e5d6 f3f1 d6e6 f1e2 e6d5 e2a6 d5e5 a6f6 e5e4 f6b2 e4d5 b2b5 d5e4 b5b2
info depth 95 currmove h5g4 currmovenumber 1
info depth 95 currmove f7b3 currmovenumber 7
info depth 95 seldepth 121 score cp -12356 nodes 1195339376566 nps 46673046 time 25610914 multipv 1 pv h5g4 c1c2 g4g3 c2d2 g3g4 d2d6 g4f5 d6d4 f5e6 d4d3 e6e5 d3f3 e5d6 f3f1 d6e6 f1e2 e6d7 e2d3 d7e7 d3d4 e7e6 d4d8 e6e5 d8f6 e5d5 f6a6 d5e5 a6f6
info depth 96 currmove h5g4 currmovenumber 1
info depth 96 currmove f7d5 currmovenumber 2
info depth 96 seldepth 121 score cp -12356 nodes 1208613518039 nps 46568541 time 25953433 multipv 1 pv h5g4 c1c2 g4g3 c2d2 g3g4 d2d6 g4f5 d6d4 f5e6 d4d3 e6e5 d3f3 e5d6 f3f1 d6e6 f1e2 e6d7 e2d3 d7e7 d3d4 e7e6 d4d8 e6e5 d8f6
info depth 97 currmove h5g4 currmovenumber 1
info depth 97 currmove f7d5 currmovenumber 2
info depth 97 seldepth 121 score cp -12356 nodes 1761970857997 nps 46788323 time 37658346 multipv 1 pv h5g4 c1c2 g4g3 c2d2 g3g4 d2d6 g4f5 d6d4 f5e6 d4d3 e6e5 d3f3 e5d6 f3f1 d6e6 f1e2 e6d7 e2d3 d7e7 d3d4 e7e6 d4d8 e6e5 d8f6 e5d5 f6f5 d5c6 f5h3 f7d5 h3e3 c6d6 e3f4
info depth 98 currmove h5g4 currmovenumber 1
info depth 98 currmove f7g8 currmovenumber 10
info depth 98 seldepth 121 score cp -12356 nodes 1940517572902 nps 46578701 time 41661049 multipv 1 pv h5g4 c1c2 g4g3 c2d2 g3g4 d2d6 g4f5 d6d4 f5e6 d4d3 e6e5 d3f3 e5d6 f3f1 d6e6 f1e2 e6d7 e2d3 d7e7 d3d4 e7e6 d4d8 e6e5 d8f6 e5d5 f6f5 d5d4 f5g4 d4c5 g4g5 c5b6 g5d8 b6a6 d8d6 a6b5 d6d3 b5c5 d3d8 c5c6 d8e7 c6d5 e7a3 d5e6 a3c3 e6d7 c3d3
info depth 99 currmove h5g4 currmovenumber 1
info depth 99 currmove f7e8 currmovenumber 2
info depth 99 seldepth 121 score cp -12356 nodes 1958475646581 nps 46537106 time 42084173 multipv 1 pv h5g4 c1c2 g4g3 c2d2 g3g4 d2d6 g4f5 d6d4 f5e6 d4d3 e6e5 d3f3 e5d6 f3f1 d6e6 f1e2 e6d7 e2d3 d7e7 d3d4 e7e6 d4d8 e6e5 d8f6 e5d5 f6h4 d5e6 h4h3 e6e7 h3a3 e7d8 a3d3 d8c7 d3f3 f7e6 f3e2 e6f7 e2e1 c7d7 e1e2 d7d8 e2d3
info depth 100 currmove h5g4 currmovenumber 1

[Eelco de Groot]

Is seldepth still capped at 120 (or 121)? Does it need to be?

Seem to be running into a limit when searching this position:

[D]7k/5Bp1/6P1/7K/8/5P2/8/2q5 w - - 1 5

In types.h the constant is still the same

Code: Select all

const int MAX_PLY        = 120;

only Stockfish no longer counts half plies. I think the main counter in id_loop was always counting in full plies, not half plies and this has not changed. So the size of the arrays that determines the load on the stack has not changed with the new code, and to prevent stack overflow, you can't make

Code: Select all

Stack stack[MAX_PLY_PLUS_6]

line 244 now in search.cpp at the start of id_loop, much larger. If the maximum depth is not enough, maybe it is better to make the last iteration search with some reductions disabled, there is some risk of stack overflow I suppose? But in most cases that should be fine. Or accept that in some positions the maximum depth is not enough. Which is simpler, it usually means search is making simplistic assumptions if there are too many positions with problems for the standard depthlimit.

[bob]

Is seldepth still capped at 120 (or 121)? Does it need to be?

Seem to be running into a limit when searching this position:

[D]7k/5Bp1/6P1/7K/8/5P2/8/2q5 w - - 1 5

In types.h the constant is still the same

Code: Select all

const int MAX_PLY        = 120;

only Stockfish no longer counts half plies. I think the main counter in id_loop was always counting in full plies, not half plies and this has not changed. So the size of the arrays that determines the load on the stack has not changed with the new code, and to prevent stack overflow, you can't make

Code: Select all

Stack stack[MAX_PLY_PLUS_6]

line 244 now in search.cpp at the start of id_loop, much larger. If the maximum depth is not enough, maybe it is better to make the last iteration search with some reductions disabled, there is some risk of stack overflow I suppose? But in most cases that should be fine. Or accept that in some positions the maximum depth is not enough. Which is simpler, it usually means search is making simplistic assumptions if there are too many positions with problems for the standard depthlimit.

I think it is even simpler. NO chess program has any business searching out to 120 plies and deeper. There is so much error in the search when it is tuned to reach those depths, that such scores that get backed up will never actually be seen anyway.

In general, these limits are set to avoid segfaults that result from a subscript going out of bounds. There is a famous position that causes the default Fruit 2.1 to completely blow up on a simple 7 ply search, because it extends out beyond 200 plies. And wastes a ton of time searching stuff that is completely imaginary.

[BeyondCritics]

Curiously black wins immediately, if he has the move:
[d]7k/5Bp1/6P1/7K/8/5P2/8/2q5 b - - 1 5
Qf4! and white has to move the bishop.

[Zenmastur]

I think it is even simpler. NO chess program has any business searching out to 120 plies and deeper. There is so much error in the search when it is tuned to reach those depths, that such scores that get backed up will never actually be seen anyway.

In general, these limits are set to avoid segfaults that result from a subscript going out of bounds. There is a famous position that causes the default Fruit 2.1 to completely blow up on a simple 7 ply search, because it extends out beyond 200 plies. And wastes a ton of time searching stuff that is completely imaginary.

I'm not so sure that's true. I've had SF change a move on ply 112 on two different occasions and have had it run to 120 plies so many times that I can't count that high. This mostly happens during endgames of course. But some of them are not so simple. I.E. 8-12 pieces on the board. It also seems that if the position has degenerated to a mate search, which often happens in endgames, it needs a lot of depth (unusually large) in some cases.

I'm currently working on one that is KRBPPPPkbnp. This is from an old GM game where white had pre-paired a sac line in the Sicilian. The program doesn't even start to find the proper line of play until 50-60 plies.

I have noticed that if I stop the search and then immediately restart it, sometimes it will pick-up its previous analysis and score at a much shallower ply. e.g. stopped the search at ply 65 and on restart the same score and line is picked up at ply 42. By the time it got back to ply 65 again it had found a mating line.

I noticed SF will re-search the ply if it fails high or low. Under some conditions it might be prudent to back up a ply instead of just researching the current ply over and over again. I've seen it do this over 20 times on a single ply and do this for multiplies in a single search. The problem is that if it starts this at a deep ply it takes for-ever to research the same ply 20 times in a row. I have found that this is massively sped up by stopping and starting multiple times. This get you to the same score / line of play at a much lower ply where the repeated re-searches of the ply proceeds much faster.

Regards,

Forrest

Regards.

[Uri Blass]

I think it is even simpler. NO chess program has any business searching out to 120 plies and deeper. There is so much error in the search when it is tuned to reach those depths, that such scores that get backed up will never actually be seen anyway.

In general, these limits are set to avoid segfaults that result from a subscript going out of bounds. There is a famous position that causes the default Fruit 2.1 to completely blow up on a simple 7 ply search, because it extends out beyond 200 plies. And wastes a ton of time searching stuff that is completely imaginary.

I'm not so sure that's true. I've had SF change a move on ply 112 on two different occasions and have had it run to 120 plies so many times that I can't count that high. This mostly happens during endgames of course. But some of them are not so simple. I.E. 8-12 pieces on the board. It also seems that if the position has degenerated to a mate search, which often happens in endgames, it needs a lot of depth (unusually large) in some cases.

I'm currently working on one that is KRBPPPPkbnp. This is from an old GM game where white had pre-paired a sac line in the Sicilian. The program doesn't even start to find the proper line of play until 50-60 plies.

I have noticed that if I stop the search and then immediately restart it, sometimes it will pick-up its previous analysis and score at a much shallower ply. e.g. stopped the search at ply 65 and on restart the same score and line is picked up at ply 42. By the time it got back to ply 65 again it had found a mating line.

I noticed SF will re-search the ply if it fails high or low. Under some conditions it might be prudent to back up a ply instead of just researching the current ply over and over again. I've seen it do this over 20 times on a single ply and do this for multiplies in a single search. The problem is that if it starts this at a deep ply it takes for-ever to research the same ply 20 times in a row. I have found that this is massively sped up by stopping and starting multiple times. This get you to the same score / line of play at a much lower ply where the repeated re-searches of the ply proceeds much faster.

Regards,

Forrest

Regards.

Note that stockfish does a lot of pruning so there is a difference between iteration 120 and ply 120.(stockfish limit both of them by the same constant
const int MAX_PLY = 120;)

121 is practically the maximal ply because stockfish stop the search
if the ply is bigger than MAX_PLY so only after it get 121 plies

I agree that the number 120 is not enough for every position

I know that there are cases when 120 iterations are not enough to solve some studies(and probably there are also few positions from games when 120 iterations are not enough)

I also believe that there are positions when searching 121 plies forward is not enough to find the best move and you need more than it because there is a long line with checks and singular extensions that is more than 121 plies that you need to find it in order to find the right move when stockfish may find the relevant line at iteration 70 if you do not limit the plies that the search can go forward to 121 plies.

I do not think that these positions happen often enough to have a significant effect on playing strength(at least not at tournament time control) and probably the effect of increasing max ply is going to be less than 0.1 elo today(assuming time control of 3 minutes per move) but
I also believe that positions when stockfish needs more than 121 plies clearly happen(at least in analysis of positions when people give stockfish many hours to search)

Note that the first position in this thread is clearly mate in less than 50 moves(remember somebody gave houdini's analysis with 6 piece nalimov tablebases when the analysis show mate in clearly less than 50 moves) so I do not think that stockfish need to search more than 121 plies forward.

[Zenmastur]

I think it is even simpler. snip.. snip..

I'm not so sure that's true. snip .. snip

Regards,

Forrest

Regards.

Note that stockfish does a lot of pruning so there is a difference between iteration 120 and ply 120.(stockfish limit both of them by the same constant
const int MAX_PLY = 120;)

121 is practically the maximal ply because stockfish stop the search
if the ply is bigger than MAX_PLY so only after it get 121 plies....

On an older version of SF I have seen it get to 121 I think, but on the newer versions (9-04) I've never seen more than 120. I'm not sure I understand the difference between a ply and an iteration so I can't comment on that portion of it.

I will comment on its mate finding abilities. In a previous 2014 version it sucked rocks... It wouldn't reliably find a mate in 9-15 in some cases even with a large amount of time. The newer versions is an order of magnitude better in this regard. So, my complements to the Chef.

I agree that the number 120 is not enough for every position

I know that there are cases when 120 iterations are not enough to solve some studies(and probably there are also few positions from games when 120 iterations are not enough)

I also believe that there are positions when searching 121 plies forward is not enough to find the best move and you need more than it because there is a long line with checks and singular extensions that is more than 121 plies that you need to find it in order to find the right move when stockfish may find the relevant line at iteration 70 if you do not limit the plies that the search can go forward to 121 plies.

I do not think that these positions happen often enough to have a significant effect on playing strength(at least not at tournament time control) and probably the effect of increasing max ply is going to be less than 0.1 elo today(assuming time control of 3 minutes per move) but
I also believe that positions when stockfish needs more than 121 plies clearly happen(at least in analysis of positions when people give stockfish many hours to search)

Note that the first position in this thread is clearly mate in less than 50 moves(remember somebody gave houdini's analysis with 6 piece nalimov tablebases when the analysis show mate in clearly less than 50 moves) so I do not think that stockfish need to search more than 121 plies forward.

I agree to the above for the most part. I will note that at least on one occasion I had it go to max ply in a "relatively" short period of time and it wasn't the result of it finding a short mate. If fact it failed to find a mate that was there. I saved this analysis in the game I was analyzing. I then analyzed the line it gave and quickly found a long mate (something like 47 moves) that was, after a lot more analysis and me fiddling with the analysis, reduced to a mate in 19. I also saved this analysis in the game. Unfortunately, I didn't save the version of the game with the analysis to disk before going to bed. When I got up, the system had restarted to install some patches. Since then I always save the file before going to bed or leaving the computer for an extended period of time and I changed auto update so it won't reboot my system without my consent. I had intended to bring this up in the forums before I lost the analysis. So, be advised that there are some positions that can reach max-ply with out extreme time usage and without finding a mate.

Regards,

Forrest

P.S. I'm still trying to recreate the analysis in that game. If I get back to that same point and it does the same thing, I will save the game and analysis and post it to this forum.

[Uri Blass]

The difference between ply and iteration.

ply is the number of half plies that stockfish practically searches
when iteration is the depth that you see that it get.


for example

info depth 85 seldepth 121 mean
iteration 85 and searching 121 plies forward in the longest line.


Note that stockfish can practically search more than seldepth plies(assuming it is not more than 121 plies) but never less than seldepth plies and stockfish does not show the maximal number of plies that it search in non pv lines.

I think that the output is misleading and if the stockfish team does not want to make stockfish slightly slower by showing correct output of seldepth then it is better if it does not show seldepth in the output.

[Joerg Oster]

The difference between ply and iteration.

ply is the number of half plies that stockfish practically searches
when iteration is the depth that you see that it get.


for example

info depth 85 seldepth 121 mean
iteration 85 and searching 121 plies forward in the longest line.


Note that stockfish can practically search more than seldepth plies(assuming it is not more than 121 plies) but never less than seldepth plies and stockfish does not show the maximal number of plies that it search in non pv lines.

I think that the output is misleading and if the stockfish team does not want to make stockfish slightly slower by showing correct output of seldepth then it is better if it does not show seldepth in the output.

Still it might offer some valuable information if, for example, you change something in the singular extension stuff ...