Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Junior-Crafty hardware user experiment - 19th and final game

Author: Vasik Rajlich

Date: 02:20:55 12/25/03

Go up one level in this thread


On December 24, 2003 at 10:54:45, Christophe Theron wrote:

>On December 23, 2003 at 21:44:07, Robert Hyatt wrote:
>
>>On December 23, 2003 at 18:25:26, Christophe Theron wrote:
>>
>>>On December 23, 2003 at 09:49:27, Anthony Cozzie wrote:
>>>
>>>>On December 23, 2003 at 08:50:51, Amir Ban wrote:
>>>>
>>>>>On December 23, 2003 at 08:09:34, Uri Blass wrote:
>>>>>
>>>>>>On December 23, 2003 at 06:47:18, Amir Ban wrote:
>>>>>>
>>>>>>>
>>>>>>>Thanks for running this match and for the interesting commentary.
>>>>>>>
>>>>>>>My point in playing this match was never to show how weak crafty is, but
>>>>>>>something different: Too many programmers and posters in this forum take the
>>>>>>>speed issue way too seriously. They don't understand the importance of
>>>>>>>evaluation, and when they do think about it, they think it's about pawn
>>>>>>>structure and a few super-rare endgame tableaus.
>>>>>>>
>>>>>>>I also needed to check that I've not been wasting my efforts in the last few
>>>>>>>years.
>>>>>>>
>>>>>>>Merry Christmas and Happy Hanukka,
>>>>>>>Amir
>>>>>>
>>>>>>I do not claim that evaluation is not important but my opinion is that search is
>>>>>>not thing that is less important.
>>>>>>
>>>>>>I also know that inspite of the fact that you say that evaluation is important
>>>>>>your evaluation takes only 20% of Junior's time(I do not know about latest
>>>>>>Junior but I know about previous post of you).
>>>>>>
>>>>>
>>>>>Less than 10% in most positions.
>>>>>
>>>>>
>>>>>>How is it possible?
>>>>>>
>>>>>>Did not you find important things to evaluate that it is simply impossible to
>>>>>>evaluate them fast?
>>>>>>
>>>>>
>>>>>There are many things I can do basically for free in my framework. There are
>>>>>things that break the model, and either are neglected or if considered critical
>>>>>get done outside it.
>>>>>
>>>>>
>>>>>>For example let talk about pieces that are in danger of being trapped because
>>>>>>the opponent control every square that they can goto.
>>>>>>
>>>>>>There are cases that you need to search many plies forward to see by search that
>>>>>>they are really trapped but a good evaluation should detect the danger.
>>>>>>
>>>>>>Correct me if I am wrong but I guess that you do not evaluate this information
>>>>>>in every node that you evaluate otherwise you cannot be faster in nps than the
>>>>>>opponents.
>>>>>>
>>>>>>Did you consider to evaluate this information or do you think that this
>>>>>>information is not important?
>>>>>>
>>>>>
>>>>>I do this for some important special cases. Not in the general case. It's hard
>>>>>for me to guess how productive that would be.
>>>>>
>>>>>
>>>>>>I think that evaluating expensive information in part of the cases is probably
>>>>>>the best practical idea.
>>>>>>
>>>>>>Based on my understanding Rebel is using that idea when it evaluates every node
>>>>>>before qsearch by full evaluation and use lazy evaluation after it when the lazy
>>>>>>evaluation can miss only factors that were not relevant before the qsearch.
>>>>>>
>>>>>>Do you use a similiar idea?
>>>>>>
>>>>>
>>>>>No.
>>>>>
>>>>>You are confusing between the evaluation elements and its result. Both are
>>>>>important, but it's still true that your evaluation of a position can use a lot
>>>>>of smart and correct elements and be totally off, and it is equally true that it
>>>>>can be right though neglecting a lot of important stuff.
>>>>>
>>>>>Amir
>>>>
>>>>
>>>>It seems like you and Christophe have some tricks up your sleeve.  He's been
>>>>making comments like this for some time about his new 'Fugu' thing.  It looks
>>>>like I'm going to have to do some serious thinking :)
>>>>
>>>>anthony
>>>
>>>
>>>
>>>The basic thinking with Fugu is that I'm fed up of evaluating every position. I
>>>want Chess Tiger to be able to understand which positions do not need more than
>>>a pure material evaluation, and which positions must be evaluated positionally
>>>very precisely.
>>>
>>>Another idea is to have an engine that performs two searches at the same time: a
>>>very deep, full speed tactical search, and a less deep, very slow positional
>>>search. The problem is what to do with the two results when they differ... :)
>>>
>>>
>>>
>>>    Christophe
>>
>>Look at Shaeffer's stuff on Sun Phoenix.  He had problems getting reasonable
>>efficiency on a distributed search with an old 10mbit ethernet LAN, so he
>>split the system into two parts, one that searched normally, one that did a
>>fast tactics-only search.  And he reached the same conclusion.  What to do
>>when they disagree.  Or when the positional search says "play X" and the
>>tactical search says "X sucks".  :)
>>
>>I don't like the concept myself, but perhaps it can work.
>
>
>
>Actually both searches would not be separated. They would be performed by the
>same algorithm. So you do not get two separate results as my previous post
>implied.
>
>The tactical and positional searches are completely interwoven, and information
>extraction happens everywhere in the resulting tree.
>
>So the final decision is not between move X and move Y. The final decision takes
>into account thousands of microscopic positional vs tactical results, where you
>add a positional score for depth 0 to a tactical score for a depth of 4 or 5 for
>example. The problem is that you can add a positional score that says that your
>queen is extremely well positioned, but the tactical search has already found
>that this queen will be exchanged 2 plies later.
>
>While it may sound completely screwed, I think it makes *some* sense (maybe not
>enough to be a successful idea, but who knows).
>
>The basic idea is to have a positional, not very deep search, but that is almost
>completely free of tactical mistakes.
>
>The potential of the idea is to allow for a more complex and expensive
>positional evaluation without losing tactical depth, which is as experience
>shows absolutely crucial in computer chess.
>
>
>
>    Christophe

Interesting. You could also prepare some data structures in the positional
search and use them in the tactical search, a sort of root-node pre-processing
repeated in mid-search.

What I'm curious about is, how expensive is a really heavy evaluation? I've put
into my engine a rather bloated eval and some conservative rules for doing only
lazy eval and still the eval takes up barely over 50% of the total search time.
This number seems hardly worth reducing - even reducing it to zero would only
double the nps, which is less than half an extra ply. It seems much more
important to improve the eval and to guide the search better than to worry about
a factor of 2 in the nps.

Maybe I underestimate the size of a really good eval. (Mine is about 4 months
old.)

Vas



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.