Author: Robert Hyatt
Date: 18:51:01 07/31/04
Go up one level in this thread
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... > >> 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.
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.