All and Cut nodes

[Michel]

Well reducing ALL nodes more was tested in Stockfish and it did not work. So something must be going on.

Here is another possible explanation.

Things that may change the score at a PV node are:

A predicted ALL node fails high.
A predicted CUT node fails low.

So it is important not to make a mistake in one of those situations for otherwise you will compute the wrong value for the tree.

Suppose you reduce heavily at a predicted ALL node and you fail low erroneously. This goes completely undetected!

On the other hand if you reduce heavily at a predicted CUT node and a reduced move fails high erroneously it will be researched (since that is how LMR is usually implemented) at full depth. So now there is a safety net!

[Daniel Shawul]

Suppose you reduce heavily at a predicted ALL node and you fail low erroneously. This goes completely undetected!

The plies above and below are CUT nodes that will also fail high so you have researches there. It is not like all the reduction is concentrated at a certain node.

On the other hand if you reduce heavily at a predicted CUT node and a reduced move fails high erroneously it will be researched (since that is how LMR is usually implemented) at full depth. So now there is a safety net!

Yes you re-search immediately at a CUT node, but you would get similar behaviour at ALL node fail lows too only a ply later. But we are missing another thing here, that we are potentially trying to hide fail highs at expected fail high node. It is like saying I don't want to see you fail high ,even though you are expected to fail high, and if you do fail high i will research you to see if you really failed high

[Michel]

It is like saying I don't want to see you fail high ,even though you are expected to fail high, and if you do fail high i will research you to see if you really failed high

If all predicted CUT nodes failed high and all predicted ALL nodes failed low then no search would be necessary. It is precisely the job of the search to discover those misbehaving nodes! Preferably as quickly as possible.

[Daniel Shawul]

It is like saying I don't want to see you fail high ,even though you are expected to fail high, and if you do fail high i will research you to see if you really failed high

If all predicted CUT nodes failed high and all predicted ALL nodes failed low then no search would be necessary. It is precisely the job of the search to discover those misbehaving nodes! Preferably as quickly as possible.

What if a move only fails high when searched with a proper search depth? You return with a fail low at CUT node just because it was heavily reduced! You are not going to increment the depth and re-search like IID, because you need a fail high for LMR research. So you would go buy classifying it as a fail low node. But I can see why this IID thing was being thrown around.
Also if you are out of the first three moves zone, then expecting a fail high afterwards is like watching paint dry. You are not going to get it 99% of the time so you might as well classify it as an ALL node (which it is in my engine). So basically you are doing more reductions at an ALL node in my case, because you can imagine the engine will be weaker if you reduce those first 3 moves at which the node is really an expected CUT node.

[Michel]

What if a move only fails high when searched with a proper search depth? You return with a fail low at CUT node just because it was heavily reduced

Well if the fail low influences the value of the tree the predicted CUT node will be researched at higher depth, either because one of the ALL ancestor moves was reduced, or else it will turn into an ALL node by a PVS research.

So in any case I think it will ultimately be researched at full depth and the fail high will be discovered.

[Harald]

I have a stupid question:
When you count moves for CUT/ALL node decisions or for LMR,
do you count all moves including the move from TT and (good) capture moves
or does the relevant move count start with the first normal move?

[Daniel Shawul]

I have a stupid question:
When you count moves for CUT/ALL node decisions or for LMR,
do you count all moves including the move from TT and (good) capture moves
or does the relevant move count start with the first normal move?

I use legal moves but the decision entirely depends on how aggressive you want to be. At some time I started LMR after 6 moves at CUT nodes, and just 2-3 moves at ALL nodes. What is being debated here is by how much CUT nodes should be reduced compared to ALL nodes. What is your first reaction if I tell you the all important CUT nodes are reduced by 4 ply and ALL nodes by 2 ply?

[Michel]

I have a stupid question:
When you count moves for CUT/ALL node decisions or for LMR,
do you count all moves including the move from TT and (good) capture moves or does the relevant move count start with the first normal move?

As I understand it the nodetypes of the ancestors should be

PV,PV,....,PV,CUT,ALL,CUT,ALL,....,{CUT,ALL}

If you reduce differently at CUT and ALL nodes you need a flag in the TT with the nodetype of the score so that you don't use upperbound from a CUT node in an ALL node and similarly you don't use a lowerbound from an ALL node in a CUT node.

With this convention faulty LMR at a CUT node is mostly harmless and only costs extra time through the research(es) that is(are) triggered. This was explained at the Stockfish forum by Frank Peeters (who seemed to be quite knowledgeable in these matters).

[Harald]

I have a stupid question:
When you count moves for CUT/ALL node decisions or for LMR,
do you count all moves including the move from TT and (good) capture moves
or does the relevant move count start with the first normal move?

I use legal moves but the decision entirely depends on how aggressive you want to be. At some time I started LMR after 6 moves at CUT nodes, and just 2-3 moves at ALL nodes. What is being debated here is by how much CUT nodes should be reduced compared to ALL nodes. What is your first reaction if I tell you the all important CUT nodes are reduced by 4 ply and ALL nodes by 2 ply?

That's nice if it works.

But that was not my question. I wanted to know if the move count
("after 6 moves") depends in any way on the type of the first moves.
There is of course the standard count of all moves in a node as they come
from the move generator or pick move loop.
But there could also be another move count that starts counting quiet moves.
If the moves are
PxR (from TT), PxQ, NxB, e2-e4, Nf3, ...
it _could_ be useful to start the special move count with
1. e2-e4, 2. Nf3, ...
instead of
1. PxR, 2. PxQ, ...
especially if you have a table like
int lmr_reduction_dep_of_moves[] = { 0, 1, 1, 1, 2, 2, 2, ...};
or a condition
if ( movenum > 2 ) node_type = ALL;

And I am not talking about your engine. I am talking about the
move count in the general discussion.

Harald

[Daniel Shawul]

I believe I have answered exactly what you asked by stating what i do. I use legal_moves because i want to be aggressive. I tried counting moves only in quiet_move_phase but that was too conservative since killers,captures,hash_moves all come before that. Not something to debate much about. Others could offer their opinions so I realize you are not talking about my engine, why should you.