Using length of PV to estimate search depth

[matthewlai]

Just something I thought may be of interest.

I found that length of the PV is a better measure of how deep an engine is searching than the reported depth.

It tells you exactly how deep it went on the PV branch, after extensions, reductions, etc.

Of course it's not perfect, and it's impossible to be perfect because it's impossible to describe the shape of a search tree by a single number.

But I found it to be better for my purposes.

This can be affected by q-search, but most PV lines do not end in capture, simply because most PV positions don't have winning captures.

It can also be affected if the engine's PV reporting can be cut short by HT hit (old Stockfish, etc).

[Daniel Shawul]

Often the pv line is the least reduced/pruned so you will be overestimating the average search depth.

[matthewlai]

Often the pv line is the least reduced/pruned so you will be overestimating the average search depth.

Yes, definitely.

However, for positional stuff (which is what I am working on), I believe depth of the PV is more useful than "average depth", because the search score is propagated up from that leaf.

For tactical stuff it's probably different.

[bob]

Just something I thought may be of interest.

I found that length of the PV is a better measure of how deep an engine is searching than the reported depth.

It tells you exactly how deep it went on the PV branch, after extensions, reductions, etc.

Of course it's not perfect, and it's impossible to be perfect because it's impossible to describe the shape of a search tree by a single number.

But I found it to be better for my purposes.

This can be affected by q-search, but most PV lines do not end in capture, simply because most PV positions don't have winning captures.

It can also be affected if the engine's PV reporting can be cut short by HT hit (old Stockfish, etc).

Only problem is it tells you exactly how deep the search went on THAT path only, not all the side-paths on the PV or other moves. And if you hash the PV path as I do to avoid any short PVs, it is REALLY misleading on the depth reached.

[bob]

Often the pv line is the least reduced/pruned so you will be overestimating the average search depth.

Yes, definitely.

However, for positional stuff (which is what I am working on), I believe depth of the PV is more useful than "average depth", because the search score is propagated up from that leaf.

For tactical stuff it's probably different.

The currently used depth value is not a "average depth" don't forget. It is a "nominal depth for this iteration". Average depth can be greater or less than the iteration depth depending on the position.

[matthewlai]

Just something I thought may be of interest.

I found that length of the PV is a better measure of how deep an engine is searching than the reported depth.

It tells you exactly how deep it went on the PV branch, after extensions, reductions, etc.

Of course it's not perfect, and it's impossible to be perfect because it's impossible to describe the shape of a search tree by a single number.

But I found it to be better for my purposes.

This can be affected by q-search, but most PV lines do not end in capture, simply because most PV positions don't have winning captures.

It can also be affected if the engine's PV reporting can be cut short by HT hit (old Stockfish, etc).

Only problem is it tells you exactly how deep the search went on THAT path only, not all the side-paths on the PV or other moves. And if you hash the PV path as I do to avoid any short PVs, it is REALLY misleading on the depth reached.

Yes, those are the things I said in my post .

[sje]

PV analysis depth with tablebase assistance in a one-second search:
[d]8/2Q4K/8/1q6/8/3P4/8/7k w - - 0 1[/d]

Code: Select all

[] sf 8/2Q4K/8/1q6/8/3P4/8/7k w - - 0 1
[] s 1
[MateIn124/247/0.606/28] 1. Qc3 Qg5 2. Kh8 Qe7 3. Kg8 Qe8+ 4. Kg7 Qe7+ 5. Kg6 Qe6+ 6. Kg5 Qe3+ 7. Kf5 Kg2 8. Qc4 Qf3+ 9. Kg6 Qg3+ 10. Kf7 Qf2+ 11. Ke7 Qa7+ 12. Ke6 Qb6+ 13. Kf5 Qf2+ 14. Qf4 Qc5+ 15. Qe5 Qf8+ 16. Qf6 Qc5+ 17. Ke4 Qc2 18. Qd4 Kf1 19. Kd5 Qa2+ 20. Kd6 Qg8 21. Kc7 Qf7+ 22. Qd7 Qf4+ 23. Qd6 Qf7+ 24. Kc6 Qf3+ 25. Qd5 Qf6+ 26. Kd7 Qg7+ 27. Ke8 Qh8+ 28. Ke7 Qh4+ 29. Kd7 Qa4+ 30. Kd6 Qf4+ 31. Qe5 Qf8+ 32. Kc7 Qf7+ 33. Kc6 Qf3+ 34. Qe4 Qf8 35. Kb7 Qf7+ 36. Ka6 Qa2+ 37. Kb5 Qb2+ 38. Kc4 Qa2+ 39. Kd4 Qb2+ 40. Kd5 Qb5+ 41. Kd6 Qb8+ 42. Ke7 Qc7+ 43. Ke6 Qc8+ 44. Kf7 Qc7+ 45. Kg6 Qg3+ 46. Kf6 Qd6+ 47. Kf5 Qf8+ 48. Kg4 Qg7+ 49. Kf3 Qf6+ 50. Qf4 Qc3 51. Ke4+ Ke2 52. Qe3+ Kd1 53. d4 Qc6+ 54. Kf5 Qd7+ 55. Kg6 Qd6+ 56. Kh5 Qd5+ 57. Qe5 Qf3+ 58. Kg5 Qg2+ 59. Kf6 Qa8 60. Qc5 Qd8+ 61. Kf5 Qd7+ 62. Kf4 Qf7+ 63. Qf5 Qc4 64. Qe4 Qc7+ 65. Kf3 Qc3+ 66. Kg2 Qb2+ 67. Kg1 Qb6 68. Qd3+ Ke1 69. Qe3+ Kd1 70. Kf2 Qa7 71. Qd3+ Kc1 72. Ke3 Qe7+ 73. Qe4 Qg5+ 74. Kf2 Qf6+ 75. Ke2 Qa6+ 76. Kf3 Qf1+ 77. Kg4 Qc4 78. Kf4 Qf7+ 79. Qf5 Qg7 80. d5 Qd4+ 81. Kg5 Qg7+ 82. Kh4 Qc7 83. Kg4 Kd1 84. Qd3+ Kc1 85. Qd4 Qc8+ 86. Kf4 Qf8+ 87. Ke4 Qa8 88. Kd3 Qa3+ 89. Qc3+ Kb1 90. Kd4 Qa4+ 91. Ke3 Qd7 92. Qc6 Qa7+ 93. Kd3 Qa3+ 94. Kc4 Qa2+ 95. Kb5 Qb2+ 96. Ka5 Qa3+ 97. Kb6 Qe3+ 98. Qc5 Qb3+ 99. Kc7 Ka1 100. Qd4+ Ka2 101. d6 Qg3 102. Kb6 Qb3+ 103. Ka5 Qg8 104. Qa4+ Kb1 105. Qb5+ Kc1 106. d7 Qd8+ 107. Ka6 Qa8+ 108. Kb6 Qb8+ 109. Kc6 Qa8+ 110. Kc7 Qa7+ 111. Qb7 Qa5+ 112. Qb6 Qe5+ 113. Kb7 Qe7 114. Qc7+ Kb1 115. d8=Q Qe4+ 116. Qc6 Qb4+ 117. Ka6 Qa3+ 118. Qa5 Kb2 119. Qb5+ Ka2 120. Qxa3+ Kxa3 121. Ka5 Ka2 122. Ka4 Ka1 123. Kb3 Kb1 124. Qf1#

[matthewlai]

PV analysis depth with tablebase assistance in a one-second search:
[d]8/2Q4K/8/1q6/8/3P4/8/7k w - - 0 1[/d]

Code: Select all

[] sf 8/2Q4K/8/1q6/8/3P4/8/7k w - - 0 1
[] s 1
[MateIn124/247/0.606/28] 1. Qc3 Qg5 2. Kh8 Qe7 3. Kg8 Qe8+ 4. Kg7 Qe7+ 5. Kg6 Qe6+ 6. Kg5 Qe3+ 7. Kf5 Kg2 8. Qc4 Qf3+ 9. Kg6 Qg3+ 10. Kf7 Qf2+ 11. Ke7 Qa7+ 12. Ke6 Qb6+ 13. Kf5 Qf2+ 14. Qf4 Qc5+ 15. Qe5 Qf8+ 16. Qf6 Qc5+ 17. Ke4 Qc2 18. Qd4 Kf1 19. Kd5 Qa2+ 20. Kd6 Qg8 21. Kc7 Qf7+ 22. Qd7 Qf4+ 23. Qd6 Qf7+ 24. Kc6 Qf3+ 25. Qd5 Qf6+ 26. Kd7 Qg7+ 27. Ke8 Qh8+ 28. Ke7 Qh4+ 29. Kd7 Qa4+ 30. Kd6 Qf4+ 31. Qe5 Qf8+ 32. Kc7 Qf7+ 33. Kc6 Qf3+ 34. Qe4 Qf8 35. Kb7 Qf7+ 36. Ka6 Qa2+ 37. Kb5 Qb2+ 38. Kc4 Qa2+ 39. Kd4 Qb2+ 40. Kd5 Qb5+ 41. Kd6 Qb8+ 42. Ke7 Qc7+ 43. Ke6 Qc8+ 44. Kf7 Qc7+ 45. Kg6 Qg3+ 46. Kf6 Qd6+ 47. Kf5 Qf8+ 48. Kg4 Qg7+ 49. Kf3 Qf6+ 50. Qf4 Qc3 51. Ke4+ Ke2 52. Qe3+ Kd1 53. d4 Qc6+ 54. Kf5 Qd7+ 55. Kg6 Qd6+ 56. Kh5 Qd5+ 57. Qe5 Qf3+ 58. Kg5 Qg2+ 59. Kf6 Qa8 60. Qc5 Qd8+ 61. Kf5 Qd7+ 62. Kf4 Qf7+ 63. Qf5 Qc4 64. Qe4 Qc7+ 65. Kf3 Qc3+ 66. Kg2 Qb2+ 67. Kg1 Qb6 68. Qd3+ Ke1 69. Qe3+ Kd1 70. Kf2 Qa7 71. Qd3+ Kc1 72. Ke3 Qe7+ 73. Qe4 Qg5+ 74. Kf2 Qf6+ 75. Ke2 Qa6+ 76. Kf3 Qf1+ 77. Kg4 Qc4 78. Kf4 Qf7+ 79. Qf5 Qg7 80. d5 Qd4+ 81. Kg5 Qg7+ 82. Kh4 Qc7 83. Kg4 Kd1 84. Qd3+ Kc1 85. Qd4 Qc8+ 86. Kf4 Qf8+ 87. Ke4 Qa8 88. Kd3 Qa3+ 89. Qc3+ Kb1 90. Kd4 Qa4+ 91. Ke3 Qd7 92. Qc6 Qa7+ 93. Kd3 Qa3+ 94. Kc4 Qa2+ 95. Kb5 Qb2+ 96. Ka5 Qa3+ 97. Kb6 Qe3+ 98. Qc5 Qb3+ 99. Kc7 Ka1 100. Qd4+ Ka2 101. d6 Qg3 102. Kb6 Qb3+ 103. Ka5 Qg8 104. Qa4+ Kb1 105. Qb5+ Kc1 106. d7 Qd8+ 107. Ka6 Qa8+ 108. Kb6 Qb8+ 109. Kc6 Qa8+ 110. Kc7 Qa7+ 111. Qb7 Qa5+ 112. Qb6 Qe5+ 113. Kb7 Qe7 114. Qc7+ Kb1 115. d8=Q Qe4+ 116. Qc6 Qb4+ 117. Ka6 Qa3+ 118. Qa5 Kb2 119. Qb5+ Ka2 120. Qxa3+ Kxa3 121. Ka5 Ka2 122. Ka4 Ka1 123. Kb3 Kb1 124. Qf1#

In that case, using the length of the PV is valid. That's how far ahead the engine looked to arrive at the conclusion. The fact that it didn't actually do all the work doesn't matter.

[bob]

Just something I thought may be of interest.

I found that length of the PV is a better measure of how deep an engine is searching than the reported depth.

It tells you exactly how deep it went on the PV branch, after extensions, reductions, etc.

Of course it's not perfect, and it's impossible to be perfect because it's impossible to describe the shape of a search tree by a single number.

But I found it to be better for my purposes.

This can be affected by q-search, but most PV lines do not end in capture, simply because most PV positions don't have winning captures.

It can also be affected if the engine's PV reporting can be cut short by HT hit (old Stockfish, etc).

Only problem is it tells you exactly how deep the search went on THAT path only, not all the side-paths on the PV or other moves. And if you hash the PV path as I do to avoid any short PVs, it is REALLY misleading on the depth reached.

Yes, those are the things I said in my post .

I interpreted "branch" to be whatever move is best, followed by the "branch" below it, which itself has many sub-branches. If you meant "path" then we are in total agreement...

[matthewlai]

Just something I thought may be of interest.

I found that length of the PV is a better measure of how deep an engine is searching than the reported depth.

It tells you exactly how deep it went on the PV branch, after extensions, reductions, etc.

Of course it's not perfect, and it's impossible to be perfect because it's impossible to describe the shape of a search tree by a single number.

But I found it to be better for my purposes.

This can be affected by q-search, but most PV lines do not end in capture, simply because most PV positions don't have winning captures.

It can also be affected if the engine's PV reporting can be cut short by HT hit (old Stockfish, etc).

Only problem is it tells you exactly how deep the search went on THAT path only, not all the side-paths on the PV or other moves. And if you hash the PV path as I do to avoid any short PVs, it is REALLY misleading on the depth reached.

Yes, those are the things I said in my post .

I interpreted "branch" to be whatever move is best, followed by the "branch" below it, which itself has many sub-branches. If you meant "path" then we are in total agreement...

Yeah I use them interchangeably... I probably shouldn't.