Toga/Glaurung/Strelka Prunings/Reductions

[Edsel Apostol]

In the last couple of months/weeks some of the strongest open source chess engines has been released, the latest Toga, Strelka, and Glaurung. I have a few observations and I hope that other programmers could share their ideas about this.

I have noticed from the sources that they support Razoring but Strelka differs from Toga and Glaurung in its implementation.

Strelka still searches losing captures at depth 2 and 3 while Toga/Glaurung does not. Is it safe to do the Toga/Glaurung way?

Strelka also do the Razoring before the Null Move while Toga/Glaurung do the reverse? Is there a difference if one pruning method is called before the other? Which method is best?

Also Toga/Glaurung does Futility Pruning even when there already is Razoring. Is it not redundant? I think that when the Razoring doesn't exceed beta, the search shouldn't do the Futility Pruning as it would only repeat the path taken by the Razoring Search.

I also have tried adding a Strelka style Razoring with depth = 4 without doing Futility Prunings and it seems stronger than just using depth = 3 though I still have to test the idea further. My theory is that maybe it is ok to do Razoring to at most depth 8, but I have not tried this.

I also have noticed Toga style History Prunings. Is it safe? It seems to work with previous versions of Twisted Logic but I removed the history stuff now in the rewrite version so I can't try it now.

Toga/Glaurung also is doing LMR in PV nodes. Is this a good idea?

Toga/Glaurung doesn't do Futility Pruning in PV quiescent nodes while Strelka does it? Is Strelka's way much better?

[pedrox]

LMR in PV nodes is good for me.

I use history in LMR, but I have not managed to adjust the value for history prunning.

I am trying more extended reduce according the values of history.

[Ryan Benitez]

Futility pruning is not worth the time in PV nodes. In fact Fruit does not use Futility Pruning at all any more. Unless you have other pruning I would not recommend removing it from non-PV nodes though. I save some cpu time Razoring before null move. I avoid null move any time I can. LMR in PV seems reasonable with added safe conditions.

[jdart]

Also Toga/Glaurung does Futility Pruning even when there already is Razoring. Is it not redundant?

Different programs seem to use the term "razoring" in a different way. As used by Ernst Heinz, it means reducing the depth (under certain conditions, based on score + margin) and Heinz did allow this to also cause the search to drop into a futility pruning step where the move could actually be pruned. But razoring is a bit redundant if you have LMR - LMR is basically also a reduction method, just with a different set of criteria.

[Ryan Benitez]

Also Toga/Glaurung does Futility Pruning even when there already is Razoring. Is it not redundant?

Different programs seem to use the term "razoring" in a different way. As used by Ernst Heinz, it means reducing the depth (under certain conditions, based on score + margin) and Heinz did allow this to also cause the search to drop into a futility pruning step where the move could actually be pruned. But razoring is a bit redundant if you have LMR - LMR is basically also a reduction method, just with a different set of criteria.

I think you refer to limited razoring.

[Edsel Apostol]

I don't use history as a criteria for LMR anymore. It seems to produce random numbers only when running in fast machines or when playing longer time controls.

I think I will try LMR in PV nodes also.

[Edsel Apostol]

Razoring first before null move seems faster especially in positions where the eval is less than alpha.

In positions where eval >= beta razoring is never called anyway so it goes directly to null move.

The order of which one should come first doesn't matter really if your null move has a "eval >= beta" criteria.