Author: Stuart Cracraft
Date: 21:20:48 09/20/04
Go up one level in this thread
On September 20, 2004 at 00:28:06, Michael Henderson wrote: >On September 20, 2004 at 00:00:57, Stuart Cracraft wrote: > >>On September 19, 2004 at 20:21:57, Michael Henderson wrote: >> >>>On September 19, 2004 at 19:26:25, Stuart Cracraft wrote: >>> >>>>On September 19, 2004 at 19:11:51, Michael Henderson wrote: >>>> >>>>>On September 19, 2004 at 18:55:25, Stuart Cracraft wrote: >>>>> >>>>>>On September 19, 2004 at 17:51:05, Michael Henderson wrote: >>>>>> >>>>>>>On September 19, 2004 at 17:04:14, Stuart Cracraft wrote: >>>>> >>>>>>>> 2) is the above normal that walking the hash gives sometimes >>>>>>>> a longer pv? >>>>>>> >>>>>>>perfectly normal since many people use hash to "extend" their PV's >>>>>>> >>>>>> >>>>>>Not sure I understand. >>>>> >>>>>The length of the PV using hash tables is variable because you don't know the >>>>>length of the PV...you just keep probing the hash until you can't get anything >>>>>useful out of it. >>>>> >>>>>for example: >>>>>triangular array PV: A B C D E >>>>>walking the hash PV: A B C D E F G >>>>> >>>>>you got move F because you probed position E and found a good move to print. >>>>>Move G from probing position F. Triangular array PV has a definite depth--search >>>>>depth limited. >>>>> >>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> 3) I update my triangular array in the main search and the >>>>>>>> quiescence search. reasonable? >>>>>>> >>>>>>>yes. The problem with qsearch is that it's just "cleanup"--considers only >>>>>>>certain types of moves. So qsearch section of the PV might contain some stupid >>>>>>>moves you might not want to display. There's nothing wrong with knowing what >>>>>>>your qsearch is doing, though... >>>>>> >>>>>>More information is never less, to be sure. >>>>>> >>>>>>> >>>>>>>> >>>>>>>> 4) Anything else you can think of. >>> >>>Ok these are some random but relevant questions: >> >>>1. When you make a two-square pawn move, and the opponent cannot make an ep >>>capture, do you hash-xor the "target" ep square in the hash table? >> >>Currently no special handling is done for the hash table in regards to >>enpassant. That information is not recorded in any way. >> >>>2. When you get a null move cutoff at a node and store in the hash table, do you >>>store NULLMOVE as the move in the hash table, or do you store the move from the >>>hash probe at this node? >> >>When the null move score is >= beta, I am returning >>from the search routine immediately. No hash store. >> >>Stuart > >I highly recommend trying it, null move cutoffs are a major portion of your >search! Storing them will give you a speedup esp with 1-tier, 1 second searches. > Now tell me your WAC results :) > >Michael I implemented 2-tier this past weekend and also just implemented the storing of null move cutoffs in the hash table. I measure by result on test suite and didn't check overall tree size but need to redo that to answer the question. The test suite result didn't improve as a result of either of the above. 250/300 is a hard limit for me right now. We'll see what happens in the coming weeks. I constantly rework things that I have tried before and abandoned or that I think won't work or that were already (I think) implemented properly -- to see if some slipup would give an extra position or two. Also I am constantly trying anything from the bulletin board. Well, thanks for the interest and support. The final 16.67% will take 99.999% of the effort I am sure. 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.