Moderator: Ras
Greenblatt used an idea like this in MackHack years ago. The problem is, stepping forward more than one ply forces you to follow the PV as given, but what if that is no longer the best path due to your now deeper search????jhaglund wrote:Has anyone tried a SFSB approach with a search?
Take a PV_line @ ply x and Step_Forward y ply and see if it's still okay
if (fail)
Step_Back please and take another look at the next PV move in the move list
and
Repeat
y can be base on the score in the relation to plies +/-...
if after y plies and
if(good)
force PV line to y ply
PV = PV_Line[x] + forced_pv_line[y];
Joshua
Yes, the only way to know is to try it.Greenblatt used an idea like this in MackHack years ago. The problem is, stepping forward more than one ply forces you to follow the PV as given, but what if that is no longer the best path due to your now deeper search????
The idea is to look ahead to see if the pv is any good before it's too late by scouting the PV line ahead to see if fails there instead at the root where it's too late... Otherwise, step_back and try the next move in the move list.if (fail)
Step_Back please and
take another look at the next PV move in the move list
I understood the idea. The downfall is that when you "step forward" you are being selective, because you follow the PV from the current N ply search. You go down a couple (or few) moves and search from there. But a deeper search might find a better alternative for any of the moves you just stepped over.jhaglund wrote:Yes, the only way to know is to try it.Greenblatt used an idea like this in MackHack years ago. The problem is, stepping forward more than one ply forces you to follow the PV as given, but what if that is no longer the best path due to your now deeper search????
Also, I said:The idea is to look ahead to see if the pv is any good before it's too late by scouting the PV line ahead to see if fails there instead at the root where it's too late... Otherwise, step_back and try the next move in the move list.if (fail)
Step_Back please and
take another look at the next PV move in the move list
Why would you keep a worse score? It would be same as to keeping a bad move.Greenblatt stepped way down the PV, did a short search, and if the score was worse he kept it,
Because this is a _highly_ dangerous form of pruning. Greenblatt used this as a way to diminish the horizon effect. Taking it as a pessimistic bound on the score. Otherwise you make critical mistakes because you trust the original PV to have the best moves, even though you are fixing to add another couple of plies at the end.jhaglund wrote:Why would you keep a worse score? It would be same as to keeping a bad move.Greenblatt stepped way down the PV, did a short search, and if the score was worse he kept it,
Too many obvious flaws to the idea, and with the depth we are seeing today, it seems counter-productive.
It would be like playing out y moves and hitting analyze(); ...
if (analyze < [window(s)])
return to root+x and try the next move in the list...
Given the new hardware and tuning you can accomplish, I dont see why you don't try it today.
I did something like that for an alternative form of quiescent search.jhaglund wrote:Has anyone tried a SFSB approach with a search?
Take a PV_line @ ply x and Step_Forward y ply and see if it's still okay
if (fail)
Step_Back please and take another look at the next PV move in the move list
and
Repeat
y can be base on the score in the relation to plies +/-...
if after y plies and
if(good)
force PV line to y ply
PV = PV_Line[x] + forced_pv_line[y];
Joshua
Good to hear.I did something like that for an alternative form of quiescent search.
I think 1 is way too low.The basic idea was to have a search with a branching factor close to 1 but which follows the normal search pattern instead of only captures.
Being restrictive to just the Best move is where it fails...I called it BMOBUN (Best Move Only, Back Up N).
N is a parameter supplied to the search which tells how many times you are allowed to back up and try an alternative.
The purpose would be for move ordering, based on jumping a head x moves and then steping back anyway to the next move in the list...You will not want to use this method for your regular search (absolutely, definitely not).
It sounds like a good idea to me for the root search because a little effort there will give a lot of return. I would be curious to see how it does in the general case.jhaglund wrote:Good to hear.I did something like that for an alternative form of quiescent search.
I think 1 is way too low.The basic idea was to have a search with a branching factor close to 1 but which follows the normal search pattern instead of only captures.
Being restrictive to just the Best move is where it fails...I called it BMOBUN (Best Move Only, Back Up N).
N is a parameter supplied to the search which tells how many times you are allowed to back up and try an alternative.
The purpose would be for move ordering, based on jumping a head x moves and then steping back anyway to the next move in the list...You will not want to use this method for your regular search (absolutely, definitely not).
First you would order your moves... then you would go down the list and
search ...
you would be searching y plies ahead of x and ordering the moves based on the end search of y.
example
PV = 1. e4 e5 2. Nf3 Nc6 3.Bb5....
ply = 5;
bestmove = e4
2nd = d4
3rd = Nf3
4th = c4
...
second search = PV = 1. e4 e5 2. Nf3 Nc6 3.Bb5(forced)3. Bb5 a6 4. Nxc6 bxc6 5. 0-0
ply = 9!
best move = Bb5
2nd = d4
3rd = Bb4
4th = Nc3
...
a concurrent search at the end of each PV.
So the actual PV could be displayed either:
ply 5, PV = 1. e4 e5 2. Nf3 Nc6 3.Bb5
or
ply 9, PV = 1. e4 e5 2. Nf3 Nc6 3. Bb5 a6 4. Nxc6 bxc6 5. 0-0
The step forward would be the second search();
The step back would be going back to the move list and trying the next move, especially if it fails...
You would have 2 or more PV scores to compare if needed.
How you initialize this is up too you. I'd use another thread for the concurrent second search();...
Multiply threads for even more then two, three, etc. searches if desired.
If you jumped to the end of each search(), you could really really increase your depth...
Understand still?
I'm sure it would be revolutionary! Thanks for your support DannIt sounds like a good idea to me for the root search because a little effort there will give a lot of return. I would be curious to see how it does in the general case.
