Author: Christophe Theron
Date: 16:03:06 12/29/01
Go up one level in this thread
On December 29, 2001 at 12:03:04, Uri Blass wrote:
>On December 29, 2001 at 11:16:23, Christophe Theron wrote:
>
>>On December 28, 2001 at 02:09:49, Tom Kerrigan wrote:
>>
>>>On December 28, 2001 at 01:44:04, Uri Blass wrote:
>>>
>>>>On December 27, 2001 at 20:39:31, Tom Kerrigan wrote:
>>>>
>>>>>On December 27, 2001 at 15:47:33, Uri Blass wrote:
>>>>>
>>>>>>There are practical cases when the qsearch include
>>>>>>hundreds of nodes
>>>>>
>>>>>Hundreds of nodes are insignificant.
>>>>>
>>>>>Every node you search that doesn't end up in the PV is arguably wasted.
>>>>>
>>>>>It has been pointed out to you that if you do static evaluation of a dynamic
>>>>>position, the results are absolutely worthless. I do not believe you've
>>>>>responded to this argument. Do you disagree with it?
>>>>>
>>>>>-Tom
>>>>
>>>>The results are not absolutely worthless
>>>>
>>>>I can also use a special evaluation
>>>>to reduce the demage and I agree that using evaluate that only count pieces in
>>>>the board is not the right evaluation.
>>>>I expect the side to move to earn something(I can assume that the side to move
>>>>earn half of the material that it can capture and I think that I have better
>>>>ideas that do not cost me a lot of time).
>>>>
>>>>Uri
>>>
>>>Some earlier programs did not do qsearches (due to lack of processor power) but
>>>they did do SEE of the pieces on the board during evaluation. Seems like this is
>>>what you're interested in.
>>
>>
>>
>>I would like to point out that in most of the cases, using a SEE is MORE
>>EXPENSIVE than doing a real, unlimited QSearch.
>>
>>It sounds strange, but the reason is that in most of the cases the QSearch will
>>search no node (no capture available or eval>beta) or only one node and stop,
>>which is faster than calling your SEE. Naturally that depends on the speed of
>>your SEE, but in all my programs (slow searchers and fast searchers), using SEE
>>instead of QSearch was a loser.
>
>Note that my makemove function generates attack tables for every square in the
>board so for me makemove is relatively slow and I need to think if there is an
>efficient way to calculate SEE.
>
>The case eval>beta or no capture available is no problem because before I call
>SEE in the qsearch I may check if eval>beta or if no move available in the
>qsearch(I do not say capture because promotion is also a move that is considered
>in the qsearch even if it is not a capture)
>
>Uri
OK, anyway you need to check it by yourself.
Something else: in some endgames, SEE is a killer.
Take for example a KBPPKP which is a draw if white exchanges one of its pawns
against black's, ending up in a draw KBPKP.
A SEE cannot see this. You can see it only if you play the capture sequence.
Once the position is on the board your evaluation sees that it is a draw. But if
you let your SEE evaluate the exchange sequence, it will return a score
approximately equal to the KBPPKP score (score=B+P), very far away from a draw
(score=0).
Once your program starts to have a lot of endgame knowledge, the SEE starts to
create big distortions. I can think about a lot of these cases.
Christophe
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.