Author: Sune Fischer
Date: 16:20:59 07/29/04
Go up one level in this thread
On July 29, 2004 at 19:02:49, Uri Blass wrote: >On July 29, 2004 at 18:30:26, Sune Fischer wrote: > >>On July 29, 2004 at 11:44:39, Robert Hyatt wrote: >> >>>"more complicated" != "more advanced". I don't believe it is possible to >>>accurately forecast the time for the next iteration. Which means when is it >>>appropriate to do that quick nullwindow search? >> >>I can't pridict when a check extension is wasted and when it is useful either, I >>can only say if it works better or worse on average. >> >>> And when you do it and it >>>returns way quicker than you expected, what do you do with the remaining time? >>> >>>There appear to be more problems this way than with what I currently do... >> >>Simple != Good > >I agree and not agree. > >I agree that simple does not have to be good but I also think that exactly the >same thing can be more simple if it is a good code and less simple if it is a >bad code. > >For example it is possible to have in many places in the code some conditions >like: >if ((a-b)*p<=c) when a,b,p,c global varaibles and >a=The time now >b=time of starting the search >p=the expected brancing factor >c=time that is too big to start a new iteration. > >In my case I had some significant names but they still did not do the code easy >to understand. :) You should consider the context. Bob insinuated it was a bad idea because it was more complicated than what he did. By the same argument TSCP should be a better chess engine than Crafty, which it isn't, so obviously we must have Simple != Good, or should I say Simpler != Better. >It is also possible to have some code >if (time_next_iteration_is_too_big()) >when the functions time_next_iteration_is_too_big() is defined in time.cpp and >is using static varaibles that only that file knows. > >I think that the second solution is more simple inspite of the fact that the >algorithm is the same and I am now working on modification in movei to do the >code more simple without changing the time management algorithm. > > >> >>(I can play that game too:) >> >>>>But you have not tested what I'm suggesting. >>> >>>I have definitely tested doing a fail-low search. You can find references to >>>that back in 1978 which was when I finally dumped the idea of "don't start the >>>next iteration if I don't believe it can be finished..." >> >>Then why did it not work, which part failed, what is your analysis? >> >>>> >>>>>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... > >Note only that if you start some search with null move window it is not only a >change in time management. I don't really see the point in doing it a all plies though. For the first plies you are definitely interested in an exact score so eventually you will need to open the window, a nullwindow search will introduce some overhead. You have to find some way to make it save some nodes somewhere. It makes more sense at places where you only want a yes-no answer, such as the last ply where you only want to know if you fail-low or not. >I believe that it can be a good idea to do it but I am now interested only in >changes in time management so I do not plan to test it in the near future. Yeah, anything is possible :) >Uri -S.
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.