Author: Uri Blass
Date: 03:47:22 04/08/04
Go up one level in this thread
On April 07, 2004 at 15:38:59, Tony Werten wrote: >On April 07, 2004 at 11:04:23, Robert Hyatt wrote: > >>On April 07, 2004 at 10:54:40, Tony Werten wrote: >> >>>On April 07, 2004 at 10:48:23, Renze Steenhuisen wrote: >>> >>>> >>>>>>>>>I'm sure it was some implementation bug with Renze. >>>> >>>>Anyone, >>>> >>>>I only store result from the main search, so no NULL-move and no Qsearch >>>>results. >>>>I get a TT-hit ratio of 11.73%, of which a part will generate cut-offs. >>>> (I call something a tt-hit when an entry is found with the same hashkey, >>>> draft does not need to be sufficient) >>> >>>Hmm, I'm sorry but that's way too low. You probably have a problem with your >>>hashkey. >>> >>>In XiniX I get a hitrate of at least 60% in normal search, >20% in qsearch. >> >>That can't be right unless you are talking positions like Fine 70... >> >>Too many have run that experiment over the years and 30% is the _highest_ number >>I have ever seen reported in opening/middlegame positions. > >:) We have different programs. > >The 60% is raw hits, and without leaf nodes ( I have them in quiescence hits ). >In total it would average to 30% i guess. (Can't check now) > >I think my singular extensions and checks in quiesc make sure it searches the >same tree often. It has to, since it only searches max 200Kn/s and at that speed >you can't afford to have an unstable search. I do not understand why do you say that at that speed you cannot afford unstable search. I see no relation between speed and the decision to search the same tree often. By that logic if you have a slow computer and you also search max 200 kn/s because of that reason you should decide about different search strategy. slow search can be for many reasons. Some possible reasons: 1)slow hardware 2)code that is not optimized for speed. 3)big evaluation 4)attack tables that are generated during make move Maybe you claim that you cannot afford slow search because you spend relatively more time on evaluation but I still do not understand what the claim that you can't afford to have an unstable search has to do with it and why unstable search is a bigger problem with big evaluation and not with slow evaluation. Uri
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.