Author: Tony Werten
Date: 23:24:38 03/22/04
Go up one level in this thread
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 >2. Add the piece back to the board and calculate all of its influence. 2b If it's not a capture move, for every slider attacking the tosquare, limit the influence. 2c if the move is a epcapture, extend the influence of sliders attacking the epsquare. 2d If the move is a castlemove, repeat for the rook. 2e make sure that with a promotion, you remove a pawn, but add the promoted piece. In XiniX I use a second internal board to help do all that stuff. Later, when everything is working, you can start optimizing with fe not updating the rankfile when moving a rook along a rank (ie not removing or adding the influence of the rook) except for from and to square. It's quite a nasty piece of code but it seems worth it. > >Move generation and partial evaluation happens at the same time. Yes, you can incrementaly update a score of the pieces looking at certain squares wich is a simple form of mobility. Since you get it for free after a make_move, it is available for lazy eval, wich makes your le a lot more accurate. Capture moves are easily generated by looping over the (max 16) opponent pieces and see if you attack them. Tony
This page took 0.01 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.