Author: JW de Kort
Date: 10:59:16 06/15/03
Go up one level in this thread
On June 15, 2003 at 08:12:46, Uri Blass wrote: >On June 15, 2003 at 08:10:18, JW de Kort wrote: > >>On June 14, 2003 at 19:34:12, Magoo wrote: >> >>>On June 14, 2003 at 17:11:11, JW de Kort wrote: >>> >>>>On June 14, 2003 at 10:30:58, Magoo wrote: >>>> >>>>>I did some tests last night, replacing my in_check() function with attack >>>>>tables, my thought was that it would be faster, but the result was not that >>>>>good, ok i did a fast hack, scanning the whole board because i dont have piece >>>>>lists, but my previous x-ray in_check function was huge. But now im wondering if >>>>>attack tables (implemented with piece lists) are that much better than x-ray. >>>>> >>>>>You have to check all pieces, = 8 pieces (king checks). >>>>>You have to check if pawns are promoted... = x pieces. >>>>>Check two squares in front of the king. >>>>> >>>>>And of course, sometimes you have to do some tracing.. (sliding pieces). >>>>>In the opening, middlegame there are usually pieces near the king, so the x-ray >>>>>based in_check only has to trace a few directions. >>>>>This got me thinking that the difference between the two isn't so big, am i >>>>>correct? maybe attacks are a few % faster? >>>> >>>>Hi, >>>> >>>>my in check is also a time consuming process. But is it absolutely necessery? >>>>Maybe it is possible not to check for check at all and just check if a capture >>>>removes the king one ply later. I have not tried this idea but maybe it is >>>>faster then using an in check. >>>> >>>>Also i'am thinking of implementing attack tables in my 0x88 program but i have >>>>not found a fast approach. Ant tips?> >>>> >>>>regards >>>> >>>>Jan Willem >>> >>>"Maybe it is possible not to check for check at all and just check if a capture >>>removes the king one ply later." >>> >>>Yes this is possible, but as i discoverd its really slow, in the early stages of >>>my program i did just what you say. The thing is if you are going to do a search >>>to depth D, you are really doing a search to depth D+1, which is much much >>>slower than doing a search to depth D and calling in_check() after each move. >>>If you don't have already implemented the "perft" command, i recommend you to do >>>it, it's a really good way to test the move generator. Depth 4 should only take >>>a second or two, Depth 5 i get 16 seconds (6 seconds are spent in in_check()). >>>Good programs do Depth 5 under 10 seconds. >>>About attack tables, if you already have piece lists, there is no harm trying it >>>(the code for creating the table is easy, and the modification to in_check is >>>also easy). >>> >>>But as I said in my first post i can't see how this would really improve the >>>time spent in in_check() in opening/middlegame positions. (the king has >>>pieces/pawns near => only a few directions have to be traced). >> >>Nice reply, thanks. >> >>In my program i use a piecelist. I used to do what you describe, checking for >>scheck starting at the position of the king. I found it more efficient to go >>through the piecelist of the opponent and only start 'sliding' if the piece of >>the opponent could move form to the square of teh king. This turned out to be >>faster than the methode you describe. >> >>As fot het attack table. I think that with an attack table only the attack >>status of the square of the king would have to be checked to see if there is a >>check. I think this would be faster than any routine. >> >>regards >>Jan Willem > >I think that you miss the point that you need to update the attack tables for >every square in the board so if you use the attack tables only to detect checks >than the program is slower. > >Uri I should have been more careful writing. I mean if you already have attack tables then only the in check routine would take little time. You are completely right. The attack table will also be helpfull: - SEE - cpature move generation - evalustion Jan Willem
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.