Author: Uri Blass
Date: 10:39:30 03/23/04
Go up one level in this thread
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
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.