Again.. the first 8 plies are book plies right? After that (my engine is white) it depends on position on the board if the engine takes a minute to figure out the move, or 4 5 seconds...
It happens that only when playing the velena engine, because of its drawish play style, it takes my engine more than a minute to calculate the move. (Because the position on the board)
Hashing connect -4 board (for Transposition table)..need some help :)
Oh, I see. How long does your program take in this position?
_ _ _ _ _ _ _
_ _ _ 1 _ _ _
_ _ _ 2 _ _ _
_ _ _ 1 _ _ _
_ 1 _ 2 _ _ _
_ 2 _ 1 2 _ _
Author
2 whole minutes! 
And it happens in this kind of positions exactly. in other positions (played by weaker engines) it takes only a few seconds for the engine to find a move. what is the reason for that?? do you think its related to the TT and move ordering? my code suppose to be fast , except for the move ordering part
If you are searching as many positions per second as John Tromp's program, you either have much worse ordering, much worse transposition tables, bugs, or a combination of all of the above.
It's hard to give you advice, other than testing every change and every decision. Also, don't get too discouraged if you can't make your program as good as John's. I know him well and he is extremely smart.
I have never read all the code in Fhourstones carefully, but it is rather short, so you can probably learn a lot by reading it.
Author
thx i will try to improve it as much as i can. it is probably have a lot to do with the move ordering and TT implementation, my bitboard code is not very different from john tromp's implementation. my getMoves() method is probably not that fast but i don't believe that the problem lies there. thx again for all the help
By the way. You do not need to use a bit aligned system to hash a base 3 numerical format.
You can easily achieve 40 base-3 digits in 64 bits.
Just use division by three instead of bit rotation (division by 4).
Granted you are still two digits short...
But still, there is no reason to cling to bit-wise math when your number scale isn't a power of 2.
Author
And another thing that may be causing my some troubles, right now i am not doing anything in the root negamax function but passing through all the root moves one by one and only changing alpha if the score is higher than the best score so far. and in the end i am returning the best move. should i also check for TT entry in the root function ? should i insert to the TT at the end of this function? should i try to play the hash move? i don't do any of those things at the moment, and maybe that's one of the reasons that the engine is slow.
this is my root negamax function: is there a point in doing - if(alpha >= beta){ break;} ? ) cause the beta value is not changing in the root function...only the alpha!
public int rootNegamax(int depth,int alpha,int beta,int side){
int bestMove = -1;
ArrayList<Integer>moves = board.getMoves(depth);
for(Integer move:moves){
board.makeMove(move);
int value = -negamax(depth+1,-beta,-alpha,-side);
board.unmakeMove(move);
if(value>alpha){
alpha = value;
bestMove = move;
}
if(alpha>=beta){
break;
}
}
return bestMove;
}
in the inner negamax functions i am doing all the TT operation and getMoves() etc. no point in posting it out here
You don't need to handle transpositions in the root function. You could try the hash move first, if there is one from a previous search, but it won't chance things much: If this position has been visited before, chances are the TT has enough stored about it that the search will be very very fast.
You are correct: You don't need to check for beta cutoffs at the root, since they can't happen. Also, there is no point in passing alpha and beta to the root function: You are probably passing -Infinity, +Infinity or something like that, which you can hard-code into the function.
Author
thx for the approval Alvaro! :) ok..so i now testing the engine with a new size of the TT (8306069!! , Just like in fhourstones code ) and a simple alwauys replace scheme..i will also try to play with other replacement schemes later, but this seems to work ok... + killer moves which also seems to do the job quite nicely. like i said, testing it against my weak AI factory "four in a row" app , my engine calculated the first (non-book) move in seconds! i will now test it against the more problematic positions.. hope that some tweaking with move ordering and TT will help.
Author
Since i can't get over the problematic positions issue, i am now trying the last resource: using an evaluation function for one move! (the 9th ply), just to get another token on the board (two to be more correct..there is a black move too) and make the calculation easier for the engine. right now, testing it against the velena engine (plays always the same moves) my engine seem to find the correct 9th move in order to win the game. now i will test it against the john tromp engine, which plays in more varied fashion.. just to see how it goes. It may turn out that this simple evaluation function ,when taken to a depth of 18 plies,can catch the correct move. but i still got more tests to do 
I am anxious to finish this project so i can move to the next challange..a chess engine (which is my favourite game). the knowledge i earned in the connect 4 project will help me a lot in the process, so again.. special thx to Alvaro for all your help and also the rest of the participants in this thread.
EDIT: for now seems to work great! (tested it also against the john tromp machine with 100% success)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
