🚀 go-pugleaf

I've been looking at gnuchess 5 sort.c

It uses "history" to help sort moves. Certainly at blitz it is not clear
to me this is helping.



Similarly the section 5 uses the (minus) taxicab distance from E4 as a
sort criteria.

Should this not be the "taxicab distance of 'from' square from E4" minus
"taxicab distant of 'to' square from E4"?

Otherwise it would sort "Nb1c3" and "Nd5c3" equally -- when one
centralises and one decentralises?!



Cutting history and adding the "from square" seems to give a small
advantage at short time scales, but I'd like to know why this history
mechanism went in, or who knows why only the "to" square was included.

I wonder if my gains at short timescales from cutting history would be
lost at later timescales? Also I'm finding cutting anything seems to
give performance benefits, which I suspect are due to better use of the
CPU cache - so other peoples results may vary depending on processor.

Similarly I find cutting the ChkCnt code from search.c and related areas
(Extending the search for any check - not just where the ChkCnt[ply} is
low enough) seems to help. But again I wonder if this is just blitz
speed gains.

BTW these gains are very minor - less than 5% on nps - so hard to
measure accurately.

Other ideas for sorting moves welcome. I was thinking of trying to put
pawn advances that threaten something on the list - but I'm still
working on the test - it'll probably just encourage more a3 and h3 pawn
moves to kick the bishop.

	Simon