Author: Uri Blass
Date: 12:11:31 06/04/02
Go up one level in this thread
On June 04, 2002 at 14:35:08, Robert Henry Durrett wrote: >On June 04, 2002 at 13:12:14, Uri Blass wrote: > >>On June 04, 2002 at 10:49:00, Vincent Diepeveen wrote: >> >>>On June 04, 2002 at 08:54:57, José Carlos wrote: >>> >>>What i read in Dann's words is he is more believing in search >>>rather than the knowledge. If that's the case then i think he is >>>wrong. >>> >>>I do not see how to easily improve search either. >>> >>>Let's compare diep 1998 with diep 2002. >>> >>>Of course when takling about eval we are quickly finished. It's >>>way bigger now and way better. Let's just compare the SEARCH now. >>> >>>DIEP 2002: 8 probes hashtable, nullmove R=3 always, 2 killermoves, >>>complex move ordering but not that much changed last years, >>>some complex extensions but those >>>do not contribute much to the game, at most solve testsets a bit >>>sooner. quiescencesearch is pretty complex but compared to 1998 >>>very simple as i do way more there now. >>> >>>Now DIEP 1998, this is a very complex search. First of all i did >>>all kind of efforts to not get too undeep. It was getting not enough >>>depth at tournament level to even see basic tactics which i see. >>> >>>So i did all kind of difficult forward pruning. Also weird things >>>like special killertables were used. Special information was gathered >>>in order to search less last few plies and qsearch was way more >>>limited. Nearly no check was extended in the main search, because >>>this was to expensive. Hardly any extension was done there. >>> >>>Of course it was not a parallel engine, but that's about only thing >>>which has become more complex in search, though it in fact is still the >>>same type of search. >>> >>>In short my search has become much simpler, especially when talking >>>about quiescencesearch. I'm not blinking with my eyes now to have >>>a bigger overhead there! >> >>Better search rules does not mean always more complex rules. >> >>The right rules also may be dependent on the evaluation and I think that this is >>a good reason after getting to the level of programs like my program that is in >>similiar level to the Baron to start with improving the evaluation(otherwise you >>may waste time on implementing some rules that are good for your stupid program >>when you will need to change them when you have a better program). >> >>I do not like the idea of writing a lot of evaluation code for a lot of cases >>and I think that a better idea is to think about few rules that generalize a >>lot of cases. >> >> >>Uri > >Is it fair to infer from the above that you are doing the following? > >(1) First evaluate a position, > >(2) Then chose a small set of "search rules" from a large set of available >rules [available in your software], with this selection based on the findings of >the position evaluation, > >(3) And, finally, perform a search from that position using the selected >"search rules"? > >Bob D. No. When I said that the right rules may be dependent on the evaluation I meant that it is possible that the optimal search rules after improving the evaluation is different(for example it is possible that null move with R=2 is better for a bad evaluation when null move with R=3 is better for better evaluation). I do not like to waste time about testing when the new search rules may be worse for the new evaluation. What you suggest may be a good idea but today there is only a small set of search rules and not a large set of search rules. 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.