Will your engine play better or worse?

[Michael Sherwin]

score = -Search(...
if(score > alpha && score < beta && beta - score < 5) score = beta;

[Harald Johnsen]

Should it play better because the node count is reduced ? Is the node count reduced btw, I think the search will be more instable.

What you are doing is perhaps better done with rounding of scores returned by the evaluation function.

HJ.

[Michael Sherwin]

It seems better for RomiChess.

There are fewer nodes examined on average at fixed depth.

No stability problem noted.

Notice, that it is done only when the window is quite narrow, when there is not much to be gained from further searching anyway.

It is just a one-liner so, maybe at least a few will give it a try and give a report.

[Harald Johnsen]

I'll have a look when i'm at home.

What you are doing looks like sibbling prediction when using a small positional margin.

HJ.

[mcostalba]

score = -Search(...
if(score > alpha && score < beta && beta - score < 5) score = beta;

Sorry for my silly question. But with null window searching if

score > alpha && score < beta

then it is always true that

beta - score < 5

Am I missing something ? Do you intend to apply to PV search only ?

Thanks
Marco

[hgm]

With a null window you will never have

score > alpha && score < beta

so indeed this only applies to PV nodes.

[bob]

score = -Search(...
if(score > alpha && score < beta && beta - score < 5) score = beta;

You are trying to prevent "small" score jumps? Some have tried this in the past, including me (although 10 years ago or so). It never worked for me...

[BubbaTough]

I have tried a technique I saw in Glaurung for this that looked cool for doing something similar (look at GrainSize in Glaurung evaluate function)...it did not help. Which made me glad actually, because I prefer the idea that accurate eval is helpful and that rounding, while it makes search trees smaller and lets you go a little deeper, is not worth because of the corresponding decreased accuracy in eval. I would assume the technique is helpful for some and harmful to others depending on the degree of sensitivity of the eval.

-Sam

[Zach Wegner]

I have tried a technique I saw in Glaurung for this that looked cool for doing something similar (look at GrainSize in Glaurung evaluate function)...it did not help. Which made me glad actually, because I prefer the idea that accurate eval is helpful and that rounding, while it makes search trees smaller and lets you go a little deeper, is not worth because of the corresponding decreased accuracy in eval. I would assume the technique is helpful for some and harmful to others depending on the degree of sensitivity of the eval.

Of course, there are other ways to make use of this granularity.

[Eelco de Groot]

I have tried a technique I saw in Glaurung for this that looked cool for doing something similar (look at GrainSize in Glaurung evaluate function)...it did not help. Which made me glad actually, because I prefer the idea that accurate eval is helpful and that rounding, while it makes search trees smaller and lets you go a little deeper, is not worth because of the corresponding decreased accuracy in eval. I would assume the technique is helpful for some and harmful to others depending on the degree of sensitivity of the eval.

Of course, there are other ways to make use of this granularity.

Would you care to elaborate a bit on that?
Something found in the Strelka sources or is it something you found by yourself Zach? I believe "grain-size" of the eval was also part of some of the later Fruits from Ryan, as an UCI option but it seemed to be doing not much for testpositions at least...

Eelco