Author: Uri Blass
Date: 23:04:52 10/15/03
Go up one level in this thread
On October 16, 2003 at 01:40:39, Uri Blass wrote: >On October 15, 2003 at 23:26:41, Christophe Theron wrote: > >>On October 14, 2003 at 18:47:31, Uri Blass wrote: >> >>>On October 14, 2003 at 17:58:04, Christophe Theron wrote: >>> >>>>On October 14, 2003 at 03:54:28, Uri Blass wrote: >>>> >>>>>On October 14, 2003 at 03:49:38, Christophe Theron wrote: >>>>> >>>>>>On October 13, 2003 at 15:44:30, Joachim Rang wrote: >>>>>> >>>>>>>On October 13, 2003 at 14:19:14, Christophe Theron wrote: >>>>>>> >>>>>>>>On October 13, 2003 at 13:09:03, Charles Roberson wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> You make the statement that Diep is a positional engine and you chose it based >>>>>>>>>on that. So, why did you run G/5 matches? At G/5 tactics and search depth >>>>>>>>>is crucial. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>I would like to bring to your attention that tactics and search depth are >>>>>>>>crucial at any time controls in chess. >>>>>>>> >>>>>>>>Showing dimishing returns from increased search depth is so difficult that in >>>>>>>>practice there is little difference between blitz and long time controls. >>>>>>>> >>>>>>>>If engine A gets a beating at blitz, expect it to get the same beating if you >>>>>>>>repeat the match with long time controls. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Christophe >>>>>>> >>>>>>> >>>>>>>Hi Chrisotphe, >>>>>>> >>>>>>>this interesting statement was many times repeated from you, but in the meantime >>>>>>>a lot of tests have shown, that there are certain programs (not all) which give >>>>>>>different results at short and long games. Hiarcs i.E. is better at short >>>>>>>timecontrols, for Rebel the contrary is true. >>>>>> >>>>>> >>>>>> >>>>>>I do not think that your examples are true. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>I think one could easily tune an engine to short or long time controls (not that >>>>>>>this is necessarily a good idea, but it is possible and therefore you can not a >>>>>>>priori know if y program plays wiht equal relative strenght at all time >>>>>>>controls). >>>>>> >>>>>> >>>>>> >>>>>>It is possible, if you try hard enough, to build a very unbalanced chess >>>>>>program. >>>>>> >>>>>>But it is relatively easy to get rid of this problem. So I don't see why someone >>>>>>would design on purpose a program that would be weak at blitz and strong at long >>>>>>time controls. >>>>>> >>>>>> >>>>>> >>>>>> Christophe >>>>> >>>>>If somebody has a bad data structure so he cannot calculate the functions that >>>>>he needs fast then he may prefer instead of improving the data structure to >>>>>improve the branching factor so the program may earn more from time relative to >>>>>the opponents. >>>>> >>>>>Uri >>>> >>>> >>>> >>>>You do not need to be slow to have a state of the art branching factor. >>>> >>>>Take a very slow program (slow because it spends a lot of time ordering the >>>>moves) and add on top of that two plies of very fast search (not perfectly >>>>ordered, but not too bad either). >>>> >>>>You get a very fast searcher with an excellent branching factor (the last two >>>>plies might not very good in branching factor but you won't notice). >>>> >>>>Being fast is not an excuse for having a bad branching factor. >>>> >>>>Being slow won't give you any advantage in branching factor. >>>> >>>> >>>> >>>> Christophe >>> >>>I do not say that you need to be slow in order to have state of the art >>>branching factor but being fast is also a function of the data structure that >>>you choose. >>> >>>programmers have limited time and if they choose to improve order of moves >>>instead of improving the data structure then they may achieve being 200% faster >>>at slow time control and 50% faster at blitz instead of being 100% faster in >>>both cases. >>> >>>Uri >> >> >> >>I have repeated many times that it is possible to build an unbalanced chess >>program. >> >>But competitive chess programs are not unbalanced, because it is not excessively >>hard to build a balanced chess program. >> >>In the example you mention, the program would not be competitive because it >>would be anyway also slower at long time controls than programs based on a >>reasonably fast data structure. Not to mention the disaster at blitz. >> >> >> >> Christophe > >Unless the programmer found a way to have better branching factor relative to >the commercial programs and in that case it may be even better at long time >control and weaker at blitz. > >Uri I can add that personally I also plan to optimize my program for long time control at least in the near future. Of course I plan to make it better in every time control but I do not plan to do things like: 1)Using profile based optimization(I do not have it as a possibility in visual C++ 6 and I do not have visual C.net). I also do not like to waste time again and again after changes only for some static speed improvement when I expect big improvement not from doing things faster). 2)Using assembler stuff. 3)testing which functions to inline and which functions not to inline(I use today inline every suitable). Maybe I will do it if I believe that I cannot make it more than 100 elo better in a year by other ways but it is not the case today. 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.