Odd crafty problem

Discussion of chess software programming and technical issues.

Moderator: Ras

Uri Blass
Posts: 10895
Joined: Thu Mar 09, 2006 12:37 am
Location: Tel-Aviv Israel

Re: Odd crafty problem

Post by Uri Blass »

hgm wrote:This behavior is a consequence of the desire to search every branch to the same effective depth (equating the "effective depth" of a null move to R+1 ply). From a chessic perspective this is a non-sensical desire: after having concluded that promotion is unavoidable, and takes 35 moves against best defense, it is not satisfied (and thus will not give the 35-ply score) before it has searched all other branches to that depth as well. Also those branches that, against very stupid defense, already promoted after 15 ply. Before those braches were null-move pruned to almost nothing, because there was no need to move the Queen: it could just be sitting there on the promotion square while you null-moved, until you finally received its big fat score in the material evaluation of the much-reduced end leaf, which would make these null-moves fail high.

But when merely having a Queen is no longer guarantee for fail high, because the PV now has a Queen too, the Queen has suddenly to take offensive action in those sub-trees, exploding them completely. It will be making an attempt to figure out how much damage that Queen can do in the remaining 20 ply, of which it had no idea before. (So this is a completely uninformed search.)

Humans don't think that way; they think more in a DTC metric. First you try to delay the Queening as much as possible. When you finally proved that Queening is unavoidable, you start analyzing the next phase of the game, where you start counting the depth from the point where you promoted. Allowing an early promotion might be a much beter defense; before you discovered that promotion was unavoidable the tree will contain many horizon moves sacrificing material or position just to delay promotion. So it makes sense to compare early promotions to delayed promotions, with the same number of ply after the promotion. If you don't, the late promotion is likely to (unjustly) look better for many more plies, because there is less depth to see the sme (or worse) disasters. Basically you are just cultivating the horizon effect. To make a sensible choice between the promotion positions, you need to compare their search scores at the same remaining depth.

This is not impossible to implement in an engine: one could propagate the "depth after resolution", defined as depth searched past the point where the static eval approximated the search score, back towards the root with the PV score. In a sense it would be a tag to the window limit, and should also be propagated upward through the tree, together with this window limit. As long as the static eval is very far from the window limit, depth for daughter nodes would be decreased as usual. But as soon as the static eval reaches the window limit again (e.g. because you are in a branch that promoted early), so that this new branch could become PV, the remaining depth should be reduced to the depth of resolution of the window limit we are comparing it against.

Another, more general method, which also ameliorates problems like this, is node-balancing: use fractional ply, and could each ply made from a given position for log(nr_of_moves). This would count plies after promotion more heavily than plies before promotion, reducing the search work in the early-promotion branches somewhat. This method would also help in the opposite situation, where you trade your last piece. The plies in the resulting Pawn ending would be counted for much less, increasing the true search depth there.
The problem that you describe does not happen with top programs because they do not search for an exact score in order to get a fail high.

Branches that, against very stupid defense, already promoted after 15 ply are pruned to almost nothing when the score is not winning score and the score can be winning score only after fail high that means after finding the best move.

The program may be slow in finding an exact score for the best move but finding the best move should not be a problem.

I guess that the main problem is simply that the program needs to search many lines to fail high and not the problem of searching positions with big advantage.

Uri
User avatar
hgm
Posts: 28390
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Odd crafty problem

Post by hgm »

I think it will happen, but not on a fail high, but on a fail low. Say the root static eval is +1. At some point even the PV gets the promotion within its horizon, and the score drops from -1 to -9. (On the previous iteration you had been sacrificing two Pawns to push the promotion over the horizon, which explains the drop from +1 to -1.) All the other lines, including those with stupid defense, where only refuted so far to the level -7. After the promotion the opponent stopped working, and was just null moving, because -7 was enough to make us fail low.

But now that our old best move is -9, that is enough, and none of the old upper-bouds are any good. The opponent now has to prove that he can hold us below -9. And that might require Queen action in branches where we did not sac any material to delay the promotion, but on the contrary hastened the promotion by going for the opponent's Pawns and letting the passer run. In those branches he will have to first gobble up 3 or 4 Pawns before he can make them fail low for us in the root again. And perhaps he cannot do it at all within the horizon, and one of those other moves will actually be the best.

So we have no idea what the best move is.
Uri Blass
Posts: 10895
Joined: Thu Mar 09, 2006 12:37 am
Location: Tel-Aviv Israel

Re: Odd crafty problem

Post by Uri Blass »

I can see that rybka in case of fail low does not try to solve the fail low and try to find a better move than the bound.

Only if Rybka does not find a better move it searches the root move again with a bigger window so rybka can find an exact score or a better bound.

Practically rybka does not print bounds of fail low in the pv so you can see in the analysis something like the following.

depth 19 Re1 0.00
depth 20 Rd1 -0.40

The reason is that Re1 fail low at depth 20 and rybka already found that the score is lower than -0.50 so she did not care to get an exact score for Re1 at depth 20 and searched the rest of the moves and found an exact score for Rd1 that is better than -0.50.

Uri
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Odd crafty problem

Post by bob »

Uri Blass wrote:
hgm wrote:This behavior is a consequence of the desire to search every branch to the same effective depth (equating the "effective depth" of a null move to R+1 ply). From a chessic perspective this is a non-sensical desire: after having concluded that promotion is unavoidable, and takes 35 moves against best defense, it is not satisfied (and thus will not give the 35-ply score) before it has searched all other branches to that depth as well. Also those branches that, against very stupid defense, already promoted after 15 ply. Before those braches were null-move pruned to almost nothing, because there was no need to move the Queen: it could just be sitting there on the promotion square while you null-moved, until you finally received its big fat score in the material evaluation of the much-reduced end leaf, which would make these null-moves fail high.

But when merely having a Queen is no longer guarantee for fail high, because the PV now has a Queen too, the Queen has suddenly to take offensive action in those sub-trees, exploding them completely. It will be making an attempt to figure out how much damage that Queen can do in the remaining 20 ply, of which it had no idea before. (So this is a completely uninformed search.)

Humans don't think that way; they think more in a DTC metric. First you try to delay the Queening as much as possible. When you finally proved that Queening is unavoidable, you start analyzing the next phase of the game, where you start counting the depth from the point where you promoted. Allowing an early promotion might be a much beter defense; before you discovered that promotion was unavoidable the tree will contain many horizon moves sacrificing material or position just to delay promotion. So it makes sense to compare early promotions to delayed promotions, with the same number of ply after the promotion. If you don't, the late promotion is likely to (unjustly) look better for many more plies, because there is less depth to see the sme (or worse) disasters. Basically you are just cultivating the horizon effect. To make a sensible choice between the promotion positions, you need to compare their search scores at the same remaining depth.

This is not impossible to implement in an engine: one could propagate the "depth after resolution", defined as depth searched past the point where the static eval approximated the search score, back towards the root with the PV score. In a sense it would be a tag to the window limit, and should also be propagated upward through the tree, together with this window limit. As long as the static eval is very far from the window limit, depth for daughter nodes would be decreased as usual. But as soon as the static eval reaches the window limit again (e.g. because you are in a branch that promoted early), so that this new branch could become PV, the remaining depth should be reduced to the depth of resolution of the window limit we are comparing it against.

Another, more general method, which also ameliorates problems like this, is node-balancing: use fractional ply, and could each ply made from a given position for log(nr_of_moves). This would count plies after promotion more heavily than plies before promotion, reducing the search work in the early-promotion branches somewhat. This method would also help in the opposite situation, where you trade your last piece. The plies in the resulting Pawn ending would be counted for much less, increasing the true search depth there.
The problem that you describe does not happen with top programs because they do not search for an exact score in order to get a fail high.

Branches that, against very stupid defense, already promoted after 15 ply are pruned to almost nothing when the score is not winning score and the score can be winning score only after fail high that means after finding the best move.

The program may be slow in finding an exact score for the best move but finding the best move should not be a problem.

I guess that the main problem is simply that the program needs to search many lines to fail high and not the problem of searching positions with big advantage.

Uri
You don't necessarily have to search for an "exact score". A fail-high is good enough, if it happens in a critical place, because suddenly things that were failing high or low most of the time, suddenly do not because we have now proven that we can force a queen, as an example.

There's a huge difference between a zero-window search to 35 plies where promotions instantly fail high, and a non-zero-window search to that same depth where beta is now higher, regardless of how much higher. Zero-window means a fail high or a fail low every time. Once you have to relax beta, regardless of how little you increase it, that's sometimes enough to blow the tree up badly.
User avatar
hgm
Posts: 28390
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Odd crafty problem

Post by hgm »

Uri Blass wrote:I can see that rybka in case of fail low does not try to solve the fail low and try to find a better move than the bound.
I think that is usual. But to stick to the hypothetical case I sketched above: if the score on the previous iteration was -1, and the window {-2,0}, and the PV move now fails low because of the promotion, seaching the other moves first with the same window will not help much. As they all resulted in even earlier promotions, their true scores would be something like -8, and searching one ply extra when a Queen behind is not likely to improve that. So they will all fail low.

You then get into a situation where all moves failed low, and you have no idea whatsoever what the best move is. You must re-search with an opened window to get a move. Re-searching any move will now take disastrously long. Even the PV move, as it will also contain many side branches that led to an early Queen, some of which are likely to be better than the old PV, and fail high on the first zero-window you set.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Odd crafty problem

Post by bob »

Uri Blass wrote:I can see that rybka in case of fail low does not try to solve the fail low and try to find a better move than the bound.

Only if Rybka does not find a better move it searches the root move again with a bigger window so rybka can find an exact score or a better bound.

Practically rybka does not print bounds of fail low in the pv so you can see in the analysis something like the following.

depth 19 Re1 0.00
depth 20 Rd1 -0.40

The reason is that Re1 fail low at depth 20 and rybka already found that the score is lower than -0.50 so she did not care to get an exact score for Re1 at depth 20 and searched the rest of the moves and found an exact score for Rd1 that is better than -0.50.

Uri
Not resolving a fail-low is one of many choices. It may or may not be the best, but there are other ideas. Once you fail low, you can just completely restart the search from iteration 1. The hash table will make the old best move fail low, and you find a new best move quicker. Of course, if it fails low at the same depth, you do this again, and again, and after investing a bunch of time, you still have no best move to play. I tested the "Rybka approach" years ago, and didn't like it. First, when you fail low, you don't know how bad you failed low, so it is difficult to make any time-related decisions about using extra time. Second, if you search all the way thru the ply-1 move list, you may well have burned up all your search time, and you are still stuck playing a move that is bad, without knowing if it is the "best bad move" or what.

I like the idea of resolving a fail-low or fail-high on the spot. You already have lots of good hash information that will disappear if you search other moves first and then have to come back to this move.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Odd crafty problem (more)

Post by bob »

I ran this here. Here's the results, first.

Code: Select all

               27->  17.39  -0.03   1. ... Bb6 2. Bh8 Ke4 3. Bf6 Be3 4.   
                                    Bh8 Ba7 5. Bc3 Bg1 6. Bg7 Bc5 7. Bf6
                                    Bd6 8. Bg7 Be7 9. Be5 Bd8 10. Bg7 Ba5
                                    11. Bc3 Bxc3 12. bxc3 Kd5 13. Kf2 Kc5
                                    14. Ke3 Kd5 (s=5)
               28    20.44  -0.01   1. ... Bb6 2. Bh8 Ke4 3. Bf6 Be3 4.   
                                    Bh8 Ba7 5. Bc3 Bg1 6. Bg7 Bc5 7. Bf6
                                    Bd6 8. Bg7 Be7 9. Be5 Bd8 10. Bg7 Ba5
                                    11. Bc3 Bxc3 12. bxc3 Kd5 13. Ke3 Kc5
                                    14. Ke2 Kd5 (s=4)
               28->  20.90  -0.01   1. ... Bb6 2. Bh8 Ke4 3. Bf6 Be3 4.   
                                    Bh8 Ba7 5. Bc3 Bg1 6. Bg7 Bc5 7. Bf6
                                    Bd6 8. Bg7 Be7 9. Be5 Bd8 10. Bg7 Ba5
                                    11. Bc3 Bxc3 12. bxc3 Kd5 13. Ke3 Kc5
                                    14. Ke2 Kd5
               29    25.78  -0.01   1. ... Bb6 2. Bh8 Ke4 3. Bf6 Be3 4.   
                                    Bh8 Ba7 5. Bc3 Bg1 6. Bg7 Bc5 7. Bf6
                                    Bd6 8. Bg7 Be7 9. Be5 Bd8 10. Bg7 Ba5
                                    11. Bc3 Bxc3 12. bxc3 Kd5 13. Ke3 Kc5
                                    14. Ke2 Kd5
               29->  26.08  -0.01   1. ... Bb6 2. Bh8 Ke4 3. Bf6 Be3 4.   
                                    Bh8 Ba7 5. Bc3 Bg1 6. Bg7 Bc5 7. Bf6
                                    Bd6 8. Bg7 Be7 9. Be5 Bd8 10. Bg7 Ba5
                                    11. Bc3 Bxc3 12. bxc3 Kd5 13. Ke3 Kc5
                                    14. Ke2 Kd5
               30    33.57  -0.01   1. ... Bb6 2. Bh8 Ke4 3. Bf6 Be3 4.   
                                    Bh8 Ba7 5. Bc3 Bg1 6. Bg7 Bc5 7. Bf6
                                    Bd6 8. Bg7 Be7 9. Be5 Bd8 10. Bg7 Ba5
                                    11. Bc3 Bxc3 12. bxc3 Kd5 13. Ke3 Kc5
                                    14. Ke2 Kd5

               30->  33.95  -0.01   1. ... Bb6 2. Bh8 Ke4 3. Bf6 Be3 4.   
                                    Bh8 Ba7 5. Bc3 Bg1 6. Bg7 Bc5 7. Bf6
                                    Bd6 8. Bg7 Be7 9. Be5 Bd8 10. Bg7 Ba5
                                    11. Bc3 Bxc3 12. bxc3 Kd5 13. Ke3 Kc5
                                    14. Ke2 Kd5
               31     3:27  -0.01   1. ... Bb6 2. Bc3 Bd4 3. Bxd4 Kxd4    
                                    4. Kd2 Ke4 5. Ke2 Kd4
               31     5:48     -1   1. ... c3!                            
               31     7:38  -1.13   1. ... c3 2. Bxc3 Bb6 3. Bh8 Kc4 4.   
                                    Bg7 Kb3 5. Bh8 Kc2 6. Bc3 Bc7 7. Ke3
                                    Kd1 8. Be5 Bb6+ 9. Bd4 Bxd4+ 10. Kxd4
                                    Ke2 11. Ke5 Kf3 12. Kxf5 Kxg3 13. Ke4
                                    Kxh4 14. Ke3 g3 15. Kf3 g2 <HT>
               31->   7:38  -1.13   1. ... c3 2. Bxc3 Bb6 3. Bh8 Kc4 4.   
                                    Bg7 Kb3 5. Bh8 Kc2 6. Bc3 Bc7 7. Ke3
                                    Kd1 8. Be5 Bb6+ 9. Bd4 Bxd4+ 10. Kxd4
                                    Ke2 11. Ke5 Kf3 12. Kxf5 Kxg3 13. Ke4
                                    Kxh4 14. Ke3 g3 15. Kf3 g2 <HT> (s=2)
               32     9:06  -1.13   1. ... c3 2. Bxc3 Bb6 3. Bh8 Kc4 4.   
                                    Bg7 Kb3 5. Bh8 Kc2 6. Bc3 Bg1 7. Bh8
                                    Bc5 8. Bg7 Ba7 9. Bh8 <HT>
               32->   9:09  -1.13   1. ... c3 2. Bxc3 Bb6 3. Bh8 Kc4 4.   
                                    Bg7 Kb3 5. Bh8 Kc2 6. Bc3 Bg1 7. Bh8
                                    Bc5 8. Bg7 Ba7 9. Bh8 <HT>
               33     9:14     +1   1. ... c3?                            
               33    12:03  -0.79   1. ... c3 2. Bxc3 Bb6 3. Bh8 Kc4 4.   
                                    Bg7 Kb3 5. Be5 Kc2 6. Bc3 Bc7 7. Ke3
                                    Kd1 8. Be5 Bb6+ 9. Bd4 Ba5 10. Bc3
                                    Bd8 11. Kd4 Ke2 12. Ke5 Kf2 13. Kxf5
                                    Kxg3 14. Ke5 Bc7+ 15. Ke4 Kxh4 16.
                                    Bd4 Kg3 17. Be5 Bxe5 18. fxe5 <HT>
               33->  12:14  -0.79   1. ... c3 2. Bxc3 Bb6 3. Bh8 Kc4 4.   
                                    Bg7 Kb3 5. Be5 Kc2 6. Bc3 Bc7 7. Ke3
                                    Kd1 8. Be5 Bb6+ 9. Bd4 Ba5 10. Bc3
                                    Bd8 11. Kd4 Ke2 12. Ke5 Kf2 13. Kxf5
                                    Kxg3 14. Ke5 Bc7+ 15. Ke4 Kxh4 16.
                                    Bd4 Kg3 17. Be5 Bxe5 18. fxe5 <HT>
               34    28:45  -0.79   1. ... c3 2. Bxc3 Bb6 3. Bh8 Kc4 4.   
                                    Bg7 Kb3 5. Be5 Kc2 6. Bc3 Bc7 7. Ke3
                                    Kd1 8. Be5 Bb6+ 9. Bd4 Ba5 10. Bc3
                                    Bd8 11. Kd4 Ke2 12. Ke5 Kf2 13. Kxf5
                                    Kxg3 14. Ke5 Bc7+ 15. Ke4 Kxh4 16.
                                    Bd4 Kg3 17. Be5 <HT>
               34->  29:00  -0.79   1. ... c3 2. Bxc3 Bb6 3. Bh8 Kc4 4.   
                                    Bg7 Kb3 5. Be5 Kc2 6. Bc3 Bc7 7. Ke3
                                    Kd1 8. Be5 Bb6+ 9. Bd4 Ba5 10. Bc3
                                    Bd8 11. Kd4 Ke2 12. Ke5 Kf2 13. Kxf5
                                    Kxg3 14. Ke5 Bc7+ 15. Ke4 Kxh4 16.
                                    Bd4 Kg3 17. Be5 <HT>
Thru depth 30, the effective branching factor looks odd. At 31, things slow way down and it changes to c3 after almost 6 minutes. And from that point the branching factor goes back to the normal value. So something happens there that causes problems. For whatever reason, whether it be hash size, parallel search, or whatever, your version doesn't see this until depth 34. Which is a problem, because depth 34 will blow up much worse than depth 31 since there are 3 more plies of stuff to deal with.

This is not that uncommon and highlights a known problem with alpha/beta search. If you avoid aspiration search, this is less likely to happen, but the search iterations will really slow down since they will have to deal with pawn promotions and sort thru them with a full search rather than an abbreviated one.
Michael Sherwin
Posts: 3196
Joined: Fri May 26, 2006 3:00 am
Location: WY, USA
Full name: Michael Sherwin

Re: Odd crafty problem (more)

Post by Michael Sherwin »

bob wrote:I ran this here. Here's the results, first.

Code: Select all

               27->  17.39  -0.03   1. ... Bb6 2. Bh8 Ke4 3. Bf6 Be3 4.   
                                    Bh8 Ba7 5. Bc3 Bg1 6. Bg7 Bc5 7. Bf6
                                    Bd6 8. Bg7 Be7 9. Be5 Bd8 10. Bg7 Ba5
                                    11. Bc3 Bxc3 12. bxc3 Kd5 13. Kf2 Kc5
                                    14. Ke3 Kd5 (s=5)
               28    20.44  -0.01   1. ... Bb6 2. Bh8 Ke4 3. Bf6 Be3 4.   
                                    Bh8 Ba7 5. Bc3 Bg1 6. Bg7 Bc5 7. Bf6
                                    Bd6 8. Bg7 Be7 9. Be5 Bd8 10. Bg7 Ba5
                                    11. Bc3 Bxc3 12. bxc3 Kd5 13. Ke3 Kc5
                                    14. Ke2 Kd5 (s=4)
               28->  20.90  -0.01   1. ... Bb6 2. Bh8 Ke4 3. Bf6 Be3 4.   
                                    Bh8 Ba7 5. Bc3 Bg1 6. Bg7 Bc5 7. Bf6
                                    Bd6 8. Bg7 Be7 9. Be5 Bd8 10. Bg7 Ba5
                                    11. Bc3 Bxc3 12. bxc3 Kd5 13. Ke3 Kc5
                                    14. Ke2 Kd5
               29    25.78  -0.01   1. ... Bb6 2. Bh8 Ke4 3. Bf6 Be3 4.   
                                    Bh8 Ba7 5. Bc3 Bg1 6. Bg7 Bc5 7. Bf6
                                    Bd6 8. Bg7 Be7 9. Be5 Bd8 10. Bg7 Ba5
                                    11. Bc3 Bxc3 12. bxc3 Kd5 13. Ke3 Kc5
                                    14. Ke2 Kd5
               29->  26.08  -0.01   1. ... Bb6 2. Bh8 Ke4 3. Bf6 Be3 4.   
                                    Bh8 Ba7 5. Bc3 Bg1 6. Bg7 Bc5 7. Bf6
                                    Bd6 8. Bg7 Be7 9. Be5 Bd8 10. Bg7 Ba5
                                    11. Bc3 Bxc3 12. bxc3 Kd5 13. Ke3 Kc5
                                    14. Ke2 Kd5
               30    33.57  -0.01   1. ... Bb6 2. Bh8 Ke4 3. Bf6 Be3 4.   
                                    Bh8 Ba7 5. Bc3 Bg1 6. Bg7 Bc5 7. Bf6
                                    Bd6 8. Bg7 Be7 9. Be5 Bd8 10. Bg7 Ba5
                                    11. Bc3 Bxc3 12. bxc3 Kd5 13. Ke3 Kc5
                                    14. Ke2 Kd5

               30->  33.95  -0.01   1. ... Bb6 2. Bh8 Ke4 3. Bf6 Be3 4.   
                                    Bh8 Ba7 5. Bc3 Bg1 6. Bg7 Bc5 7. Bf6
                                    Bd6 8. Bg7 Be7 9. Be5 Bd8 10. Bg7 Ba5
                                    11. Bc3 Bxc3 12. bxc3 Kd5 13. Ke3 Kc5
                                    14. Ke2 Kd5
               31     3:27  -0.01   1. ... Bb6 2. Bc3 Bd4 3. Bxd4 Kxd4    
                                    4. Kd2 Ke4 5. Ke2 Kd4
               31     5:48     -1   1. ... c3!                            
               31     7:38  -1.13   1. ... c3 2. Bxc3 Bb6 3. Bh8 Kc4 4.   
                                    Bg7 Kb3 5. Bh8 Kc2 6. Bc3 Bc7 7. Ke3
                                    Kd1 8. Be5 Bb6+ 9. Bd4 Bxd4+ 10. Kxd4
                                    Ke2 11. Ke5 Kf3 12. Kxf5 Kxg3 13. Ke4
                                    Kxh4 14. Ke3 g3 15. Kf3 g2 <HT>
               31->   7:38  -1.13   1. ... c3 2. Bxc3 Bb6 3. Bh8 Kc4 4.   
                                    Bg7 Kb3 5. Bh8 Kc2 6. Bc3 Bc7 7. Ke3
                                    Kd1 8. Be5 Bb6+ 9. Bd4 Bxd4+ 10. Kxd4
                                    Ke2 11. Ke5 Kf3 12. Kxf5 Kxg3 13. Ke4
                                    Kxh4 14. Ke3 g3 15. Kf3 g2 <HT> (s=2)
               32     9:06  -1.13   1. ... c3 2. Bxc3 Bb6 3. Bh8 Kc4 4.   
                                    Bg7 Kb3 5. Bh8 Kc2 6. Bc3 Bg1 7. Bh8
                                    Bc5 8. Bg7 Ba7 9. Bh8 <HT>
               32->   9:09  -1.13   1. ... c3 2. Bxc3 Bb6 3. Bh8 Kc4 4.   
                                    Bg7 Kb3 5. Bh8 Kc2 6. Bc3 Bg1 7. Bh8
                                    Bc5 8. Bg7 Ba7 9. Bh8 <HT>
               33     9:14     +1   1. ... c3?                            
               33    12:03  -0.79   1. ... c3 2. Bxc3 Bb6 3. Bh8 Kc4 4.   
                                    Bg7 Kb3 5. Be5 Kc2 6. Bc3 Bc7 7. Ke3
                                    Kd1 8. Be5 Bb6+ 9. Bd4 Ba5 10. Bc3
                                    Bd8 11. Kd4 Ke2 12. Ke5 Kf2 13. Kxf5
                                    Kxg3 14. Ke5 Bc7+ 15. Ke4 Kxh4 16.
                                    Bd4 Kg3 17. Be5 Bxe5 18. fxe5 <HT>
               33->  12:14  -0.79   1. ... c3 2. Bxc3 Bb6 3. Bh8 Kc4 4.   
                                    Bg7 Kb3 5. Be5 Kc2 6. Bc3 Bc7 7. Ke3
                                    Kd1 8. Be5 Bb6+ 9. Bd4 Ba5 10. Bc3
                                    Bd8 11. Kd4 Ke2 12. Ke5 Kf2 13. Kxf5
                                    Kxg3 14. Ke5 Bc7+ 15. Ke4 Kxh4 16.
                                    Bd4 Kg3 17. Be5 Bxe5 18. fxe5 <HT>
               34    28:45  -0.79   1. ... c3 2. Bxc3 Bb6 3. Bh8 Kc4 4.   
                                    Bg7 Kb3 5. Be5 Kc2 6. Bc3 Bc7 7. Ke3
                                    Kd1 8. Be5 Bb6+ 9. Bd4 Ba5 10. Bc3
                                    Bd8 11. Kd4 Ke2 12. Ke5 Kf2 13. Kxf5
                                    Kxg3 14. Ke5 Bc7+ 15. Ke4 Kxh4 16.
                                    Bd4 Kg3 17. Be5 <HT>
               34->  29:00  -0.79   1. ... c3 2. Bxc3 Bb6 3. Bh8 Kc4 4.   
                                    Bg7 Kb3 5. Be5 Kc2 6. Bc3 Bc7 7. Ke3
                                    Kd1 8. Be5 Bb6+ 9. Bd4 Ba5 10. Bc3
                                    Bd8 11. Kd4 Ke2 12. Ke5 Kf2 13. Kxf5
                                    Kxg3 14. Ke5 Bc7+ 15. Ke4 Kxh4 16.
                                    Bd4 Kg3 17. Be5 <HT>
Thru depth 30, the effective branching factor looks odd. At 31, things slow way down and it changes to c3 after almost 6 minutes. And from that point the branching factor goes back to the normal value. So something happens there that causes problems. For whatever reason, whether it be hash size, parallel search, or whatever, your version doesn't see this until depth 34. Which is a problem, because depth 34 will blow up much worse than depth 31 since there are 3 more plies of stuff to deal with.

This is not that uncommon and highlights a known problem with alpha/beta search. If you avoid aspiration search, this is less likely to happen, but the search iterations will really slow down since they will have to deal with pawn promotions and sort thru them with a full search rather than an abbreviated one.
In the above line 11. Kd4 looses but, 11. Kd3 seems to hold.
If you are on a sidewalk and the covid goes beep beep
Just step aside or you might have a bit of heat
Covid covid runs through the town all day
Can the people ever change their ways
Sherwin the covid's after you
Sherwin if it catches you you're through
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Odd crafty problem (more)

Post by bob »

Note that this is without any EGTB data, and that I am not too concerned with moves near the horizon. The only move that can't be a mistake is the first move, otherwise it would be dead. As you go down a few moves, that "mistake" will either be corrected (most of the time) or else is unavoidable because the first move started a forced sequence of moves that can not be terminated early. This is why we want extended depth, to push the unclear moves out near the tips where they are less likely to be forced on us, compared to the moves near the root of the PV.