Author: Robert Hyatt
Date: 07:43:44 07/31/04
Go up one level in this thread
On July 31, 2004 at 05:08:34, Sune Fischer wrote: >On July 30, 2004 at 21:40:39, Robert Hyatt wrote: > >>>And lo and behold 95% of the time you waste your time. >> >>I'll remind you once more, 85% of the time you do iteration N+1 and don't get a >>new move. You just wasted _that_ time. It is the 15% case that is important. >>Ditto for failing low or high, etc... > >Which is why I prefer a faster method for detecting fail-lows, imagine if you >could detect 5% extra fail-lows! OK. That can be measured. I search with a very narrow aspiration window. I don't believe a null-window will fail low 5% faster, but I'll run that test tonight to find out and post the numbers... > >Haven't we already discussed this? :) > >>>Vanilla search has its advantages :) >>> >> >>When there are two equal alternatives, the simpler alternative is _always_ the >>best one. That is the KISS principle... > >But how do you know they are equal if you haven't tested it? > >>>What you have tested and found is that a + b < 0. >>> >>>I'm proposing that a > 0. >>> >>>This is indeed possible, solution space is b = -(a+p) , p>0. >>> >>>>>>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? >>>> >>>>Then we can _never_ compare results. Our searches are different. >>> >>>yes, but more importantly our experiments are different. >>> >>>I think if you want to test "a" there is no reason to be testing "a+b" and then >>>say we can't possible compare. >> >>We are _always_ testing A+B+C+D+E+F against G+H+I+J+K+F. Because the searches >>are different, the extensions are different, the evals are different, etc. > >I think this smokescreen isn't worth the paper it isn't written on. > >I suppose it is not possible for you to test PVS and nullmove as it has been >described either? Those are _your_ words, not mine. Remember? You complained that my null-window search wasn't done the same way you suggested because something _else_ in my search was different. I just pointed out that _lots_ of things in my search are different, so using your logic, we can't compare _anything_. I agree the idea is broken. But it wasn't _my_ idea. :) > >Imagine if one of your students came and showed you a code that implemented PVS >but at the same time had a lot of horrible futility pruning. > >He comes to you and claims he has proved PVS isn't working because his program >is playing a lot better without PVS and futility pruning. > >Do you accept such a ridiculous argumentation??? No, that's why I pointed out the flaw in that statement which is a variation on what you said earlier. > > >>>Yes it will, but the null-move search will _still_ be faster than the aspiration >>>search, so it saves time no matter how you twist and turn it. >>> >> >>Never said otherwise. What I _did_ say is that often you won't have time to >>fail low with either approach. -equality-. Often both will fail low. >>-equality-. A fraction of the time one will fail low and the other will not. > >Agreed. > >>Another fraction of the time neither will fail low and one will finish before >>the real time limit and quit while the other has a chance to find a better move. > >I don't believe this can practicly happen if you use careful estimates. I know it _does_ happen. I am looking at log files all the time and see some very unusual timing issues that are surprising... > >>I simply prefer the last case, which is what I do. If you don't like it, don't >>do it. That's pretty simple to deal with. I'm simply stating what I do, and >>why, and noting that I have tested _lots_ of alternatives before settling on >>what I do now. Not that it might not change in the future, of course. I doubt >>anything I do is totally "optimal" at present... > >I still don't see how you can know it's the best thing without testing the other >approach. > >You have no experimental data to support your claim and you have no convincing >arguments. > >You might still be right of course, but I don't trust your "gut feeling" that >much to let it convince me, particularly not when my own gut feeling says >something different :) > >>>> Except what threshold do you use to say "I don't believe >>>>I can complete the next iteration because I have less than xx percent of the >>>>total time left..." >>> >>>That's the big question of course, one very important parameter. Perhas a more >>>sophisticated algorithm would even be needed. >>> >>>Some experimentation would have to be conducted, or one could start by >>>collecting a bunch of data from real games and then grind the numbers. >> >>That's where my original algorithm started. I did this starting in 1978 where I >>became full-width iterated rather than selective search only. It originally >>worked fairly well. But as things changed, ie fractional extensions, null-move >>search and eventually singular extensions, the predictability went south and >>never came back. I eventually dumped it and found the thing was actually >>playing better due to the occasional fail-low at the last second triggering a >>deeper search to save a game. > >Ok, so your don't want to do anymore hassle on this part of your program. >It is perfect as it is! ;) "Perfect as it is" is your term. "better as it is" is my term. > >I'm just not ready quite yet to throw in the towl. > >>>Starting off by a careful estimate, eg. 20%, should be safe and good enough to >>>assert if it works or not. >> >> >>Where does 20% come from? v=rand()*100 or something similar? > >Experience, from watching a lot of engine output. > >I can not remember _ever_ having seen Time(ply N+1) < 0.20*Time(ply n) I posted one such example already. Another way to see odd results is a deep ponder search on the wrong move, where the hash table then provides scores that make search times way beyond unpredictable due to transpositions between the move pondered and the move played. > >It doesn't mean it can't happen, but it means that it's probably rare enough to >be ignored. > >-S. That's how I feel about the probability of the null-search finishing faster with no fail low...
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.