Author: Uri Blass
Date: 10:04:59 08/19/04
Go up one level in this thread
On August 19, 2004 at 12:28:01, Jonas Bylund wrote: >>>Isn't there in "normal" engines condensed code in terms of knowledge that you >>>would like to add but the cost in kn/s is too high, knowledge that you know is >>>sound, but it will not work for your engine in practical play at popular time >>>controls? >> >>If it will not work at popular time controls then I do not know that it is sound >>and has no bugs unless I do a lot of testing. > >It is my understanding that search depth and speed becomes inreasingly more and >more important, the shorter the time control is. It is not clear that the same is not for evaluation. It is possible that at blitz you need knowledge in order to win some position with some material advantage when at long time control search can do the job even if you do not have the knowledge because you search deep enough to see winning more material. I can give a simple example. Suppose a program does not have tablebases and does not know to win KQ vs K. At blitz it can miss the win but at long time control it can see deep enough to see the mate so it can win the game. Therefore i assumed that adding >knowledge that might speed things down and even slow down the search depth, >would result in counter productive play at faster time controls. maybe i got >that all wrong? Things are not so simple and I explained that there may be knowledge that is productive only at blitz. > >>> >>>My suggestion was not to cramp in all the knowledge at once, but to gradually >>>add the knowledge to the extend where you might even see an increase of strength >>>in 40/2 20/1 30 min for the rest games, but a decrease in strength in blitz and >>>rapid games. >> >>I see no reason to assume that some knowledge that is counter productive at >>blitz starts to be productive at 40/2 hours. > >It was more the other way around, that what might be productive for longer TC's >might be counter productive far fast TC's, please see above reply. The problem is that you do not know that something is productive for long time control in the first place. > >>Tests may prove that it something is productive at long time control but the >>same testing time to prove it can be used to find different improvements that >>are relevant for all time control so I do not think that it is smart to spend >>time on this testing when there is a good chance that the results will show that >>the change is counter productive. >> >>Uri > >What i mean is: if someone that has developed a chess engine have made >considerations towards having it play as good as it can at different time >controls including blitz and bullet even, then if this person was to remove >those considerations and not pay any attention to the faster time controls, when >developing his engine further, could it have a positive effect at long time >controls. No The problem is that even when the programmer try to improve things at blitz he can find that what he believed to be productive is not productive. If the programmer know that he does not know if a change is productive at blitz without testing then it is clear that he also does not know if a change is productive at long time control without testing and I see no reason to waste time on changes that are maybe productive at long time control and counter productive at blitz when there are probably a lot of productive changes for all time controls. 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.