   How to initialize zobrist key?
  Here is the part of my code which involves usage of hash tables and zobrist keys.  byte hashType = 1;   int hI = (int) (zobrist_key & hSize); System.out.println("zob_key at start"+zobrist_key);   // hash probes   if (depth == 0) {  hKey[hI] = zobrist_key;  hType[hI] = 0;  hDepth[hI] = (byte) depth;  hVal[hI] = (short) eval;   System.out.println("zob_key when depth=0"+zobrist_key);  return eval;   }   eval = New_Eval.Eval(board1, turn);   if ((eval == -1000) || (depth == 0) || eval == 1000) {  return (eval - depth);   }   if (Board_Full(board1) == true) {  //return Evalc(board1, turn);  return New_Eval.Eval(board1, turn);   }   for (int i = 0; i < legal_moves1.length; i++) {  int coor = legal_moves;  make_move(coor, player);  if (hKey[hI] == zobrist_key) {  System.out.println("hKey[hI]==zobrist_key "+zobrist_key); // using exact matches for now. if (hDepth[hI] >= depth) {if (hType[hI] == 0) {    return hVal[hI];}if ((hType[hI] == 2) && (hVal[hI] <= alpha)) {    return alpha;}if ((hType[hI] == 1) && (hVal[hI] >= beta)) {    return beta;} }  }  undo_move(coor);  board1[coor] = (turn ? 1 : 2);  eval = -Negamax_ab1(!turn, depth - 1, -beta, -alpha, board1);  board1[coor] = 0;  if (eval > alpha) { alpha = eval; hashType = 0;  }  if (alpha >= beta) { //Record under conditions hKey[hI] = zobrist_key; hType[hI] = 2; hDepth[hI] = (byte) depth; hVal[hI] = (short) beta; curr_vals[player][coor] += (long) 1 << depth;System.out.println("zob_key when alpha>=beta"+zobrist_key); return alpha;  }   }   return alpha;    }Every time I execute this I get zobrist key as 0.Is it the correct way I am implementing?Entire source can be found here.Code
  I haven't found a line of code that changes the value of zobrist_key. What did you expect to happen?   ;  @alvarothanks for replying.I think that code lies in make_move() and undo_move()Here is the code for make move and undo move methodsCODE;  Those look correct to me. I don't know why make_move would return the zobrist key, though. And where is zobrist_table initialized?Can you use a debugger to see what's going on?   ;  Here is where I initialize the zobrist key.CODEThe point is its either 0 or any random number.To see a small game(incomplete) click on this link.Small GameAs you can see, the zobrist key is not changing at all.Since these are quiet lengthy, I am not posting in forum but in other link.Am I missing something?   ;  I'm guessing what you posted there is the constructor of the Game object. I have no idea why you have this line there: zobrist_key^=zobrist_table[sq];</pre><br><br>It turns out that the initial value of zobrist_key doesn't matter at all, so it may as well be the result of XORing together all the entries in the table.<br><br>I'm back to my suggestion of using a debugger.;Quote:Original post by alvaroI'm back to my suggestion of using a debugger.This.That should be a mandatory step for posting questions:Did you trace the execution of your bloody code by hand?After all, that's what you're asking the respondents to do.*shrug*;Quote:This.That should be a mandatory step for posting questions:Did you trace the execution of your bloody code by hand?After all, that's what you're asking the respondents to do.*shrug*I am implementing hash tables for the first time and hence would like some experienced programmer to take a look at it,and let me know whether my approach is correct or not.I am not telling any one to debug my code,programing is my hobby,and yes I post here only when I run out of my resources.@Alvaro.There was a minor bug in the code,which I have now fixed.is 4MB enough for hash tables?I have added move ordering using history heuristics.also what are the further improvements that I can go for?Let me know if you want the code as well.   ;Quote:Original post by mandar9589Quote:This.That should be a mandatory step for posting questions:Did you trace the execution of your bloody code by hand?After all, that's what you're asking the respondents to do.*shrug*I am implementing hash tables for the first time and hence would like some experienced programmer to take a look at it,and let me know whether my approach is correct or not.I am not telling any one to debug my code,programing is my hobby,and yes I post here only when I run out of my resources.I understand how confusing and frustrating this can be the first time around, and that's part of why I continue helping you with this. But InnocuousFox is correct in detecting abuse when you keep asking about something that is obviously a programming bug that has nothing to do with the difficulties of the concept.Quote:@Alvaro.There was a minor bug in the code,which I have now fixed.is 4MB enough for hash tables?Only testing can tell. Take a few reference positions, search from them and compute the average or the median time it takes to finish the searches. Then make a plot where the X axis is depth and the Y axis is log(time). You'll get something roughly linear, with the slope indicating your "effective branching factor" (how long it takes to search depth n+1 divided by how long it takes to search depth n). Whenever you are working on hash tables or move ordering, you are trying to lower that slope. In the case of hash tables, you typically see two slopes: Things are pretty good up to a certain depth and then the slope increases (to approximately the slope you would have gotten from the beginning if you didn't have hash tables at all). What happens is that the hash tables saturate and you lose some of the benefits because you keep forgetting relevant information. This is usually pretty sharp and can often be seen with the results from searching a single position. The bigger the hash tables, the higher the depth at which this will happen. You should probably keep track of what fraction of the entries are used, and plot this information along with the timings. If you get fancy, you can keep stats on the depths of the entries, which flag they have, how often you get a hit when you search, how often the depth of the entry is as high as the depth of the current search...You should also use the same methodology to tune the replacement scheme for your hash tables.Quote:I have added move ordering using history heuristics.also what are the further improvements that I can go for?There are always many areas for potential improvement in a program of this type: * Removing bugs * Evaluation * Search (ordering, hash, extensions, various types of pruning...) * Opening book * Endgame analysis (tablebases, interior node recognizers)But the most important thing is having good methodologies to detect progress. Besides what I just described to measure the effective branching factor, you should set up some machinery to be able to match your program against other programs (moderately stronger programs are best for this). You can then get an idea of progress by the ELO score you get from these matches, and if you put the effort to observe the games and the scores that each program produces, you'll find many situations where the opponent seems to know something your program doesn't know, or where your program simply did something stupid. Collect those positions and figure out if there is something you can change in evaluation or search to do the right thing in that type of position. Make sure your change doesn't make things worse in other test positions you consider important.If you really want to be fancy, you should look into mechanisms to automatically tune parameters in your program, especially in the evaluation. But here the Math involved will likely be fancy.Quote:Let me know if you want the code as well.No, thank you.