Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Algorithms vs. knowledge - What to do next?

Author: Uri Blass

Date: 13:09:26 06/04/02

Go up one level in this thread


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.

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.01 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.