Author: Colin Frayn
Date: 17:29:40 04/11/00
Go up one level in this thread
>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 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. 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.