Author: Mridul Muralidharan
Date: 18:38:04 01/04/04
Go up one level in this thread
On January 04, 2004 at 16:12:40, Russell Reagan wrote: >On January 04, 2004 at 14:03:08, Tord Romstad wrote: > >Hi Tord, > >>Another >>idea I have experimented with is to include passed pawn pushes in the qsearch in >>pawn endgames. > >I think this is a good idea. I don't think of qsearch as "capture and check >search." I think of it as "forcing move search." Pushing a passed pawn in the >endgame is certainly a forcing move. > >The goal of qsearch is to hand off quiet positions to the evaluation function. >If there is a passed pawn that can promote in a few plies, that isn't a quiet >position at all! Your evaluation may be off by a whole queen or more in that >situation. > >I think it is better here to take the time to resolve things correctly. >Otherwise you can say, "my evaluation may be off by a queen here, but look at >that full-width depth!" Search depth and nodes per second are only a means to an >end. > >Maybe you will search one full-width ply less, but if you detect the passed pawn >several plies earlier, is that not an improvement overall? Looking at it from >the other side, is it possible that you will now miss something because of the >slighly shallower full-width depth? > > >>Endgame evaluation is also tricky, because the evaluation should be very >>different >>depending on the type of endgame. I am tempted to write several different >>evaluation >>functions (one for pawn endgames, one for rook endgames, one for bishop vs >>knight >>endgames, one for endgames with unequal coloured bishops, and so on), but I am >>afraid this would cause too big jumps when exchanges occur, make my static >>exchange >>evaluator too unreliable, and perhaps have other unfortunate side effects. Is >>the idea >>still worth a try? > >I don't understand why this would make it unreliable. Wouldn't it make it more >reliable? Your program might switch to another "plan" all of the sudden, but as >long as you implemented your specific endgame evaluation correctly, it should be >a better plan, right? > >This seems like a similar situation to using endgame tablebases. Your program is >searching along, evaluating the position at +2, and all of the sudden it sees >mate in 46 :) Hi, I think it is high time mess also had specialised endgame evaluation functions. Right now before my eyes , I see mess trading from an obviously won position , to a drawn one and still thinks it is ahead :( 30 moves later it is going to signal a draw score - sheesh !! Even I believe that endgame has to be handled very carefully - but lack of sufficient knowledge (mine here) has prevented me from making major leaps in this direction. With most of mess's games being decided in endgame phase (and if it reaches endgame - it is an unfavourable ending) I have to seriously do something about it. Thanks for all the suggestions. (Rishard has seen many games where mess loses pathetically in endgames !) Right now , I do allow passed pawn pushes in endgame - from any rank. (In middle game , I consider passed pawn pushes in only last 3 ranks). This helps tremendously - but does not help in draw detection. Regards Mridul
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.