Body: <p>After going through a long list of test positions for my chess engine, I found this simple mate in 2 puzzle that my engine failed to see even after searching to a depth of 16 ply. I checked the puzzle with Stockfish and Stockfish also failed, playing the move Kxa2, stalemating black. This was the same move my engine played, and Stockfish continued to recommend it even until reaching high depths when it finally saw the correct move, 1. Ba3, after which 1. ...Kxf6 is forced and met with 2. Bb2#.</p>
  <p>Anyway, here's the position (white to move):</p>
  <pre><code>[FEN &quot;n1N3br/2p1Bpkr/1pP2R1b/pP3Pp1/P5P1/1P1p4/p2P4/K7 w - - 0 1&quot;]
  </code></pre>
  <p>After testing various changes to find the cause of the bug, I found that disabling null-move pruning fixed the issue, at least for my chess engine. This makes sense since the engine probably tries 1. Ba3 Kxf6 and black can stand pat while being up lots of material, despite white's forced mate with black being in zugzwang.</p>
  <p>My question is if null-move pruning is actually the cause in other engines and if not, what am I doing wrong and how should I fix it? Additionally, is it even a good idea to tune a chess engine based on ultra-specific composed positions like this?</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-04-09T18:36:40.533Z
Comments.Text: I guess you could just run engine without null-move pruning for some amount of time, and then switch back to regular engine configuration for the majority of the analysis time.
Comments.UserDisplayName: Mateen Ulhaq
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-04-09T22:38:25.600Z
Comments.Text: I tried four engines, three found it, including stockfish 16.1.
Comments.UserDisplayName: Brad Lanam
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-04-10T02:32:31.073Z
Comments.Text: @BradLanam just out of curiosity what engines did you try and what depth did they find it at?
Comments.UserDisplayName: Stockfischer
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-04-11T04:13:58.787Z
Comments.Text: Now can they find the full mate in 6 from the starting position of this Giegold problem?  https://www.chessbase.in/news/Problems-of-Fritz-Emil-Giegold
Comments.UserDisplayName: Noam D. Elkies
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-04-11T15:43:04.910Z
Comments.Text: Without null move pruning, yes, but the colossal increase in searched nodes for most positions doesn't justify it.
Comments.UserDisplayName: Hank's back rank
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-04-11T15:45:18.790Z
Comments.Text: On my laptop (with a good GPU), LC0 finds the mate in two at a depth of 2, in 3.41s. SF16.1(CPU only) needs a depth of 32 to find it, but in 0.01s !! Comparing the engines at a given depth may provide stange results. Also, I don't know what happens at Windows level when the GPU is waked up after a period of inactivity ...
Comments.UserDisplayName: Damien
Tags: <engines>
Title: Chess engines missing mate in 2
ThreadText: # Chess engines missing mate in 2
  
  (Asked by: username_0 on 2024-04-08)
  
  After going through a long list of test positions for my chess engine, I found this simple mate in 2 puzzle that my engine failed to see even after searching to a depth of 16 ply. I checked the puzzle with Stockfish and Stockfish also failed, playing the move Kxa2, stalemating black. This was the same move my engine played, and Stockfish continued to recommend it even until reaching high depths when it finally saw the correct move, 1. Ba3, after which 1. ...Kxf6 is forced and met with 2. Bb2#.
  
  Anyway, here's the position (white to move):
  
  ```
  [FEN "n1N3br/2p1Bpkr/1pP2R1b/pP3Pp1/P5P1/1P1p4/p2P4/K7 w - - 0 1"]
  
  ```
  
  After testing various changes to find the cause of the bug, I found that disabling null-move pruning fixed the issue, at least for my chess engine. This makes sense since the engine probably tries 1. Ba3 Kxf6 and black can stand pat while being up lots of material, despite white's forced mate with black being in zugzwang.
  
  My question is if null-move pruning is actually the cause in other engines and if not, what am I doing wrong and how should I fix it? Additionally, is it even a good idea to tune a chess engine based on ultra-specific composed positions like this?
  
  **Tags:** engines
  
  > **Comments:**
  > **username_1**: I guess you could just run engine without null-move pruning for some amount of time, and then switch back to regular engine configuration for the majority of the analysis time.  
  > **username_2**: I tried four engines, three found it, including stockfish 16.1.  
  > **username_3**: @username_2 just out of curiosity what engines did you try and what depth did they find it at?  
  > **username_4**: Now can they find the full mate in 6 from the starting position of this Giegold problem?  https://www.chessbase.in/news/Problems-of-Fritz-Emil-Giegold  
  > **username_0**: Without null move pruning, yes, but the colossal increase in searched nodes for most positions doesn't justify it.  
  > **username_5**: On my laptop (with a good GPU), LC0 finds the mate in two at a depth of 2, in 3.41s. SF16.1(CPU only) needs a depth of 32 to find it, but in 0.01s !! Comparing the engines at a given depth may provide stange results. Also, I don't know what happens at Windows level when the GPU is waked up after a period of inactivity ...  
  
  ---
  
  ## 0 answers
  
  