Author: Uri Blass
Date: 07:18:32 03/23/04
Go up one level in this thread
On March 23, 2004 at 10:11:01, Heiner Marxen wrote: >On March 23, 2004 at 09:47:35, Uri Blass wrote: > >>On March 23, 2004 at 09:21:21, Heiner Marxen 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. >>> >>>That is exactly the way I do it in Chest all the time. >>>Still, extending through a removed piece is necessary, as well as restricting >>>sliders at a newly placed piece. But you knew that already :-)) >>> >>>But e.p. and castling are just some more calls of these basic operations. >>>I have 3 basic operations: put, delete and replace. >> >>I have no replace and I simply do put and delete. >> >>I decided that most of the moves in chess are not captures so adding a replace >>function will probably be a waste of a lot of time without big advantage in >>speed. > >I understand. But you should measure it. In Chest I found the advantage >to be significant, and for you q-search could kick in heavily. > >Cheers, >Heiner Do you have also makemove,undomove and replacemove? I think that it is also an idea for speed improvement because if you replace Qd1-d2 by Qd1-d3 you only need to delete d2 and add d3 instaed of deleting d2,adding d1,deleting d1 and adding d3. 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.