maximal ply that programs need today

[Uri Blass]

I wonder what is the maximal ply that chess programs need today.

It is possible to test it by having different versions of the same program with different MAX_PLY that limits the program maximal selective search and to see at what point the program stops to earn elo.

Of course I expect the maximal ply to be dependent on the time control and on the program.

[lucasart]

I wonder what is the maximal ply that chess programs need today.

It is possible to test it by having different versions of the same program with different MAX_PLY that limits the program maximal selective search and to see at what point the program stops to earn elo.

Of course I expect the maximal ply to be dependent on the time control and on the program.

I have a much easier method:
* allocate memory to a fixed MAX_PLY
* treat overflow as a fatal error, instead of guarding against it in the search. Or remove the overflow guard and let the program segfault, or corrupt its own memory and eventually crash...

No need to measure, just to see if the program crashes or not.

[jdart]

Maximal ply means different things to different programs. Those that aggressively prune can reach impressive depths, but they are only visiting part of the search tree, sacrificing width for depth.

Re how much is enough: in some endgames there is a reachable limit but in the opening and middlegame more depth is always better. Chess is very complex and there is always a chance that one more iteration will reveal a new best line. I think there was some research indicating that this chance does not diminish with increasing depth.

--Jon

[Uri Blass]

Maximal ply means different things to different programs. Those that aggressively prune can reach impressive depths, but they are only visiting part of the search tree, sacrificing width for depth.

Re how much is enough: in some endgames there is a reachable limit but in the opening and middlegame more depth is always better. Chess is very complex and there is always a chance that one more iteration will reveal a new best line. I think there was some research indicating that this chance does not diminish with increasing depth.

--Jon

Of course one more iteration may reveal something new.
The question is what is the practical limit that is productive for elo strength that may be different than the limit that the program extends.

The program may get at least 50 plies in half of the blitz games when practically the few lines that it searchs at least 50 plies forward do not give it more than 1 elo.

Note that I talk about plies and not about iterations and of course searching another iteration is always productive.

[jdart]

If you are winning 100% of your games already you can't gain any more ELO with deeper search.

But if you are not, and want to beat searchers with nearly the same speed you have, then more plies will continue to gain you ELO. There is no limit, with current hardware, where it won't. At least I don't think so.

--Jon

[Uri Blass]

If you are winning 100% of your games already you can't gain any more ELO with deeper search.

But if you are not, and want to beat searchers with nearly the same speed you have, then more plies will continue to gain you ELO. There is no limit, with current hardware, where it won't. At least I don't think so.

--Jon

I do not talk about limiting the number of iterations but about limiting the number of plies that the program search forward.

The program may practically search in few lines more than 50 plies forward in 5 minutes for all the game but limiting it to 50 plies does not change much and the difference is less than 1 elo because in most of the cases the few nodes that the program searchs with lines of more than 50 plies do not change the choice of the move..

[bob]

If you are winning 100% of your games already you can't gain any more ELO with deeper search.

But if you are not, and want to beat searchers with nearly the same speed you have, then more plies will continue to gain you ELO. There is no limit, with current hardware, where it won't. At least I don't think so.

--Jon

I do not talk about limiting the number of iterations but about limiting the number of plies that the program search forward.

The program may practically search in few lines more than 50 plies forward in 5 minutes for all the game but limiting it to 50 plies does not change much and the difference is less than 1 elo because in most of the cases the few nodes that the program searchs with lines of more than 50 plies do not change the choice of the move..

I personally believe that anything beyond 64 or so is wasted. The Fruit bug I fixed last year for example, were on a 7 ply search, it was blowing past 200 plies of depth because of a bizarre position with checks every other ply, and only one move to get out, triggering a 1-ply extension every ply until it exploded. That is beyond pointless...

[jdart]

Some programs limit extensions although usually not with a hard ply limit. This prevents going very deep into lines with a lot of checks for example. This is just another example of trading off depth and width.

But since any node in the tree can have its value and path backed up to the root, every time you fail to search a node, due to ply limitations or anything else, you are missing a chance to find the best move.

--Jon

[Uri Blass]

Some programs limit extensions although usually not with a hard ply limit. This prevents going very deep into lines with a lot of checks for example. This is just another example of trading off depth and width.

But since any node in the tree can have its value and path backed up to the root, every time you fail to search a node, due to ply limitations or anything else, you are missing a chance to find the best move.

--Jon

Movei limit extensions with hard ply limit to 100 plies.

It is easy to change it for example by adding
max_search_ply 5 to the changes file.

In that case movei can show stupid lines.
For example search of 5 plies from the opening position finds that white can win a pawn by the line
1.e4 e6 2.Qg4 Qf6 3.Qxe6+

Of course search plies of 5 plies is not enough for playing well and I think that it may be interesting to have a rating list of the same program with different ply limits to see how much the program earns from increasing the maximal ply.

It is also possible to do it with stockfish if you change the code and it may be interesting to see what is the maximal ply that is needed in games.

Lucas's idea can give some bound(find that the program never search in blitz more than 80 plies in games) but the practical limit can be smaller because it is possible that the few lines that the program search for more than 70 plies practically do not change the move choice.