Author: Stuart Cracraft
Date: 07:10:29 09/11/04
Go up one level in this thread
On September 11, 2004 at 01:21:44, Michael Henderson wrote: >On September 11, 2004 at 01:03:37, Stuart Cracraft wrote: > >>Well, here's the result. Two runs on Win-at-Chess at 1 second per move >>on a P3. The compilation flag UTM is with the triangular array and >>its entry taken as the best move. >> >>Walking the Hash for best move/pv: >>+ 6.78/27.44 81% 243/300 250.06 74259544 247532/1/296973 0/855173/1429928/507556 >>/17118632/97735 >> >>Triangular Array for best move/pv: >>+ 6.78/23.28 82% 248/300 250.70 73645824 245486/1/293757 0/851605/1423773/506165 >>/17084388/98392-DUTM >> >>The bottom line is that 5 more positions got solved with the >>triangular array method than for walking the pv in the hash table. >> >>5 positions is a lot since progress has become slower. >> >>This is proof enough for me though I hope to hear the specifics from >>Bob Hyatt of how a hash table can get trashed if there are no collisions >>and length >= depth for replacement algorithm is used which would seem >>to all guarantee that nothing worse for the same position would ever be >>stored. Obviously it's something in the tree that I can't see. >> >>Good stuff. >> >>Stuart > >That's good news! The extra +5 positions may be due to stuffing PV in hash >table (improved move ordering and longer PVs). I found Hyatt's explantion here: >http://chessprogramming.org/cccsearch/ccc.php?art_id=343272 > >I don't understand how it causes blunders, but I do see how extensions can cause >move disagreements. Okay I think I undersand now from the comments in the thread, and heck, we didn't even need Bob Hyatt. Hash PV's can get bolixed up due to the hashkey % mask coming out to the same thing -- the low-order bits being masked are only so random after all. There's probably something more obscure than this. Regarding the extra +5, I am not even stuffing the PV in the hash table yet and got the +5 before trying it (still have yet to try to try stuffing). The +5 is just from the global "bestmove" which is updated by the search at ply == 0 when there is a move improvement being ignored, completely and instead using pv[0][0] instead of bestmove when the final move is chosen from the search. That one change is the one that did the +5. Not sure I understand why because ply == 0 move changes should be very straightforward. I can live with that for now that's sure. Perhaps the bugfix will turn up some day. Stuart
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.