Stockfish Singular Extension, does it make sense?

[Mangar]

Hi,

I just tried to implement singular extension (I did it a lot of times before ...) in Spike using the Stockfish implementation. I detected some undesired behaveior.

To explain I will first discuss why to extend moves. In my opignon there are two possible reasons: To find out the move is better or worse than a shallow search will reveal. The Singular extension is a "find out if it is worse" extension. The move is good, but it is the only one. If we find out it is not good the position will suddenly drop to bad. Thus we will find out if the move is really good by searching deeper.

Now the behavior spottet in a pv move right after increasing the search depth:
Take the move from a hash entry if the value is a fail high or exact value (it is as good or better). Then test it for singular extension. If it is the only move then search deeper. Now it the deeper search reveals a bad - fail low move it may result in a pv fail low.
As the position has been searched at high depth the fail low will be written in hash overwriting the last entry. Now there is a fail low value for the position in hash.
As the whole pv failed low a research with larger window is done. Coming back to the same situation the hash will give us a fail low value. Thus on research it does not try a singular extension, searching the move with normal depth. As the +1 depth was needed to find out the move is bad search is now very happy and back at its old value.
The time control no longer increases time to spend for the move as the value is good now, the move is played ... shit.

Anything I do wrong here? a known drawback? Or something new I discovered?

Greetings Volker

[Mangar]

Example search-tree of spike (hard to read):
PV = PV search
w: ..; .. (Search window - 2 == 1cp)
d: Search depth; 4 == 1ply
v: value (entering node -> position value, leaving node -> search value)
m: move
SEX: SingularEXtension search

// Search of positon:
// setboard r3r1k1/1pq2pp1/2p2n2/1PNn4/2QN2b1/6P1/3RPP2/2R3KB b - - 0 1
// Search tree of moves: a8d8 b5c6
// First search b7c6 is searched with d==24 (6 plys), research with d==20 (5 plys).

// First search:
[m:----][ROT][PV][w: -74; 46][d:28][v: -192][ 53185]
[m:a8d8][PV ][PV][w: -46; 74][d:24][v: -111][ 53186]
[m:b5c6][PV ][PV][w: -74; 46][d:24][v: 151][ 53261]
[m: nm][NUL][CT][w: 45; 46][d: 8][v: -12][ 53281][BETA]
// Singular extension search on node after a8d8 b5c6
[m:b5c6][SEX][AL][w: -55; -54][d:12][v: 151][ 53282]
[m:d5b6][FUL][CT][w: -55; -54][d: 8][v: -106][ 53305][BETA]
[m:g4e2][FUL][CT][w: -55; -54][d: 8][v: -597][ 53306][HASH]
[m:e8e2][FUL][CT][w: -55; -54][d: 8][v: -562][ 53307][HASH]
[m:c7c6][FUL][CT][w: -55; -54][d: 8][v: -969][ 53308][HASH]
[m:c7g3][FUL][CT][w: -55; -54][d:12][v:-1239][ 53309][HASH]
[m:d8a8][LMR][CT][w: -75; -74][d: 2][v: -595][ 53310][HASH]
[m:b7b5][LMR][CT][w: -75; -74][d: 1][v: -80][ 53311][HASH]
[m:b7b6][FLQ][CT][w: -55; -54][d: 1][v: -112][ 53312][BETA]
[m:d5e3][FLQ][CT][w: -55; -54][d: 1][v: -58][ 53315][BETA]
[m:d5b4][FLQ][CT][w: -55; -54][d: 1][v: -77][ 53316][BETA]
[m:d5c3][FLQ][CT][w: -55; -54][d: 1][v: -120][ 53317][BETA]
[m:d5f4][FLQ][CT][w: -55; -54][d: 1][v: -182][ 53318][BETA]
[m:d8d7][FLQ][CT][w: -55; -54][d: 1][v: -295][ 53319][BETA]
[m:d8d6][FLQ][CT][w: -55; -54][d: 1][v: -273][ 53320][BETA]
[m:g4e6][FLQ][CT][w: -55; -54][d: 1][v: -288][ 53321][BETA]
[m:f6e4][FLQ][CT][w: -55; -54][d: 1][v: -173][ 53322][HASH]
[m:f6h5][FLQ][CT][w: -55; -54][d: 1][v: -200][ 53323][BETA]
[m:f6d7][FLQ][CT][w: -55; -54][d: 1][v: -292][ 53324][BETA]
[m:f6h7][FLQ][CT][w: -55; -54][d: 1][v: -186][ 53325][BETA]
[m:g4h5][FLQ][CT][w: -55; -54][d: 1][v: -266][ 53326][BETA]
[m:g4f5][FLQ][CT][w: -55; -54][d: 1][v: -365][ 53327][BETA]
[m:d5e7][FLQ][CT][w: -55; -54][d: 1][v: -126][ 53328][BETA]
[m:g4d7][FLQ][CT][w: -55; -54][d: 1][v: -372][ 53329][BETA]
[m:g4c8][FLQ][CT][w: -55; -54][d: 1][v: -304][ 53330][BETA]
[m:g4h3][FLQ][CT][w: -55; -54][d: 1][v: -228][ 53331][BETA]
[m:g4f3][FLQ][CT][w: -55; -54][d: 1][v: -132][ 53332][BETA]
[m:e8e7][FLQ][CT][w: -55; -54][d: 1][v: -236][ 53333][BETA]
[m:e8e6][FLQ][CT][w: -55; -54][d: 1][v: -221][ 53334][BETA]
[m:e8e5][FLQ][CT][w: -55; -54][d: 1][v: -215][ 53335][BETA]
[m:e8e4][FLQ][CT][w: -55; -54][d: 1][v: -149][ 53336][BETA]
[m:e8e3][FLQ][CT][w: -55; -54][d: 1][v: -228][ 53337][BETA]
[m:e8f8][FLQ][CT][w: -55; -54][d: 1][v: -247][ 53338][BETA]
[m:g7g5][FLQ][CT][w: -55; -54][d: 1][v: -295][ 53339][BETA]
[m:g8f8][FLQ][CT][w: -55; -54][d: 1][v: -225][ 53340][BETA]
[m:d8c8][FLQ][CT][w: -55; -54][d: 1][v: -249][ 53341][BETA]
[m:d8b8][FLQ][CT][w: -55; -54][d: 1][v: -264][ 53342][BETA]
[m:g7g6][FLQ][CT][w: -55; -54][d: 1][v: -262][ 53343][BETA]
[m:c7b8][FLQ][CT][w: -55; -54][d: 1][v: -208][ 53344][BETA]
[m:c7d6][FLQ][CT][w: -55; -54][d: 1][v: -165][ 53345][BETA]
[m:c7e5][FLQ][CT][w: -55; -54][d: 1][v: -200][ 53346][BETA]
[m:c7f4][FLQ][CT][w: -55; -54][d: 1][v: -184][ 53347][BETA]
[m:c7b6][FLQ][CT][w: -55; -54][d: 1][v: -176][ 53348][BETA]
[m:c7a5][FLQ][CT][w: -55; -54][d: 1][v: -110][ 53349][BETA]
[m:c7c8][FLQ][CT][w: -55; -54][d: 1][v: -233][ 53350][BETA]
[m:c7d7][FLQ][CT][w: -55; -54][d: 1][v: -275][ 53351][BETA]
[m:c7e7][FLQ][CT][w: -55; -54][d: 1][v: -176][ 53352][BETA]
[m:g8h7][FLQ][CT][w: -55; -54][d: 1][v: -216][ 53353][BETA]
[m:g8h8][FLQ][CT][w: -55; -54][d: 1][v: -208][ 53354][BETA]
[m:b5c6][SEX][AL][w: 54; 55][d:12][v: 58][ 53354][DONE]
// Singular extension has been finished on "AL" == ALL-Node returning value 58 and "DONE" (no beta cutoff found).
[m:b7c6][SEX][AL][w: 26; 27][d:12][v: 27][ 53433][DONE]
// Thus b7c6 is searched with d==24 as PV node with a BETA cutoff when searching it. The result value is -74
[m:b7c6][PV ][PV][w: -74; 46][d:24][v: -74][ 71434][BETA]
[m:d5b6][FUL][CT][w: -74; -73][d:20][v: -95][ 72010][BETA]
[m:g4e2][FUL][CT][w: -74; -73][d:20][v: -80][ 72332][BETA]
[m:e8e2][FUL][CT][w: -74; -73][d:20][v: -108][ 72547][BETA]
[m:c7c6][FUL][CT][w: -74; -73][d:20][v: -78][ 72720][NULL]
[m:c7g3][FUL][CT][w: -74; -73][d:24][v: -175][ 72878][BETA]
[m:d5b4][FUL][CT][w: -74; -73][d:20][v: -111][ 73092][BETA]
[m:c7e5][LMR][CT][w: -94; -93][d:12][v: -140][ 73101][NULL]
[m:b7b5][LMR][CT][w: -94; -93][d:12][v: -96][ 73164][BETA]
[m:b7b6][LMR][AL][w: -94; -93][d:12][v: -120][ 73438][BETA]
[m:d8d6][LMR][CT][w: -94; -93][d:12][v: -113][ 73569][BETA]
[m:d5e3][LMR][AL][w: -94; -93][d:12][v: -42][ 73899][DONE]
[m:d5e3][FUL][CT][w: -74; -73][d:20][v: -76][ 75113][BETA]
[m:d8d7][LMR][CT][w: -94; -93][d:12][v: -164][ 75120][NULL]
[m:c7b8][LMR][CT][w: -94; -93][d:12][v: -148][ 75126][NULL]
[m:d8a8][LMR][CT][w: -94; -93][d:12][v: -595][ 75127][HASH]
[m:e8e4][LMR][CT][w: -94; -93][d:12][v: -838][ 75135][BETA]
[m:g7g6][LMR][CT][w: -94; -93][d:12][v: -160][ 75223][BETA]
[m:d5f4][LMR][CT][w: -94; -93][d:12][v: -112][ 75307][BETA]
[m:g8f8][LMR][CT][w: -94; -93][d:12][v: -114][ 75397][BETA]
[m:d5e7][LMR][CT][w: -94; -93][d:12][v: -108][ 75488][BETA]
[m:g4h5][LMR][CT][w: -94; -93][d:12][v: -114][ 75564][BETA]
[m:g4f5][LMR][CT][w: -94; -93][d:12][v: -305][ 75568][NULL]
[m:g4e6][LMR][CT][w: -94; -93][d:12][v: -122][ 75605][NULL]
[m:g4d7][LMR][CT][w: -94; -93][d:12][v: -132][ 75609][NULL]
[m:g4c8][LMR][CT][w: -94; -93][d:12][v: -106][ 75724][BETA]
[m:g4h3][LMR][CT][w: -94; -93][d:12][v: -114][ 75817][BETA]
[m:g4f3][LMR][CT][w: -94; -93][d:12][v: -682][ 75822][BETA]
[m:e8e7][LMR][CT][w: -94; -93][d:12][v: -114][ 75905][BETA]
[m:e8e6][LMR][CT][w: -94; -93][d:12][v: -156][ 75915][NULL]
[m:e8e5][LMR][CT][w: -94; -93][d:12][v: -114][ 76013][BETA]
[m:f6h5][LMR][CT][w: -94; -93][d:12][v: -599][ 76024][BETA]
[m:e8e3][LMR][CT][w: -94; -93][d:12][v: -168][ 76029][NULL]
[m:e8f8][LMR][CT][w: -94; -93][d:12][v: -114][ 76105][BETA]
[m:f6d7][LMR][CT][w: -94; -93][d:12][v: -102][ 76156][NULL]
[m:f6e4][LMR][CT][w: -94; -93][d:12][v: -625][ 76164][BETA]
[m:d8c8][LMR][CT][w: -94; -93][d:12][v: -583][ 76175][BETA]
[m:d8b8][LMR][CT][w: -94; -93][d:12][v: -589][ 76186][BETA]
[m:d5c3][LMR][CT][w: -94; -93][d:12][v: -619][ 76196][BETA]
[m:f6h7][LMR][CT][w: -94; -93][d:12][v: -613][ 76206][BETA]
[m:c7d6][LMR][CT][w: -94; -93][d:12][v: -118][ 76284][BETA]
[m:g7g5][LMR][CT][w: -94; -93][d:12][v: -191][ 76368][BETA]
[m:c7f4][LMR][CT][w: -94; -93][d:12][v:-1503][ 76374][BETA]
[m:c7b6][LMR][CT][w: -94; -93][d:12][v: -95][ 76478][BETA]
[m:c7a5][LMR][AL][w: -94; -93][d:12][v: -107][ 76717][BETA]
[m:c7c8][LMR][CT][w: -94; -93][d:12][v: -124][ 76778][BETA]
[m:c7d7][LMR][CT][w: -94; -93][d:12][v: -215][ 76782][NULL]
[m:c7e7][LMR][CT][w: -94; -93][d:12][v: -116][ 76789][NULL]
[m:g8h7][LMR][CT][w: -94; -93][d:12][v: -98][ 76849][BETA]
[m:g8h8][LMR][CT][w: -94; -93][d:12][v: -99][ 76930][BETA]
[m:b5c6][PV ][PV][w: -46; 74][d:24][v: 74][ 76930][DONE]
[m:a8d8][PV ][PV][w: -74; 46][d:24][v: -74][ 76930][BETA]

// Research with larger window
[m:----][ROT][PV][w: -474; 326][d:28][v: -192][ 76931]
[m:a8d8][PV ][PV][w: -326; 474][d:24][v: -111][ 76932]
[m:b5c6][PV ][PV][w: -474; 326][d:24][v: 151][ 76980]
// No singular extension search here. Thus b7c6 is searched at depth == 20. giving a value of -14 with a "DONE" node (all moves searched, no beta cutoff)
[m:b7c6][PV ][PV][w: -474; 326][d:20][v: -14][ 78264][DONE]
[m:d5b6][FUL][CT][w: -14; -13][d:20][v: -95][ 78265][HASH]
[m:g4e2][FUL][CT][w: -14; -13][d:20][v: -80][ 78266][HASH]
[m:e8e2][FUL][CT][w: -14; -13][d:20][v: -108][ 78267][HASH]
[m:c7c6][FUL][CT][w: -14; -13][d:20][v: -78][ 78268][HASH]
[m:c7g3][FUL][CT][w: -14; -13][d:24][v: -175][ 78269][HASH]
[m:b7b6][LMR][CT][w: -34; -33][d:13][v: -59][ 78336][BETA]
[m:f6e4][LMR][CT][w: -34; -33][d:12][v: -625][ 78337][HASH]
[m:b7b5][LMR][CT][w: -34; -33][d:12][v: -96][ 78338][HASH]
[m:g4h3][LMR][CT][w: -34; -33][d:12][v: -114][ 78339][HASH]
[m:d8d6][LMR][CT][w: -34; -33][d:12][v: -113][ 78340][HASH]
[m:d5b4][LMR][CT][w: -34; -33][d:12][v: -111][ 78341][HASH]
[m:c7a5][LMR][CT][w: -34; -33][d:12][v: -107][ 78342][HASH]
[m:c7e5][LMR][CT][w: -34; -33][d:12][v: -140][ 78343][HASH]
[m:d5e3][LMR][CT][w: -34; -33][d:12][v: -76][ 78344][HASH]
[m:d8d7][LMR][CT][w: -34; -33][d:12][v: -164][ 78345][HASH]
[m:f6h5][LMR][CT][w: -34; -33][d:12][v: -599][ 78346][HASH]
[m:d5f4][LMR][CT][w: -34; -33][d:12][v: -112][ 78347][HASH]
[m:g8f8][LMR][CT][w: -34; -33][d:12][v: -114][ 78348][HASH]
[m:d5e7][LMR][CT][w: -34; -33][d:12][v: -108][ 78349][HASH]
[m:g4h5][LMR][CT][w: -34; -33][d:12][v: -114][ 78350][HASH]
[m:g4f5][LMR][CT][w: -34; -33][d:12][v: -305][ 78351][HASH]
[m:g4e6][LMR][CT][w: -34; -33][d:12][v: -122][ 78352][HASH]
[m:g4d7][LMR][CT][w: -34; -33][d:12][v: -132][ 78353][HASH]
[m:g4c8][LMR][CT][w: -34; -33][d:12][v: -106][ 78354][HASH]
[m:g7g6][LMR][CT][w: -34; -33][d:12][v: -160][ 78355][HASH]
[m:g4f3][LMR][CT][w: -34; -33][d:12][v: -682][ 78356][HASH]
[m:e8e7][LMR][CT][w: -34; -33][d:12][v: -114][ 78357][HASH]
[m:e8e6][LMR][CT][w: -34; -33][d:12][v: -156][ 78358][HASH]
[m:e8e5][LMR][CT][w: -34; -33][d:12][v: -114][ 78359][HASH]
[m:e8e4][LMR][CT][w: -34; -33][d:12][v: -838][ 78360][HASH]
[m:e8e3][LMR][CT][w: -34; -33][d:12][v: -168][ 78361][HASH]
[m:e8f8][LMR][CT][w: -34; -33][d:12][v: -114][ 78362][HASH]
[m:d5c3][LMR][CT][w: -34; -33][d:12][v: -619][ 78363][HASH]
[m:g7g5][LMR][CT][w: -34; -33][d:12][v: -191][ 78364][HASH]
[m:d8c8][LMR][CT][w: -34; -33][d:12][v: -583][ 78365][HASH]
[m:d8b8][LMR][CT][w: -34; -33][d:12][v: -589][ 78366][HASH]
[m:d8a8][LMR][CT][w: -34; -33][d:12][v: -595][ 78367][HASH]
[m:c7b8][LMR][CT][w: -34; -33][d:12][v: -148][ 78368][HASH]
[m:c7d6][LMR][CT][w: -34; -33][d:12][v: -118][ 78369][HASH]
[m:f6h7][LMR][CT][w: -34; -33][d:12][v: -613][ 78370][HASH]
[m:c7f4][LMR][CT][w: -34; -33][d:12][v:-1503][ 78371][HASH]
[m:c7b6][LMR][CT][w: -34; -33][d:12][v: -95][ 78372][HASH]
[m:f6d7][LMR][CT][w: -34; -33][d:12][v: -102][ 78373][HASH]
[m:c7c8][LMR][CT][w: -34; -33][d:12][v: -124][ 78374][HASH]
[m:c7d7][LMR][CT][w: -34; -33][d:12][v: -215][ 78375][HASH]
[m:c7e7][LMR][CT][w: -34; -33][d:12][v: -116][ 78376][HASH]
[m:g8h7][LMR][CT][w: -34; -33][d:12][v: -98][ 78377][HASH]
[m:g8h8][LMR][CT][w: -34; -33][d:12][v: -99][ 78378][HASH]
[m:b5c6][PV ][PV][w: -326; 474][d:24][v: 14][ 78378][DONE]
[m:a8d8][PV ][PV][w: -474; 326][d:24][v: -14][ 85278][DONE]

[Eelco de Groot]

Hi,

I just tried to implement singular extension (I did it a lot of times before ...) in Spike using the Stockfish implementation. I detected some undesired behaveior.

To explain I will first discuss why to extend moves. In my opignon there are two possible reasons: To find out the move is better or worse than a shallow search will reveal. The Singular extension is a "find out if it is worse" extension. The move is good, but it is the only one. If we find out it is not good the position will suddenly drop to bad. Thus we will find out if the move is really good by searching deeper.

Now the behavior spottet in a pv move right after increasing the search depth:
Take the move from a hash entry if the value is a fail high or exact value (it is as good or better). Then test it for singular extension. If it is the only move then search deeper. Now it the deeper search reveals a bad - fail low move it may result in a pv fail low.
As the position has been searched at high depth the fail low will be written in hash overwriting the last entry. Now there is a fail low value for the position in hash.
As the whole pv failed low a research with larger window is done. Coming back to the same situation the hash will give us a fail low value. Thus on research it does not try a singular extension, searching the move with normal depth. As the +1 depth was needed to find out the move is bad search is now very happy and back at its old value.
The time control no longer increases time to spend for the move as the value is good now, the move is played ... shit.

Anything I do wrong here? a known drawback? Or something new I discovered?

Greetings Volker

Hello Volker,

It would have to be tested by numbers, but my feeling is that extending the hash move in a PV node is of limited value and not really what this is all about. The gains to be had are more I think in the bulk of the searchtree, where you just can't extend everything and you have to make choices.

Most extensions in non-PV nodes are based on the classification what sort of move it is, and those extensions are important. You also can extend on the approximate move value, then you are more on the terrain of (extension counterpart of) futility pruning. I see the singular extensions as more related to the extension counterpart of Late Move Reductions, if there is some reasonable sorting in the move list you can reduce the last moves or extend the first, I have called that Early Move Extensions. Singular Extensions are related to this. It is not about absolute quality or absolute quantity of move value but about the relative value of a move in this node compared to other moves in this node.

If you can look at only one move in a non PV node you will look at the most promising with the limited data that you have, the relative value to other moves in the node may have good enough guessing value to warrant an extension, an extension that may trigger a beta cutoff where a limited search may not.

The real power of the exclusion search has not yet been unleashed in Stockfish I think, at least I have not yet seen it and that is somewhat surprising because there are some very obvious ideas here. But I have not yet studied the new search of Stockfish, maybe I missed it My five cents, but I am a little out of practice about the specifics of Stockfish code.

Regards, Eelco

[bob]

Hi,

I just tried to implement singular extension (I did it a lot of times before ...) in Spike using the Stockfish implementation. I detected some undesired behaveior.

To explain I will first discuss why to extend moves. In my opignon there are two possible reasons: To find out the move is better or worse than a shallow search will reveal. The Singular extension is a "find out if it is worse" extension. The move is good, but it is the only one. If we find out it is not good the position will suddenly drop to bad. Thus we will find out if the move is really good by searching deeper.

Now the behavior spottet in a pv move right after increasing the search depth:
Take the move from a hash entry if the value is a fail high or exact value (it is as good or better). Then test it for singular extension. If it is the only move then search deeper. Now it the deeper search reveals a bad - fail low move it may result in a pv fail low.
As the position has been searched at high depth the fail low will be written in hash overwriting the last entry. Now there is a fail low value for the position in hash.
As the whole pv failed low a research with larger window is done. Coming back to the same situation the hash will give us a fail low value. Thus on research it does not try a singular extension, searching the move with normal depth. As the +1 depth was needed to find out the move is bad search is now very happy and back at its old value.
The time control no longer increases time to spend for the move as the value is good now, the move is played ... shit.

Anything I do wrong here? a known drawback? Or something new I discovered?

Greetings Volker

SE is a mixed bag. I once did the full Hsu SE implementation in Cray Blitz, and it was a complex thing to do. And even using Hsu's explicit explanation including tricky things like the sticky transposition table and such, there are still some interesting twists and turns. And after 2+ years of doing this, I _still_ got blown up at the last ACM event we went to where the thing caused the search to explode.

Moral is that this is not something you can just cut and paste and have it work, without lots of testing, tuning and hard work.

If you test for singularity, you have to use an offset window. That offset is almost certainly not going to be constant for all programs. Before you give up, sweat a little and see what happens. Every program is different. Each will respond differently to different ideas. Idea A works fine in program X but not in program Y. This is not unusual, it is actually expected behaviour once you do this stuff for a while.

[Daniel Shawul]

I tested it my self and unfortunately is in the garbage can for now. It slows down the search too much and doesn't seem to improve it at a fair tc (40/60sec). AFAIK I did the implementation alright maybe not well tuned. It is not really that difficult to implement even I did it in iterative search with something equivalent to implementing IID. So if it works for all programs with state of art search (by that I mean heavy reductions/prunings), it should have shown some promise already IMO. It definitely doesn't work for me if applied at every node.

The idea makes sense from the human thinking perspective but bear in mind that there is/was a lot of hype associated with singular extensions so the only objective evaluation you can get is by testing yourself. Even if it really works and gives something like 70 elo, people won't say it does hard but true So keep us posted with your progress. I will.

Daniel

[Mangar]

Hi Daniel,

the implementation of the stockfish idea was quite easy in spike. The only extension that really gives elo is the check - extension. I think that an extension that does not loose elo and gives better result in typical problem solving positions is ok too.

I allready have another implementation in mind. If it gives better result I will post it here.

Greetings Volker

[Mangar]

I see the singular extensions as more related to the extension counterpart of Late Move Reductions, if there is some reasonable sorting in the move list you can reduce the last moves or extend the first, I have called that Early Move Extensions. Singular Extensions are related to this. It is not about absolute quality or absolute quantity of move value but about the relative value of a move in this node compared to other moves in this node.
Regards, Eelco

Hi Eleco,

in my opigion there is a little more about late move reduction than simply reducing the search depth. If you do not have a research at extended depth for the later moves early move extension will not be the same. On the other hand, if you research at later moves with the extended depth then early move extension is exactly the same as late move reduction.

A move that is not good at search depth n and is good at search depth n+1 has a high risk that the good result is not true. It is probably that only few evaluation calls have produced the good result. A move that is good at depth n and at depth n+1 is not as risky as there are probably more positions that can be reached with good eval result.

Thus maybe it is a good idea for a singlular move to search it at normal depth and then at depth + 1. I´ll try it ...

Greetings Volker

[Daniel Shawul]

Well I have no extensions in non-pv nodes now in the strict sense of the word. I got read of the check extension in the previous version, but i do not reduce it either. Things I used to extend before have now become don't reduce. This really gave me some elo and was somewhat surprising after years of 100 elo from check extension. Maybe I will try to not reduce singular moves instead of extending but it seems like a lot of effort just to avoid reduction but you never know..
EDIT: nevermind , I don't reduce first move anyway.

[zamar]

Moral is that this is not something you can just cut and paste and have it work, without lots of testing, tuning and hard work.

If this is really the case then I think we were extremely lucky with Stockfish. First implementation (and window size) we tried gave around +40 elo.

We of course tried to fine tune things, but were never able to improve.

[bob]

Moral is that this is not something you can just cut and paste and have it work, without lots of testing, tuning and hard work.

If this is really the case then I think we were extremely lucky with Stockfish. First implementation (and window size) we tried gave around +40 elo.

We of course tried to fine tune things, but were never able to improve.

It is easy enough to test. Singular extensions are on my to-do list since previous versions had SE. I did not like it at the time (made some impressively long PV outputs, but seemed to hurt overall, although this was well prior to cluster-testing being available. I will give this ip* idea a try when I have time and start to re-test the old SE code (code developed way back when Bruce Moreland and I were experimenting with a "cheap" implementation (cheap as compared to the full Hsu algorithm which is extremely complicated.)