Author: Uri Blass
Date: 13:49:47 09/03/03
Go up one level in this thread
On September 03, 2003 at 16:17:37, Rafael Andrist wrote: >On September 03, 2003 at 03:26:59, Uri Blass wrote: > >>It is something that I need to fix but before fixing it I prefer >>to read what other people do. >> >>Today I update >>1)the side to move >>2)the ep array(I have instead of one global varaible an array of 3 numbers that >>gives me the en passant possibilities(square of the pawn that can capture and >>squares that it can capture) and maybe it is better if I compress it to one >>varaible and replace ep[0],ep[1],ep[2] by defines) >> >>I am also not sure if all my global varaibles is a good idea and it may be >>better to save the ep information only in the history information. > >I have all position related information in a struct, this includes some attack >tables, ep information and hashkey. The code is then much easier to read and to >modify. > > >>3)A global varaible that is the zobrist key(maybe I should get rid of it and >>read the zobrist key from the history information something that is possible >>only after I change my makenull move) >> >>4)The arrays that are search dependent(for example the array that gives me >>information about the evaluation of every ply). >> >>I do not include these arrays in a struct and maybe I should do it. > >I would not include the search dependent variables in the struct for the >position. > > >>I do not update >>1)The fifty global varaible that tells me the number of plies >>from the last conversion and I am not sure how to update it after null move and >>if to reset it to 0 or to increase fifty by 1. > >You should increase it just like you would do it after a normal move. In this >context you can look at the Nullmove as a move which is useless, but legal. And >it brings you one ply closer to the draw. > >>2)The history ply and all the arrays in the struct that are dependent on it. > >That depends on how you organised your data structure. I use this history >information only for repetition checks and for updating the PV. For me it does >not matter if I increase the history ply or not. If you use it for repeptition detection then it should matter. If you have an array of >positions/hashkeys for repetion check and if you increase the counter without >storing the root of the Nullmove subtree, you end up with an undefined entry >which may cause problems. practically I have an array and I compare the hash key of the position with the hash key of the position 2,4,6,8,...plies earlier to find repetitions when I need to do it based on the number of plies from the last conversion. null move is not considered as move so when I go 2 plies backward and null move is in the middle the side to move is changed so the result of the comparison is that there is no repetition. I do not store this info and so I don't have to >increase my history ply. How can you check for repetition without storing the information. > >>3)The zobrist array that is history dependent and is used only for checking >>repetition. > >Do you have two different hashkeys, one for the table and one for repetition >checking? No The hash key is the same hash key but I remember it as a global varaible and also in the array after making normal moves(I should remember it in the array also after making null moves but I forgot about it when I implemented hash tables(If I remember correctly hash was implemented after null move). Uri
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.