Author: James Swafford
Date: 15:05:50 11/20/01
Go up one level in this thread
On November 20, 2001 at 18:02:16, Robert Hyatt wrote: >On November 20, 2001 at 17:57:35, James Swafford wrote: > >>On November 20, 2001 at 17:53:35, Peter McKenzie wrote: >> >>>On November 20, 2001 at 16:55:13, Michel Langeveld wrote: >>> >>>>On November 20, 2001 at 05:04:42, Michel Langeveld wrote: >>>> >>>>>Hello all, >>>>> >>>>>I implemented qsearch in my program nullmover, but got a problem for it back. >>>>> >>>>>When I search with a depth 1 (just testing at the moment) my program thinks that >>>>>after the openingmove 1. d4, ... h6! is the best move. >>>>> >>>>>After h6 the qsearch starts. >>>>> >>>>>[D]rnbqkbnr/ppppppp1/7p/8/3P4/8/PPP1PPPP/RNBQKBNR w KQkq - 0 2 >>>>> >>>>>The qsearch evaluates _only_ captures now. The program thinks white HAS to take >>>>>on h6 then (is only capture in that position) and black can win a bishop after >>>>>gxh6 or Rxh6. So score is about +2 for black then. This is incorrect of >>>>>course.... >>>>> >>>>>I'm thinking about ways to solve this. One way is to implement a null move so >>>>>that beside capturing there's always a doing nothing option. But I was curious >>>>>how you guys solve this thing. >>>>> >>>>>Regards, >>>>> >>>>>Michel Langeveld >>>> >>>>Ok, >>>> >>>>Fixed the qsearch with a no move situation >>>>Debugged it and tested it. It works very well at the moment. >>>> >>>>I also implemented a better move ordening. >>>>My search sometimes BOOMS already at ply 1 in tactical positions. >>>>How can I fix this? Can I stop qsearch at an centain depth? >>> >>>You can, but its not recommended. You shouldn't need too. >>> >> >>Are you sure? I'm sure it doesn't happen very often, but it >>seems naive to let the recursive call go and go and go... >> >>You've got me curious. I'm going to put in a counter and >>see how often that happens. >> >>-- >>James >> > >It is self-limiting. Each time you rip a piece there is one less possible >piece to capture the next time the same side is to move, and one less piece >to make captures at the next ply. > > I had just put a little more thought into that and came to the same conclusion... the recursion can't go but so far with captures... of course. :) -- James > >> >>>I guess you either have a bug or your move ordering is broken. Are you >>>searching captures only? Or you ordering using MVV/LVA ? >>> >>>> >>>>history: >>>>(d2-d4 e7-e6 c1-e3 f8-d6 d4-d5 e8-f8 e3xa7 d6xh2 a7xb8 h2xg1 h1xh7 >>> >>>d6xh2 indicates you aren't using MVV/LVA >>>Always capture the Most Valuable Victim (MVV) first! a8xa7 should be searched >>>before d6xh2. a8xa7 will cause a quick fail high, therefore d6xh2 will never >>>need to be searched at all. >>> >>>> a8xa2 b8xc7 g1xf2 e1xf2 d8xc7 d5xe6 a2xb2 e6xf7 h8xh7 f7xg8B b2xb1 >>>> d1xb1 f8xg8 b1xb7 c7xc2 b7xd7 c2xe2 f1xe2 c8xd7 )
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.