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.