Author: Stuart Cracraft
Date: 16:47:47 09/30/04
Go up one level in this thread
On September 30, 2004 at 18:49:50, martin fierz wrote: >On September 30, 2004 at 15:51:33, Stuart Cracraft wrote: > >>On September 30, 2004 at 04:49:15, martin fierz wrote: >> >>>On September 30, 2004 at 00:52:04, Will Singleton wrote: >>> >>>[snip] >>> >>>hi will, >>> >>>>If the previous move was a piece moving near the enemy king, I don't null move. >>>>Also, don't null near the leafs. >>> >>>i'm wondering about your suggestion to not null near the leafs. i think i once >>>tried that but it didn't work for me. i do checks on the first ply of qsearch >>>though, which reduces problems with null-moves dropping straight into qsearch. >>> >>>could you give some more details of your approach? are you doing checks in QS or >>>not? and how near is "near"? >> >>Doesn't that cause your qsearch to slow down by having to do a full move >>gen? My full movegen is slower than my capture gen. > >i only do a "semi-full-gen". just like when you generate capture moves you only >produce moves going to certain squares (those where there is an enemy piece), >you only generate moves which check the king - you first generate the squares >where pieces would check the king, and then generate moves to these squares, for >every piece type. > >that certainly isn't the reason my program is slow :-) > >cheers > martin My move generator is really, really dumb and clumsy. Not too slow but grotesque in terms of being able to do refinements like the above. The best I could think of for my move generator is create a duplicate of it that last thing before it adds a move to the move list checks by going to next move if a capture, otherwise making the move, seeing if side on move now in check, backing up, and if in check adding the move to the movelist otherwise going to the next move. I suppose this wouldn't be too bad since it would all come after the captures search failed to generate a cutoff so the cost would be less -- and I do get a lot of cutoffs and SEE's stopping the quiescence. I do plan to try it fairly soon. Maybe tonight or tomorrow. Just finished implementing and testing Bob's recapture. It is working fine and I was able to lift my restriction of ply<=iply+1 and yet still solve WAC 141, though with the depth<=1 restriction which I don't like. Stuart
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.