* Grab bag of eval.c changes.

* Don't bother not hashing when moves are pruned.
* Prune moves move librerally with LMP.

Inexplicably, this is slightly shallower than HEAD (despite pruning
MORE).  It may be because it is slightly slower.

It consistently beats HEAD in match_play.py though (3x now).

1 files changed, 0 insertions, 53 deletions

diff --git a/src/chess.h b/src/chess.h
index fc2ef85..c66dbc0 100755
--- a/src/chess.h
+++ b/src/chess.h
@@ -1202,56 +1202,6 @@ typedef struct _COUNTERS
         UINT64 u64TooDeepPlyLimit;
         UINT64 u64TooDeepQsearchExtendLimit;
         UINT64 u64LeafCount;
-        // How often a node's actual outcome contradicts its assumed
-        // NODE_TYPE (chess.h) -- a real, if imperfect, sanity check on
-        // the classic PVS node typing. Counted at every Search()/
-        // QSearch() exit, using the window it was actually asked to
-        // search (iAlpha/iBeta at that point, not whatever the initial
-        // caller-supplied window was, since mate-distance pruning can
-        // narrow it before this node's own outcome is known). Some
-        // "surprises" (e.g. an immediate hash-table cutoff) are
-        // legitimate and expected, not actual instability, so these
-        // counts are a rough signal, not a bug indicator by themselves.
-        // 2026-10-03: denominators for the "node-type surprises" line
-        // (root.c). Incremented in CommonSearchInit right where
-        // eNodeType is assigned, so they count EVERY node that got a
-        // type -- which includes QSEARCH nodes, because
-        // CommonSearchInit is the single funnel both Search() and
-        // QSearch() pass through. That matters for reading the
-        // percentages: see root.c's comment on why an "ALL node failed
-        // high" rate near 100% is routine rather than alarming.
-        UINT64 u64NodeTypeCount[3];
-        // 2026-10-03: the qsearch half of the same accounting. QSearch's
-        // copy of the surprise counters was removed so the full-width
-        // rates would stop being dominated by stand-pat cutoffs -- but
-        // that broke a real cross-check, because the PVS identity it
-        // should satisfy spans BOTH populations:
-        //
-        //   a CUT node failing low returns score <= alpha_C, so its
-        //   parent P (an ALL node) sees -score_C >= beta_P and fails
-        //   HIGH. P cannot have had an earlier child fail low -- it
-        //   would have cut off and never reached C. So #(CUT fails low)
-        //   and #(ALL fails high) should run ~1:1.
-        //
-        // With qsearch dropped the identity read 3.6:1 (25,097 ALL-FH
-        // vs 7,009 CUT-FL), because an ALL node at remaining depth 1
-        // takes its fail-high from a QSEARCH child failing low, and
-        // that child was counted nowhere. The same artifact shows in
-        // the raw counts: 36,306 ALL vs 57,813 CUT nodes -- fewer ALL
-        // than CUT, impossible when every ALL node is a CUT node's
-        // child.
-        //
-        // So count qsearch separately rather than not at all. Ignore
-        // these for the full-width rates; add them in to check the
-        // identity. Residual imbalance after that is real signal:
-        // recognizer/EGTB fail-highs and null-move cutoffs resolve a
-        // node with no child searched at all. NODE_TYPE itself is
-        // untouched -- these are counter slots, not a new node type.
-        UINT64 u64QNodeTypeCount[3];
-        UINT64 u64QNodeSurprise[3];
-        UINT64 u64PVNodeSurprised;        // PV node failed high or low
-        UINT64 u64AllNodeFailedHigh;      // ALL node (expected fail-low) failed high
-        UINT64 u64CutNodeFailedLow;       // CUT node (expected fail-high) failed low
         UINT64 u64TerminalPositionCount;
         UINT64 u64BetaCutoffs;
         UINT64 u64BetaCutoffsOnFirstMove;
@@ -3937,9 +3887,6 @@ FLAG
 TestSearch(void);
 
 FLAG
-TestSearchHashConsistency(void);
-
-FLAG
 TestQSearchSanity(void);
 
 //