Author: Robert Hyatt
Date: 11:07:52 09/28/04
Go up one level in this thread
On September 28, 2004 at 13:43:48, Stuart Cracraft wrote: >On September 28, 2004 at 08:44:04, martin fierz wrote: > >>On September 28, 2004 at 08:19:15, Stuart Cracraft wrote: >> >>>On September 28, 2004 at 02:14:51, martin fierz wrote: >>> >>>>On September 27, 2004 at 23:45:54, Stuart Cracraft wrote: >>>> >>>>>I experimented with reordering root ply at iterative depth iply > 1 >>>>>where 1 is the root ply, with the results of iply-1 sorted by the >>>>>total nodes of quiescence and main search defined as the # of entries >>>>>for each of those subroutines. >>>>> >>>>>I didn't sort at root node on the first sort by quiescence but instead >>>>>by my normal scheme though I tried quiescence and it was worse. I felt >>>>>this gave a better chance to the above method. >>>>> >>>>>I sorted moves at the root ply for iply > 1 in the following way >>>>>for 7 different parts to the experiment. >>>>> >>>>> sort by normal method (history heuristic, mvv/lva, see, etc. >>>>> sort exactly by subtree node count, nothing else >>>>> sort by subtree node count added to normal score (hh, mvv/lva, see, etc.) >>>>> same as previous but node count x 10 before addition >>>>> same as previous but node count x 100 before addition >>>>> same as previous but node count x 1000 before addition >>>>> same as previous but node count x 10000 before addition >>>>> >>>>>The results, measured by # right on Win-at-Chess varied from >>>>>250 for the first in the list above to 234 for the last. >>>>>Most bunched up between 244-247 except the first was 250, >>>>>my current best on WAC with handtuning everything. >>>>> >>>>>For me, I'm convinced that this style of sorting root ply is >>>>>slightly less good for my short searches compared to what I am using: >>>>>a combination of history, heuristic, see(), and centrality with >>>>>various bonuses, about a half page of code sprinkled about. >>>>> >>>>>The advantage of sorting root node by subtree is the simplicity. >>>>>It eliminates about a half a page of code and introduces >>>>>about a quarter page of code for only slightly lesser results >>>>>(within 1-2% of my current result) so that is good. >>>>> >>>>>Still I think I'll leave it #ifdefed out for now and use it as >>>>>a baseline that is only improvable upon with handtuning of my >>>>>current methods and others to be discovered. >>>>> >>>>>Stuart >>>> >>>>...as ed schröder said to me: "terrible testing". he was right, of course. >>>> >>>>cheers >>>> martin >>> >>>Each to his own. >> >>if you get free advice from one of the world's best computer chess programmers >>it is a good idea to use it. there's not much point writing tons of posts here >>asking for advice if you don't listen.... >> >>cheers >> martin > >Well, condemnations aside, without specific feedback beyond "Oh that's just >bad" (I can get that at work from the boss or from relatives) -- I don't >respond well to that kind of input. It is non-constructive. > >Specific constructive feedback, regardless of the person's perceived or >actual stature please. > >Stuart Here is what is bad: You are searching for 1 second per position. Exactly how accurate do you think that one second time interval is? Probably +/- .1 seconds or so. So you introduce a random variability because your time error is a major fraction of the total time used. If you search for 60 seconds, the operating system won't introduce nearly as much error (still +/- .1 second or whatever it really is) and that error percentage is small enough that it will not introduce nearly as much random noise. 1 second is simply NFG. At least you should make it 1 sec + complete current iteration before stopping. And that might not be good enough on such short searches...
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.