bug?

[Henk]

I think that there was a problem if first search failed low but when doing a research time was up and if search always returns a best move ...

[flok]

(thinking out loud)

Ah, OK. So the question is where the -110 score comes from in that iteration. If after "Qxa2 Rxa2 b5b4 null" a score of 110 is enough to make white's null move fail high, black must already have had a move that scored -110 for him, either as an alternative for b5b4 or Qxa2. For otherwise beta would still be at 160, and a score of 110 would not be a fail high, so that the null move would be ignored.

The -110 is the result of the aspiration window;

Code: Select all

++++START 0 15f0b8764a43cf81 r3k2r/p1p2p2/2n5/qp1Pp1pp/4P3/1QP1NPPb/P2B3P/R3K2R b KQkq - 0 18 -143/-93 
info depth 8 seldepth 25 score cp -135 time 1604 nodes 128832 pv c6e7 15f0b8764a43cf81 "r3k2r/p1p2p2/2n5/qp1Pp1pp/4P3/1QP1NPPb/P2B3P/R3K2R b KQkq - 0 18" 
++++START 0 15f0b8764a43cf81 r3k2r/p1p2p2/2n5/qp1Pp1pp/4P3/1QP1NPPb/P2B3P/R3K2R b KQkq - 0 18 -160/-110 
info depth 9 seldepth 27 score cp -110 time 2474 nodes 199764 pv c6e7 15f0b8764a43cf81 

The iteration for depth 8 starts with window -143...-93. The result of it is -135.
Iteration for depth 9 starts with window -160...-110.

So the question now is if I understood it correctly: iteration 9 with that -160...-110 window, why is there a move resulting in -110.

[Henk]

Maybe replace aspiration search with PVS and see if there are any bugs left over. Then you know if aspiration search is causing the bugs or not.

[flok]

I'd rather first understand why it currently fails.

[hgm]

The -110 is the result of the aspiration window;

Indeed, for the first d=9 search. There it is a fail high, of another move than Qxa2. Nothing strange there. But the problem is in the re-search you do, with window {-160, 10000}:

Code: Select all

++++START 0 15f0b8764a43cf81 r3k2r/p1p2p2/2n5/qp1Pp1pp/4P3/1QP1NPPb/P2B3P/R3K2R b KQkq - 0 18 -160/-110 
info depth 9 seldepth 27 score cp -110 time 2474 nodes 199764 pv c6e7 15f0b8764a43cf81 "r3k2r/p1p2p2/2n5/qp1Pp1pp/4P3/1QP1NPPb/P2B3P/R3K2R b KQkq - 0 18" 
++++START 0 15f0b8764a43cf81 r3k2r/p1p2p2/2n5/qp1Pp1pp/4P3/1QP1NPPb/P2B3P/R3K2R b KQkq - 0 18 -160/10000 
info depth 9 seldepth 28 score cp -110 time 3507 nodes 287066 pv a5a2 15f0b8764a43cf81 "r3k2r/p1p2p2/2n5/qp1Pp1pp/4P3/1QP1NPPb/P2B3P/R3K2R b KQkq - 0 18"

It is this search that gives you the Qxa2 blunder, so the problem is in that search. And that search also returns a score -110. But there it is an in-window score. So the question is, where did this score come from. It cannot be from the line Qxa2 Rxa2 b5b4 null ..., because null moves either fail low, in which case they are ignored, or they fail high, in which case the preceding move will be rejected. If a score of 110 (white POV) is enough to make the null move fail high, beta must be <= 110 at that point. But beta in the root was 160 (white POV). So there must have been a black move that raised the black alpha (which lowers the white beta) from -160 to -110, either on ply 1 or ply 3. Which move caused alpha to be raised from -160 to -110?

[flok]

Will look into tonight. This is a fascinating quest!

[flok]

The one upping -160 to -110 is the first move of that first depth 9 attempt:

Code: Select all

15f0b8764a43cf81, a -160 b -110 : r3k2r/p1p2p2/2n5/qp1Pp1pp/4P3/1QP1NPPb/P2B3P/R3K2R b KQkq - 0 18, black

That node starts with -160, -110.

The first move (c6-e7) it tries is bingo:

Code: Select all

trying c6-e7 3cf586c79cee9b23 -110 c6e7 9r3k2r/p1p1np2/8/qp1Pp1pp/4P3/1QP1NPPb/P2B3P/R3K2R b KQkq - 1 19

Code: Select all

info depth 9 seldepth 27 score cp -110 time 2432 nodes 199764 pv
c6e7/-110/search 15f0b8764a43cf81 "r3k2r/p1p2p2/2n5/qp1Pp1pp/4P3/1QP1NPPb/P2B3P/R3K2R b KQkq - 0 18"
c3c4/110/search 3cf586c79cee9b23 "r3k2r/p1p1np2/8/qp1Pp1pp/4P3/1QP1NPPb/P2B3P/R3K2R w KQkq - 1 19"
a5a4/-110/search 3ae7f2e982ef0378 "r3k2r/p1p1np2/8/qp1Pp1pp/2P1P3/1Q2NPPb/P2B3P/R3K2R b KQkq - 0 19"
b3a4/110/search d6dec693171db8ab "r3k2r/p1p1np2/8/1p1Pp1pp/q1P1P3/1Q2NPPb/P2B3P/R3K2R w KQkq - 1 20"
b5a4/-110/search ab12014f2581d757 "r3k2r/p1p1np2/8/1p1Pp1pp/Q1P1P3/4NPPb/P2B3P/R3K2R b KQkq - 0 20"
a1b1/110/search 7e70d2d4e2062ecc "r3k2r/p1p1np2/8/3Pp1pp/p1P1P3/4NPPb/P2B3P/R3K2R w KQkq - 0 21"
c7c6/-95/search 39ddf9b4aa0243b5 "r3k2r/p1p1np2/8/B2Pp1pp/p1P1P3/4NPPb/P6P/R3K2R b KQkq - 1 21"
d5c6/95/search 41c2b5dd22628635 "r3k2r/p3np2/2p5/B2Pp1pp/p1P1P3/4NPPb/P6P/R3K2R w KQkq - 0 22"

So at the node with hash 7e70d2d4e2062ecc and fen "r3k2r/p1p1np2/8/3Pp1pp/p1P1P3/4NPPb/P2B3P/R3K2R w KQkq - 0 21" move "a1-b1" gives score 110.

Checking that 7e70d node:

Code: Select all

...
move for 0x7e70d2d4e2062eccll/d2-a5: 95 (39ddf9b4aa0243b5)
move for 0x7e70d2d4e2062eccll/a1-b1: 110 (26824e7c75801bfb)
move for 0x7e70d2d4e2062eccll/a1-c1: 60 (b75512e7102cfbdf)
...
7e70d2d4e2062ecc ret with: 110 a1b1 4   r3k2r/p1p1np2/8/3Pp1pp/p1P1P3/4NPPb/P2B3P/R3K2R w KQkq - 0 21           

Digging further, the a1b1 move is caused by a null move in 26824e7c75801bfb.
The null move is called with (110, 111).

[hgm]

Well, if c6-e7 increased alpha to -110 (which is reasonable) then it becomes best move at that point. If Qxa2 later scores also -110 it is a fail low, and thus an upper bound only. (And indeed its true score should be somewhere around -900.) It should never have been able to replace c6-e7 as best move in the root,and get played.

[flok]

Well, if c6-e7 increased alpha to -110 (which is reasonable) then it becomes best move at that point. If Qxa2 later scores also -110 it is a fail low, and thus an upper bound only. (And indeed its true score should be somewhere around -900.) It should never have been able to replace c6-e7 as best move in the root,and get played.

So the root, the code around search() should only update the score if new_score > alpha?

[Evert]

Well, if c6-e7 increased alpha to -110 (which is reasonable) then it becomes best move at that point. If Qxa2 later scores also -110 it is a fail low, and thus an upper bound only. (And indeed its true score should be somewhere around -900.) It should never have been able to replace c6-e7 as best move in the root,and get played.

So the root, the code around search() should only update the score if new_score > alpha?

The score at the root is the score for the best move. This should be an exact score, not a bound.

So it depends a bit on how your search is ordered. If you don't iterate over root moves in your root search, then the result of search() is just the score for the node. If that is not within bounds, you need to research with a wider window.