Author: Uri Blass
Date: 09:03:04 12/29/01
Go up one level in this thread
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
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.