int r=(int)(2.5+sqrt(ddepth)/1.22+sqrt(log(ddept*delta))

[Michael Sherwin]

Less aggressive for depth

Less aggressive for delta at low depth

more aggressive for delta as depth increases

...

Early in testing for RomiChess but, Romi has solid wins so far.

[Gian-Carlo Pascutto]

What units do you express ddepth in?

[Michael Sherwin]

What units do you express ddepth in?

Since this formula is for RomiChess the units are in whole ply values.

However, I have already refined the idea further.

MAKING A BETTER SMOOTHIE!

In more general terms.

iDepth is the depth at the root.

r = base + (coeff1 * depth / iDepth) + (log(depth / iDepth * delta) / coeff2);

The point here is that both main terms are smoothed downward as depth diminishes.

[bob]

What units do you express ddepth in?

Since this formula is for RomiChess the units are in whole ply values.

However, I have already refined the idea further.

MAKING A BETTER SMOOTHIE!

In more general terms.

iDepth is the depth at the root.

r = base + (coeff1 * depth / iDepth) + (log(depth / iDepth * delta) / coeff2);

The point here is that both main terms are smoothed downward as depth diminishes.

Here's the key question, before you spend a lot of time testing all sorts of ways to smoothly reduce R: How does a simple smoothing function compare to the typical R=3 everywhere, or else R=2~3 as in the usual adaptive null-move that uses a sort of unit-step-function approach to reducing R. If you can get an improvement of any kind, going further is worthwhile. I was unable to improve on plain R=3 when I did my testing, and I threw out R=2~3 which I used to use, when testing showed R=3 was better. The difference between R=3 and R=2~3 was 2 (two) Elo, for reference. We are _not_ talking significant gains in this smooth reduction approach.

[Michael Sherwin]

What units do you express ddepth in?

Since this formula is for RomiChess the units are in whole ply values.

However, I have already refined the idea further.

MAKING A BETTER SMOOTHIE!

In more general terms.

iDepth is the depth at the root.

r = base + (coeff1 * depth / iDepth) + (log(depth / iDepth * delta) / coeff2);

The point here is that both main terms are smoothed downward as depth diminishes.

Here's the key question, before you spend a lot of time testing all sorts of ways to smoothly reduce R: How does a simple smoothing function compare to the typical R=3 everywhere, or else R=2~3 as in the usual adaptive null-move that uses a sort of unit-step-function approach to reducing R. If you can get an improvement of any kind, going further is worthwhile. I was unable to improve on plain R=3 when I did my testing, and I threw out R=2~3 which I used to use, when testing showed R=3 was better. The difference between R=3 and R=2~3 was 2 (two) Elo, for reference. We are _not_ talking significant gains in this smooth reduction approach.

Yes, there is too much to test. But, it makes sense (from personal experience) that too high of a reduction near the leafs is detrimental. This adaptation allows the coefficients to be set so that reductions at high remaining depths are more aggressive and then diminish as depth diminishes. If the standard formula does not help, this one might.

Horses race against each other, not themselves. And if the winning horse can not beat the track record that does not make the race uninteresting.

[bob]

What units do you express ddepth in?

Since this formula is for RomiChess the units are in whole ply values.

However, I have already refined the idea further.

MAKING A BETTER SMOOTHIE!

In more general terms.

iDepth is the depth at the root.

r = base + (coeff1 * depth / iDepth) + (log(depth / iDepth * delta) / coeff2);

The point here is that both main terms are smoothed downward as depth diminishes.

Here's the key question, before you spend a lot of time testing all sorts of ways to smoothly reduce R: How does a simple smoothing function compare to the typical R=3 everywhere, or else R=2~3 as in the usual adaptive null-move that uses a sort of unit-step-function approach to reducing R. If you can get an improvement of any kind, going further is worthwhile. I was unable to improve on plain R=3 when I did my testing, and I threw out R=2~3 which I used to use, when testing showed R=3 was better. The difference between R=3 and R=2~3 was 2 (two) Elo, for reference. We are _not_ talking significant gains in this smooth reduction approach.

Yes, there is too much to test. But, it makes sense (from personal experience) that too high of a reduction near the leafs is detrimental. This adaptation allows the coefficients to be set so that reductions at high remaining depths are more aggressive and then diminish as depth diminishes. If the standard formula does not help, this one might.

Horses race against each other, not themselves. And if the winning horse can not beat the track record that does not make the race uninteresting.

I don't follow. If you can't beat the "best so far" (and I am talking about a specific algorithm, not a combination of all algorithms) then there is much of a point in continuing down that path unless somehow intuition suggests that the idea _ought_ to work.

[Michael Sherwin]

What units do you express ddepth in?

Since this formula is for RomiChess the units are in whole ply values.

However, I have already refined the idea further.

MAKING A BETTER SMOOTHIE!

In more general terms.

iDepth is the depth at the root.

r = base + (coeff1 * depth / iDepth) + (log(depth / iDepth * delta) / coeff2);

The point here is that both main terms are smoothed downward as depth diminishes.

Here's the key question, before you spend a lot of time testing all sorts of ways to smoothly reduce R: How does a simple smoothing function compare to the typical R=3 everywhere, or else R=2~3 as in the usual adaptive null-move that uses a sort of unit-step-function approach to reducing R. If you can get an improvement of any kind, going further is worthwhile. I was unable to improve on plain R=3 when I did my testing, and I threw out R=2~3 which I used to use, when testing showed R=3 was better. The difference between R=3 and R=2~3 was 2 (two) Elo, for reference. We are _not_ talking significant gains in this smooth reduction approach.

Yes, there is too much to test. But, it makes sense (from personal experience) that too high of a reduction near the leafs is detrimental. This adaptation allows the coefficients to be set so that reductions at high remaining depths are more aggressive and then diminish as depth diminishes. If the standard formula does not help, this one might.

Horses race against each other, not themselves. And if the winning horse can not beat the track record that does not make the race uninteresting.

I don't follow. If you can't beat the "best so far" (and I am talking about a specific algorithm, not a combination of all algorithms) then there is much of a point in continuing down that path unless somehow intuition suggests that the idea _ought_ to work.

My intuition tells me that this new adaptation should be better as it has qualities that based on my experience avoids problems that Dann's might have at lower depths. And it may help more at higher depths.

If Dann does not mind my input then I hope that he might give my adaptation a try. Thanks!

[Michael Sherwin]

What units do you express ddepth in?

Since this formula is for RomiChess the units are in whole ply values.

However, I have already refined the idea further.

MAKING A BETTER SMOOTHIE!

In more general terms.

iDepth is the depth at the root.

r = base + (coeff1 * depth / iDepth) + (log(depth / iDepth * delta) / coeff2);

The point here is that both main terms are smoothed downward as depth diminishes.

Here's the key question, before you spend a lot of time testing all sorts of ways to smoothly reduce R: How does a simple smoothing function compare to the typical R=3 everywhere, or else R=2~3 as in the usual adaptive null-move that uses a sort of unit-step-function approach to reducing R. If you can get an improvement of any kind, going further is worthwhile. I was unable to improve on plain R=3 when I did my testing, and I threw out R=2~3 which I used to use, when testing showed R=3 was better. The difference between R=3 and R=2~3 was 2 (two) Elo, for reference. We are _not_ talking significant gains in this smooth reduction approach.

Yes, there is too much to test. But, it makes sense (from personal experience) that too high of a reduction near the leafs is detrimental. This adaptation allows the coefficients to be set so that reductions at high remaining depths are more aggressive and then diminish as depth diminishes. If the standard formula does not help, this one might.

Horses race against each other, not themselves. And if the winning horse can not beat the track record that does not make the race uninteresting.

I don't follow. If you can't beat the "best so far" (and I am talking about a specific algorithm, not a combination of all algorithms) then there is much of a point in continuing down that path unless somehow intuition suggests that the idea _ought_ to work.

My intuition tells me that this new adaptation should be better as it has qualities that based on my experience avoids problems that Dann's might have at lower depths. And it may help more at higher depths.

If Dann does not mind my input then I hope that he might give my adaptation a try. Thanks!

Just to be clear, I will be testing this in RomiChess as time permits and will report my results. However, until I finalize a new release I have no time to try it in Stockfish.

Now, I am testing a close variation (second term) and it is doing the best of any so far.

Next test: (actual code line from RomiChess)

int r = (int)(2.5 + 0.4 * d / id + log(d / id * delta)/4.0);

the coefficients are simply a first guess.

Been invited to supper. Wont be back till late.