What ply is depth-2?

[vittyvirus]

Many engines like Maverick and Chesser use ply as an argument for alphabeta search. In both, I couldn't implement LMR, because it takes ply as argument and LMR needs the move to be searched at depth-2. If you try ply+2, it corrupts history heuristics. Everything else fails too. I'm confused now.

Does anyone know how to solve this without removing the need of ply as an argument?

[Sven]

Many engines like Maverick and Chesser use ply as an argument for alphabeta search. In both, I couldn't implement LMR, because it takes ply as argument and LMR needs the move to be searched at depth-2. If you try ply+2, it corrupts history heuristics. Everything else fails too. I'm confused now.

Does anyone know how to solve this without removing the need of ply as an argument?

I'd say: "depth" is usually "remaining depth", and "ply" is often used as the distance of the current node to the root node. In that case, if you decide to search from the current node with a reduced remaining depth then this does not affect the distance to root, so with LMR you can search the move with depth-2 but still pass "ply", not "ply+2" or anything like that.

[vittyvirus]

Many engines like Maverick and Chesser use ply as an argument for alphabeta search. In both, I couldn't implement LMR, because it takes ply as argument and LMR needs the move to be searched at depth-2. If you try ply+2, it corrupts history heuristics. Everything else fails too. I'm confused now.

Does anyone know how to solve this without removing the need of ply as an argument?

I'd say: "depth" is usually "remaining depth", and "ply" is often used as the distance of the current node to the root node. In that case, if you decide to search from the current node with a reduced remaining depth then this does not affect the distance to root, so with LMR you can search the move with depth-2 but still pass "ply", not "ply+2" or anything like that.

Well, I tried that before but, it overwrites current position heuristics, and move lists.

[kbhearn]

assuming 'ply' is the distance from the root, it should always be ply+1 to index the next entry in your arrays. no reductions or extensions should change this as you're always moving one move further from the root.

[cdani]

Hi!
A very basic example of LMR in cheeser. I do not claim that it's any good .

Code: Select all

				bool dopvs=true;
				if (movesfound != 0
					&& depth>5
					&& !moveBuffer[i].getCapt() 
					&& !moveBuffer[i].isPromotion()
					&& !moveBuffer[i].isCastle())
				{
					val = -alphabetapvs(ply+1, depth-2, -alpha-1, -alpha); 
					if (val <= alpha) {
						dopvs=false;
					}
				}

				inodes++;
				if (--countdown <=0) readClockAndInput();
				movesfound++;
				if (!ply) displaySearchStats(3, ply, i); 

				if (dopvs) {
					if (pvmovesfound)
					{
						val = -alphabetapvs(ply+1, depth-1, -alpha-1, -alpha); 
						if ((val > alpha) && (val < beta))
						{
							// in case of failure, proceed with normal alphabeta
							val = -alphabetapvs(ply+1, depth - 1, -beta, -alpha);  		        
						}
					} 
					// normal alphabeta
					else val = -alphabetapvs(ply+1, depth-1, -beta, -alpha);	    
				}
				unmakeMove(moveBuffer[i]);

So the idea is to try depth-2 and if it's good enough, don't try the standard depth-1.
Of course is just to show the idea. Any engine instead of trying depth-2 do variable reductions, and with more conditions.

[vittyvirus]

Hi!
A very basic example of LMR in cheeser. I do not claim that it's any good .

Code: Select all

				bool dopvs=true;
				if (movesfound != 0
					&& depth>5
					&& !moveBuffer[i].getCapt() 
					&& !moveBuffer[i].isPromotion()
					&& !moveBuffer[i].isCastle())
				{
					val = -alphabetapvs(ply+1, depth-2, -alpha-1, -alpha); 
					if (val <= alpha) {
						dopvs=false;
					}
				}

				inodes++;
				if (--countdown <=0) readClockAndInput();
				movesfound++;
				if (!ply) displaySearchStats(3, ply, i); 

				if (dopvs) {
					if (pvmovesfound)
					{
						val = -alphabetapvs(ply+1, depth-1, -alpha-1, -alpha); 
						if ((val > alpha) && (val < beta))
						{
							// in case of failure, proceed with normal alphabeta
							val = -alphabetapvs(ply+1, depth - 1, -beta, -alpha);  		        
						}
					} 
					// normal alphabeta
					else val = -alphabetapvs(ply+1, depth-1, -beta, -alpha);	    
				}
				unmakeMove(moveBuffer[i]);

So the idea is to try depth-2 and if it's good enough, don't try the standard depth-1.
Of course is just to show the idea. Any engine instead of trying depth-2 do variable reductions, and with more conditions.

Thank you! I'd try that soon...

[Sven]

assuming 'ply' is the distance from the root, it should always be ply+1 to index the next entry in your arrays. no reductions or extensions should change this as you're always moving one move further from the root.

That's what I meant: no change of the 'ply' parameter value compared to non-reduced moves. If other moves are searched with ply+1 then of course also the reduced ones.