Author: Dan Newman
Date: 02:13:43 10/10/99
Go up one level in this thread
On October 10, 1999 at 01:24:11, Josh Levine wrote:
>Hello,
> Josh Levine here. First off, as a new user to the CCC I need to say, I LOVE
>IT. This is the best thing I've found yet. Now on to business.
>
>I have a program (Saboteur) which I introduced earlier. I have strong
>suspicions that the hash table(s) are not storing information properly. There
>was a thread here a while ago that I noticed where people were talking about
>mate bounds and the position
>
>/p/P5p/7p/7P/4kpK/// w
>
My program likes Kh3 in this position, so I made that move and searched
from there.
>I am wondering how many hash table hits people get on this position and how >many nodes (per iteration. here's mine:
>
>score: 1020, nodes: 626, depth: 5
>Best: f2 Kg2 Ke2 Kh1 f1=Q Kh2
>score: 1020, nodes: 1112, depth: 6
>Best: f2 Kg2 Ke2 Kh1 f1=Q Kh2 Qb1
>score: 1150, nodes: 5066, depth: 7
>Best: f2 Kg2 Ke2 Kh1 f1=Q Kh2 Qf4 Kh3 Qg4 Kh2 Qxh4
>score: 1166, nodes: 16691, depth: 8
>Best: f2 Kg2 Ke2 Kh1 f1=Q Kh2 Qf4 Kh3 Qg4 Kh2 Qxh4 Kg1
>score: 1166, nodes: 77578, depth: 9
>Best: f2 Kg2 Ke2 Kg3 f1=Q Kh2 Qf4
>score: 1166, nodes: 193026, depth: 10
>Best: f2 Kg2 Ke2 Kg3 f1=Q Kh2 Qf4 Kg2 Qf2 Kh3 Qf4 Kh2
>
>Score: 9999988, Time: 59.996, NPS: 29329.
>nodes: 1759648, depth: 11, table use: 30716
>
>Best: f2 Kg2 Ke2 Kg3 f1=Q Kh2 g5 h4xg5 Kf3
>
Here's what I get from on a P6/200:
EPD: 8/p7/P5p1/7p/7P/4kp1K/8/8 b - - id "Hash Test";
5> 1000 0.00 1144 Ke2 Kg3 f2 Kh2 f1=Q Kg3
6> 1010 0.06 3483 Ke2 Kg3 f2 Kf4 f1=Q+ Kg5 Qg1+ Kh6 Qb6
7> 1100 0.11 8272 Ke2 Kg3 f2 Kf4 f1=Q+ Kg5 Qg1+ Kh6 Qb6 Kh7
Qxa6
8> 1100 0.22 24680 Ke2 Kg3 f2 Kf4 f1=Q+ Kg5 Qg1+ Kh6 Qb6 Kh7
Qxa6
9+ 1150 0.39 60458 f2
9> 1201 0.55 90020 f2 Kg2 Ke2 Kg3 f1=Q Kh2 Qf4+ Kh1 Qxh4+ Kg1
Qc4 Kh1 Qxa6
10+ 1301 0.55 99066 f2
10> +mate6 1.42 323068 f2 Kg2 Ke2 Kg3 f1=Q Kh2 g5 hxg5 Kf3 g6
Qg2+ <Checkmate>
fwnodes: 85282, qnodes: 237786
one_reply_exts: 280
mate_threat_exts: 0
null_move_cutoffs: 108
ttable probes: 84531 hits: 54037, 63.9257 %
elapsed time: 1.42 s
node rate: 225.922 knps
I only yesterday fixed a really stupid bug in my hash table code after
reading a thread on hash table troubles here and discovering a too low
hit rate on Fine #70. The bug had been there a year, and I know I had
looked any number of times at it...
>Also, how do I stop the hashtable from truncating the PV? I have tried lookng
>up best moves from the hashtable when displaying/using the PV, but my threading
>model doesn't really allow for that in a game situation (ugh...).
>Thanks for any input :)
>
>Josh Levine
I guess you are extracting your PV readout by walking the hash table. I don't
do this myself. I maintain a PV array that I keep up to date while searching.
Then I stuff the PV back into the hash table at the end of an iteration so
that it will be found on the next. Your PV entries are likely getting
trashed by the remainder of the search after the best move is found.
Maybe use of a "sticky" bit in the table entry would help, though you don't
really know you've got a PV node until you make it back to the root. Maybe
every time you get back to the root with a new best move you could walk the
hash table and mark each PV entry by setting a bit to indicate "don't
overwrite" (the sticky bit). This would at least prevent further searches
on this iteration from overwriting the PV entries.
Now, you have the trouble of figuring out how to prevent those entries from
sticking around forever... One way would be to walk the table again to
clear the sticky bits of the old PV entries whenever a new PV is found.
(I haven't tried any of this myself though...)
-Dan.
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.