Please try to focus on the fact that we are talking of pruning at node level, not pruning of the single move.....and no, it is not the same thing.
Absolutely and that's were (I think) the confusion comes from.
There are 2 ways of futility pruning.
1. Classic following Heinz model, move pruning, no need to involve QS.
2. Node pruning, try futility before move generation, QS is a must.
But our topic is razoring, not futility pruning. Heinz did apply razoring at the node level, look here again. The razoring condition triggers a depth reduction from pre-pre-frontier to pre-frontier. You are right about futility pruning + extended futility pruning but to me it seems Heinz did not razor moves.
Sven
As I always understood Heinz means move_futlity_pruning (not node) and razoring means a reduction. I could be wrong, the text does not deserve the beauty prize for clarity, the idea itself does
Sure, but you started your previous post with the goal to clean up some confusion, instead you even added more to it
And nobody else is going to clean it up, obviously, unless Bob and Marco stop refusing to answer my question a couple of posts above ...
I thought we were talking about "razoring". Which is the process of taking a move directly to q-search rather than pruning it and throwing it away without searching at all.
Razoring is taking a _position_ directly to quiescence search, not a move.
The idea is that the position is so bad that you would like to discard it.
But as Marco said, the opponent might have left a queen hanging.
So to make sure that does not happen you perform a qsearch.
Actually the idea applies to a move. In the context you are using, it is the move that led to this position. So this is a semantic issue. I did razoring decisions after making a move but before calling search. If you do it after calling search, it is simply slightly less efficient because in my case, I would drop into q-search, in your case, you have a call to search which does an early call to qsearch and then drops out... Operationally, they would produce identical results.
I thought we were talking about "razoring". Which is the process of taking a move directly to q-search rather than pruning it and throwing it away without searching at all.
Razoring is taking a _position_ directly to quiescence search, not a move.
The idea is that the position is so bad that you would like to discard it.
But as Marco said, the opponent might have left a queen hanging.
So to make sure that does not happen you perform a qsearch.
It seems that the only thing that is agreed between different experts here is that razoring can be applied either as a depth reduction or as directly dropping into q-search (which is a special kind of depth reduction, of course).
Disagreement is there about the question where exactly in the search razoring shall be applied. In contrast to Marco's remark above "it is not the same thing" I have the impression that both ways are possible in general, albeit under different conditions and viewpoints:
a) applying razoring at "node level", i.e. in the top part of a search function before starting the move loop, and
b) applying razoring to one particular move within the move loop.
The paper of Heinz describes his "limited razoring" in the sense of variant a). Bob, however, sees razoring in the sense of b), which I believe is possible, too.
Sven
They are actually the same thing. In my case, I applied razoring after making a move before calling search. In the second case, one makes the move, calls search, and lets it directly call q-search. Same tree. Same everything. One extra procedure call (the unnecessary call to search rather than directly calling qsearch...
Please try to focus on the fact that we are talking of pruning at node level, not pruning of the single move.....and no, it is not the same thing.
Absolutely and that's were (I think) the confusion comes from.
There are 2 ways of futility pruning.
1. Classic following Heinz model, move pruning, no need to involve QS.
2. Node pruning, try futility before move generation, QS is a must.
Exactly why is a node not EXACTLY the same thing as the result of making a move but doing whatever you want to do BEFORE calling search, rather than calling search and doing whatever you want to do at the TOP? Same thing. One extra procedure call is all I see... Standard AI vocabulary says a node is what is produced when you make a move. If you razor AFTER making a move, you are razoring at the successor node to the one you were passed into the search.
Please try to focus on the fact that we are talking of pruning at node level, not pruning of the single move.....and no, it is not the same thing.
Absolutely and that's were (I think) the confusion comes from.
There are 2 ways of futility pruning.
1. Classic following Heinz model, move pruning, no need to involve QS.
2. Node pruning, try futility before move generation, QS is a must.
But our topic is razoring, not futility pruning. Heinz did apply razoring at the node level, look here again. The razoring condition triggers a depth reduction from pre-pre-frontier to pre-frontier. You are right about futility pruning + extended futility pruning but to me it seems Heinz did not razor moves.
Sven
Again, when you read this, and look at his pseudo-code, I don't see where this matters at all. If you take the "limited razoring code" at the top of his search, and move it down to after the makemove in the main search loop, and you change the razoring code to use the new positoin makemove just created, rather than the starting position that was passed into search, you should get the SAME result, without the fairly small overhead of calling search an extra time.
Only question I didn't research was how he handles his "razoring" when he simply reduces the depth to nothing. His "logic" caused me lots of issues when I played with this, and that is how I actually discovered that one could safely do futility pruning 4 or even 5 plies from the tips, where he limits everything to the last 3 plies. But he doesn't count plies and depth like I do, and it is easy to get off by "1" when looking at his pseudo-code and trying to implement those ideas in my code...
Please try to focus on the fact that we are talking of pruning at node level, not pruning of the single move.....and no, it is not the same thing.
Absolutely and that's were (I think) the confusion comes from.
There are 2 ways of futility pruning.
1. Classic following Heinz model, move pruning, no need to involve QS.
2. Node pruning, try futility before move generation, QS is a must.
But our topic is razoring, not futility pruning. Heinz did apply razoring at the node level, look here again. The razoring condition triggers a depth reduction from pre-pre-frontier to pre-frontier. You are right about futility pruning + extended futility pruning but to me it seems Heinz did not razor moves.
Sven
As I always understood Heinz means move_futlity_pruning (not node) and razoring means a reduction. I could be wrong, the text does not deserve the beauty prize for clarity, the idea itself does
Sure, but you started your previous post with the goal to clean up some confusion, instead you even added more to it
And nobody else is going to clean it up, obviously, unless Bob and Marco stop refusing to answer my question a couple of posts above ...
Sven
Sorry, I was not "refusing to answer". This IS Christmas Vacation here. And I am in and out quite a bit.
Hopefully I have given my thoughts to further cloud this up. And I agree, the text he wrote is anything but clear (see my previous post about this introducing a bug that was actually a good thing, where I discovered one could actually do futility pruning farther away from the tips than just 2-3 plies...
Please try to focus on the fact that we are talking of pruning at node level, not pruning of the single move.....and no, it is not the same thing.
Absolutely and that's were (I think) the confusion comes from.
There are 2 ways of futility pruning.
1. Classic following Heinz model, move pruning, no need to involve QS.
2. Node pruning, try futility before move generation, QS is a must.
But our topic is razoring, not futility pruning. Heinz did apply razoring at the node level, look here again. The razoring condition triggers a depth reduction from pre-pre-frontier to pre-frontier. You are right about futility pruning + extended futility pruning but to me it seems Heinz did not razor moves.
Sven
As I always understood Heinz means move_futlity_pruning (not node) and razoring means a reduction. I could be wrong, the text does not deserve the beauty prize for clarity, the idea itself does
Sure, but you started your previous post with the goal to clean up some confusion, instead you even added more to it
And nobody else is going to clean it up, obviously, unless Bob and Marco stop refusing to answer my question a couple of posts above ...
Sven
If you go through Heinz pseudo code the term "razoring" is what we call "reduction" today. That's what I remember from the 95/96 RGCC when Ernst presented his paper. And as such I have used it for years.
At RD1 and RD2 you prune.
At RD3 you reduce.
Note that reductions in those years were not common practice, it's power was recognized by only a few and they massively profited until null-move made its entree and the term razoring fell out of grace and was the replaced by reductions.
What razoring means today I have no idea, I suggest to drop the term without a firm distinct definition that separates it clearly from pruning and reductions.
Please try to focus on the fact that we are talking of pruning at node level, not pruning of the single move.....and no, it is not the same thing.
Absolutely and that's were (I think) the confusion comes from.
There are 2 ways of futility pruning.
1. Classic following Heinz model, move pruning, no need to involve QS.
2. Node pruning, try futility before move generation, QS is a must.
Exactly why is a node not EXACTLY the same thing as the result of making a move but doing whatever you want to do BEFORE calling search, rather than calling search and doing whatever you want to do at the TOP? Same thing. One extra procedure call is all I see... Standard AI vocabulary says a node is what is produced when you make a move. If you razor AFTER making a move, you are razoring at the successor node to the one you were passed into the search.
It's fundamental different to prune 40 generated moves (from a node) one by one with code then to prune the whole node without generating the 40 children of that node at all. The latter needs QS, the former does not. The latter technique could be called razoring, at least it makes some sense to me.
Please try to focus on the fact that we are talking of pruning at node level, not pruning of the single move.....and no, it is not the same thing.
Absolutely and that's were (I think) the confusion comes from.
There are 2 ways of futility pruning.
1. Classic following Heinz model, move pruning, no need to involve QS.
2. Node pruning, try futility before move generation, QS is a must.
Exactly why is a node not EXACTLY the same thing as the result of making a move but doing whatever you want to do BEFORE calling search, rather than calling search and doing whatever you want to do at the TOP? Same thing. One extra procedure call is all I see... Standard AI vocabulary says a node is what is produced when you make a move. If you razor AFTER making a move, you are razoring at the successor node to the one you were passed into the search.
It's fundamental different to prune 40 generated moves (from a node) one by one with code then to prune the whole node without generating the 40 children of that node at all. The latter needs QS, the former does not. The latter technique could be called razoring, at least it makes some sense to me.
Back up one ply.
At ply=10 I can make a "razoring decision" move by move, by either searching a move normally, or going directly to q-search. OR, at ply=11, I can razor the entire node produced by one or more of the moves at the previous ply by dropping directly to q-search. Those are identical. Only difference is, the former did not do the unnecessary call to search, only to have it immediately call q-search.
For example, some do a hash probe at the top of Search(). Others do hash probes after each MakeMove() inside the main loop of search. Identical results. The latter is slightly more efficient in that a hash cutoff does not make that extra call to Search() which would then find the hash cutoff.
Avoiding a procedure call is beneficial, although the cost of doing the call is not huge.
bob wrote:At ply=10 I can make a "razoring decision" move by move, by either searching a move normally, or going directly to q-search. OR, at ply=11, I can razor the entire node produced by one or more of the moves at the previous ply by dropping directly to q-search. Those are identical. Only difference is, the former did not do the unnecessary call to search, only to have it immediately call q-search.
We all understand (futility) pruning and reductions.
