Author: Uri Blass
Date: 01:54:24 12/28/01
Go up one level in this thread
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. > >You failed to mention your idea of using a different eval function... could have >saved everybody some breath. > >-Tom You are right and I am probably going to generate my SEE after enough plies in the qsearch. I know that programs like Crafty use SEE but it is using it only for a better order of moves in the qsearch and not for evaluation. I (like cristhophe) do not believe that ideas that were good for old programs are useless for the new programs. My program generates attack tables for every square in the board so I think that this information can be used for a faster SEE but still there are problems. The information that I have is: 1)an array int directsee[64]; This array gives For every suare in the board a 32 bit number that is the direction that white attack it and the direction that black attacks it. 2)An array int squaresee[64][16] that gives for every square and direction the square of the attacker. 3)pin array int pin[64] that tells me for every piece of the side to move if it is pinned Finding the pieces of the attackers of a square based on this information is still not simple enough(I need always to look at directsee first to detect directions and later to look at squaresee to find the squares) and I need to consider if it may be better to generate more information in my makemove function. The information of the squares of the attacker still cannot help to detect a case when white has a Rook at a2 and a queen at a1 when black has a pawn at a7 and a rook at a8 when the capture Ra2xa7 is a good capture and based on looking at the comments for swap.c of Crafty's code it seems that Crafty knows that this capture is a good capture. I may consider to generate another array in order to detect that the queen at a1 threats the pawn at a7 indirectly. The question is if the benefit from these attack tables is bigger than the disadvantage in the speed of my move generator. Note that I tried to do optimization of my move generator for speed(I talk only about the algorithm and I did not try to optimize it by using assembler and I know nothing about assembler) but I still have ideas how to do my move generator faster with generating the same information. My makemove function is similiar to my undomove function and I believe that it may be better to remember all the changes that I do in my makemove and doing the opposite changes in my undomove function. Inspite of not doing it and inspite of using only C and not assembler in my program my move generator is clearly better than every free program that I know in calculating the function perft(it does not need to make the last move and unmake it because it generates a list of only legal moves and this idea is not clearly bad and the best mate solver chest also generates only leagl moves). 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.