Eliminate ONE_PLY

[SapphireBrand]

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.

Binary identical to master.

No functional change

[vondele]

missing bit:

diff --git a/.travis.yml b/.travis.yml
index 1d56a23e9..a59ea4251 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -56,9 +56,6 @@ script:
   - make clean && make -j2 ARCH=x86-32 optimize=no debug=yes build && ../tests/signature.sh $benchref
   - make clean && make -j2 ARCH=x86-32 build && ../tests/signature.sh $benchref
 
-  # Verify bench number is ONE_PLY independent by doubling its value
-  - sed -i'.bak' 's/.*\(ONE_PLY = [0-9]*\),.*/\1 * 2,/g' types.h
-  - make clean && make -j2 ARCH=x86-64 build && ../tests/signature.sh $benchref
   #
   # Check perft and reproducible search
   - ../tests/perft.sh

[Vizvezdenec]

Well I do agree.
All functions that use depth divided by smth look extremely ugly, especially if you use std::min
Like std::min(((depth - 4 * ONE_PLY) / ONE_PLY) / 2, 0) * ONE_PLY etc
For the sake of potential functionality that was never used?

[locutus2]

I have tried int the past several tests around fractional plies but had no success. But i'am personally convinced that with fractional plies there a higher optimum is possible. I understand that removing simplifies the code and coding (which for me makes no really difference, i never forget the ONE_PLY, its a automatic move for me) but if we remove it nobody will test around fractional plies anymore because too much would be to changed for it (and probably something is forgotten and an error is introduced).

Perhaps we should set a target date and call for a period of intensive fractional plies testing. And if nothing is found until then simplify it away.

[gvreuls]

I've been playing around with fractional plies since #2081 and haven't come up with any results either. To my understanding factional plies as they're implemented (with the tt only saving integer plies) can only be used for search reductions and there they're just a way to do less search reduction (skip every other half ply reduction), so they're less efficient than full ply reductions in almost every instance (because they search deeper).

[vondele]

The first request I can find to keep ONE_PLY 'a few more months' was in 2016:
#916 (comment)
similar request in 2018:
#1543 (comment)
We've kept it around for a few years without impact on performance... time to let it go IMO.

[MichaelB7]

@gvreuls They also could be used for extensions. For every other ply as noted in your comment regarding reductions or having multiple factors existing on a move , that would trigger a full ply extension.

[MichaelB7]

I would suggest a 6 month moratorium before removing it to allow one more shot at it with testing - if none is found, remove it. But since we know it doesn’t hurt the performance or current testing , my first choice would be to leave it “as is” since any re-introduction at a later time could be problematic.

[xoto10]

We could try tuning the related variables with ONE_PLY set to something like 256 and see what comes out?

One issue is there are at least a couple of places where the * ONE_PLY is too late in the order of execution to use the full significance (see tests by sg), e.g.
r -= ss->statScore / 16384 * ONE_PLY;
and
return ((r + 520) / 1024 + (!i && r > 999)) * ONE_PLY;

Perhaps there are others?

[SapphireBrand]

To some extent, this comes down to "enough people have tried and failed to make fractional search work that we have decided as a community to focus our attention on other avenues, which have proved much more fruitful."

In addition to having entirely failed in our experience, there are theoretical reasons why fractional search depths should be difficult to make work:

1. TT stores depth as an integer, whereas fractional depths will have a lot of "in between" values. E.g., you stored a 5-ply result, but now you are doing a 5.125 ply search, so...a lot of positions no longer match.
2. Depth cutoffs are built into every major system in search. There are a lot of synergistic and counter-balancing effects from null move, futility, iterative deepening, LMR, singular,... It seems likely to me that the balance will be upset by fractional depths. That is, there are implicit assumptions that a move is 1 ply.
3. LMR already gives the program the effect of fractional depth, just with a different frame of reference. That is, depth decrements in LMR have all sorts of ratios of non-integer ratios, but without any fractions.

To summarize, fractional depth systems

• haven't worked, despite a lot of engineers trying to find such things (me too),
• will always reduce efficiency in the TT,
• are likely to disrupt other systems (making them difficult to find/test/evaluate), and
• are probably not much better than an LMR change, which has proven to be easier to find.

[xoto10]

From the history, it seems that this might be the time to make a deadline (1 month, 6 months, whatever), do a concerted effort and then remove it if no gain is found by then. But right now, the TCEC premier division has just started, so perhaps we would be best to spend the next 3 weeks looking for Elo gainers for a hopeful superfinal appearance (maybe including fractional plies, maybe not) and then spend some time concentrating on this issue once the TCEC superfinal has started?

[locutus2]

@SapphireBrand
That are good points which makes it difficult to make fractional plies working. Especially we have the problem that for a minimum fractional ply change several uses of depth changes the outcome.
Par example for LMR we have the condition depth >= 3 * ONE_PLY. If ins master depth = 3 and its now only slightly reduced by a fractional ply this condition doesn't trigger anymore. To avoid this sharp changes i implemented a branch (using ONE_PLY=256) which adjusts the depth by a half ply so that the trigger interval is centered around the full plies and not sit at the boundaries.
https://github.com/locutus2/Stockfish/tree/fractional_base
The bench shouldn't change but it does so i obviously i have overlooked something or adjusted in the wrong way. So if someone finds some of my errors feedback would be nice :-)
Nevertheless i will try further tests based on above base branch.

Edit:
On the last point in your arguments i have to disagree. 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. The problem is to find it.

[snicolet]

What date in the future should we decide for the removal, if no test proves that the ONE_PLY feature is useful after all?

[Vizvezdenec]

I think that everyone who wanted already tried this partial plies. My guess that today will be pretty OK.

[SapphireBrand]

I will make a fresh version on top of the latest master, so we can all take another look.

[SapphireBrand]

@SapphireBrand
On the last point in your arguments i have to disagree. 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. The problem is to find it.

@locutus2
The dimensionality argument is plausible if Stockfish development were starting from scratch, provided that someone invents a way to overcome inherent xref inefficiency. But starting from here, it seems likely (to me) that ONE_PLY == 1 is a deeply entrenched local optimum. I cited theoretical reasons for this, and the experiments of quite a few devoted researchers (including yourself) seem to confirm this.

That is, I think that you have found the optimum, and, furthermore, it is through your efforts that the community has that confidence.

[snicolet]

@SapphireBrand
Could you edit the PR message, adding references and links to the various discussions we had about the ONE_PLY feature? thanks :-)

[SapphireBrand]

Rebased onto the latest master, and updated the commit comment to include a summary (necessarily abbreviated) of the discussion.

[vondele]

@snicolet this should be merged, as maintaining the PR is tedious, every other commit to master causes a conflict.

[snicolet]

Merged via ca7d4e9, thanks!

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.