PV depth increasing and decreasing (sorting bug?)

[hero2017]

I happen across this position in a game and I'm thinking this is either a SF bug or gui but I've been using Aquarium for a decade and never saw this. Notice the depth below goes from d=31 to d=32 then back down to d=31. Then it reaches d=33 and goes down to 32 then skips and goes to d=34. This is with the latest SF (reduce depth after fail high).

Sorry about the formatting (looks better in notepad) but I couldn't improve the view and had to settle to insert it as a quote...this is the PV directly from the infinite analysis tree window in Aquarium (best to view from bottom to top):

[FEN "r4rk1/2pnqppp/p2bpn2/1p2N3/3P1B2/1N4P1/PP2PPKP/R1QR4 b - - 0 17"]

[+0.11] d=38 17...Nd5 18.Na5 Rac8 19.Nac6 Qe8 20.Bd2 f5 21.Nxd7 Qxd7 22.Qc2 Qf7 23.f3 Rce8 24.Ne5 Qh5 25.Rac1 c5 26.Nd7 Rf7 27.dxc5 Rxd7 28.cxd6 Rxd6 29.Qb3 Qf7 30.e4 fxe4 31.fxe4 Nb6 32.Bb4 Rxd1 33.Qxd1 Nc4 34.Qf3 Qxf3+ 35.Kxf3 Nxb2 36.Rc6 a5 37.Bc3 Nc4 38.Ke2 Rb8 39.Rxe6 b4 40.Be5 Nxe5 41.Rxe5(0:02:23) 2878096kN [+0.09] d=38 17...Nd5 18.Na5 Qe8 19.Qc6 Bxe5 20.Bxe5 f6 21.Bf4 Qf7 22.Nb7 Ra7 23.Nc5 Nxc5 24.dxc5 Raa8 25.Rd2 Nxf4+ 26.gxf4 Rad8 27.Rad1 Rxd2 28.Rxd2 Qg6+ 29.Kf1 Qb1+(0:01:53) 2263076kN [+0.00] d=36 17...Nd5 18.Na5 Qe8 19.Qc6 Bxe5 20.Bxe5 f6 21.Bf4 Qf7 22.Nb7 Ra7 23.Nc5 Nxc5 24.dxc5 Raa8 25.Rd2 Nxf4+ 26.gxf4 Rad8 27.Rad1 Rxd2 28.Rxd2 Qg6+ 29.Kf1 Qb1+ 30.Kg2(0:01:37) 1955732kN [+0.09] d=37 17...Nd5 18.Na5 Qe8 19.Nd3 N7b6 20.Be5 Rc8 21.e4 Nb4 22.Nxb4 Bxb4 23.Bxg7 Kxg7 24.Qg5+ Kh8 25.Qf6+ Kg8 26.Nc6 Qxc6(0:01:31) 1825379kN [+0.17] d=37 17...Nd5 18.Na5 Qe8 19.Nd3 N7b6 20.Be5 Rc8 21.e4 Nb4 22.Nxb4 Bxb4 23.Bxg7 Kxg7 24.Qg5+ Kh8 25.Qf6+ Kg8 26.Nc6 Qxc6 27.Qg5+(0:01:16) 1538585kN [+0.09] d=37 17...Nd5 18.Na5 Qe8 19.Nd3 N7b6 20.Be5 Rc8 21.e4 Nb4 22.Nxb4 Bxb4 23.Bxg7 Kxg7 24.Qg5+ Kh8 25.Qf6+ Kg8 26.Nc6 Qxc6 27.Qg5+ Kh8(0:01:15) 1509717kN [+0.00] d=36 17...Nd5 18.Na5 Qe8 19.Nd3 N7b6 20.Be5 Rc8 21.e4 Nb4 22.Nxb4 Bxb4 23.Bxg7 Kxg7 24.Qg5+ Kh8 25.Qf6+ Kg8 26.Nc6 Qxc6 27.Qg5+ Kh8 28.Qf6+(0:01:13) 1477753kN [+0.00] d=34 17...Nd5 18.Na5 Qe8 19.Nd3 N7b6 20.Be5 Rc8 21.e4 Nb4 22.Nxb4 Bxb4 23.a3 Bxa5 24.Bxg7 Kxg7 25.Qg5+ Kh8 26.Qf6+ Kg8 27.Qg5+(0:00:45) 917023kN [+0.19] d=35 17...Nd5 18.Na5 Qe8 19.Nd3 N7b6 20.Qc6 Qe7 21.Rac1 Bxf4 22.Nxf4 Nxf4+ 23.gxf4 Nd5 24.e3 Qh4 25.Rg1 Qg4+ 26.Kh1 Qf3+ 27.Rg2 Qe2 28.Qc2 Qxc2 29.Rxc2 Nb4 30.Rc5 Nd3 31.Rc3 Nxb2 32.Rg1 c5 33.dxc5 Rac8 34.Rc2 Nd3 35.c6(0:00:40) 820105kN [+0.30] d=35 17...Nd5 18.Na5 Qe8 19.Nd3 N7b6 20.Qc6 Qe7 21.Rac1 Bxf4 22.Nxf4 Nxf4+ 23.gxf4 Nd5 24.e3 Qh4 25.Rg1 Qg4+ 26.Kh1 Qf3+ 27.Rg2 Qe2 28.Qc2 Qxc2 29.Rxc2 Nb4 30.Rc5 Nd3 31.Rc3 Nxb2 32.Rg1 c5 33.dxc5 Rac8 34.Rc2 Nd3 35.c6 Nb4(0:00:39) 790305kN [+0.17] d=35 17...Nd5 18.Na5 Qe8 19.Nd3 N7b6 20.Qc6 Qe7 21.Rac1 Bxf4 22.Nxf4 Nxf4+ 23.gxf4 Nd5 24.e3 Qh4 25.Rg1 Qg4+ 26.Kh1 Qf3+ 27.Rg2 Qe2 28.Qc2 Qxc2 29.Rxc2 Nb4 30.Rc5 Nd3 31.Rc3 Nxb2 32.Rg1 c5 33.dxc5 Rac8 34.Rc2 Nd3 35.c6 Nb4 36.Rc5(0:00:33) 679510kN [+0.09] d=35 17...Nd5 18.Na5 Qe8 19.Nd3 N7b6 20.Qc6 Qe7 21.Rac1 Bxf4 22.Nxf4 Nxf4+ 23.gxf4 Nd5 24.e3 Qh4 25.Rg1 Qg4+ 26.Kh1 Qf3+ 27.Rg2 Qe2 28.Qc2 Qxc2 29.Rxc2 Nb4 30.Rc5 Nd3 31.Rc3 Nxb2 32.Rg1 c5 33.dxc5 Rac8 34.Rc2 Nd3 35.c6 Nb4 36.Rc5 Nd3(0:00:30) 625107kN [+0.00] d=34 17...Nd5 18.Na5 Qe8 19.Nd3 N7b6 20.Qc6 Qe7 21.Rac1 Bxf4 22.Nxf4 Nxf4+ 23.gxf4 Nd5 24.e3 Qh4 25.Rg1 Qg4+ 26.Kh1 Qf3+ 27.Rg2 Qe2 28.Qc2 Qxc2 29.Rxc2 Nb4 30.Rc5 Nd3 31.Rc3 Nxb2 32.Rg1 c5 33.dxc5 Rac8 34.Rc2 Nd3 35.c6 Nb4 36.Rc5 Nd3 37.Rc2(0:00:28) 567305kN [+0.00] d=32 17...Nd5 18.Na5 Qe8 19.Nd3 N7b6 20.Qc6 Qe7 21.Rac1 Bxf4 22.Nxf4 Nxf4+ 23.gxf4 Nd5 24.e3 Qh4 25.Rg1 Qg4+ 26.Kh1 Qf3+ 27.Rg2 Qe2 28.Qc2 Qxc2 29.Rxc2 Nb4 30.Rc5 Nd3 31.Rc3 Nxb2 32.Rg1 c5 33.dxc5 Rac8 34.Rc2 Nd3 35.c6 Nb4 36.Rc5 Nd3(0:00:21) 437731kN [+0.01] d=33 17...Nd5 18.Na5 Qe8 19.Nd3 N7b6 20.Qc6 Qe7 21.Rac1 Bxf4 22.Nxf4 Nxf4+ 23.gxf4 Nd5 24.e3 Qh4 25.Rg1 Kh8 26.Qc2 g5 27.fxg5 Rg8 28.Kh1 Nb4 29.Qe2 Rxg5 30.Qf3 Rxg1+ 31.Rxg1 Rg8 32.Rg3 f5 33.Kg1 Rf8 34.Nb3 Nd3 35.Qe2 f4 36.exf4 Nxf4 37.Qe5+ Qf6 38.Qxf6+ Rxf6 39.Kf1 Rh6 40.Rf3 Nd5 41.Kg2 Kg8 42.Nc5 Rg6+(0:00:21) 429619kN [+0.10] d=31 17...Nd5 18.Na5 Qe8 19.Nd3 N7b6 20.Qc6 Qe7 21.Rac1 Bxf4 22.Nxf4 Nxf4+ 23.gxf4 Nd5 24.e3 Qh4 25.Rg1 Kh8 26.Qc2 g5 27.fxg5 Rg8 28.Kh1 Nb4 29.Qe2 Rxg5 30.Qf3 Rxg1+ 31.Rxg1 Rg8 32.Rg3 f5 33.Kg1 Rf8 34.Nb3 Nd3 35.Qe2 f4 36.exf4 Nxf4 37.Qe5+ Qf6 38.Qxf6+ Rxf6 39.Kf1 Rh6 40.Rf3 Nd5 41.Kg2 Kg8 42.Nc5 Rg6+ 43.Rg3(0:00:16) 327446kN [+0.09] d=32 17...Nd5 18.Na5 Qe8 19.Nd3 N7b6 20.Qc2 Nxf4+ 21.Nxf4 e5 22.dxe5 Bxe5 23.Rd2 Bxf4 24.gxf4 Qe6 25.Qxc7 Rae8 26.Qc3 Qh6 27.Qf3 Rd8 28.Rad1 Rxd2 29.Rxd2 Qg6+ 30.Qg3(0:00:15) 323364kN [+0.17] d=32 17...Nd5 18.Na5 Qe8 19.Nd3 N7b6 20.Qc2 Nxf4+ 21.Nxf4 e5 22.dxe5 Bxe5 23.Rd2 Bxf4 24.gxf4 Qe6 25.Qxc7 Rae8 26.Qc3 Qh6 27.Qf3 Rd8 28.Rad1 Rxd2 29.Rxd2 Qg6+ 30.Qg3 Qe6(0:00:14) 285086kN [+0.09] d=32 17...Nd5 18.Na5 Qe8 19.Nd3 N7b6 20.Qc2 Nxf4+ 21.Nxf4 e5 22.dxe5 Bxe5 23.Rd2 Bxf4 24.gxf4 Qe6 25.Qxc7 Rae8 26.Qc3 Qh6 27.Qf3 Rd8 28.Rad1 Rxd2 29.Rxd2 Qg6+ 30.Qg3 Qe6 31.Qe3(0:00:12) 251799kN [+0.00] d=31 17...Nd5 18.Na5 Qe8 19.Nd3 N7b6 20.Qc2 Nxf4+ 21.Nxf4 e5 22.dxe5 Bxe5 23.Rd2 Bxf4 24.gxf4 Qe6 25.Qxc7 Rae8 26.Qc3 Qh6 27.Qf3 Rd8 28.Rad1 Rxd2 29.Rxd2 Qg6+ 30.Qg3 Qe6 31.Qe3 Qg6+(0:00:08) 181478kN

Now I suppose that's expected behaviour with the latest patch but that just feels weird.

[ssj100]

I can confirm this "bug" in Arena. I've also never seen this before.

I've also noticed another issue with this latest patch - at least some test positions (such as listed below) which @vondele randomise draw eval patch "fixed", appear to be back to previous behaviour ("draw blindness"?): 3r2k1/pr6/1p3q1p/5R2/3P3p/8/5RP1/3Q2K1 b - - 0 51 3r2kq/p2prp1p/1p4pP/2R5/1Q6/1B3RP1/P4PK1/8 b - - 0 47 rnbqk1nr/ppp2ppp/4p3/3pP3/1b1P4/2N5/PPP3PP/R1BQKBNR b KQkq - 0 8 For those wanting to test, just observe the difference between Stockfish Oct 23 and Oct 25 when analysing these positions.

[vondele]

The depth behavior is not unexpected (i.e. was implemented on purpose). It is the way fail high searches are now being handled while the aspiration window is being adjusted.

@ssj100 surprising to see that these positions would be influenced, but it can't be excluded.

[ssj100]

@vondele Thanks for confirming the depth behaviour is not unexpected. Yes I'm surprised that those positions would be influenced too, but Bryan SF is also seeing the same "issue". Could you check it out please?

[crossbr]

@vondele I put the three cases on fishcooking. One from K-H game, one from AZ vs. SF8 Game 3, and one from the disabled LC0 game.

[ElbertoOne]

I can confirm that for the test positions reported by @ssj100 the randomize eval patch doesn't work anymore (on single thread). I created a test in the framework that might fix this: http://tests.stockfishchess.org/tests/view/5bd305a60ebc595e0ae1e13c It does solve the positions and also doesn't have the PV depth increasing and decreasing. However, I'm afraid that it will not perform well, so the test is for a limited number of games only.

[NKONSTANTAKIS]

More info and discussion of this topic here: https://groups.google.com/forum/#!topic/fishcooking/UC9-n50prSc

[DragonMist]

Depth going up and down is far more serious "bug" than the one that caused recent revert (end of fail high PV) imo.

[vondele]

well, it is the correct output for what the engine is right now doing at failhigh. Fail highs are resolved at increasingly lower depth (named 'adjustedDepth' in the code). So, the output definitely matches what is going on...

However, 'depth' means anyway not much... we could consider this printed 'adjustedDepth' an implementation detail and continue to print 'rootDepth'. I have no strong opinion here.

[DragonMist]

So, if I understood correctly, latest pv, even if it shows lower depth than the one before that, is to be considered "best so far"?

[vondele]

tricky .... I would guess so (in the sense that we will play the move that is first in that PV if we're forced by the clock to play, and that's the best line we've found so far), but we optimize for winning games ... and that's not the same as producing the best PVs. We might have found that it is more effective (overall) to do a lousy job while resolving a failhigh, so we gain more time that we can use when it is needed more.

The PV in the new scheme, once the failhigh is resolved is presumably of lower quality than the resolved PV in the old scheme (because it is at lower depth).

[DragonMist]

      tricky .... I would guess so (in the sense that we will play the move that is first in that PV if we're forced by the clock to play, and that's the best line we've found so far),

That answers my question, last line shown is best SF could come up so far, with the code as it is now.

but we optimize for winning games ... and that's not the same as producing the best PVs. We might have found that it is more effective (overall) to do a lousy job while resolving a failhigh, so we gain more time that we can use when it is needed more.

That one concerns me less, as it is in the hands of devs to find the optimum. What I was worried is we are not sure any more if the "best found so far" is what is typed last or what is typed with higher depth. That would render SF almost unusable for chess analysis.

The PV in the new scheme, once the failhigh is resolved is presumably of lower quality than the resolved PV in the old scheme (because it is at lower depth).

That is confusing. If the new resolved pv is of lower quality than the old resolved pv is, shouldn't that mean lower quality of moves played overall, too? And if so, how come the patch is elo gain (at 1 core at least)?

[vondele]

The PV in the new scheme, once the failhigh is resolved is presumably of lower quality than the resolved PV in the old scheme (because it is at lower depth).

That is confusing. If the new resolved pv is of lower quality than the pv old resolved pv is, shouldn't that mean lower quality of moves played overall, too? And if so, how come the patch is elo gain (at 1 core at least)?

because of time gained in iterations involving failhigh, the overall quality of played moves might increase, e.g. we can do an iteration more, or we can resolve the failhigh. The patch is quite clearly an elo gainer.

[DragonMist]

Ah ok, gains time. One thing to consider for us correspondence players (time not really an issue).

[vondele]

nevertheless similar, consider the new scheme the most efficient way to high depth.

[DragonMist]

Yes of course. Thank you @vondele for your input!

[Coolchessguykevin]

As I understand from this topic, the new depth reduce patch is good for the engines games, but it degrades the quality of the analysis. Is it possible to make a check-box in parameters for the possibility old depth scheme for the correspondence players?

[DragonMist]

Kevin, given the exact same amount of time, new SF will outperform old SF. But if you compare the quality of pv on the same depth, old SF pv will be probably better. At least that's the way I understood this.

[Coolchessguykevin]

DragonMist, ok, but it is dizzying. I also noticed a drop in speed with a new patch on my PC (about 6%). Has anyone else noticed?

[DragonMist]

I think this is one of those things that for us, practical users, it is better to ignore it (same as I concluded about introducing contempt per se, as well as about analysis asymmetry). Haven't tried it yet so no idea about slow down.

[vondele]

slowdown is well possible, but again doesn't say much for this kind of change, search is pretty different now e.g. the fraction of TThits vs nodes will be rather different.

[hero2017]

I have noticed slower performance as well now that I've played more positions.

But most important right now is that we clearly understand, from a correspondence player's point of view, which is the best line? The line last displayed even if lower depth than previous line at higher depth?

[DragonMist]

The last line displayed, yes. Even if lower depth.

[vondele]

I think the last line, but this would actually be testable... I might be giving it a try on fishtest.

[hero2017]

Well do we know if, in engine vs engine matches, the elo gain is from which line? The last line regardless of depth or the one with highest depth?

[DragonMist]

@vondele if you can create such test, do it please, it confuses us.

[vondele]

yes, looking into it.

[vondele]

Test here: http://tests.stockfishchess.org/tests/view/5bd37a120ebc595e0ae1e7c3 if this passes it is better to play the move from the PV line with the largest depth, otherwise just the latest printed one (even if at lower depth).

[IIvec]

a) this patch passed more tests than most other patches, b) alpha-beta search is not natural for human brain, and so it is difficult to correctly interpret the notion of depth in chess engines.

[DragonMist]

Ivan, we're not trying to interpret the notion of depth, we're trying to ascertain if the latest displayed pv by new SF is in fact strongest, i.e. stronger than previous with higher depth, which we saw is feature of new patch (showing depth of X then going back)

[IIvec]

DragonMist, in my opinion when the depth goes down, you should wait for it to go up again to be sure.

[DragonMist]

No, that resolves nothing imo.

[IIvec]

With this patch, or without this patch uncompleted depth is not good. Always is best to wait for fail lows and fail highs to be resolved, if we can afford so.

[DragonMist]

That I absolutely agree :)

[IIvec]

Before we had only + and -, now we also have those drops in depth when failing high. In my opinion, those drops try to check whether fail high is sound or not. In that way I like the patch.

[vondele]

OK, test is clear now, better play the move of the last PV.

[DragonMist]

Yeah, watched every second of it. Great help, thanks @vondele !

[hero2017]

With this patch, or without this patch uncompleted depth is not good. Always is best to wait for fail lows and fail highs to be resolved, if we can afford so.

Cool...how do I know when a fail high/low has been resolved?

[vdbergh]

Lowering the depth seems to confuse xboard somewhat (it does not print the lower depth pv in its engine output window),

[pb00068]

≤<Cool...how do I know when a fail high/low has been resolved?

According UCI-protocol SF gives out fail Highs with the lowerbound notion and fail lows with the upperbound notion. Usually a GUI highlights fail h/l with according symbols for instance arena puts a +/- symbol after depth/seldepth. When the GUI gives out a line without these symbols then you know that the fail h/l is resolved.

[vondele]

@pb00068 what about just continuing to print 'rootDepth' instead of 'adjustedDepth' in the pv info lines. It is cosmetics, but I feel like printing adjustedDepth is exposing users to an implementation detail (what if the scheme gets even more complex in the future). The issue with xboard would be and additional reason.

[Coolchessguykevin]

I just noticed a new issue with the new patch. I analyzed some position for several hours, got depth 62 and 0.00 eval. As soon as I began to run the received variation on the game notation, SF lost its accumulated depth and evals, as if the hash had been suddenly reset. Can it be fixed?

[pb00068]

@vondele I feel that SF should give out the thruth and not something the users or the GUI expected for pure habit. There's no protocol that specify depths must be reported in strict ascending order. Anyhow thats a question / proposal that IMO should be answered by maintainers.

[vondele]

well, depth is all about convention, little about truth.... but I'm not too opinionated about which convention we adopt.

[pb00068]

@Coolchessguykevin If you don't stop analysis while doing moves over the board, it's totally normal that search begins again with depth 1 (without clearing the hash).

[Coolchessguykevin]

@pb00068 It is very strange. I did not notice this in previous versions. The search continued from high depths with the previously obtained eval, when I was making candidate moves on the board in the considered position.

[pb00068]

Coolchessguykevin which GUI are you using? When you change the root position the engine can't just resume at a higher depth, it always has to restart iterative deepening from depth 1

[joergoster]

I'm really sorry to say, but this patch is causing a real mess!

master, go depth 24 ... info depth 22 seldepth 33 multipv 1 score cp 69 nodes 8158726 nps 1156937 hashfull 998 tbhits 0 time 7052 pv e2e4 e7e5 g1f3 b8c6 f1b5 g8f6 d2d3 c6e7 b1c3 c7c6 b5c4 d7d5 c4b3 e7g6 e4d5 c6d5 e1g1 f8e7 f1e1 e8g8 f3e5 g6e5 e1e5 e7d6 e5d5 f6d5 info depth 23 currmove e2e4 currmovenumber 1 info depth 23 currmove g1f3 currmovenumber 2 info depth 23 currmove c2c3 currmovenumber 3 info depth 23 currmove b1c3 currmovenumber 4 info depth 23 currmove a2a3 currmovenumber 5 info depth 23 currmove c2c4 currmovenumber 6 info depth 23 currmove e2e3 currmovenumber 7 info depth 23 currmove d2d4 currmovenumber 8 info depth 23 currmove d2d3 currmovenumber 9 info depth 23 currmove f2f3 currmovenumber 10 info depth 23 currmove h2h3 currmovenumber 11 info depth 23 currmove f2f4 currmovenumber 12 info depth 23 currmove b2b3 currmovenumber 13 info depth 23 currmove b2b4 currmovenumber 14 info depth 23 currmove a2a4 currmovenumber 15 info depth 23 currmove g2g3 currmovenumber 16 info depth 23 currmove b1a3 currmovenumber 17 info depth 23 currmove g1h3 currmovenumber 18 info depth 23 currmove h2h4 currmovenumber 19 info depth 23 currmove g2g4 currmovenumber 20 info depth 23 seldepth 31 multipv 1 score cp 60 upperbound nodes 9213612 nps 1151845 hashfull 999 tbhits 0 time 7999 pv e2e4 e7e5 info depth 23 currmove e2e4 currmovenumber 1 info depth 23 currmove g1f3 currmovenumber 2 info depth 23 currmove d2d4 currmovenumber 3 info depth 23 currmove b1c3 currmovenumber 4 info depth 23 currmove c2c3 currmovenumber 5 info depth 23 currmove g2g3 currmovenumber 6 info depth 23 currmove d2d3 currmovenumber 7 info depth 23 currmove h2h3 currmovenumber 8 info depth 23 currmove b1a3 currmovenumber 9 info depth 23 currmove b2b4 currmovenumber 10 info depth 23 currmove f2f3 currmovenumber 11 info depth 23 currmove a2a3 currmovenumber 12 info depth 23 currmove a2a4 currmovenumber 13 info depth 23 currmove c2c4 currmovenumber 14 info depth 23 currmove f2f4 currmovenumber 15 info depth 23 currmove b2b3 currmovenumber 16 info depth 23 currmove g2g4 currmovenumber 17 info depth 23 currmove h2h4 currmovenumber 18 info depth 23 currmove e2e3 currmovenumber 19 info depth 23 currmove g1h3 currmovenumber 20 info depth 23 seldepth 31 multipv 1 score cp 69 nodes 11155522 nps 1147215 hashfull 999 tbhits 0 time 9724 pv e2e4 e7e5 g1f3 b8c6 f1b5 g8f6 e1g1 f6e4 d2d4 e4d6 b5c6 d7c6 d4e5 d6f5 d1e2 f5d4 f3d4 d8d4 f1d1 d4h4 h2h3 f8e7 c1e3 c8e6 b1d2 e8g8 info depth 24 currmove e2e4 currmovenumber 1 info depth 24 currmove g1f3 currmovenumber 2 info depth 24 currmove c2c3 currmovenumber 3 info depth 24 currmove b1c3 currmovenumber 4 info depth 24 currmove c2c4 currmovenumber 5 info depth 24 currmove h2h3 currmovenumber 6 info depth 24 currmove g2g4 currmovenumber 7 info depth 24 currmove f2f3 currmovenumber 8 info depth 24 currmove e2e3 currmovenumber 9 info depth 24 currmove d2d4 currmovenumber 10 info depth 24 currmove a2a3 currmovenumber 11 info depth 24 currmove g2g3 currmovenumber 12 info depth 24 currmove d2d3 currmovenumber 13 info depth 24 currmove f2f4 currmovenumber 14 info depth 24 currmove b2b4 currmovenumber 15 info depth 24 currmove b1a3 currmovenumber 16 info depth 24 currmove b2b3 currmovenumber 17 info depth 24 currmove g1h3 currmovenumber 18 info depth 24 currmove a2a4 currmovenumber 19 info depth 24 currmove h2h4 currmovenumber 20 info depth 24 seldepth 30 multipv 1 score cp 60 upperbound nodes 11895367 nps 1146209 hashfull 999 tbhits 0 time 10378 pv e2e4 e7e5 info depth 24 currmove e2e4 currmovenumber 1 info depth 24 seldepth 32 multipv 1 score cp 69 lowerbound nodes 13908134 nps 1142351 hashfull 999 tbhits 0 time 12175 pv e2e4 info depth 23 currmove e2e4 currmovenumber 1 info depth 23 currmove g1f3 currmovenumber 2 info depth 23 currmove d2d4 currmovenumber 3 info depth 23 currmove b1c3 currmovenumber 4 info depth 23 currmove b2b4 currmovenumber 5 info depth 23 currmove c2c4 currmovenumber 6 info depth 23 currmove c2c3 currmovenumber 7 info depth 23 currmove a2a3 currmovenumber 8 info depth 23 currmove e2e3 currmovenumber 9 info depth 23 currmove g2g3 currmovenumber 10 info depth 23 currmove h2h3 currmovenumber 11 info depth 23 currmove f2f4 currmovenumber 12 info depth 23 currmove d2d3 currmovenumber 13 info depth 23 currmove f2f3 currmovenumber 14 info depth 23 currmove a2a4 currmovenumber 15 info depth 23 currmove b1a3 currmovenumber 16 info depth 23 currmove g1h3 currmovenumber 17 info depth 23 currmove b2b3 currmovenumber 18 info depth 23 currmove g2g4 currmovenumber 19 info depth 23 currmove h2h4 currmovenumber 20 info depth 23 seldepth 32 multipv 1 score cp 58 nodes 14402819 nps 1141631 hashfull 999 tbhits 0 time 12616 pv e2e4 e7e5 g1f3 b8c6 f1c4 g8f6 d2d3 f8c5 e1g1 e8g8 b1c3 d7d6 c1g5 c6d4 c3d5 c8g4 b2b4 c7c6 b4c5 c6d5 e4d5 d6c5 c2c3 d4f3 g2f3 g4h3 f1e1 bestmove e2e4 ponder e7e5

Only showing the last 2 (or 3 ?) iterations, starting from depth 22. SF always obeyed to the 'go depth' command in the past, and now we're stopping with info depth 23??? It is not even clear if this is iteration 23 or already iteration 24. I can't believe this patch has been committed!

[Coolchessguykevin]

pb00068 I use Aquarium 2018 GUI. Of course, I do not mean an instantaneous continuation from the same depth, when I continue the variant manually, but a very rapid increase in it (in a matter of seconds high values are reached, close to the reached value initially). In the most recent dev-version, with the introduction of the next move on the board, the analysis began from zero, that is, the accumulated estimate and deep depth disappeared. Its increase began very slowly from low values, like when you first started the engine.

[pb00068]

@Joster: search was at rootdepth 24 then it failed high, then search terminated with resolving at rootdepth 23, so actually the used/explored depth is something between 23 and 24, more near to 23 however. I must admit that SF now do not more strict obey the Go depth Command. I'm in vacation the next 3 days, after that i'm quite confident to find a solution/fix for this minor problem.

[joergoster]

@pb00068 Hi Günther, glad to hear this. I really think this patch needs some polishing. ;-)

In the meantime you may want to take a look at this https://github.com/joergoster/Stockfish/commit/b9c2496ae86e885447a66c9a95cfb1d1ec410759 which seems to fix the problem of truncated PVs. But I need to write a verification function for the PVs and do some tests.