Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


cryo75

Member Since 04 Dec 2002
Offline Last Active Jul 19 2013 03:39 AM

Posts I've Made

In Topic: Negascout behaves oddly

04 July 2013 - 07:24 AM

What's the best way to fix the odd behaviors? Playing around with the values of the evaluation function?

 

Also, should the depth of the killer moves be the depth left (like the tt) or the current depth?


In Topic: Negascout behaves oddly

04 July 2013 - 06:04 AM

I commented out the transposition table code. It is not always playing better. In some games, the AI has a clear win on the next move, however it stays moving other unnecessary pieces. Looks like this happens more often in the endgame.

 

I use 2 depths because (as you can see from the code above), I do:

 

1. check if the current depth is the maximum depth (maximum being that of the current iterative of the ID) and if it is, I exit the function, and

2. if current depth == 0, then the search is at the root and I need to save the the move too.

 

I don't know how I can eliminate one depth variable.


In Topic: Speeding up evaluation function

18 June 2013 - 03:05 AM

I added LMR into my current code. Does this make sense?

                int LMR_DEPTH = 3;
                int LMR_MOVENUMBER_MINIMUM = 3

		for (int i = 0, n = moves.size(); i < n; i++) 
		{
			moveCount++;
			Move move = moves.get(i);

			//Begin Late Move Reduction search
			boolean reduced = false;			
			if (movesSearched >= LMR_MOVENUMBER_MINIMUM 
					&& depth >= LMR_DEPTH
					&& ply < depth)
			{
				depth--;
				reduced = true;
			}		
			//End Late Move Reduction search
			
			//PV has been found
			if (alpha < bestScore) 
			{ 
				alpha = bestScore; 
				foundPV = true; 
			} 
			
			//Make the move
			board.make(move, true);
			
			//Search
			if (foundPV) 
			{
				//Zero window
				val = -negaScout(-alpha - 1, -alpha, ply + 1, depth);
				if (val > alpha && val < beta) 
					val = -negaScout(-beta, -alpha, ply + 1, depth);
			} 
			//PV search
			else	
				val = -negaScout(-beta, -alpha, ply + 1, depth);
			
			//Begin Late Move Reduction research
			if (reduced && val >= beta)
			{
				depth++;
				val = -negaScout(-beta, -alpha, ply + 1, depth);
			}
			//End Late Move Reduction research
			
			//Undo the move
			board.undo(move);
			
			//Cut-offs here...
		}

In Topic: Speeding up evaluation function

18 June 2013 - 12:53 AM

My move ordering sorts by: transposition move, capture move, primary killer, secondary killer in descending order. It also adds the history heuristic to each move before sorting. I currently don't implement move reduction. Maybe I should consider this too.

 

my game consists of a 6x4 board and 8 pieces per player. All pieces are of the same value (ie. no king, queen, etc). And the game is just moving pieces from one square to another. Something similar to checkers.


In Topic: Iterative Deepening

22 March 2013 - 07:55 AM

I've finally managed to implement ID into the search and it's working.  I have a couple of questions:
 
1. Killer moves are local to the current search. Should the TT also be local to the current search or should it be for the whole game?

The TT should be for the whole game, or you'll forget what you learned in the previous search, which is not a good idea.

>2. I also implemented transposition move in the search (before normal negascout search starts). However an assert is failing on makeMove because the current position doesn't belong to the current player on turn. Should I even bother with an assert there?

So you have an assert that fails for reasons you don't quite understand? It sounds like removing it is a horrible idea.

3. I would like to implment history heuristics. Are these local to the current search or should they be for the whole game?

I make them for the whole game, but I divide every entry by 4 at the beginning of each search, so old entries that are no longer relevant can decay. If you were to make them local to the current search, I think they would work just fine too.

 

 

good answer for question 2!! nah I will need to find out what the problem is and solve it.

 

for the history table and in the case of nine men morris where you have just placement of pieces, moving, and also placement+capture and move+capture is it wise to have a 4d array in this case or should I have a 2 3d arrays (one for each player).

 

when sorting the history, i would assume that the moves are sorted based on the array of player whose turn it is at that stage of the search. right?

 

small question about iterative deepening... I have a time limit of 2s and it goes 7 plies deep but sometimes it goes even 8 or 9 but because the time required to complete the search at that depth is more than 2s, it can take up to 6s to complete. should i also quite searching in negascout by checking outOfTim() in the move loop or is it wise to let it finish the search at that depth?


PARTNERS