Author: Dieter Buerssner
Date: 12:12:35 10/31/03
Go up one level in this thread
On October 31, 2003 at 05:14:03, martin fierz wrote: >On October 30, 2003 at 16:27:18, Dieter Buerssner wrote: > >>You might also enjoy to read http://www.chess-archive.com/ccc.php?art_id=190318 >>which shows some experiment about collisions, and that they are really not worth >>to mention as a practical problem in typical situations. I just tested "Gerd's" >>PRNG (close to the start of this thread). I is really bad as a PRNG. For >>example, a simple test that tries to find out how many lower case letter that should have been lower case three letter words. >>PRNG will find. When we assume that 'a' is 0, 'b' 1, etc. and we take the lower >>8 bits of that PRNG. One would assume, (26 letters - 256 possibilities for lower >>8 bits), that one would find one word in 1000 calls to the PRNG. But that PRNG >>is really bad - it won't find even one word after letting it run for years (That >>PRNG will never output 3 numbers in a row, where the last 8 bits are < 26). >>Still - it will work nicely for "our" Zorbrist type hashing. >interesting post that you point to there. i once did something similar in my >checkers program but i've forgotten my results - they were definitely similar to >yours though. i just masked of a number of bits in my hashkey. it's pretty >surprising that even a 12-bit hashkey will suffice for practical purposes! Note, that actually it was a longer hashkey, because the index part was independent of the 12-bit signature used for comparing. Because only positions are considered, that match the index already, effectively a longer hash-key was used. >BTW you mention that you do hashing in QS in yace. since i don't do this in my >program: how much does this help? should i try? (of course the answer to this >question is yes, as one should always try... but how much in % would you >estimate that you gain by using hash in QS?) Sorry, I have no estimate in % anymore. I did test it, however. First I was surprised that using hash in QS will help even in situations where the HT is totally overfilled (long searches). I guess, it might have to do with the fact, that I don't use SEE. So the benifit might be bigger than in an engine that uses SEE. Also, it might help move-ordering in the search later (that was the best capture in the qsearch earlier, an iteration later, it might be useful for move-ordering in the search). I actually have 3 different QS functions: One "first level" QS, remaining QS-levels, and one, that gets called when QS is needed directly after a null move in search. I can selectively allow/disallow hash probe and store in each level. Allowing probe and store at each level seems to work best. Not surprisingly, it hurts a bit nodes/s but makes search trees somewhat smaller on average. It also has disadvantages. I do the probing slightly different at the several levels. So it cannot easily be hidden in one function (without some overhead, by having more logic and parameters for the probe function). I always wanted to change some things for the hash logic. For example storing up to 2 scores (with different bounds) for each position. The thought to change this 4 times in my source, didn't look appealing, and I delayed and delayed the idea ... Regards, Dieter
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.