Author: Uri Blass
Date: 08:28:24 03/23/04
Go up one level in this thread
On March 23, 2004 at 10:56:03, Heiner Marxen wrote: >On March 23, 2004 at 10:18:32, Uri Blass wrote: > >>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? > >No, the replacement function is currently implemented only for attack info. > >>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. > >This is on my "try it" list for a long time, already. >The problem is that I have to delay the unmake until I have decided for the >next move, and only then I can take advantage of a possibly shorter operation. >Meanwhile, the board does not really reflect the position which is meant, >and hence must not be looked at... great care must be taken, here. >That has delayed this interesting idea again and again. > >Cheers, >Heiner I thought about a case when you already expect the next move to be bad move and so the order is not important and you already generated all moves. I generate all move after every move(it is another place for improvement but today I use the number of moves for evaluation so I need first to get rid of my mobility evaluation and replace it by another mobility if I want not to generate all moves). I guess that the best way to do the improvement that I think about is probably to start from something more simple in order to improve and to start again even without mobility and test and only later to add mobility that is based on static evaluation of the board and not on the number of legal moves of both sides. I probably need to rewrite my alpha beta my hash and part of the evaluation because I have no fun in looking at my alpha beta code today and even if I can improve by changing it I have no fun in doing it. I have also no fun with starting with something more simple but I guess that I need to do some sacrifice to improve. rewriting my big move generator is too much so inspite of the fact that I do not consider my arrays to be the best idea I will probably not try to change them and I may even consider to add replace function(after all I do not like to wait another year to get an improvement) 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.