For Marco---possible Stockfish bug

[Uri Blass]

Hi Marco

be ironic now can't help to solve the problem pointed .

If other engines solve the problem and Stockfish dont, _AND_ this is not a bug, where the algorithm is failing?


PS.: This is the question...

I think that the problem is that there is more than one zugzwang
After
1.Kh6 Be5 2.Kg7 Bh2 3.c4 bxc4 4.e5 Bxe5 5.bxc4 black is in zugzwang and after 5...Bxf6+ gxf6 there is another zugzwang and even if you use zugzwang detection you may evaluate Rh8 Kxh8 as better for black and fail to detect the zugzwang.

[Sven]

I see the knock out coming

This is a good time to die as an old Indian said, and went to a brothel.
I still come back!

Hi Marek,

I am not the KnockOut, only its author

You wrote the following:

I changed (in Stockfish 2.1.1)

Code: Select all

 if (!Root && value > alpha)
          {
              if (PvNode && value < beta) // We want always alpha < beta
{
                  alpha = value;

to:

Code: Select all

 if (!Root && value > alpha)
          {
              if (PvNode && value <= beta) // We want always alpha < beta
{
                  alpha = value;

but I have trouble to understand why this can have any effect at all. If the search comes to that point [EDIT: in a PV node] with value == beta (which is exactly the situation describing your change) then in my opinion the following happens:

- in contrast to the original SF version, you raise alpha to the value of beta (o.k., it has already been commented that this is against alpha-beta standards but let's ignore it for a moment, just to show what happens);

- furthermore, if the current node is a split point (SP) node then you also update alpha of the SP but, in contrast to original SF, do NOT set the is_betaCutoff flag [this code also exists in more recent SF versions albeit slightly rearranged], which in turn can cause the cutoff_occurred() function not to return "true" when checking the hierarchy of split points even though you already reached "beta" [but nevertheless I don't see where cutoff_occurred() will be called again in the given case; is it in "Step 20. Update tables"? But that is only for non-SP nodes.];

- the next code that could be executed for a non-root, non-SP node would be to try an SMP split, but that will not happen since one of its conditions is "bestValue < beta" which is no longer valid;

- then, to my understanding the search loop stops in any case, whether SP node or normal node, due to its "while (bestValue < beta)" condition, the same way it did stop without your change; after finishing the loop, everything else up to returning from search() is not affected since it does not depend on alpha (only on oldAlpha).


I did not check all details of the SMP-related code but for me it seems as if your change did not have any direct effect within the search function itself but instead some (most probably unwanted) side effect which might only occur with SMP.

Therefore I would like to know whether your change causes Stockfish to solve that particular position also in the single-CPU version. If the answer is "no" then for me the interesting part would be which side effect on the SMP code was triggered by your change. If the answer is "yes" then most probably I'll have missed something in my analysis.

Sven

[Robert]

Given:
[d]4kr2/5p1K/3p1Q2/1p4P1/4P3/1PP5/7b/8 w - -

and after 1.Kh6 Be5 2.Kg7 Bh2

we reach this position:
[d]4kr2/5pK1/3p1Q2/1p4P1/4P3/1PP5/7b/8 w - - 4 3

Now looking to engine output when Stockfish must play a move:

2012-02-03 09:22:47,177<--1:info depth 33
2012-02-03 09:22:47,178<--1:info currmove g7h6 currmovenumber 1
2012-02-03 09:22:47,969<--1:info nodes 6526864 nps 2057649 time 3172
2012-02-03 09:22:47,970<--1:info currmove f6d8 currmovenumber 2
2012-02-03 09:22:47,974<--1:info currmove g7h7 currmovenumber 3
2012-02-03 09:22:47,975<--1:info currmove f6f2 currmovenumber 4
2012-02-03 09:22:47,976<--1:info currmove g5g6 currmovenumber 5
2012-02-03 09:22:47,978<--1:info currmove c3c4 currmovenumber 6
2012-02-03 09:22:52,327<--1:info nodes 19743879 nps 2622377 time 7529
2012-02-03 09:22:52,327<--1:info currmove c3c4 currmovenumber 1 <= best move found and soon be played
2012-02-03 09:22:52,495<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:22:52,813<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:22:54,215<--1:info nodes 24012758 nps 2549666 time 9418
2012-02-03 09:22:54,215<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:22:55,128<--1:info nodes 25977128 nps 2514726 time 10330
2012-02-03 09:22:55,128<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:22:55,642<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:22:56,311<--1:info nodes 28321400 nps 2459735 time 11514
2012-02-03 09:22:56,312<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:22:56,918<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:22:58,453<--1:info nodes 33235302 nps 2433750 time 13656
2012-02-03 09:22:58,454<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:23:01,984<--1:info nodes 41878298 nps 2436626 time 17187
2012-02-03 09:23:01,985<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:23:04,968<--1:info depth 33 seldepth 43 multipv 1 score cp 609 nodes 49409726 nps 2449664 time 20170 pv c3c4 b5c4 e4e5 h2e5 b3c4 e5f6 g5f6 d6d5 c4d5
2012-02-03 09:23:04,979<--1:info nodes 49409726 nps 2449542 time 20171
2012-02-03 09:23:04,979<--1:bestmove c3c4 ponder b5c4
2012-02-03 09:23:04,979*1*Found move:c3-c4

And the output when Stockfish is just analysing the position:

2012-02-03 09:33:07,030<--1:info depth 34
2012-02-03 09:33:07,034<--1:info currmove f6f2 currmovenumber 1
2012-02-03 09:33:07,331<--1:info nodes 6175696 nps 1945101 time 3175
2012-02-03 09:33:07,334<--1:info currmove f6d8 currmovenumber 2
2012-02-03 09:33:07,338<--1:info currmove g5g6 currmovenumber 3
2012-02-03 09:33:07,364<--1:info currmove g7h7 currmovenumber 4
2012-02-03 09:33:07,369<--1:info currmove f6f5 currmovenumber 5
2012-02-03 09:33:07,373<--1:info currmove g7h6 currmovenumber 6
2012-02-03 09:33:07,382<--1:info currmove f6e6 currmovenumber 7
2012-02-03 09:33:07,385<--1:info currmove e4e5 currmovenumber 8
2012-02-03 09:33:07,403<--1:info currmove c3c4 currmovenumber 9
2012-02-03 09:33:12,870<--1:info nodes 21555408 nps 2473652 time 8714
2012-02-03 09:33:12,874<--1:info currmove c3c4 currmovenumber 1 <= correct move found but info of "lowerbound" missing!
2012-02-03 09:33:13,396<--1:info nodes 22897191 nps 2478050 time 9240
2012-02-03 09:33:13,400<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:33:15,140<--1:info nodes 27737174 nps 2525234 time 10984
2012-02-03 09:33:15,144<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:33:16,332<--1:info nodes 30770027 nps 2527935 time 12172
2012-02-03 09:33:16,335<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:33:17,569<--1:info nodes 33818578 nps 2521328 time 13413
2012-02-03 09:33:17,573<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:33:18,432<--1:info nodes 35936499 nps 2517266 time 14276
2012-02-03 09:33:18,436<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:33:19,372<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:33:20,168<--1:info nodes 40107125 nps 2504973 time 16011
2012-02-03 09:33:20,171<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:33:21,428<--1:info nodes 42995468 nps 2489316 time 17272
2012-02-03 09:33:21,435<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:33:23,663<--1:info nodes 48380352 nps 2480153 time 19507
2012-02-03 09:33:23,673<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:33:29,266<--1:info nodes 61745507 nps 2459000 time 25110
2012-02-03 09:33:29,274<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:33:45,863<--1:info nodes 103790532 nps 2488563 time 41707
2012-02-03 09:33:45,871<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:35:09,865<--1:info nodes 311958526 nps 2481592 time 125709
2012-02-03 09:35:09,873<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:37:04,225<--1:info nodes 586790930 nps 2444259 time 240069
2012-02-03 09:37:04,233<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:38:43,115<--1:info nodes 819781875 nps 2418535 time 338958
2012-02-03 09:38:43,122<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:38:59,351-->1:stop <= good info just after "stop" command.
2012-02-03 09:38:59,363<--1:info depth 34 seldepth 46 multipv 1 score cp 4661 nodes 859716647 nps 2420332 time 355206 pv c3c4 b5c4 e4e5 h2e5 b3c4 e5f6 g5f6 e8d7 g7f8 d7e6 f8g7 e6d7 g7f7 d7c6 f7e6 c6c5 f6f7 c5d4 e6d6
2012-02-03 09:38:59,377<--1:info nodes 859716647 nps 2420332 time 355206
2012-02-03 09:38:59,381<--1:bestmove c3c4 ponder b5c4


This is not about zugzwang, alpha-beta, ELO, ...

But can be solved, right?

[lech]

Becouse there is only one VALUE_DRAW, and two sides.

This is the main line of my " THEORY".
What does this mean?
If an item returns VALUE_DRAW it is very likely (repeated moves) that a lot of nodes return a bad value and move, they will have VALUE_DRAW as beta.
This is very wrong.
I used alpha = beta only for me to quickly confirm my guess.
I mean, I feel rather (it is better ) search.
Now, I doubt if there is anyone among you who feel it as well.

[Uri Blass]

Given:
[d]4kr2/5p1K/3p1Q2/1p4P1/4P3/1PP5/7b/8 w - -

and after 1.Kh6 Be5 2.Kg7 Bh2

we reach this position:
[d]4kr2/5pK1/3p1Q2/1p4P1/4P3/1PP5/7b/8 w - - 4 3

Now looking to engine output when Stockfish must play a move:

2012-02-03 09:22:47,177<--1:info depth 33
2012-02-03 09:22:47,178<--1:info currmove g7h6 currmovenumber 1
2012-02-03 09:22:47,969<--1:info nodes 6526864 nps 2057649 time 3172
2012-02-03 09:22:47,970<--1:info currmove f6d8 currmovenumber 2
2012-02-03 09:22:47,974<--1:info currmove g7h7 currmovenumber 3
2012-02-03 09:22:47,975<--1:info currmove f6f2 currmovenumber 4
2012-02-03 09:22:47,976<--1:info currmove g5g6 currmovenumber 5
2012-02-03 09:22:47,978<--1:info currmove c3c4 currmovenumber 6
2012-02-03 09:22:52,327<--1:info nodes 19743879 nps 2622377 time 7529
2012-02-03 09:22:52,327<--1:info currmove c3c4 currmovenumber 1 <= best move found and soon be played
2012-02-03 09:22:52,495<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:22:52,813<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:22:54,215<--1:info nodes 24012758 nps 2549666 time 9418
2012-02-03 09:22:54,215<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:22:55,128<--1:info nodes 25977128 nps 2514726 time 10330
2012-02-03 09:22:55,128<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:22:55,642<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:22:56,311<--1:info nodes 28321400 nps 2459735 time 11514
2012-02-03 09:22:56,312<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:22:56,918<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:22:58,453<--1:info nodes 33235302 nps 2433750 time 13656
2012-02-03 09:22:58,454<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:23:01,984<--1:info nodes 41878298 nps 2436626 time 17187
2012-02-03 09:23:01,985<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:23:04,968<--1:info depth 33 seldepth 43 multipv 1 score cp 609 nodes 49409726 nps 2449664 time 20170 pv c3c4 b5c4 e4e5 h2e5 b3c4 e5f6 g5f6 d6d5 c4d5
2012-02-03 09:23:04,979<--1:info nodes 49409726 nps 2449542 time 20171
2012-02-03 09:23:04,979<--1:bestmove c3c4 ponder b5c4
2012-02-03 09:23:04,979*1*Found move:c3-c4

And the output when Stockfish is just analysing the position:

2012-02-03 09:33:07,030<--1:info depth 34
2012-02-03 09:33:07,034<--1:info currmove f6f2 currmovenumber 1
2012-02-03 09:33:07,331<--1:info nodes 6175696 nps 1945101 time 3175
2012-02-03 09:33:07,334<--1:info currmove f6d8 currmovenumber 2
2012-02-03 09:33:07,338<--1:info currmove g5g6 currmovenumber 3
2012-02-03 09:33:07,364<--1:info currmove g7h7 currmovenumber 4
2012-02-03 09:33:07,369<--1:info currmove f6f5 currmovenumber 5
2012-02-03 09:33:07,373<--1:info currmove g7h6 currmovenumber 6
2012-02-03 09:33:07,382<--1:info currmove f6e6 currmovenumber 7
2012-02-03 09:33:07,385<--1:info currmove e4e5 currmovenumber 8
2012-02-03 09:33:07,403<--1:info currmove c3c4 currmovenumber 9
2012-02-03 09:33:12,870<--1:info nodes 21555408 nps 2473652 time 8714
2012-02-03 09:33:12,874<--1:info currmove c3c4 currmovenumber 1 <= correct move found but info of "lowerbound" missing!
2012-02-03 09:33:13,396<--1:info nodes 22897191 nps 2478050 time 9240
2012-02-03 09:33:13,400<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:33:15,140<--1:info nodes 27737174 nps 2525234 time 10984
2012-02-03 09:33:15,144<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:33:16,332<--1:info nodes 30770027 nps 2527935 time 12172
2012-02-03 09:33:16,335<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:33:17,569<--1:info nodes 33818578 nps 2521328 time 13413
2012-02-03 09:33:17,573<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:33:18,432<--1:info nodes 35936499 nps 2517266 time 14276
2012-02-03 09:33:18,436<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:33:19,372<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:33:20,168<--1:info nodes 40107125 nps 2504973 time 16011
2012-02-03 09:33:20,171<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:33:21,428<--1:info nodes 42995468 nps 2489316 time 17272
2012-02-03 09:33:21,435<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:33:23,663<--1:info nodes 48380352 nps 2480153 time 19507
2012-02-03 09:33:23,673<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:33:29,266<--1:info nodes 61745507 nps 2459000 time 25110
2012-02-03 09:33:29,274<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:33:45,863<--1:info nodes 103790532 nps 2488563 time 41707
2012-02-03 09:33:45,871<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:35:09,865<--1:info nodes 311958526 nps 2481592 time 125709
2012-02-03 09:35:09,873<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:37:04,225<--1:info nodes 586790930 nps 2444259 time 240069
2012-02-03 09:37:04,233<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:38:43,115<--1:info nodes 819781875 nps 2418535 time 338958
2012-02-03 09:38:43,122<--1:info currmove c3c4 currmovenumber 1
2012-02-03 09:38:59,351-->1:stop <= good info just after "stop" command.
2012-02-03 09:38:59,363<--1:info depth 34 seldepth 46 multipv 1 score cp 4661 nodes 859716647 nps 2420332 time 355206 pv c3c4 b5c4 e4e5 h2e5 b3c4 e5f6 g5f6 e8d7 g7f8 d7e6 f8g7 e6d7 g7f7 d7c6 f7e6 c6c5 f6f7 c5d4 e6d6
2012-02-03 09:38:59,377<--1:info nodes 859716647 nps 2420332 time 355206
2012-02-03 09:38:59,381<--1:bestmove c3c4 ponder b5c4


This is not about zugzwang, alpha-beta, ELO, ...

But can be solved, right?

I wonder how do you get this output?
Do you use console mode or do you use it under some gui

I do not get all the info depth info currmove when I use uci engines under some gui like Fritz gui.

When I use Stockfish under Fritz gui it shows very strange behaviour that no other engine shows under that interface.

from experience I can see that stockfish change his mind on move A at the time it considers move B in many cases and I guess that the reason is simply some bug that prevents stockfish to show the output at the time that stockfish changes its mind

I used stockfish at analysis mode and asked stockfish to print a log file
and stopped it after some minutes

The output under Fritz gui is the following


New game, 120'/40
4kr2/5pK1/3p1Q2/1p4P1/4P3/1PP5/7b/8 w - - 0 1

Analysis by Stockfish 2.2.2 JA:

+- (3.87) 1.g5-g6 00:00:02
+- (3.39) 1.c3-c4 Bh2-e5 00:00:07
-+ (-3.19) 1.Qf6-d8+ Ke8xd8 2.Kg7xf8 Bh2-f4 3.Kf8xf7 Bf4xg5 00:00:16
-+ (-3.19) 1.Qf6-d8+ Ke8xd8 2.Kg7xf8 Bh2-f4 3.Kf8xf7 Bf4xg5 00:00:16
-+ (-3.19) 1.Qf6-d8+ Ke8xd8 2.Kg7xf8 Bh2-f4 3.Kf8xf7 Bf4xg5 00:00:17
-+ (-3.03) 1.Qf6-d8+ Ke8xd8 2.Kg7xf8 Bh2-f4 3.Kf8xf7 Bf4xg5 4.Kf7-e6 00:00:17
-+ (-3.19) 1.Qf6-d8+ Ke8xd8 2.Kg7xf8 Bh2-f4 3.Kf8xf7 Bf4xg5 4.Kf7-e6 Bg5-f4 5.Ke6-d5 Kd8-d7 00:00:17
-+ (-3.39) 1.Qf6-d8+ Ke8xd8 2.Kg7xf8 Bh2-f4 3.Kf8xf7 Bf4xg5 4.Kf7-e6 Bg5-f4 5.Ke6-f5 Bf4-e5 6.Kf5-e6 Kd8-c7 00:00:17
-+ (-3.39) 1.Qf6-d8+ Ke8xd8 2.Kg7xf8 Bh2-f4 3.Kf8xf7 Bf4xg5 4.Kf7-e6 Bg5-f4 5.Ke6-d5 Kd8-d7 6.b3-b4 Bf4-e5 7.c3-c4 00:00:17
-+ (-3.27) 1.Qf6-d8+ Ke8xd8 2.Kg7xf8 Bh2-f4 3.Kf8xf7 Bf4xg5 4.Kf7-e6 Bg5-f4 5.Ke6-d5 Kd8-d7 6.b3-b4 Bf4-e5 7.c3-c4 b5xc4 8.Kd5xc4 Kd7-c6 9.b4-b5+ Kc6-b6 00:00:17
-+ (-3.27) 1.Qf6-d8+ Ke8xd8 2.Kg7xf8 Bh2-f4 3.Kf8xf7 Bf4xg5 4.Kf7-e6 Bg5-f4 5.Ke6-d5 Kd8-d7 6.b3-b4 Bf4-e5 7.c3-c4 b5xc4 8.Kd5xc4 Kd7-c6 9.b4-b5+ Kc6-b6 00:00:17
-+ (-3.63) 1.Qf6-d8+ Ke8xd8 2.Kg7xf8 Bh2-f4 3.Kf8xf7 Bf4xg5 4.Kf7-e6 Bg5-f4 5.Ke6-d5 Kd8-c7 6.c3-c4 b5xc4 7.Kd5xc4 Bf4-e5 8.Kc4-d5 Kc7-b6 9.Kd5-c4 Kb6-c6 00:00:17
-+ (-3.59) 1.Qf6-d8+ Ke8xd8 2.Kg7xf8 Bh2-f4 3.Kf8xf7 Bf4xg5 4.Kf7-e6 Bg5-f4 5.Ke6-d5 Kd8-c7 6.c3-c4 b5xc4 7.Kd5xc4 Kc7-c6 8.Kc4-b4 Bf4-e5 9.Kb4-c4 Kc6-b6 10.Kc4-b4 Be5-d4 11.Kb4-c4 00:00:17
-+ (-3.67) 1.Qf6-d8+ Ke8xd8 2.Kg7xf8 Bh2-f4 3.Kf8xf7 Bf4xg5 4.Kf7-e6 Bg5-f4 5.Ke6-d5 Kd8-c7 6.Kd5-d4 Bf4-e5+ 7.Kd4-d3 Kc7-d7 8.Kd3-d2 Kd7-c6 9.Kd2-d3 Kc6-c5 10.Kd3-d2 Kc5-b6 11.Kd2-d3 Kb6-c5 00:00:17
-+ (-3.75) 1.Qf6-d8+ Ke8xd8 2.Kg7xf8 Bh2-f4 3.Kf8xf7 Bf4xg5 4.Kf7-e6 Bg5-f4 5.Ke6-d5 Kd8-c7 6.c3-c4 b5xc4 7.Kd5xc4 Kc7-b6 8.Kc4-b4 Kb6-c6 9.Kb4-c4 Bf4-e5 10.Kc4-b4 Be5-h2 11.Kb4-c4 Bh2-e5 00:00:17
= (0.00) 1.Kg7-h7 Bh2-e5 2.Kh7-g7 Be5-h2 00:00:17
= (0.00) 1.Kg7-h7 Bh2-e5 2.Kh7-g7 Be5-h2 00:00:17
= (0.00) 1.Kg7-h7 Bh2-e5 2.Kh7-g7 Be5-h2 00:00:17
= (0.00) 1.Kg7-h7 Bh2-e5 2.Kh7-g7 Be5-h2 00:00:17
= (0.00) 1.Kg7-h7 Bh2-e5 2.Kh7-g7 Be5-h2 00:00:17
= (0.00) 1.Kg7-h7 Bh2-e5 2.Kh7-g7 Be5-h2 00:00:17
= (0.00) 1.Kg7-h7 Bh2-e5 2.Kh7-g7 Be5-h2 00:00:17
= (0.00) 1.Kg7-h7 Bh2-e5 2.Kh7-g7 Be5-h2 00:00:17
= (0.00) 1.Kg7-h7 Bh2-e5 2.Kh7-g7 Be5-h2 00:00:17
= (0.00) 1.Kg7-h7 Bh2-e5 2.Kh7-g7 Be5-h2 00:00:17
= (0.00) 1.Kg7-h7 Bh2-e5 2.Kh7-g7 Be5-h2 00:00:17
= (0.00) 1.Kg7-h7 Bh2-e5 2.Kh7-g7 Be5-h2 00:00:17
= (0.00) 1.Kg7-h7 Bh2-e5 2.Kh7-g7 Be5-h2 00:00:17
= (0.00) 1.Kg7-h7 Bh2-e5 2.Kh7-g7 Be5-h2 00:00:17
= (0.00) 1.Kg7-h7 Bh2-e5 2.Kh7-g7 Be5-h2 00:00:17
= (0.00) 1.Kg7-h7 Bh2-e5 2.Kh7-g7 Be5-h2 00:00:17
= (0.00) 1.Kg7-h7 Bh2-e5 2.Kh7-g7 Be5-h2 00:00:17
= (0.00) 1.Kg7-h7 Bh2-e5 2.Kh7-g7 Be5-h2 00:01:17
= (0.00) 1.Kg7-h7 Bh2-e5 2.Kh7-g7 Be5-h2 00:03:12

(, 03.02.2012)

The output in the logfile of stockfish is later at the bottom of this post and my question is why stockfish print into the logfile information that I do not see in Fritz gui
and why stockfish hide the best move that it suggest when I do not look at the output.

Note that other engines have no problem in analysis mode under Fritz gui and they show the best move that they suggest and it seems only stockfish does not want to share the best move that it has with Fritz GUI

Note that I used single thread and 128 mbytes hash so other should have no problem to reproduce the analysis and stockfish seems to be one of the most unfriendly engines because it does not show the best move that it found to the user under Fritz gui.

Searching: 4kr2/5pK1/3p1Q2/1p4P1/4P3/1PP5/7b/8 w - - 0 1
infinite: 1 ponder: 0 time: 0 increment: 0 moves to go: 0
1 +3.88 00:00 59 g6
2 +3.39 00:00 422 c4 Be5
3 -3.19 00:00 1725 Qd8+ Kxd8 Kxf8 Bf4 Kxf7 Bxg5
4 -3.19 00:00 1843 Qd8+ Kxd8 Kxf8 Bf4 Kxf7 Bxg5
5 -3.19 00:00 2073 Qd8+ Kxd8 Kxf8 Bf4 Kxf7 Bxg5
6 -3.03 00:00 2729 Qd8+ Kxd8 Kxf8 Bf4 Kxf7 Bxg5 Ke6
7 -3.19 00:00 3716 Qd8+ Kxd8 Kxf8 Bf4 Kxf7 Bxg5 Ke6 Bf4 Kd5 Kd7
8 -3.39 00:00 5088 Qd8+ Kxd8 Kxf8 Bf4 Kxf7 Bxg5 Ke6 Bf4 Kf5 Be5 Ke6 Kc7
9 -3.39 00:00 9402 Qd8+ Kxd8 Kxf8 Bf4 Kxf7 Bxg5 Ke6 Bf4 Kd5 Kd7 b4 Be5
c4
10 -3.27 00:00 22433 Qd8+ Kxd8 Kxf8 Bf4 Kxf7 Bxg5 Ke6 Bf4 Kd5 Kd7 b4 Be5
c4 bxc4 Kxc4 Kc6 b5+ Kb6
11 -3.27 00:00 26214 Qd8+ Kxd8 Kxf8 Bf4 Kxf7 Bxg5 Ke6 Bf4 Kd5 Kd7 b4 Be5
c4 bxc4 Kxc4 Kc6 b5+ Kb6
12 -3.64 00:00 41700 Qd8+ Kxd8 Kxf8 Bf4 Kxf7 Bxg5 Ke6 Bf4 Kd5 Kc7 c4 bxc4
Kxc4 Be5 Kd5 Kb6 Kc4 Kc6
13 -3.60 00:00 62376 Qd8+ Kxd8 Kxf8 Bf4 Kxf7 Bxg5 Ke6 Bf4 Kd5 Kc7 c4 bxc4
Kxc4 Kc6 Kb4 Be5 Kc4 Kb6 Kb4 Bd4 Kc4
14 -3.68 00:00 91244 Qd8+ Kxd8 Kxf8 Bf4 Kxf7 Bxg5 Ke6 Bf4 Kd5 Kc7 Kd4
Be5+ Kd3 Kd7 Kd2 Kc6 Kd3 Kc5 Kd2 Kb6 Kd3 Kc5
15 -3.76 00:00 125063 Qd8+ Kxd8 Kxf8 Bf4 Kxf7 Bxg5 Ke6 Bf4 Kd5 Kc7 c4 bxc4
Kxc4 Kb6 Kb4 Kc6 Kc4 Be5 Kb4 Bh2 Kc4 Be5
16 +0.00 00:00 223636 Kh7 Be5 Kg7 Bh2
17 +0.00 00:00 231200 Kh7 Be5 Kg7 Bh2
18 +0.00 00:00 246222 Kh7 Be5 Kg7 Bh2
19 +0.00 00:00 259447 Kh7 Be5 Kg7 Bh2
20 +0.00 00:00 276145 Kh7 Be5 Kg7 Bh2
21 +0.00 00:00 296952 Kh7 Be5 Kg7 Bh2
22 +0.00 00:00 319822 Kh7 Be5 Kg7 Bh2
23 +0.00 00:00 357308 Kh7 Be5 Kg7 Bh2
24 +0.00 00:00 396262 Kh7 Be5 Kg7 Bh2
25 +0.00 00:00 453802 Kh7 Be5 Kg7 Bh2
26 +0.00 00:00 519299 Kh7 Be5 Kg7 Bh2
27 +0.00 00:00 602411 Kh7 Be5 Kg7 Bh2
28 +0.00 00:01 717591 Kh7 Be5 Kg7 Bh2
29 +0.00 00:01 786609 Kh7 Be5 Kg7 Bh2
30 +0.00 00:01 929698 Kh7 Be5 Kg7 Bh2
31 +0.00 00:01 1129K Kh7 Be5 Kg7 Bh2
32 +0.00 00:01 1441K Kh7 Be5 Kg7 Bh2
33 +0.00 00:02 1857K Kh7 Be5 Kg7 Bh2
34 +0.00 00:03 2393K Kh7 Be5 Kg7 Bh2
35 +0.00 00:07 5468K Kh7 Be5 Kg7 Bh2
36 +0.00 03:30 170961K c4 bxc4 e5 Bxe5 bxc4 Bh2 c5 Be5 cxd6 Kd7
Nodes: 170961307
Nodes/second: 811627
Best move: c4
Ponder move: bxc4

[lech]

Becouse there is only one VALUE_DRAW, and two sides.

This is the main line of my " THEORY".
What does this mean?
If an item returns VALUE_DRAW it is very likely (repeated moves) that a lot of nodes return a bad value and move, they will have VALUE_DRAW as beta.
This is very wrong.
I used alpha = beta only for me to quickly confirm my guess.
I mean, I feel rather (it is better ) search.
Now, I doubt if there is anyone among you who feel it as well.

[Evert]

s mean?
If an item returns VALUE_DRAW it is very likely (repeated moves) that a lot of nodes return a bad value and move, they will have VALUE_DRAW as beta.
This is very wrong.

Why?
Once the position repeats (for the third time) the game ends and the node is a terminal node. The results is a draw. So what it says that the repeated move leads to a draw, which is correct.
If the current search bounds say that this is a good result (raises alpha), then it means that we currently expect our position to be worse. If it fails high (raises alpha >= beta) then it is the best option found so far. What we know at that point is that this line is at least a draw, but we don't have an exact score, only a lower bound. If we need an exact score (for a PV node) then the position will be researched with a wider window. Now, the draw score will not cause a cutoff and we can try to find something better (we may or may not).

Of course there is a problem if the evaluation scores a better position as worse, even marginally worse, because then the engine needlessly goes for a repetition. The correct fix is to improve the evaluation. A workaround is to set a contempt factor that makes the engine not accept the repetition until the evaluation is below a certain limit, so it doesn't go for the draw in positions that are only marginally worse (or where it still has some prospect of winning the game).

[lech]

Thanks Evert that you see a problem too and you didin't write that I am an idiot and must rethink somethink.

[BubbaTough]

humans distinguish between who is "forcing the draw" often in their thinking. The idea is, the forcer always has a draw in hand, but may try for more, while the drawEE is at the drawERs mercy. Thus, in most humans thinking not all draws (in the search) are equally scored. It is a useful concept for human-style analysis, but remarkably hard to encode in a chess program. The better the eval, the less it causes problems, but given evaluation functions can never be perfect its a problem that can not be completely addressed within the confines of the eval.

I played with a few things related to this a long time ago, but was never impressed with the results.

-Sam

[kbhearn]

disable null move and it should find the answer very quickly. The problem lies in lines like Kh6 Be5 Kg7 Bxf6 gxf6 +- where a) black might be evaluated as better by static eval (he is up a rook for a mere pawn, and passers are not readily evident) and b) null moves can continue to save the position. There is a null move verification search, but obviously it's not catching it all that quickly.

If you wanted to fix this specific position in the engine without weakening it too much you'd either need to work on the static eval to recognise the dead rook or make exceptions to the null move search - it currently has the requirement that the position must have nonpawn material for the side to move, you could try for instance changing that to having more than one piece for the side to move.