Author: Uri Blass
Date: 06:42:43 03/23/04
Go up one level in this thread
On March 23, 2004 at 08:59:04, Peter Fendrich wrote: >On March 23, 2004 at 04:51:18, Uri Blass wrote: > >>On March 23, 2004 at 02:24:38, Tony Werten wrote: >> >>>On March 22, 2004 at 19:21:42, Dann Corbit wrote: >>> >>>>On March 22, 2004 at 18:57:52, Uri Blass wrote: >>>> >>>>>On March 22, 2004 at 18:50:15, Dieter Buerssner wrote: >>>>> >>>>>>On March 22, 2004 at 18:16:37, martin fierz wrote: >>>>>> >>>>>>>of course i would also like to make an incremental update of that table, but i >>>>>>>decided against such an attempt because i couldn't figure out how to do it - or >>>>>>>rather, i devised a scheme for incremental updating which was so horribly >>>>>>>complicated that i decided not to use it - i'd rather have a slow engine with >>>>>>>little bugs and good maintainability than a fast engine with many bugs and low >>>>>>>maintainability :-) >>>>>> >>>>>>Reminds me of: >>>>>> >>>>>>"Debugging is twice as hard as writing the code in the first place. Therefore, >>>>>>if you write the code as cleverly as possible, you are, by definition, not smart >>>>>>enough to debug it." Brian W. Kernighan >>>>>> >>>>>>At the moment, I don't use attack tables at all. But I want them again. And I >>>>>>also only have a "build-from-scratch" routine. I also thought about incremental >>>>>>updates, and it seems like a very hard job. And the bad thing is, they seem to >>>>>>be especially useful at the leafs or close to the leafs. Perhaps I will start >>>>>>again with using them only closer to the root, for pruning/extension decisions. >>>>>> >>>>>>Regards, >>>>>>Dieter >>>>> >>>>>I update them incrementally. >>>>>I can only give a hint that I simply have a function to update incrementally >>>>>when I add a piece or delete a piece. >>>>> >>>>>I got this idea when I got the conclusion that having a function to update them >>>>>based on a move is a very hard task. >>>> >>>>I think I have the same idea: >>> >>>You left out the interesting part: >>> >>>> >>>>1. Lift the piece off the board, and remove all of its influence >>> >>>1b for every slider attacking the fromsquare, extend its influence >> >>You miss the idea >> >>All the idea is that I consider no from square and no to square in updating the >>attack table. >> >>I look at a move as a sequence of add piece to square and remove the piece from >>square and I have function to update the attack table when I add piece or remove >>piece. >> >>Uri > >That doesn't change anything. >When you remove the piece (the piece on the from-square) don't you extend the >attackers to that piece (1b above) then? >/Peter Yes but my point is that I consider one square at a time so I do not think about from and to squares. It seems based on tony's post that he does not do it. I have a different problem my attack tables do not have the information about the pieces that attack but about the direction that a piece is attacked and the square of the attackers. I did not like to calculate more information about the pieces because I thought that it is too expensive and it is better to calculate things by functions later but I can see that it may be a bad idea because I could probably use more attack tables to calculate faster my existing attack tables. I have in calculating my attack tables a lot of if's like if ((dirnow&16)&& piece(squaresee[sq][4])!=PAWN&&piece(squaresee[sq][4])!=KING) The problem is that I have no direction information only for queen,bishop,rook and when I try to update information about diagnol directions I need to check that the piece that threats the square is not pawn or king. Maybe it is better to use bitboards for pawns,knights and kings attacks and have direction attack tables only for bishop rook and queen but I am going to delay it to the future because I think that it is more important to improve my search first. 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.