Eliminate ONE_PLY
authorBrian Sheppard <brian.sheppard@toasttab.com>
Sat, 28 Sep 2019 20:27:23 +0000 (16:27 -0400)
committerStéphane Nicolet <cassio@free.fr>
Sat, 5 Oct 2019 22:57:00 +0000 (00:57 +0200)
commitca7d4e9ac7b5ca74be8aa807fbdf139b2a0860ab
treec6d1fce1357030aafc9f705cc0c12a55db8f5109
parent328bdd0947ea7903ee1061c8eb60bc3121a4eb19
Eliminate ONE_PLY

Simplification that eliminates ONE_PLY, based on a suggestion in the forum that
support for fractional plies has never been used, and @mcostalba's openness to
the idea of eliminating it. We lose a little bit of type safety by making Depth
an integer, but in return we simplify the code in search.cpp quite significantly.

No functional change

------------------------------------------

The argument favoring eliminating ONE_PLY:

* The term “ONE_PLY” comes up in a lot of forum posts (474 to date)
https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance

* There is occasionally a commit that breaks invariance of the code
with respect to ONE_PLY
https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ

* To prevent such commits, there is a Travis CI hack that doubles ONE_PLY
and rechecks bench

* Sustaining ONE_PLY has, alas, not resulted in any improvements to the
  engine, despite many individuals testing many experiments over 5 years.

The strongest argument in favor of preserving ONE_PLY comes from @locutus:
“If we use par example ONE_PLY=256 the parameter space is increases by the
factor 256. So it seems very unlikely that the optimal setting is in the
subspace of ONE_PLY=1.”

There is a strong theoretical impediment to fractional depth systems: the
transposition table uses depth to determine when a stored result is good
enough to supply an answer for a current search. If you have fractional
depths, then different pathways to the position can be at fractionally
different depths.

In the end, there are three separate times when a proposal to remove ONE_PLY
was defeated by the suggestion to “give it a few more months.” So… it seems
like time to remove this distraction from the community.

See the pull request here:
https://github.com/official-stockfish/Stockfish/pull/2289
.travis.yml
src/movepick.cpp
src/search.cpp
src/thread.cpp
src/tt.cpp
src/tt.h
src/types.h