Author: Robert Henry Durrett
Date: 13:18:42 06/04/02
Go up one level in this thread
On June 04, 2002 at 16:09:26, Uri Blass wrote: >On June 04, 2002 at 15:28:03, Robert Henry Durrett wrote: > >>On June 04, 2002 at 15:11:31, Uri Blass wrote: >> >>>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 >> >>Thanks. >> >>What I was trying to do is to better understand which positions are evaluated >>[only the position which occurs immediately after a move? Other positions >>occurring during search?], the form/format/content of the evaluation findings, >>and how these might be processed or utilized. >> >>Probably different for each chess engine? > >Yes >Things are different for different engines > >I do not want to discuss about what Movei does but there are a lot of free >programs with source code. > >I believe that Movei does some things that no other free program does but I do >not know because I am too lazy to read all the source codes and I cannot ask >because I do not want to tell my ideas. Well, I guess my ideas are free, since I am not in competition. But you get what you pay for. :) Bob D. > >Note that Movei is clearly weaker than the best free programs because the weight >of the good ideas that Movei does not use is clearly bigger than the weight of >the good ideas that the best free programs do not use. > >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.