Author: Sune Fischer
Date: 00:12:54 07/30/04
Go up one level in this thread
On July 29, 2004 at 20:00:04, Robert Hyatt wrote: >>Then why did it not work, which part failed, what is your analysis? > >I did the null-window search. It returned almost instantly without a fail-low. >I have time left. What do I do with it? Now the idea is to simply stop searching and save the remaining time. There is not much point in doing anything thing else because you don't have enough time to resolve a real score and go to the next ply. >I simply think that turning a boundary condition into a special-case, when all >the "rules" are not known (tree size, fail low time, etc) is at least no better >than just ignoring things. I think it is a little bit of the best of both worlds. You get the information you want regarding a fail-low, and you get to save some of the time. > IE I could take the logs for three wins and three >losses on ICC, and post a summary of the times to see what the current approach >did that was good or bad... And then I could go back to the key positions and >see what would happen with a different approach. Well you don't have to do anything, but I'm going to test it in gauntlets. If it doesn't work I'd sure like to understand why not! :) >>>>>Your "assumption" is based on facts that have tons of contradictory evidence (IE >>>>>I _have_ done lots of testing and reported on it many times in various ways.) >>>> >>>>AFAIK it was a completely new spin on an old idea. >>> >>>There's nothing new about the null-window search at all. As I said, in 1980 >>>_every_ search I did started with a null-window search. As did Belle's... >> >>Don't mix two experiments here, I'm not talking about starting every search with >>a nullwindow... > > > >What is the difference? The _last_ search is started with a null-window which >is what you are suggesting. Yeah but your also doing a lot of other crap at all the other plies. It's simply a different experiment as far as I'm concerned. >> >>Be careful with drawing too many parallels here. >> > > >The issue is when time is low, doing a null-window search rather than a normal >search. That is _exactly_ what happened in the old program. You haven't tested it like I suggested, so you haven't tested it - period. This is just like the time we had that history table discussion, you had also run a lot of experiments but _not_ the one I suggested. :) What happened to all your "I'm an experimentalist".... :) >What happens >_before_ time is low is irrelevant. How do you know that? Why should this not waste a lot of time and make the whole thing look bad? >>>>I read your conclusion that ply N took 1.5 and ply N+1 took 1.4. >>>>This is what I call the same magnitude, ie 1.4 >> 0.15*1.5 >>> >>>Yes. But _both_ together took less than 15% of the total time used up to that >>>point... >> >>Yes that's true, but I think you should compare the last iteration time with the >>time remaining, that way you eliminate a big branchfactor issue. >> > > >In one search, I can see the effective branching factor go from 1.7 to 10.0 on >extreme cases. Regularly from 1.5 to 5.0 when things are "right"... > >And I am talking about the iteration-to-iteration effective branching factor, >not completely different searches. I can post some of those for clarity if need >be... If branch factor goes up it works even better, it's the other way that can cause problems. >>I think only testing is the way to go. >> > > >As do I. I think you are a great believer in drawing fast conclusions based on similar experiments - "details don't matter enough to make a difference"!? :) -S.
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.