Author: Vincent Diepeveen
Date: 11:22:38 04/07/04
Go up one level in this thread
On April 07, 2004 at 14:16:31, Robert Hyatt wrote: >On April 07, 2004 at 11:27:47, Vincent Diepeveen 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. >> >>Xinix is a very efficient searching program with a good qsearch. >> >>Better qsearch means more efficient main search. > >Has absolutely _nothing_ to do with number of "transpositions" however... It actually does, because in crafty your fliprate is like 5% or so i remember and probably hasn't changed much sincethen. It is a result of not storing in qsearch and doing little in qsearch. In software doing checks in qsearch and storing them the fliprate is < 1% usually. Xinix belongs to that group. >That is simply a characteristic of the tree being searched and its size and >number of branches... > >If you get over 30% hash hits, something odd is going on in the middle game. IE >horrible move ordering or something... In contradiction a very good move ordering happens. He just researches the same tree time and again. In crafty you do not. You just keep searching new trees because of the instable qsearch+eval scores you get back. Each new iteration something <= alfa flips to >= beta, causing you a ply down to research for a <= alfa node possibly suddenly entire new trees you didn't search before. So a higher % there is a direct result from a more efficient search + storing in qsearch. > >> >> >>> >>>> >>>>Tony >>>> >>>>> >>>>>the tt_retrieve code retrieves a move, which I call the TT_MOVE_SUGGESTION. >>>>> >>>>>could someone provide me with a % of TT_MOVE_SUGGESTIONs in a search? >>>>> >>>>>Cheers...
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.