Winboard Forum

Which extensions are working for you now?
It is known that the need for extensions decreases with increase in speed. It seems that nowadays it is better to use very few extensions like the check + some rarely triggered extensions at pv nodes. I guess the idea behind this is to rely on the mistakes of the opponent rather than taking the initiative and attack. Most games are usually won in the endgame where it escalates due to huge search depth, but poor (some might say solid) performance in the middle game where it has no initiative to attack.

I tested a version of scorpio using
-the check extension
-all captures extended with full ply at pv nodes.
-Re-capture is not done. This one seems the most likely candidate to get rid off.
-single reply extension is not done
-Others like mate threat , passed pawn pushes are not really extended but reductions are avoided there. I believe this is a form of another extension.

This version scored as good as (less wins but more draws) the other versions with more extensions. The test is done at 40/5 and I expect it to be better at longer time controls. So my question is have you reached a point where you can use the check extension and a few other's triggered only at pv nodes?

Or is it just that both methods should work equally and the decision should be left to style. In other words do you prefer the flair of Brazil or catenacio Italy?

DAniel

Hi Daniel,

I'm currently using check extensions only for non-pv nodes and additional pawn in 7th rank and limited recapture in pv nodes. That seems to work for me. I tried to make things as simple as possible.

I also have single reply extension but it is disabled since I think that the implementation has a bug as sometimes it is extending indefinitely.

Do you have an idea how much elo having the single reply extension to check?

Twisted Logic Regards,
Edsel Apostol

Hi Edsel
I usually turn on all extensions and limit them in some way.
For example I can't turn off the mate threat extension and single reply extension because scorpio's featrues are tailored to a more attacking the king style and turning them off is a waste in my case. If you are writing a new engine, you can decide from the beginning if you need it or not.
For example I invested some time to make scorpio's king safety evaluation speculative, quiescence search(long sequence of check-few replies to check), longer checks-search when king safety evaluation drops signinficantly, longer checks-search depth after null move etc.
So for me turning these extensions off is like throwing away all that work.

To limit the mate threat extension, I only extend the first few moves rather than all when a mate-threat position is encountered.

To limit the single-reply extesnion i use fractional extesnions and sometimes only do these near the leafs say last three plies. The idea is to back up the check-single-reply sequence i have in the qsearch a little back up the tree.
Recapture extesnions are also done near the leafs in a limited way. if a BxN NXB sequence eats up two plies of search near leafs i think a recapture extesnion should be triggered to compensate for at least one of the plies. With enough depth available , and especially with the use of LMR, the need for this extension might be depreciated because captures are never reduced. I think Junior extends all captures with half-ply for better tactical ability. I guess both methods achive similar effect i.e to investigate the captures more.

I can't really say this extension is a must except for the check extension righ now. I have changed my mind for some of the extesnions while developing scorpio.It all depends on the engine I guess and one has to find out it works out for his engine by extensive tests, or belive his intuition like me

*Can't really Say* regards,
Daniel

It is hard really to determine which extensions are good and bad. I usually rely on intuition just like you as I don't have the resources to test and run a lot of games to verify it.

Based on what I read and on my experience, only check extension is important. Next is recapture. Other extensions are hard to quantify strengthwise. The only problem with recapture is that if you wouldn't limit it, the branching factor would go higher resulting to lesser depth searched. Note that I don't use fractional ply extension and I extend by a full ply.

It would be interesting to experiment on this. Maybe compile a few versions with different extension configuration. Play them against a set of opponents using a set of positions, and then compare the results of the test.

If I do have the time, I will try to run these settings:
-no extensions
-check extension only
-recapture extension only
-check and recapture extension
-all extensions enabled

Maybe you could try it on your engine also to see if what is the best extension configuration.

Twisted Logic Regards,
Edsel

Okay i will do an experiment with 5 versions of plausible extension configuration. Most of the combinations I tested in the past so I will select those I think will work for scorpio and haven't given much attention the past.

v1) check + all captures at pv
no other extension
v2) check + all captures at pv
mate_threats and pawn pushes not extended but not reduced either
v3) check + single_reply + all captures at pv
mate_threats and pawn pushes not extended but not reduced either
v4) check + singe reply + mate_threats + re-captures similar for pv/non pv nodes
pawn pushes not extended but not reduced either.
v5) Default scorpio for reference which includes
-re-captures near leafs ( i think i can ignore this also
if all captures are extended at pv nodes)
-mate threats (only first 6 moves)
-single reply
-passed pawn pushes to 5th,6th,7th rank extende all at pv nodes but none at non-pv

I am going to use 10 positions to do a gauntlet against 5 engines. So that will be 100 game for each verson,total 500. I will do the test at 40/5 which might take a weak to finish. Sorry I don't have a cluster just a single idle desktop:) If you have 10 representative sets of positons to use please give them. I have been using the nunn and silver positons in the past.

Any suggestions on the test setup?

Daniel

About extensions :
what do you mean by 'all captures at pv' ? Are you really going to extend winning and loosing captures ? What is the purpose of extending all those non forced branches ?

About your test setup :
I don't think that those 5x2 positions contain the features you want to test.
You have too few positions, testing them against more engines do not add diversity.

About the results you will find. Scores won't tell us enought, it would be interesing to have some statistics about the number and kind of extensions trigered.

HJ.

About extensions :
what do you mean by 'all captures at pv' ? Are you really going to extend winning and loosing captures ? What is the purpose of extending all those non forced branches ?

Those extensions are done only at pv nodes which already reduces rate of trigger very much.
Using see(move) >= 0 to extending all captures doesn't really make that much difference.
Also once the losing capture is done and it is really bad then futility pruning & nul move
will discard it quickly and the tree after the capture is usually very small.
Most people who does LMR does not reduce loosing captures which look perfect candidates,
I guess that it is because there is nothing to gain much there. IMO extending/reducing loosing captures
does not have a significant impact.

Also an extension does not have to be neutral. Many win-seeking extensions like the check,
passed pawn pushes etc are very speculative. IMO an extension can be anything that you think helps
your engine uderstand a position better as long as it does not explode the tree in other positons.

Using see() to refine extension of captures and passed pawn pushes is not a must if you want to
look at more threats and tree size remains acceptable .

About your test setup :
I don't think that those 5x2 positions contain the features you want to test.
You have too few positions, testing them against more engines do not add diversity.

Oh well there seems to be no conclusive way of testing changes, thats what I understood from
current CCC discussions. My guess is far small number of games will be needed to see a change
in this case because we are dealing with the most critical part of the engine, the selective part.

Do you know for sure that using more positions is better than using fewer positions with more engines of
equivalent strengh? Anyway the test that I am going to do is not going to prove/disprove
anything rather just spice up the discussion.(make it a bit scientifc)

About the results you will find. Scores won't tell us enought, it would be interesing to have some statistics about the number and kind of extensions trigered.

That I will do

Thanks for your input
Daniel

IMO extending/reducing loosing captures
does not have a significant impact.

Reducing losing captures in my engine seems to decrease its strength considerably even though it results to a much deeper search. It seems to reduce the tactical ability of the engine. I have not tried extending it.

What I have tried before was an idea from Toga where it extends in pv nodes when two consecutive captures are on the same square. It seems to work in complicated tactical positions. For example, a white piece captures a black piece on a square and a black piece recaptures on that square, I extend it.

My current implementation of the recapture extension was on pv nodes only and it considers the eval delta between the current node and the previous node.

Edsel

I am using Noomen test suite 2007 and 2008 for my testing but it is 30 positions. I think your setup is sufficient enough. Different extension configuration I think will give a big difference in performance so you don't really need a big number of positions and a lot of games. Lot of games is needed only if small eval changes are being tested.

Edsel

This is what I currently use:

At PV nodes:

• Check: One ply
• Single reply to check: One ply
• Capture leading to pawn endgame: One ply
• Passed pawn push: Half a ply
• Winning or equal captures (all captures, not just recaptures) of a piece bigger than a pawn: Half a ply

At non-PV nodes:

• Single reply to check: One ply
• Capture leading to pawn endgame: One ply
• Check: Half a ply
• Pawn to 7th rank: Half a ply

The most unusual thing is perhaps that I extend checks by only half a ply at non-PV nodes. This causes my program to occasionally miss perpetual check draws, but I think the smaller tree size is worth the price.

One of the top things on my todo list when (and if) I get back to computer chess is to experiment with different extension, pruning and reduction criteria at direct children of PV nodes. It makes some sense to be a little more conservative at such nodes than at ordinary non-PV nodes.

Tord

Tord Romstad wrote:This is what I currently use:

At PV nodes:

• Check: One ply
• Single reply to check: One ply
• Capture leading to pawn endgame: One ply
• Passed pawn push: Half a ply
• Winning or equal captures (all captures, not just recaptures) of a piece bigger than a pawn: Half a ply

At non-PV nodes:

• Single reply to check: One ply
• Capture leading to pawn endgame: One ply
• Check: Half a ply
• Pawn to 7th rank: Half a ply

The most unusual thing is perhaps that I extend checks by only half a ply at non-PV nodes. This causes my program to occasionally miss perpetual check draws, but I think the smaller tree size is worth the price.

One of the top things on my todo list when (and if) I get back to computer chess is to experiment with different extension, pruning and reduction criteria at direct children of PV nodes. It makes some sense to be a little more conservative at such nodes than at ordinary non-PV nodes.

Tord

Hi Tord,

just wondering.

I think it's the first 2 plies. We want to check if the first ply stays a fh and the 2nd a fl, so maybe 1st ply and first 4 from 2nd are in 1 group.

Then 1 and 2 ply children again are new group etc. Because these are less likely to influence PV ( is that true ?)

The further away the group, the lower extensions / bigger reductions.

Tony

xinix wrote:Hi Tord,

just wondering.

I think it's the first 2 plies. We want to check if the first ply stays a fh and the 2nd a fl, so maybe 1st ply and first 4 from 2nd are in 1 group.

Then 1 and 2 ply children again are new group etc. Because these are less likely to influence PV ( is that true ?)

The further away the group, the lower extensions / bigger reductions

Yes, I agree. The probability that a node has influence on the root score depends on the distance to the closest PV node, and on the indices of its ancestor nodes (along the path up to the closest PV node) among their siblings. It seems reasonable to take bigger risks at nodes which are unlikely to influence the root.

One of my plans in the slightly longer term is to collect statistics about precisely how a node's probability of influencing the root score depends on its coordinates in the search tree, and use this to improve the efficiency and accuracy of my selective search (this will almost certainly introduce some new search inconsistencies, but I hope it won't be a too big problem in practice). Trying to do things somewhat differently in direct children of PV nodes is just a preliminary experiment to decide whether the much more general idea is worth a closer look.

Tord

Tord Romstad wrote:This is what I currently use:

At PV nodes:

• Check: One ply
• Single reply to check: One ply
• Capture leading to pawn endgame: One ply
• Passed pawn push: Half a ply
• Winning or equal captures (all captures, not just recaptures) of a piece bigger than a pawn: Half a ply

At non-PV nodes:

• Single reply to check: One ply
• Capture leading to pawn endgame: One ply
• Check: Half a ply
• Pawn to 7th rank: Half a ply

The most unusual thing is perhaps that I extend checks by only half a ply at non-PV nodes. This causes my program to occasionally miss perpetual check draws, but I think the smaller tree size is worth the price.

One of the top things on my todo list when (and if) I get back to computer chess is to experiment with different extension, pruning and reduction criteria at direct children of PV nodes. It makes some sense to be a little more conservative at such nodes than at ordinary non-PV nodes.

Tord

I think that all these simple formulas seem to me too simple to be good.

Extending all checks by the same number of plies(half ply) at non pv nodes seem illogical to me.

You may want to extend more good checks and not to extend bad checks.
You may want to extend more when the result of the game is unclear and extend less when the result of the game is clear.

Uri

Uri Blass wrote:Extending all checks by the same number of plies(half ply) at non pv nodes seem illogical to me.

You may want to extend more good checks and not to extend bad checks.
You may want to extend more when the result of the game is unclear and extend less when the result of the game is clear.

Absolutely. The problem is to find good practical criterions for good checks, bad checks and whether the result of the game is clear. My attempts to classify good and bad checks have always failed. The most successful attempt was to simply look at the SEE value and only extend non-losing checks. This seemed to perform approximately as well as (but not better than) extending all checks equally much.

Tord

Tord Romstad wrote:Yes, I agree. The probability that a node has influence on the root score depends on the distance to the closest PV node, and on the indices of its ancestor nodes (along the path up to the closest PV node) among their siblings. It seems reasonable to take bigger risks at nodes which are unlikely to influence the root.

One of my plans in the slightly longer term is to collect statistics about precisely how a node's probability of influencing the root score depends on its coordinates in the search tree, and use this to improve the efficiency and accuracy of my selective search (this will almost certainly introduce some new search inconsistencies, but I hope it won't be a too big problem in practice). Trying to do things somewhat differently in direct children of PV nodes is just a preliminary experiment to decide whether the much more general idea is worth a closer look.

Tord

But isn't it exactly the opposite of what you do today ? Glaurung is one of the only (open source) engine that do LMR at PV sibblings ; there is one version of Toga that does reduction of 'bad' captures at PV sibblings too.
Or did I miss something ?

Note that I have not been able to do reductions at pv sibblings without a drop of strenght. But I think that this is a (common) side effect of the incorrect handling of hash table depth in reduced branches.

HJ.

FYI, what I use :

(Note that Cyrano does not handle fractional plies)

At PV nodes: (there is no reduction here)

- Check: One ply
- Single reply to check: One ply
- Capture leading to pawn endgame: not handled (not tested)
- Passed pawn push: One ply
- Winning or equal captures : not handled
- Recaptures with see() >= (knight-rook) : One ply
- Threats in stand pat positions (qsearch) : One ply


At non-PV nodes:

- Check: One ply (see (1))
- Single reply to check: One ply
- Capture leading to pawn endgame: not handled (not tested)
- Passed pawn push: no reduction
- Pawn to 7th rank: no reduction
- Winning or loosing captures, recaptures : no reduction
- A lot of moves are not reduced (killer moves, counter moves, moves related to threats, etc)

(1) : checks are extented, but are then reduced if the in-check side can do a winning capture

HJ.

Tord Romstad wrote:

Uri Blass wrote:Extending all checks by the same number of plies(half ply) at non pv nodes seem illogical to me.

You may want to extend more good checks and not to extend bad checks.
You may want to extend more when the result of the game is unclear and extend less when the result of the game is clear.

Absolutely. The problem is to find good practical criterions for good checks, bad checks and whether the result of the game is clear. My attempts to classify good and bad checks have always failed. The most successful attempt was to simply look at the SEE value and only extend non-losing checks. This seemed to perform approximately as well as (but not better than) extending all checks equally much.

Tord

In that case you can try simply to look at SEE value together with more factors that vefiry that the check is a bad check.

I can easily think of some possible conditions(the opponent is the side that has to escape from check):

1)The opponent has a good capture not with the king.
2)There is no indirect threat in the move that gives check.
3)The checking piece is undefended.
4)No squares near the king are attacked by pieces of the attacker(except
squares that are attacked by the piece that gives the check)

Uri

Tord Romstad wrote:Absolutely. The problem is to find good practical criterions for good checks, bad checks and whether the result of the game is clear. My attempts to classify good and bad checks have always failed. The most successful attempt was to simply look at the SEE value and only extend non-losing checks. This seemed to perform approximately as well as (but not better than) extending all checks equally much.

Tord

I tested that a while back (before LMR, so it might be different now)

The biggest problem seemed to be a bad check that distracted a defender.
It didn't happen that often, but it does seem to make that last-few-ply-braching-factor go seriously up ( like not doing checks in qs, and lazy eval)

Tony

I have prepared the five different versions. One slight modification I made
is the "all captures at pv" extension is now replaced with "winning captures and any capture from hash table". I am going to select randomly 10 positons from Silver test suite and start the games with the following engines. - StraightLogic;)
- Glaurung.
- Thinker 5.2I
- Spike 1.2
- The King
REquest: Can someone email me new Thinker becasue I can not access geocities from here.

Daniel

The only thing I tried to limit the check extension is to skip the first checks (Ed Schroeder's idea). And it was not that good when I tested it.
I use See to filter checks only in qsearch.

As to reduction at PV nodes, I used to reduce those after the 7th move. That I did until v1.91 of scorpio but recent testing revealed that it is not that bad even though at that time it lost like 1 ply search depth. The PV will be more stable which is the reason I chose it. But then again I still think we shoud do reduction there also.

Deep search depth seems to be the advantage of most of todays top engines. Last week I was surprized to find out Strelka does not do anything other than checks, which motivated me to test it. But I think that there might also be a way to cope up with the old-style extensions which seem way too much nowadays. Hiaracs seem to survive that way I guess.

[quote]
and if
[\quote]
I think it is good to take a break once in a while. My scocial life really degraded when I used to spend too much time in chess:)

Daniel

cheers
Daneil