Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: not using nullmove?

Author: martin fierz

Date: 09:00:36 02/16/04

Go up one level in this thread


On February 16, 2004 at 11:09:29, Tord Romstad wrote:

>On February 16, 2004 at 10:24:26, martin fierz wrote:
>
>>On February 16, 2004 at 09:46:24, Tord Romstad wrote:
>>>
>>>Thanks.  I am painfully aware of this one, and I have seen lots of lost
>>>games because of this hole.  My latest development version is slightly
>>>improved in this respect, but there is still a long way to go.
>>
>>here's an easy way out: make the connected passer eval larger for pawns on c6/d6
>>larger than for pawns on c6/d7 or c7/d6. like that, you will only push the pawns
>>if you see them either getting to c7/d7 or promoting. else you'll rather keep
>>them on c6/d6 - in general, they are better beside each other than diagonally
>>aligned.
>>i currently try detecting whether they're blocked when diagonally aligned, but i
>>guess the above should work even better.
>
>I have something like this in mind, as well.  Something like this could
>be useful even elsewhere on the board, and not only for connected passed
>pawns.  Pawns side by side are usually stronger than one pawn defending
>another, aren't they?

yes. my pawn structure code doesn't have that yet, but it will soon. i was
already spending over 10% of my entire time in the pawn eval, so i didn't want
to make it even bigger. but now that i have pawn hashing, the pawn eval has
disappeared from the top in the profile, and i can put everything in there i
always wanted to :-)
but i think for connected passers staying side-by-side is much more important
than for general pawn structure eval. keeping them side-by-side keeps both of
them mobile - which in general is not so important for other pawns which don't
have to run down the board.

>>>Other major weaknesses are that lots of important endgame knowledge
>>>is completely missing,
>>
>>i think i saw KRP-KR once, muse on the weak side, clear draw. gothmog thought it
>>was about 1.5 pawns ahead IIRC. a simple but good rule for this one is: if the
>>king of the defending side is anywhere on the pawn's path to a queen, it's a
>>draw - i don't return a draw there, but something like -0.5 pawns for the
>>defender - after all, you still have small chances against a weak opponent. but
>>perhaps this was in a game against frenzee - i hope i haven't mixed things up...
>
>This sounds entirely correct, but it is fixed in the latest development
>version.  I have written a special KRPKR eval which knows about most of
>the basic winning and drawing positions (including the third-rank defence),
>as well as the basic principles of the endgame (like keeping the rook
>on the long side and the king on the short side).  It seems to work
>pretty well, except that I still have to do some tuning to make it all
>consistent with the eval for more complicated endings.

oh, too late then - i hoped i could point you to some things that you still have
to fix, but you obviously noticed the same things i did... i also admit i didn't
look too closely for problems in your engine, i was concentrating on mine of
course!


>>> that the space eval is too big and too primitive,
>>>and that Gothmog is too happy to push pawns in front of its own king in
>>>positions with opposite side castling.
>>
>>i haven't noticed that too much yet. you should of course push the pawns on the
>>other wing :-)
>
>Yes.  The problem is that my stupid engine sometimes thinks it can slow
>down the opponent's pawn storm by advancing its own pawns.  For instance,
>when Gothmog has castled queenside, it frequently plays the move a2-a3,
>because it thinks this will make it more difficult for black to advance
>the b pawn.  Usually, this doesn't quite have the desired effect.  :-)

i don't have this problem because muse generally doesn't like pushing pawns in
front of it's own king. but obviously you give a bonus for advancing pawns
against the enemy king (i do that too), so you could easily use the same sort of
code to give a penalty for pawns advanced in front of your own king. just make
sure it doesn't lead to kasparov-fritz-game3-like behavior ;-)

cheers
  martin


>
>Tord



This page took 0.17 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.