Author: Uri Blass
Date: 11:50:32 09/14/02
Go up one level in this thread
On September 14, 2002 at 14:21:59, scott farrell wrote: >On September 14, 2002 at 14:00:14, Uri Blass wrote: > >>On September 14, 2002 at 13:27:12, Tony Werten wrote: >> >>>On September 14, 2002 at 13:00:09, scott farrell wrote: >>> >>>>I have been reading plenty on hash replacement schemes. >>>> >>>>I have read Breuker's thesis, and done some (slow) searching through the CCC >>>>archives. >>>> >>>>I am going over my code and redoing the hashing parts, only to realise I have >>>>borken IID (internal iterative deepening). >>>> >>>>Now I am unsure of what I should be aiming at in relation to hashing code. >>>> >>>>I am also unsure of exactly what multi-probing the hash tables is. I am guessing >>>>there is still only one hashtable, and different equations to go from >>>>key/checkkey to the hashtable index, so that there can be several alternative >>>>slots that a hash entry for a position could appear at. Is Multi-probe just >>>>aiming at reducing collisions - or is the idea to store more than one hash entry >>>>for popular positions (say 1 for "depth based", and one for "replace always")? >>>> >>>>I think I am correct that I need atleast one of the probes as "replace always" >>>>to get IID to work. What else do I need to guarantee that I get the best moves >>>>from IID backed up to the main search? >>>> >>>>When people say "replace always" do that mean literaly, just store it all the >>>>time? It seems over simplistic - but I tried it, and it works pretty much the >>>>same as my code below that tries to keep the deeper entries. >>>> >>>>Any help apprecated. >>> >>>What most people do is have 2 tables. In the first you only store if the >>>searchdepth >= table depth (and you move the former entry to the second table). >>>If not then store in 2nd table. >>> >>>Tony >> >>For programmers who implemented hash tables in an effective way(see definition >>later): >> >>Did you look at the source code of another program before implementing hash >>tables with 2 tables and if yes which source code did you look at? >> >>When I say using hash tables in an effective way I mean that the following >>conditions happen: >> >>1)hash tables are used to save move generation >>2)hash tables are used to prune the tree >>3)hash tables are used to avoid null move pruning >>4)the program is using 2 tables or one table that can have more than one >>position at each entry. >> >> >>Movei of today is still using only hash tables for order of moves >>and does nothing of 1-4. >> >>I think that the first thing that I will do about changing the hash tables >>management is using hash tables to save move generation. >> >>The point is that it seems to me that in order to do 2,3,4 I do not need to >>transfer lines in my code to another place, >>when in order to do 1 I need to do it, so it is better to start with 1 before >>the code that I need to transfer is more complicated. >> >> >>Uri >Thanx Uri, > >I am currently doing 2 & 3, storing the best move helps ordering, I dont think >storing all the generated moves will help, it would take too much memory also. I store only the best move. The reason that I generate all of the legal moves is that I use information about the number of them for my extension rules. I plan to store the relevant information in my hash tables so I can avoid doing it. There is a price of reducing the possible number of entrys in my hash tables but I think that the gain of not generating the legal moves is clearly bigger. > >I think I'll look over crafty ( I have looked at it once, and the hash stuff was >difficult to follow). It was also too difficult for me to follow and this is the reason for my question if there is a good source code that I can look at. 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.