For Marco---possible Stockfish bug

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

zullil
Posts: 6442
Joined: Tue Jan 09, 2007 12:31 am
Location: PA USA
Full name: Louis Zulli

For Marco---possible Stockfish bug

Post by zullil »

Just posting here to call attention to a post that might be otherwise missed:

http://www.talkchess.com/forum/viewtopi ... 99&t=42042
mcostalba
Posts: 2684
Joined: Sat Jun 14, 2008 9:17 pm

Re: For Marco---possible Stockfish bug

Post by mcostalba »

zullil wrote:Just posting here to call attention to a post that might be otherwise missed:

http://www.talkchess.com/forum/viewtopi ... 99&t=42042
Thanks Louis, I will look at this....
zamar
Posts: 613
Joined: Sun Jan 18, 2009 7:03 am

Re: For Marco---possible Stockfish bug

Post by zamar »

Maybe, I found the reason (bug in search ?). Very Happy
Why "We want always alpha < beta " ? Confused
Why in PV it is impossible: alpha = beta ?
It seems be important if e.g. value == VALUE_DRAW.
I changed it (added one sign to Stockfish 2.1.1) and now Stockfish found solution.
The reason for this are SMP-issues. If we update alpha := beta in split point and immediately after that another thread starts searching new move with (-beta, -alpha) unpredictable things can happen.

Instead we update only bestValue and make use of it (at least this was and should still be the case).
Joona Kiiski
lech
Posts: 1136
Joined: Sun Feb 14, 2010 10:02 pm

Re: For Marco---possible Stockfish bug

Post by lech »

zamar wrote: .. unpredictable things can happen.
In each case, it seems to be a bug, if Stockfish is not able to solve this simple zugzwang position at all:
[d] 4kr2/5p1K/3p1Q2/1p4P1/4P3/1PP5/7b/8 w - -
1.Kh6 Be5 2.Kg7 Bh2 3.c4 bxc4 4.e5 Bxe5 5.bxc4 +-

And my theory can be correct.
zamar
Posts: 613
Joined: Sun Jan 18, 2009 7:03 am

Re: For Marco---possible Stockfish bug

Post by zamar »

lech wrote:And my theory can be correct.
Any theory can be correct. Theories must be proven or at least some strong indication must be presented so that they can be taken seriously.

In this case this means that one should present a realistic scenario where current code doesn't work as expected.
Joona Kiiski
zullil
Posts: 6442
Joined: Tue Jan 09, 2007 12:31 am
Location: PA USA
Full name: Louis Zulli

Re: For Marco---possible Stockfish bug

Post by zullil »

I think Marek's point is that with current code Stockfish cannot solve

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

but with his modification---which he would need to explain---it can.

Of course, he also needs to explain why his modification won't have negative effects in other situations.
lech
Posts: 1136
Joined: Sun Feb 14, 2010 10:02 pm

Re: For Marco---possible Stockfish bug

Post by lech »

I changed (in Stockfish 2.1.1)

Code: Select all


 if (!Root && value > alpha&#41;
          &#123;
              if &#40;PvNode && value < beta&#41; // We want always alpha < beta
&#123;
                  alpha = value;

to:

Code: Select all


 if (!Root && value > alpha&#41;
          &#123;
              if &#40;PvNode && value <= beta&#41; // We want always alpha < beta
&#123;
                  alpha = value;

And now Stockfish can solve this position.
My theory has the position, which should be solved by Stockfish.
8th point in search give a right to watch the solution.
My theory says, that in pvnode it would be good to accept alpha = beta.
I changed the code (above) and Stockfish solved this position.
I think it is a very interesting theme for programmers.
mcostalba
Posts: 2684
Joined: Sat Jun 14, 2008 9:17 pm

Re: For Marco---possible Stockfish bug

Post by mcostalba »

lech wrote: I think it is a very interesting theme for programmers.
yes it is, although it is very difficult to understand all the implications: changes like this are really tricky and can fail in extremely subtle and unexpected way.

The first thing to do is to run in debug mode with asserts on and see what happens.

If we have no asserts than we proceed to step 2 that is the real games testing.
zamar
Posts: 613
Joined: Sun Jan 18, 2009 7:03 am

Re: For Marco---possible Stockfish bug

Post by zamar »

lech wrote:I changed (in Stockfish 2.1.1)

Code: Select all


 if (!Root && value > alpha&#41;
          &#123;
              if &#40;PvNode && value < beta&#41; // We want always alpha < beta
&#123;
                  alpha = value;

to:

Code: Select all


 if (!Root && value > alpha&#41;
          &#123;
              if &#40;PvNode && value <= beta&#41; // We want always alpha < beta
&#123;
                  alpha = value;

And now Stockfish can solve this position.
My theory has the position, which should be solved by Stockfish.
8th point in search give a right to watch the solution.
My theory says, that in pvnode it would be good to accept alpha = beta.
I changed the code (above) and Stockfish solved this position.
I think it is a very interesting theme for programmers.
The problem is that modern chess engines are very chaotic process. Changing one piece-square table value by one unit could as well make SF to solve the position.

By making to SF to solve one specific position, one can justify almost any change. What we need is a logical reasoning: why do you think that algorithmically it's better to allow alpha := beta. Give one (hypothetic) example situation where this could make positive difference.
Joona Kiiski
Joerg Oster
Posts: 937
Joined: Fri Mar 10, 2006 4:29 pm
Location: Germany

Re: For Marco---possible Stockfish bug

Post by Joerg Oster »

Hmm, my Stockfish 2.2.2 can solve this one.

Code: Select all

info depth 37 seldepth 45 score cp 7 lowerbound nodes 105904119 nps 7105274 time 14905 multipv 1 pv h7h6 h2e5 h6g7 e5g3 c3c4 b5c4 e4e5 g3e5 b3c4 e5f6 g5f6 d6d5 c4d5
info depth 37 currmove h7h6 currmovenumber 1
info depth 37 seldepth 46 score cp 15 lowerbound nodes 106588199 nps 6978407 time 15274 multipv 1 pv h7h6 h2e5 h6g7 e5g3 c3c4 b5c4 e4e5 g3e5 b3c4 e5f6 g5f6 d6d5 c4d5
info depth 37 currmove h7h6 currmovenumber 1
info depth 37 seldepth 49 score cp 26 lowerbound nodes 107664649 nps 6801734 time 15829 multipv 1 pv h7h6 h2e5 h6g7 e5g3 c3c4 b5c4 e4e5 g3e5 b3c4 e5f6 g5f6 d6d5 c4d5
info depth 37 currmove h7h6 currmovenumber 1
info depth 37 seldepth 49 score cp 43 lowerbound nodes 108597029 nps 6657901 time 16311 multipv 1 pv h7h6 h2e5 h6g7 e5g3 c3c4 b5c4 e4e5 g3e5 b3c4 e5f6 g5f6 d6d5 c4d5
info depth 37 currmove h7h6 currmovenumber 1
info depth 37 seldepth 49 score cp 68 lowerbound nodes 109584437 nps 6529101 time 16784 multipv 1 pv h7h6 h2e5 h6g7 e5g3 c3c4 b5c4 e4e5 g3e5 b3c4 e5f6 g5f6 d6d5 c4d5
info depth 37 currmove h7h6 currmovenumber 1
info depth 37 seldepth 49 score cp 107 lowerbound nodes 110526895 nps 6456764 time 17118 multipv 1 pv h7h6 h2e5 h6g7 e5g3 c3c4 b5c4 e4e5 g3e5 b3c4 e5f6 g5f6 d6d5 c4d5
info depth 37 currmove h7h6 currmovenumber 1
info depth 37 seldepth 52 score cp 164 lowerbound nodes 112962749 nps 6322070 time 17868 multipv 1 pv h7h6 h2e5 h6g7 e5g3 c3c4 b5c4 e4e5 g3e5 b3c4 e5f6 g5f6 d6d5 c4d5
info depth 37 currmove h7h6 currmovenumber 1
info depth 37 seldepth 52 score cp 249 lowerbound nodes 117600036 nps 6271667 time 18751 multipv 1 pv h7h6 h2e5 h6g7 e5g3 c3c4 b5c4 e4e5 g3e5 b3c4 e5f6 g5f6 d6d5 c4d5
info depth 37 currmove h7h6 currmovenumber 1
info depth 37 seldepth 52 score cp 377 lowerbound nodes 181320601 nps 6324843 time 28668 multipv 1 pv h7h6 f8g8 h6h5 h2e5 f6f1 e5c3 f1b5 e8e7 b5b7 e7e6 b7c6 c3e5 c6d5 e6e7 d5b7 e7e6 b3b4 g8h8 h5g4 h8h2 b7c8 e6e7 g4f3 h2b2 c8b7 e7f8 b4b5 f8g7 b5b6 e5d4 b7d5 d4b6 d5d6 b2b3 f3g4
In console mode, under Linux 64bit.
Jörg Oster