Author: Robert Hyatt
Date: 10:03:14 03/30/01
Go up one level in this thread
On March 30, 2001 at 12:34:37, Christophe Theron wrote: >On March 30, 2001 at 03:29:51, Tony Werten wrote: > >>On March 29, 2001 at 22:38:33, Christophe Theron wrote: >> >>>On March 29, 2001 at 16:01:51, Tony Werten wrote: >>> >>>>On March 29, 2001 at 15:12:21, Christophe Theron wrote: >>>> >>>>>On March 29, 2001 at 14:39:34, Tony Werten wrote: >>>>> >>>>>>On March 29, 2001 at 14:21:16, Christophe Theron wrote: >>>>>> >>>>>>>On March 29, 2001 at 13:49:06, Tony Werten wrote: >>>>>>> >>>>>>>>On March 29, 2001 at 13:31:59, Christophe Theron wrote: >>>>>>>> >>>>>>>>>On March 29, 2001 at 09:14:57, Robert Hyatt wrote: >>>>>>>>> >>>>>>>>>>On March 29, 2001 at 06:22:13, Jouni Uski wrote: >>>>>>>>>> >>>>>>>>>>>On March 29, 2001 at 06:17:50, Alexander Kure wrote: >>>>>>>>>>> >>>>>>>>>>>>On March 29, 2001 at 04:37:19, Tony Werten wrote: >>>>>>>>>>>> >>>>>>>>>>>>>Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>>until what depth do various programs probe the tablebases ? >>>>>>>>>>>>> >>>>>>>>>>>>>cheers, >>>>>>>>>>>>> >>>>>>>>>>>>>Tony >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>Hi Tony, >>>>>>>>>>>> >>>>>>>>>>>>In London 2000, I let Nimzo 8 play with a depth of 6 plies, but later I came to >>>>>>>>>>>>the conclusion that 8 plies might be better overall. This is indeed the default >>>>>>>>>>>>setting of NimzoX and Varguz playing on ICC. >>>>>>>>>>>> >>>>>>>>>>>>Greetings >>>>>>>>>>>>Alex >>>>>>>>>>> >>>>>>>>>>>Sorry one stupid question: is this the first or last 6/8 plys? >>>>>>>>>>> >>>>>>>>>>>Jouni >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>His statement would make no sense if it were the _last_ 6-8 plies. Those >>>>>>>>>>are the ones that kill performance if you aren't careful. The first 6-8 plies >>>>>>>>>>don't cost a thing. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>But it could also mean it probes TBs in all the plies except the last 6/8. >>>>>>>>> >>>>>>>>>Meaning that if Nimzo is doing a X plies search, then the program probes the TBs >>>>>>>>>in the tree for all nodes that have a distance from the root below or equal to >>>>>>>>>X-6 (or X-8). >>>>>>>> >>>>>>>>Could be but that would mean, with an average depth of 10 to 12, you'd be >>>>>>>>probing the first 4 to 6 ply. I mean, it helps but it could help more. >>>>>>>> >>>>>>>>That is, not counting extensions, but you if you search 10 ply, you don't know ( >>>>>>>>at ply 8 ) how many plies are still coming. >>>>>>>> >>>>>>>>cheers, >>>>>>>> >>>>>>>>Tony >>>>>>> >>>>>>> >>>>>>>But you know how many plies you have done since the root position... >>>>>> >>>>>>2 possibilities: >>>>>>- We are talking about different things >>>>>>- I don't get it >>>>>> >>>>>>Might be both. >>>>>> >>>>>>Tony >>>>> >>>>> >>>>>You don't know how many extensions you are going to do, so you just ignore >>>>>extensions and assume you are going to search full width the same number of >>>>>plies as your iteration number. >>>>> >>>>>So at iteration 10, stop probing TBs after two moves from the root (assuming >>>>>like Nimzo that you don't probe in the last 8 plies of search). >>>>> >>>>>That is why I say "you know how many plies you have done since the root >>>>>position...". >>>> >>>>But then you don't have almost no depths where you probe. (In your example only >>>>ply 1 and 2 ) >>> >>> >>> >>>Yes, but your NPS does not go too low then. >>> >>>It's a compromise between speed of search and accuracy of the evaluation. >>> >>>Don't forget that accessing a TB slot can be as expensive as searching 1000 >>>nodes (depends on your program). And that many TB accesses are just a waste of >>>time because they are not going to have any influence on your main line. >>> >>>I'm not saying that 8 plies like in Nimzo is the right number (actually I'm not >>>even sure that Nimzo does it this way). >>> >>>In Tiger I stop accessing the tablebases a few plies before I reach the horizon. >>>If I don't do that the program gets much weaker because of the dramatically >>>slower NPS. >> >>Make your program slower ! >> >>XiniX is a slow searcher and I'm testing on slow hardware so I hardly notice a >>slowdown because of probing. ( Might not be the best solution ) >> >>The idea I have for probing a lot is that if a position is worth being searched, >>it's probably worth being probed. ( Unless you're very near to the leafs ) >> >>Hmm, search position normal, then store no nodes in hashtable, then when >>searched second time: if n.o. nodes>1000 do probe. I'll have a try. >>Maybe combined with: first x ply always probe. >> >>Positions below current position stored in hashtable can help with enhanced >>transposition cutoffs as well. >> >>I'll put it in my totry book. >> >>Tony > > >If you search 1000 positions per second and your hard disk is fast enough to >make 1000 probes per second, don't hesitate, you can probe everywhere in the >tree. > >But if you can make 100000 NPS, then probing always will weaken your program >significantly. > >That's also why you need 2 days to implement TBs in a program, and 2 months to >have them working right (improving the strength of your program). > > > > Christophe Note that even though you search 1M nodes per second as I do. I _never_ probe at that rate. Because if you only probe for captures that take you to 5 or fewer pieces, you eliminate most of the nodes quickly and don't probe there. The requirement that Move(ply-1)-> capture and TotalPieces(ply)<=5 _really_ restricts the number of probes, because if you probe there and you don't get a hit, you won't probe anywhere _below_ that node in the tree until another capture is made...
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.