Author: Uri Blass
Date: 20:29:40 07/31/04
Go up one level in this thread
On July 31, 2004 at 23:18:35, Robert Hyatt wrote: >On July 31, 2004 at 22:41:01, Uri Blass wrote: > >>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. > >I understand. But my point was that on the _last_ iteration, I started with a >null-window search _also_. Which is what he suggested. Just because I started >_other_ iterations with a null-window search was not relevant as I did that >anyway at the time... > > >> >>> >>> >>>> >>>>> 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)" > >That makes no sense. The next iteration will only take 20% of the time required >for the current iteration? This is rarely the case and this is the reason that sune assume that it is not going to happen. What I understood was that if 20% of the time is >left, then there is no reason to start another iteration. It seems that sune meant not to 20% of the target time but to 20% of the time of the last iteration that is smaller. If the time of the last iteration is x seconds and less than 0.2x second left to the target time then he suggests not to start a new iteration but only to check for fail low. Uri
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.