LMR Conditions

[bob]

I'd be interested to test a no_killer condition, but so far everything I've tried has been broken. Whenever I try out a new LMR condition I only count the nodes on the LMR search to kinda see how its working and every time I put a no_killer condition on there the nodes slip to ZERO. Unfortunately I spent some time trying to implement some sort of REST_OF_MOVES type of idea but the first try broke the search and I haven't tried again. I've (for now) gone back to no_checks and no_pv and no moves which have been extended and a depth condition to keep an eye on the horizon. I'm trying to search a minimum of 4 moves to full depth before LMR and hoping that move_ordering will make those first 4 moves the ones worth looking at before reductions. I've tried less than 4 moves and more than 4 moves but can't be sure yet what is best for me because I've changed the testing conditions (more fair now I think). I was using the Balanced14.abk and letting it run wild, the positions were interesting but not good I think for testing. So I'm trying Perfect10.abk with a 12 move limit for the games now.
Seems much more even out of the opening. Im surprised that with all the conditions you have on there that your LMR is ever used at all, if it is then I would guess its very rarely. I wonder if LMR dosen't perform better overall when it's allowed to run free over mostly everything except the PV in some programs (not necessarily yours). Im trying to figure out exactly how LMR differs from null move in terms of the risk of missing a better move, or playing an outright 'bad' move.

The point is that you don't want to reduce moves you want/expect to fail high. Because reducing it is done with the expectation that it is so bad that it won't fail high in the first place (the idea is to reduce crappy moves so that they are easier to dismiss so that you have more time to search moves that are more promising in some way.) If the killer restriction kills reductions totally, something seems wrong, in that there are plenty of "ALL" nodes where you search everything, and they can't all be killers.

[outAtime]

Indeed, something is definitely wrong! I think the problem is I can't seem to come up with a way to tell it not to search killer_moves!

Code: Select all

if(searching_pv)
	{
		searching_pv = FALSE;
		for(i = 0; i < num_moves; i++)
		{
			from = moves[i].from;
			target = moves[i].target;
			promoted = moves[i].promoted;
			captured = moves[i].captured;

		
			/* make the pv have highest move ordering: */
			if(from == pv[1][ply].from && target == pv[1][ply].target && promoted == pv[1][ply].promoted)
			{
				searching_pv = TRUE;
				move_ordering[i] += INF;
			}

	
				/* add the killer move heuristic bonuses: */
				if(from == killer1[ply].from && target == killer1[ply].target && promoted == killer1[ply].promoted)
					move_ordering[i] += 1000;
				else if(from == killer2[ply].from && target == killer2[ply].target && promoted == killer2[ply].promoted)
					move_ordering[i] += 500;
				else if(from == killer3[ply].from && target == killer3[ply].target && promoted == killer3[ply].promoted)
					move_ordering[i] += 250;
			}
		}
	}

	

Sorry, but no matter what I do the code dosen't paste in here right, and ends up looking messy. I even ran it through UniversalIndent. Anyways, I've tried all kinds of things, but I can't figure out a !Killer_move type of condition that works in my LMR. I tried adding something similar to the (searching_pv= FALSE) to the killer_moves, but the search was broken after that, and I was getting about 30 plys of instant and utter nonsense.
I actually haven't tried adding && !killer3[ply].promoted yet, but I doubt that will work either. Of course I'd really like to try this in a similar fashion to what you have recommended, but I can't figure out what to write in the LMR conditions to exclude what I want.

Code: Select all

} else {
		     
	 	    /* Late Move Reductions */
            if (msearch >= PVMoves && depth >= FDMoves &&  !in_check()&&!searching_pv && !extensions) {
			   
		       score = -search (-alpha-1, -alpha, depth-2, TRUE);    

Thats all there is for now,. Im surprised !searching_pv even works. I need to add something like (&& !killer1) or something in there, but as I've said everything I've tried so far either dosent compile or causes LMR to have ZERO nodes accepted. The move ordering section from the top is abbreviated of course, there are also captures and hash included.

[outAtime]

the only one so far that has worked has been (&& moves.from == 0) but that is fairly meaningless I think. I really need to set some sort of flag similar to the pv for killer moves so I can say when they have all been searched, but no luck so far implementing anything that isn't broken. In root_search the searching_pv = TRUE, so I tried somthing like that with the killers already and it hasn't worked yet. Im not quite sure what you meant when you said, something like '..and Im not sure how many killer moves there will be..' Theres only (only, lol) 3 killer moves in this move ordering, so I would assume there would be only 3. How many killer moves do you have? Or perhaps you just meant that maybe you wont have any in some situations, which would mean a condition similar to the one Im using (search x moves with full window) would mean possibly wasting the full window on moves that are not killers or anything expected to be very good....which is why I guess adding a no killer condition probly couldn't hurt. Im maybe wasting some search time here and there in cases where I didn't have a cutoff?