Author: Tony Werten
Date: 04:03:04 04/12/00
Go up one level in this thread
On April 11, 2000 at 20:29:40, Colin Frayn wrote: >>Now, suppose you run out of HT space entirely... what will you do? Discard new >>positions? Or devise some replacement schema anyway? > >I discard new entries, though I suppose I could devise a replacement scheme. my >point is that it seems silly to throw away expensively calculated information >when you don't need to. > >>Let's count.. suppose your program stores 100k positions/sec in HT. > >Well... it only stores hash entries for depth >= 1 and replaces shallower ones >when a deeper alternative is found, so I think that this is a large >overestimate. I must find out roughly how many it does, though. A rough >estimate on a few test runs suggests fewer than 5k positions per second, at Even if you don't hash qsearch nodes, 5K/s is very little. Are you sure you hash every exit from your searchfunction ? >something like 20-30 bytes per position (something like that) is certainly going >to rarely be more than 100Kb per second, so unless I'm running my program for >ten minutes per move or more, hash table size isn't going to be a problem. :) > >...of course this merits further consideration. > >(oh - the way I do hash tables, I reset the entire table after each move so that >all the data is lost. I know that is dumb and I should keep data from one move >to the next, but basically I want my program to be useful for analysis so that I >can always come back to a certain position, regardless of what I've just been >analysing, and I'll know that it will give _exactly_ the same answer every time. For analyses (or testing) this is probably the best. In a game it's not. Add a 1 bit aging variable. If you or your opponent makes a move, set all these bits in your hashtable. When you're searching and find an entry with the bit set it means: Information is still usefull, but you can overwrite it whenever you want because it's from a previous search. cheers, Tony > This is useful for debugging too as I expect the node count to remain exactly >the same unless I've changed the scoring or move ordering or something. I'm >considering adding a flag to retain hash table info, though I haven't added it >yet. perhaps for the next release....) > >>Given your position storage space requires 2 pointers, > >Why is that? Only one needed as it's only a singly-linked list. > >Thanks for the input folks, > >Cheers, >Colin
This page took 0.01 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.