Answers.Body: <p>Static eval does not work when one player is in check. This is normal. Remember what static eval is - it's supposed to return the evaluation on that position <em>without searching</em>. But once a player is in check, you need to search, or there's no way to tell what the evaluation should be.</p>
  <p>I'm not sure how you got those results for SF10, but I suspect there's something wrong because all the terms are 0.00 even though the total evaluation is not.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-04-08T20:01:45.933Z
Answers.Text: Can you please elaborate on what needs to be 'searched' and why checks trigger that 'search'?
  As per https://www.dailychess.com/rival/programming/evaluation.php, static evaluation is done for both sides. There's no mentioning there that position must not be in check: 
  `The static evaluation function returns a score for the side to move from the given position. A score is calculated for both sides and the function returns the score for the side on the move minus the score for the side not on the move.`
  
  Executables for SF10 can be found here: https://github.com/senyast4745/Stockfish-Java
Answers.UserDisplayName: tim bits
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-04-09T06:29:07.860Z
Answers.Text: @Lumachado It's actually hinted at in that link: "The evaluation function does not detect checkmate." Why can't the evaluation function detect checkmate? Because you need to search the game tree to see that there are no moves the losing side can make.
Answers.UserDisplayName: Allure
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-04-07T07:06:33.613Z
Answers.LastActivityDate: 2024-04-07T07:06:33.613Z
Answers.UserDisplayName: Allure
Body: <p>When feeding a position in checkmate into SF16, not only it won't evaluate it as checkmated, it won't evaluate it at all:</p>
  <pre><code>position fen 3q4/6b1/4k3/4r3/3p2Q1/B1N1R3/5R2/6K1 b
  eval
  info string NNUE evaluation using nn-baff1ede1f90.nnue
  info string NNUE evaluation using nn-b1a57edbea57.nnue
  
  Final evaluation: none (in check) 
  </code></pre>
  <p>And it won't evaluate positions in check either:</p>
  <pre><code>position fen 8/8/8/8/8/8/8/5KRk b - - 0 1
  eval
  info string NNUE evaluation using nn-baff1ede1f90.nnue
  info string NNUE evaluation using nn-b1a57edbea57.nnue
  
  Final evaluation: none (in check)
  </code></pre>
  <p>Sf10, on the other hand, would happily evaluate such positions:</p>
  <pre><code>position fen 3q4/6b1/4k3/4r3/3p2Q1/B1N1R3/5R2/6K1 b
  eval
       Term    |    White    |    Black    |    Total
               |   MG    EG  |   MG    EG  |   MG    EG
   ------------+-------------+-------------+------------
      Material |  ----  ---- |  ----  ---- |  0.00  0.00
     Imbalance |  ----  ---- |  ----  ---- |  0.00  0.00
    Initiative |  ----  ---- |  ----  ---- |  0.00  0.00
         Pawns |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
       Knights |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
       Bishops |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
         Rooks |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
        Queens |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
      Mobility |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
   King safety |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
       Threats |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
        Passed |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
         Space |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
   ------------+-------------+-------------+------------
         Total |  ----  ---- |  ----  ---- |  0.00  0.00
  
  Total evaluation: 9.53 (white side)
  
  
  position fen 8/8/8/8/8/8/8/5KRk b - - 0 1
  eval
       Term    |    White    |    Black    |    Total
               |   MG    EG  |   MG    EG  |   MG    EG
   ------------+-------------+-------------+------------
      Material |  ----  ---- |  ----  ---- |  0.00  0.00
     Imbalance |  ----  ---- |  ----  ---- |  0.00  0.00
    Initiative |  ----  ---- |  ----  ---- |  0.00  0.00
         Pawns |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
       Knights |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
       Bishops |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
         Rooks |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
        Queens |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
      Mobility |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
   King safety |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
       Threats |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
        Passed |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
         Space |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
   ------------+-------------+-------------+------------
         Total |  ----  ---- |  ----  ---- |  0.00  0.00
  
  Total evaluation: 55.24 (white side)
  </code></pre>
  <p>Wondering why the eval behavior changed so drastically? And is this a bug or a feature?</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-04-06T13:37:53.873Z
Comments.Text: Maybe it thinks you're asking for an evaluation of an (illegal) position where the side _giving_ check is to move.  I see the "b" indicating BTM but it might not be the right format for this engine (in which case the default may be WTM).  Try it with colors reversed.
Comments.UserDisplayName: Noam D. Elkies
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-04-06T18:20:13.883Z
Comments.Text: Thank you for your insight.
  Apparently, it does evaluate both positions with reversed colors. Although I don't think that the correct behavior because the side which is in check should have the right to move, not the other way around. Additionally, this creates a problem with further use of such positions. E.g. if after eval, you want to ask for the best move, but the best move will be given for the side which has already made a move and thereby checked (or checkmated) the other side. So  effectively the position has to be reloaded with the correct colors to ask the best move for correct side
Comments.UserDisplayName: tim bits
Tags: <stockfish>
Title: Why Stockfish 16 won't evaluate positions in check or checkmate?
ThreadText: # Why Stockfish 16 won't evaluate positions in check or checkmate?
  
  (Asked by: username_0 on 2024-04-06)
  
  When feeding a position in checkmate into SF16, not only it won't evaluate it as checkmated, it won't evaluate it at all:
  
  ```
  position fen 3q4/6b1/4k3/4r3/3p2Q1/B1N1R3/5R2/6K1 b
  eval
  info string NNUE evaluation using nn-baff1ede1f90.nnue
  info string NNUE evaluation using nn-b1a57edbea57.nnue
  
  Final evaluation: none (in check) 
  
  ```
  
  And it won't evaluate positions in check either:
  
  ```
  position fen 8/8/8/8/8/8/8/5KRk b - - 0 1
  eval
  info string NNUE evaluation using nn-baff1ede1f90.nnue
  info string NNUE evaluation using nn-b1a57edbea57.nnue
  
  Final evaluation: none (in check)
  
  ```
  
  Sf10, on the other hand, would happily evaluate such positions:
  
  ```
  position fen 3q4/6b1/4k3/4r3/3p2Q1/B1N1R3/5R2/6K1 b
  eval
       Term    |    White    |    Black    |    Total
               |   MG    EG  |   MG    EG  |   MG    EG
   ------------+-------------+-------------+------------
      Material |  ----  ---- |  ----  ---- |  0.00  0.00
     Imbalance |  ----  ---- |  ----  ---- |  0.00  0.00
    Initiative |  ----  ---- |  ----  ---- |  0.00  0.00
         Pawns |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
       Knights |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
       Bishops |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
         Rooks |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
        Queens |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
      Mobility |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
   King safety |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
       Threats |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
        Passed |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
         Space |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
   ------------+-------------+-------------+------------
         Total |  ----  ---- |  ----  ---- |  0.00  0.00
  
  Total evaluation: 9.53 (white side)
  
  position fen 8/8/8/8/8/8/8/5KRk b - - 0 1
  eval
       Term    |    White    |    Black    |    Total
               |   MG    EG  |   MG    EG  |   MG    EG
   ------------+-------------+-------------+------------
      Material |  ----  ---- |  ----  ---- |  0.00  0.00
     Imbalance |  ----  ---- |  ----  ---- |  0.00  0.00
    Initiative |  ----  ---- |  ----  ---- |  0.00  0.00
         Pawns |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
       Knights |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
       Bishops |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
         Rooks |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
        Queens |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
      Mobility |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
   King safety |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
       Threats |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
        Passed |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
         Space |  0.00  0.00 |  0.00  0.00 |  0.00  0.00
   ------------+-------------+-------------+------------
         Total |  ----  ---- |  ----  ---- |  0.00  0.00
  
  Total evaluation: 55.24 (white side)
  
  ```
  
  Wondering why the eval behavior changed so drastically? And is this a bug or a feature?
  
  **Tags:** stockfish
  
  > **Comments:**
  > **username_1**: Maybe it thinks you're asking for an evaluation of an (illegal) position where the side _giving_ check is to move.  I see the "b" indicating BTM but it might not be the right format for this engine (in which case the default may be WTM).  Try it with colors reversed.  
  > **username_0**: Thank you for your insight. Apparently, it does evaluate both positions with reversed colors. Although I don't think that the correct behavior because the side which is in check should have the right to move, not the other way around. Additionally, this creates a problem with further use of such positions. E.g. if after eval, you want to ask for the best move, but the best move will be given for the side which has already made a move and thereby checked (or checkmated) the other side. So  effectively the position has to be reloaded with the correct colors to ask the best move for correct side  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2024-04-07. Score: 2
  
  Static eval does not work when one player is in check. This is normal. Remember what static eval is - it's supposed to return the evaluation on that position *without searching*. But once a player is in check, you need to search, or there's no way to tell what the evaluation should be.
  
  I'm not sure how you got those results for SF10, but I suspect there's something wrong because all the terms are 0.00 even though the total evaluation is not.
  
  > **Comments:**
  > **username_0**: Can you please elaborate on what needs to be 'searched' and why checks trigger that 'search'? As per https://www.dailychess.com/rival/programming/evaluation.php, static evaluation is done for both sides. There's no mentioning there that position must not be in check:  `The static evaluation function returns a score for the side to move from the given position. A score is calculated for both sides and the function returns the score for the side on the move minus the score for the side not on the move.`  Executables for SF10 can be found here: https://github.com/senyast4745/Stockfish-Java  
  > **username_2**: @Lumachado It's actually hinted at in that link: "The evaluation function does not detect checkmate." Why can't the evaluation function detect checkmate? Because you need to search the game tree to see that there are no moves the losing side can make.  
  
  ---
  
  