Skip to content

Commit

Permalink
Variable null-move value based reduction
Browse files Browse the repository at this point in the history
Instead of a fixed reduction of ONE_PLY, now
Null move dynamic reduction based on value can
grow larger in case we are above beta of a value
much higher then PawnValueMg.

Note that now an eval returning VALUE_KNOWN_WIN
makes null search to drop in qsearch.

Passed both short TC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 26141 W: 4871 L: 4699 D: 16571

And long TC:
LLR: 2.97 (-2.94,2.94) [0.00,6.00]
Total: 33695 W: 5309 L: 5056 D: 23330

bench: 7356053
  • Loading branch information
Stefan Geschwentner authored and mcostalba committed Jan 26, 2014
1 parent cf95a55 commit 074c7a3
Showing 1 changed file with 7 additions and 6 deletions.
13 changes: 7 additions & 6 deletions src/search.cpp
Expand Up @@ -628,12 +628,12 @@ namespace {
{
ss->currentMove = MOVE_NULL;

// Null move dynamic reduction based on depth
Depth R = 3 * ONE_PLY + depth / 4;
assert(eval - beta >= 0);

// Null move dynamic reduction based on value
if (eval - PawnValueMg > beta)
R += ONE_PLY;
// Null move dynamic reduction based on depth and value
Depth R = 3 * ONE_PLY
+ depth / (2 * ONE_PLY)

This comment has been minimized.

Copy link
@sf-x

sf-x Jan 26, 2014

Contributor

Change of |depth / 4| to |depth / (2 * ONE_PLY)| doesn't make sense. The former doesn't depend on value of ONE_PLY, but the latter does.

This comment has been minimized.

Copy link
@mcostalba

mcostalba via email Jan 26, 2014

Owner

This comment has been minimized.

Copy link
@sf-x

sf-x Jan 26, 2014

Contributor

This is a good rule for everybody (me included)

Did you even stop to think before you wrote this comment?
The value of |R| and |depth| are both measured in half-plies. This code adds one quarter of depth to R. If ONE_PLY was, say, 4, then it would be adding one eighth of it, which doesn't make any sense, as clearly a lot of effort went into making the value of ONE_PLY not affect values of depths measured in plies (except due to rounding). Might as well kill off ONE_PLY constant if this code assumes it to be 2 anyway.

but it is even more appropriate for random Joes /out of the blue guys like you.

When I see nonsense, I report it (if I have time). If you don't want me to do that, fine.

This comment has been minimized.

Copy link
@zamar

zamar Jan 26, 2014

Contributor

sf-x is correct, DEPTH / (2 * ONE_PLY) doesn't make any sense in this context.

This comment has been minimized.

Copy link
@mcostalba

mcostalba via email Jan 26, 2014

Owner

This comment has been minimized.

Copy link
@mcostalba

mcostalba via email Jan 26, 2014

Owner

This comment has been minimized.

Copy link
@sf-x

sf-x Jan 26, 2014

Contributor

If oneply would be 4 you can be sure depth would be the double of what currently is.

Yes. So would |3*ONE_PLY| and |int(eval - beta) / PawnValueMg * ONE_PLY|. But depth / (2 * ONE_PLY) would not, and you are adding them together!
You're basically adding value in kilometers and value in miles together, so to speak.

This comment has been minimized.

Copy link
@mcostalba

mcostalba via email Jan 27, 2014

Owner
+ int(eval - beta) / PawnValueMg * ONE_PLY;

pos.do_null_move(st);
(ss+1)->skipNullMove = true;
Expand All @@ -653,7 +653,8 @@ namespace {

// Do verification search at high depths
ss->skipNullMove = true;
Value v = search<NonPV>(pos, ss, alpha, beta, depth-R, false);
Value v = depth-R < ONE_PLY ? qsearch<NonPV, false>(pos, ss, alpha, beta, DEPTH_ZERO)
: search<NonPV>(pos, ss, alpha, beta, depth-R, false);
ss->skipNullMove = false;

if (v >= beta)
Expand Down

0 comments on commit 074c7a3

Please sign in to comment.