Early return in PDF but fall-through in code for score

[dlbbld]

For the score calculation the specification uses early return (page 22):

6: if m is a promotion to a Q or R then return Punish 7: else if m is a pawn move then return Reward 8: if Going-to-corner(pos, m, Lose) then return Reward 9: if m is a capture then return Punish

The code uses fall-through:

if (needLoserPromotion) {
    PieceType promoted = promotion_type(m);  // Possibly NO_PIECE_TYPE
    bool heavyProm = (promoted == QUEEN || promoted == ROOK);
    variation = (movedPiece == PAWN && !heavyProm) ? REWARD : PUNISH;
  }

  if (going_to_square(m, target, movedPiece, false))
    variation = REWARD;

  if (pos.capture(m))
    variation = PUNISH;
}

This results in different variation calculations. For example for a pawn non-promotion capturing move, the PDF will return REWARD.

The code first assigns REWARD, but then falls through and assigns PUNISH in the last step.

What is now the better way to go, the PDF or the code?

[miguel-ambrona]

After a comparison (now that we have test-vectors and benchmarks), it seems both versions give very similar results. The PDF one seems to behave slightly better on exotic positions and slightly worse (really not much) on Lichess game positions. Consequently, I lean towards using the PDF version and I made the C++ version mimic the PDF description in commit 8f0f259f013a72319c83de2439571eddf6adf0dd.