Author: Uri Blass
Date: 19:41:01 07/31/04
Go up one level in this thread
On July 31, 2004 at 21:51:01, Robert Hyatt wrote: >On July 31, 2004 at 13:01:26, Sune Fischer wrote: > >>On July 31, 2004 at 10:43:44, Robert Hyatt wrote: >> >>>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... >> >>I think it would, what else is the point of nullwindows in general? > >Slightly more efficient. But "slightly" is the opterative word if you have a >good aspiration window to start with. But that is only "maybe" as well. IE for >your null-window search, you probably want to set the window to some delta value >below what you believe is the "true score". If you do that, you will get a >fail-high, but that takes way longer than the fail-low. Meanwhile you have to >search a while to decide it won't fail low. If you do this reasonably, you >search to the fail high. And by then it is possible that I'll have a real score >for the first move rather than a >= some artificially lowered window. > >IE it isn't a clear win, IMHO, without a _lot_ of test data to show that it >works and is worth the extra complexity over having no special-case code at >all... > >> >>It gives you very little information (never an exact score), so if it's not >>faster... >> >>>>>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. >> >>No I said something else in your _experiment_ was different. > >Yes. The only thing different was my _search_. absolutely nothing else. > > >> >>If you make several changes in the same experiment, then it's not easy to say >>which is causing what. Maybe you threw out the baby with the bathwater. > >I made zero changes for the experimental setup. I later changed from predicting >to searching until time ran out and got better results. That's all I said. >That's all I have _ever_ said. > > >> >>> I just pointed out that _lots_ of things in my search are >>>different, >> >>Of course, and your point would be...? > >one of us is on a different page. You now say "if you make several changes..." >when I _never_ do that and never have. Where that came from I have absolutely >no idea. I simply pointed out that I had a search that did what you suggest, >namely using a null-window search at the start of each iteration. We went >downhill from that point somehow... null-window search at the start of each iteration was not what Sune suggested. He suggested null-window search only in iteration that he is almost sure that he has not enough time to complete and it means that he even does not suggest to do null move search in every move because there may be moves when he will believe that he has time to finish the iteration but find that he has not time so he may stop in the middle of the iteration. > > >> >>> so using your logic, we can't compare _anything_. >> >>Before you start analysing my logic it would be nice if you could understand >>what I'm talking about. > >I believe I understand the idea perfectly. It isn't that complicated and it >isn't new. I simply don't like it. If you do, fine. I'm obviously not >responsible for your engine nor you mine. > > >> >>>I agree the idea is broken. But it wasn't _my_ idea. :) >> >>So you make your conclusions _before_ you run the experiment? >> >>Fasinating, and how incredibly errorprone. > >Never did that. Never said I did. So there definitely is something incredibly >error prone here. But not my testing methodology... > > > > >> >>>>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... >> >>Well, maybe it won't work in Crafty then. >> >>I'm sure you'll come to that conclusion regardless with your very objective way >>of concluding things. > >Since I have tried other ways, yes I have reached the conclusion that what I do >is best for my program. I arrived at _every_ decision made in Crafty by lots of >testing. > > >> >>>>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. >> >>Ah, so you admit there is room for improvement! >> >>That in itself is an improvement I think :) > > >Have you _ever_ seen me claim anything I do is _perfect_? I'll give you the >same challenge as I have repeatedly given to Vincent. Please post a quote or >reference or citation of such a claim. I have _often_ said "I tried that and >didn't like it but you should test to see if it works for you" however. That's >hardly a claim of "perfection" IMHO. > > > > >> >>>>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. >> >>I repeat: I have _never_ seen such a position. > >What does that mean? I've never seen an atom split. Doesn't mean it doesn't >happen and that others have not done it. > > > > > >> >>you posted this, as an example of an extreme position: >> >>>> 35-> 15.93 8.92 1. Kb1 Kb7 2. Kc1 Kb8 3. Kc2 Kb7 4. >>>> Kc3 Kc7 5. Kd3 Kb7 6. Ke2 Kc7 7. Kf3 >>>> Kd7 8. Kg3 Ke7 9. Kh4 Kf6 10. Kh5 Kf7 >>>> 11. Kg5 Kg7 12. Kxf5 Kf7 13. Ke4 Ke8 >>>> 14. Kd3 Ke7 15. Kc4 <HT> >>>> 36 17.33 8.92 1. Kb1 Kb7 2. Kc1 Kb8 3. Kc2 Kb7 4. >>>> Kc3 Kc7 5. Kd3 Kb7 6. Ke2 Kc7 7. Kf3 >>>> Kd7 8. Kg3 Ke7 9. Kh4 Kf6 10. Kh5 Kf7 >>>> 11. Kg5 Kg7 12. Kxf5 Kf7 13. Ke4 <HT> >>>> 36-> 17.33 8.92 1. Kb1 Kb7 2. Kc1 Kb8 3. Kc2 Kb7 4. >>>> Kc3 Kc7 5. Kd3 Kb7 6. Ke2 Kc7 7. Kf3 >>>> Kd7 8. Kg3 Ke7 9. Kh4 Kf6 10. Kh5 Kf7 >>>> 11. Kg5 Kg7 12. Kxf5 Kf7 13. Ke4 <HT> >>>> 37 18.68 8.92 1. Kb1 Kb7 2. Kc1 Kb8 3. Kc2 Kb7 4. >>>> Kc3 Kc7 5. Kd3 Kb7 6. Ke2 Kc7 7. Kf3 >>>> Kd7 8. Kg3 Ke7 9. Kh4 Kf6 10. Kh5 Kf7 >>>> 11. Kg5 Kg7 12. Kxf5 Kf7 13. Ke4 <HT> >>>> 37-> 18.70 8.92 1. Kb1 Kb7 2. Kc1 Kb8 3. Kc2 Kb7 4. >>>> Kc3 Kc7 5. Kd3 Kb7 6. Ke2 Kc7 7. Kf3 >>>> Kd7 8. Kg3 Ke7 9. Kh4 Kf6 10. Kh5 Kf7 >>>> 11. Kg5 Kg7 12. Kxf5 Kf7 13. Ke4 <HT> >> >>a = time(ply 36) = 17.33-15.93 = 1.40 >>b = time(ply 37) = 18.70-17.33 = 1.37 >> >>So we have b = 0.986*a. >>I don't where you took math, but I was tought that 0.986 is MUCH LARGER than >>0.20. >> >>Correct me if I'm wrong. >> >>-S. > > >What does that have to do with anything? You said "if less than 20% of time >remaining, don't start another iteration." That will fail in the above case if >you simply assume your target search time is (say) 20 seconds. Yet there is >_plenty_ of time for another iteration to finish. I think that there is some misunderstanding here. I am not going to look exactly what he said in earlier posts but it is clear to me by his example that he meant: "Do not start a new iteration if you cannot finish it even in case that the time of the next iteration(ply N+1 minus ply N) is going to be 20% of the time of this iteration(ply N minus ply N-1)" Uri
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.