Author: Uri Blass
Date: 05:36:38 10/30/02
Go up one level in this thread
On October 29, 2002 at 14:34:53, Vincent Diepeveen wrote: >On October 29, 2002 at 12:15:29, Uri Blass wrote: > >>On October 29, 2002 at 11:52:18, Vincent Diepeveen wrote: >> >>>On October 29, 2002 at 06:46:18, Uri Blass wrote: >>> >>>>On October 29, 2002 at 04:26:38, Dave Gomboc wrote: >>>> >>>>>On October 29, 2002 at 04:05:14, Uri Blass wrote: >>>>> >>>>>>It is faster to have a special function that generate the moves and calculate >>>>>>moves that are checks. >>>>>> >>>>>>The point is that a lot of moves are from the same from square so I do not need >>>>>>to check if the from square is in the same direction with the king if I do it in >>>>>>that way. >>>>> >>>>>You may want to work outwards from the king. >>>>> >>>>>Dave >>>> >>>>Yes >>>> >>>>I think that it is a good idea in order to detect fast cases when I do not need >>>>to check the from square for all moves. >>>> >>>>If there is no piece that pseudoattack the king from all directions then it >>>>means that the only possible checks are based on the to square. >>>> >>>>I already do it when I update my pin arrays but I did not think about it when I >>>>generated my function to detect checks in the first plies of the qsearch. >>>> >>>>Note that my pin array can also be optimized. >>>>Today movei knows only the pinned pieces of the side to move and I believe that >>>>it is better to know the pinned pieces of both sides and to update them. >>>> >>>>Uri >>> >>>You could go for something cheap to detect checks in qsearch >>>and just see whether the 'to' square possibly attacks the king >>>square, only after that call a function. >>> >>>if( quickchecktable[piece][63+kingsq-to] >>> && slowcheck(piece,to,kingsq) ) >>> check = true; ... >> >>In that case I may miss checks that are not done by the piece that moved. > >You are concerned about xray checks? > >In DIEP i do things like that, but i don't know many engines >which do checks in qsearch which do them. Note that i do >unlimited checks in the qsearch for like 32 >ply in a row or so (my stackdepth of qsearch currently is 32 ply >i did see no reason yet to make that more). I limit my qsearch to 7 plies and usually there is no problem with it and I still did not change it. > >In any case, here is how i do things in qsearch, but i have to >warn you that it's very slow if you want to get a million >nodes a second :) Do not worry. Being slightly faster than tscp in nodes per seocnd is enough for me. > >Note that you see i'm using incremental attack tables too. I also have attack tables but they only tell for every square the directions that it is attacked and for every direction the square that is the attacker. They do not tell me information about a question like Does a bishop at square x attack square y when there is no bishop at square x. Even if there is a bishop at square x, I cannot find if it attacks y directly by my attack tables and I need first to find if y is attacked from direction[x][y] based on the 32 bit numbers that tell me the directions that y is attacked by white and black After it I still need to find the attacker from that direction based on another array that gives me a square for direction and square. Maybe it may be better to rewrite movei but today I still can improve movei without rewriting my move generator. > >For a number of years i could do without incremental attack tables >by simply only using them in evaluation a lot and quite a bit less >in move ordering. > >>I still have ways to improve the speed without missing checks. > >In case you want to do *all* checks, then you might want to use >attacktables too. > >Note that i simply generate all moves in qsearch. Total move generation >all together is like 0.6% system time anyway. > >Then i can do all moves from which i gamble that they are making my >search more quiet. With big evaluation not necessarily captures and >checks are the only moves that can modify evaluation a lot. > >>Note that I cannot use the difference in the squares to decide if a rook pseudo >>attack the king because the difference between h2 and a3 is the same as the >>difference between a3 and b3. > >but it's very fast to use such a small table that eliminates already the >vaste majority. > >But indeed i also got rid of that primitive table and use a bigger table >now. The primitive table works great however for programs that want to >get a million nodes a second and extend check evasions (so we do not >talk about qsearch here but about normal search where of course >calling a function to detect whether you are in check is way way too >slow). With my attack tables it is easy to find if a square is attacked by one side. If I want to know if target is attacked by side then ((directsee[(target)]>>((side)<<4))&65535) gives me all the directions(possible 16 directions when 8 are queen directions and 8 are knight directions) 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.