this is something that really makes me go mad !
Me too:). Magical prunings :).
I think there's a great opportunity for improving modern engines in combining
(1) such history based prunings
(2) cut/all approach from ippolit
Any tactical threat, even if a refutation is available, is likely to ...

Recently I ran several tests of Stockfish's history pruning (futility_move_count). It appears that this feature makes the engine perform better at fixed depth controls. However when the prunings are turned off the engine reaches the same depth a bit faster. There are also some reasons to believe ...

And if you really want to play it safe, this can be further enhanced. In my experiments (with Critter, IPPO* behavior may be different - YMMV) I tried to restrict this cut-off with several other conditions:
a) no pawns at 7th rank
b) no queen capture is possible
c) no mate threat (in IPPO ...

Don't forget the opponent's king. If opponent's king is on a square in front of our passed pawn, this pawn should be off the race.
In recent implementation you only add +1 to blockerCount in that case, which is wrong.


I have added this to better document the code:


// Pawn is passed and ...

In evaluate_unstoppable_pawns(...) within the first while loop you do not check for enemy pieces blocking a square in front of a passed pawn. In that case you should "give up" on that pawn. There might be more to fix or make better in that function. Passed pawn detection is very ELO critical. So it ...

There might still be room to earn some ELO points by only fixing bugs. For example in evaluate.c, evaluate_passed_pawns(..), line 831


Thanks ! Here is the proposed patch.


Subject: Fix bug in evaluate_passed_pawns()

If blockSq is already on rank 8, blockSq + pawn_push(Us) is on rank 9 ...

i.e. If your testing techniques are superior, and perhaps empirical....then why is StockFish not as strong than the rest of the field?

Because we are not able to come up with winning ideas: we test a lot, but for the most part candidate changes result in no ELO change or even in a weaker engine ...

I'm convinced that it doesn't actually add any ELO benefit however...
but it makes sense and I couldn't help but add it.

IMHO if it doesn't add any ELO then it doesn't make sense at all to add it.

Anyhow your sentence is interesting because with few words you perfectly synthesize what IMHO is ...

If I read your patch correctly it seems there is no functional change here, just an extra update to the GUI in case of fail low. Is it correct ?

The result is that the fail-high/fail-low move will still be played if search stops soon enough.
If I understand correctly this can happen in games. So if current SF tests better than playing these moves, maybe reversing these steps will test better than current SF.


If it is possible I would ...