Author: Peter Fendrich
Date: 02:27:44 03/24/04
Go up one level in this thread
On March 23, 2004 at 13:39:30, Uri Blass wrote: >On March 23, 2004 at 12:46:30, Peter Fendrich wrote: > >>On March 23, 2004 at 12:04:35, Uri Blass wrote: >> >>>On March 23, 2004 at 11:42:44, Uri Blass wrote: >>> >>>>On March 23, 2004 at 10:43:05, Peter Fendrich wrote: >>>> >>>>>On March 23, 2004 at 09:13:21, martin fierz wrote: >>>>> >>>>>>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 >>>>>> >>>>>>that seemed to be the big problem in incremental attack updating to me. you have >>>>>>to remember the attacks for all sliders, and if either the from or the to square >>>>>>of your move coincides with a slider attack, you have to update the attacks of >>>>>>this slider. what a bother... >>>>>> >>>>>>cheers >>>>>> martin >>>>> >>>>>Yes it is... >>>>>Basically one need 4 functions: >>>>>Insert_attacks_from(sq) >>>>>Remove_attacks_from(sq) >>>>>Extend_attacks_to(sq) >>>>>Cut_attacks_to(sq) >>>>>to be used for different moves. >>>>>Then there are all the optimistaions that can be done! >>>>>For instance a capture move to e4 doesn't need the Cut_attacks_to(e4). >>>>>/Peter >>>> >>>>I do it only with 2 functions >>>>I understand your functions but your from functions is for me only one function >>>>that addpiece and your to function is one function that delete piece. >>>> >>>>With your functions it is possible to look at a capture as doing only 2 of the 4 >>>>functions so maybe it is better. >>>> >>>>Uri >>> >>>I looked now at my code and I see that there is a reason for the fact that I do >>>not have 4 functions. >>> >>>For example >>>When I add a bishop to my board I do not like to do Remove_attacks_from >>>for diagnols of the bishop because it is a waste of time when I know that I plan >>>later to add attack information and it is better to change the attack >>>information for the diagnols of the bishop. >>> >>>Uri >> >>I don't understand. >>If you add a bishop to the empty square e4 you would need to run: >>Insert_attacks_from(e4); >>Cut_attacks_to(e4); > >when I look at the rook directions you are right. >When I look at bishop directions(for example updating attack information for d3) >I do it faster by replacing the attack information for d3(only one side is >attacking that square from that direction because my attack information does not >have xrays) when your >cut_attacks_to need to check also that you did not cut the attack to d3 that may >be the case when you added a rook. > >Maybe you think about having also xrays when you think about attack tables so >you cannot do it in that way. > >Uri As I told before I've never been using attack tables and have not been thinking much about it so my view of it is probably not the best one. I was thinking in general of keeping track of attacks in all directions and what's needed. I'm aware of that there are more optimised designs if you're satisified with leaving some information (like xrays) out. In the future I will think more about attack tables and piecce lists when I start my new project with a hybrid bitboard approach. Terra will rest in piece... /Peter
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.