optimal aspiration window for stockfish question

[Don]

I am sure the SF team have done considerable testing here.

Yes, we have.

At the end of endless trials with differnt formulas and values we end up in starting with a small window value:

Code: Select all

delta = Value(16);
alpha = RootMoves[PVIdx].prevScore - delta;
beta  = RootMoves[PVIdx].prevScore + delta;

That is increased after a fail low/high with the following formula:

Code: Select all

if (bestValue >= beta)
{
    beta += delta;
    delta += delta / 2;
}
else if &#40;bestValue <= alpha&#41;
&#123;   
    alpha -= delta;
    delta += delta / 2;
&#125;

I want to add that this is the Ippo* formula and I think that very probably it is what is used in _all_ the top engines from Rybka 3 to Houdini. Although we knew the Ippo formula since when sources were published we moved to that only one year later, after having tried all the possible different combinations: some are weaker, some are equivalent ELO wise, but more complex, so this is the simplest formula (we know) that guarantees top performance.

Answering to Uri: I am not interested in tweaking the engine on a sample position. I only use real games to validate a change.

That's what we do. We will run a few hundred games at various fixed depth levels and have the instrumentation that gives us the average time per move up to some arbitrary move number. I think we currently use move 70. We think this is superior to just running 100 positions and timing them. We only do this when we want data on something that is supposed to be a speedup - normally we just run time games to measure general improvements and things that involve trade-offs.

[Houdini]

I want to add that this is the Ippo* formula and I think that very probably it is what is used in _all_ the top engines from Rybka 3 to Houdini.

Houdini doesn't use these formulae.
Please don't spread incorrect assumptions about Houdini.

Regards,
Robert

[Houdini]

The more interesting question is which houdini does not use that formula because there are more than one houdini version.

If you're really interested, no version of Houdini has used the formulae that Marco quoted above.
Houdini uses an aspiration window that widens much faster.

Robert

[Uri Blass]

The more interesting question is which houdini does not use that formula because there are more than one houdini version.

If you're really interested, no version of Houdini has used the formulae that Marco quoted above.
Houdini uses an aspiration window that widens much faster.

Robert

Thanks Robert.

My intuition also tells me that it is better to have less researches(increasing delta faster by a different formula may be a way to do it)

Maybe the stockfish team may try something like

if (bestValue >= beta)
{
beta += delta;
delta += delta*2;
}
else if (bestValue <= alpha)
{
alpha -= delta;
delta += delta *2;
}

[Eelco de Groot]

@Uri: It is probably not such a bad idea to let it depend not only on the depth but also the amount of hash. If there are more holes in the hash table because of saturation, it is likely that you will see more failed searches for good PV nodes, and that leads to more fail lows or fail highs. I don't think that a wider window by itself will be more efficient if there are a lot of Fail Lows or Fail Highs, but the fail low or fail high searches will take longer if they find no stored positions in hash. And then it is possibly better to just use a wider window. I don't think Uri's correspondence chess example is really a case where this already applies, because the fail lows all seem to go pretty fast and the endresult is actually lower so the fail lows did their work on the right side as it were. But if Marco wants to test your theory and he needs a timecontrol of at least 40 minutes per move it is going to be rather timeconsuming. But you should be able to simulate my theory of the hash effect on short timecontrols a bit.

[Uri Blass]

@Uri: It is probably not such a bad idea to let it depend not only on the depth but also the amount of hash. If there are more holes in the hash table because of saturation, it is likely that you will see more failed searches for good PV nodes, and that leads to more fail lows or fail highs. I don't think that a wider window by itself will be more efficient if there are a lot of Fail Lows or Fail Highs, but the fail low or fail high searches will take longer if they find no stored positions in hash. And then it is possibly better to just use a wider window. I don't think Uri's correspondence chess example is really a case where this already applies, because the fail lows all seem to go pretty fast and the endresult is actually lower so the fail lows did their work on the right side as it were. But if Marco wants to test your theory and he needs a timecontrol of at least 40 minutes per move it is going to be rather timeconsuming. But you should be able to simulate my theory of the hash effect on short timecontrols a bit.

The fail low is not justified in my example
stockfish started with 1.97 and the first fail low said lower than 1.89 but the final score was 1.93

35/79 40:24 10,618,711,296 4,378,972 +1.97
36/79- 42:46 11,265,468,653 4,388,811 +1.89
36/79- 43:36 11,486,371,530 4,389,792 +1.81
36/79- 44:35 11,747,022,497 4,390,999 +1.69
36/79+ 46:55 12,371,982,241 4,393,810 +2.06
36/79 55:58 14,833,537,002 4,417,125 +1.93

second example from the same search
The score did not change so fail high and fail low are not justified.

23/56 00:36 130,367,750 3,606,399 +1.37
24/56+ 00:43 158,498,424 3,604,776 +1.45
24/56- 00:46 169,841,034 3,623,584 +1.29
24/56- 00:47 172,222,913 3,627,349 +1.17
24/56- 00:48 175,065,644 3,613,624 +0.98
24/56+ 00:50 183,805,380 3,619,356 +1.53
24/64 01:03 231,112,085 3,634,123 +1.37

[lucasart]

Code: Select all

delta = Value(16);

your initial delta is only 1/16-th of a pawn ?

[Eelco de Groot]

Code: Select all

delta = Value(16);

your initial delta is only 1/16-th of a pawn ?

Well no, because of

Code: Select all

const Value PawnValueMidgame   = Value(0x0C6);
const Value PawnValueEndgame   = Value(0x102);

in types.h you can see it is actually a lot less than that The smaller you make it the more a PV search begins to resemble the nullwindow search, apart from the reductions missing from PV nodes of course like null move pruning etc. Compare that with Fruit 2.1 that has an infinite window, and I don't think it had aspiration windows? Not sure without looking it up.

Eelco

[Karlo Bala]

The more interesting question is which houdini does not use that formula because there are more than one houdini version.

If you're really interested, no version of Houdini has used the formulae that Marco quoted above.
Houdini uses an aspiration window that widens much faster.

Robert

Thanks Robert.

My intuition also tells me that it is better to have less researches(increasing delta faster by a different formula may be a way to do it)

My intuition is somewhat different than yours. If your PV search is very similar to non-PV search, it should be a small percentage of false PV nodes, so that you can use a wider window. If your PV search is very differen from non-PV search (which is common today because of the LMR, NM, futility, delta, etc.) then it should be more false PV nodes. In that case you do not want to search a lot of false PV nodes with a wide window.

[bob]

I am sure the SF team have done considerable testing here.

Yes, we have.

At the end of endless trials with differnt formulas and values we end up in starting with a small window value:

Code: Select all

delta = Value(16);
alpha = RootMoves[PVIdx].prevScore - delta;
beta  = RootMoves[PVIdx].prevScore + delta;

That is increased after a fail low/high with the following formula:

Code: Select all

if (bestValue >= beta)
{
    beta += delta;
    delta += delta / 2;
}
else if &#40;bestValue <= alpha&#41;
&#123;   
    alpha -= delta;
    delta += delta / 2;
&#125;

I want to add that this is the Ippo* formula and I think that very probably it is what is used in _all_ the top engines from Rybka 3 to Houdini. Although we knew the Ippo formula since when sources were published we moved to that only one year later, after having tried all the possible different combinations: some are weaker, some are equivalent ELO wise, but more complex, so this is the simplest formula (we know) that guarantees top performance.

Answering to Uri: I am not interested in tweaking the engine on a sample position. I only use real games to validate a change.

That's what we do. We will run a few hundred games at various fixed depth levels and have the instrumentation that gives us the average time per move up to some arbitrary move number. I think we currently use move 70. We think this is superior to just running 100 positions and timing them. We only do this when we want data on something that is supposed to be a speedup - normally we just run time games to measure general improvements and things that involve trade-offs.

Since it was a trivial change, I took the above and rewrote it to fit Crafty's search. Absolutely no change, either up or down. A couple of things I do not like about it however. 1. Several re-searches to win a pawn or more, and 2. way too many re-searches to find a forced mate.

We've used several different approaches. In Cray Blitz we did more "bumps". In Crafty I settled on fewer. But it actually doesn't seem to matter one bit based on the testing I just did, which was run at fast games and at 1min+1sec games as well. Absolutely no +/- change when switching from what I did to this, and back...