Aspiration windows

[lucasart]

I've been doing quite a few experiments with those, and could never come up with anything elo increasing. So I currently do a search with (alpha,beta) = (-INF,+INF).

I wonder how other engine developers do that, and if they managed to find a way that actually improves anything.

Amongst my several attempts, the most "logical" one would be

Code: Select all

do {
  score = search(..., depth, alpha, beta)
  if (score <= alpha)
    alpha=-INF;
  else if (score >= beta)
    beta = +INF;
} while (score <= alpha || score >= beta);
// set aspiration window for the next depth
alpha = score - 150;
beta = score + 150;

this pseudo code is of course embedded in the iterative deepening loop.[/code]

[mar]

I've been doing quite a few experiments with those, and could never come up with anything elo increasing. So I currently do a search with (alpha,beta) = (-INF,+INF).

I wonder how other engine developers do that, and if they managed to find a way that actually improves anything.

Amongst my several attempts, the most "logical" one would be

Code: Select all

do {
  score = search(..., depth, alpha, beta)
  if (score <= alpha)
    alpha=-INF;
  else if (score >= beta)
    beta = +INF;
} while (score <= alpha || score >= beta);
// set aspiration window for the next depth
alpha = score - 150;
beta = score + 150;

this pseudo code is of course embedded in the iterative deepening loop.[/code]

According to my experience aspiration windows will add some elo when done properly.
I think 150 cp is too much. I would try something like +-40 or like that.
What I'm using now is using a margin around the result from previous iteration. If it fails low or high I don't research with full window but instead I widen the margin by two and research. I do this until the result fits between alpha and beta.

Martin

[zamar]

AFAIK the recipe that all top engines are using is:

- Use very small aspiration window (only something like 8cp - 16cp).
- Use very low effective branching factor (~1.6)

This will result in many researches, but for some reason it seems to pay off. Also you must note that with low EBF + small aspiration window, you may want to adjust your time management to be more aggressive compared to high EBF without aspiration window.

IMO all these three issues (aspiration window, EBF and time management) are so closely related that you cannot tune one without also tuning the others.

[G.B. Harms]

I've been doing quite a few experiments with those, and could never come up with anything elo increasing. So I currently do a search with (alpha,beta) = (-INF,+INF).

I wonder how other engine developers do that, and if they managed to find a way that actually improves anything.

Amongst my several attempts, the most "logical" one would be

Code: Select all

do {
  score = search(..., depth, alpha, beta)
  if (score <= alpha)
    alpha=-INF;
  else if (score >= beta)
    beta = +INF;
} while (score <= alpha || score >= beta);
// set aspiration window for the next depth
alpha = score - 150;
beta = score + 150;

this pseudo code is of course embedded in the iterative deepening loop.[/code]

It looks it will jump out of the loop after the first iteration. It may also be better to do alpha=max(-INF, alpha-margin); beta=min(+INF, beta+margin). I reset to -INF,+INF immediately after a fl or fh because, until now, I could not test an improvement by gradually opening the window and code is (a tiny bit) more readable with simple method to open it fully at once.

[Rebel]

AFAIK the recipe that all top engines are using is:

- Use very small aspiration window (only something like 8cp - 16cp).
- Use very low effective branching factor (~1.6)

Yep.

Some possible refinements,

1. Use a somewhat bigger window in case of score fluctuations between iterations.

2. Use a somewhat bigger window in case of more than 2 best move changes within an iteration. 2 is arguable of course.

This will result in many researches, but for some reason it seems to pay off. Also you must note that with low EBF + small aspiration window, you may want to adjust your time management to be more aggressive compared to high EBF without aspiration window.

IMO all these three issues (aspiration window, EBF and time management) are so closely related that you cannot tune one without also tuning the others.

Yep.

[Engin]

yup

yes i am using a small window too, about 8cp, but if the alpha or beta change at a score of mate i will search with full window.

[jacobbl]

You are saying one should use a low ebf, just as if it's a parameter you can choose. One of my largest struggles is to lower my ebf. Could you please enlighten me on what you mean with: "Use a low ebf"?

Regards
Jacob

[zamar]

You are saying one should use a low ebf, just as if it's a parameter you can choose. One of my largest struggles is to lower my ebf. Could you please enlighten me on what you mean with: "Use a low ebf"?

Regards
Jacob

Sure! Old chess programs use various extensions and few reductions. This results in high-branching factor >= 2.0.

AFAIK Modern top chess program use very few extensions and are very aggressive in reductions and prunings.

For starters you could try:
- Take out every extensions except checks and single-move
- LMR reducing two plies for non-captures (at least at the end of the move list).
- Null move with R=3,4,5,6 (higher reduction closer to root)
- Prune neg. SEE moves close to leafs
- Prune moves at the end of the move list in close to leafs

Of course every chess engine is a different beast and not every idea can work in every program. But the current tendency is to favor reductions and prunings instead of extensions.

[Evert]

Correct me if I'm wrong, but you only need an exact score for the best move, so for any other move you don't adjust the window and research when they fail low because that's the expected behaviour. Right?
Your pseudo-code sample seems to always research when a move fails low, even if you expect it to.

Or am I completely missing something?

[Sven]

Correct me if I'm wrong, but you only need an exact score for the best move, so for any other move you don't adjust the window and research when they fail low because that's the expected behaviour. Right?
Your pseudo-code sample seems to always research when a move fails low, even if you expect it to.

Or am I completely missing something?

In the pseudo code given above the "search(...)" call is meant as the search of the root node, it is the code for one single iteration, i.e. (part of) the body of the iteration loop:

Code: Select all

for (iteration = 1; iteration <= maxIteration; iteration++) {
    // now the code above
}

What you wrote applies for the root node search itself which is not shown above.

Sven