Computer Chess Club Archives




Subject: Re: not using nullmove?

Author: martin fierz

Date: 07:24:26 02/16/04

Go up one level in this thread

On February 16, 2004 at 09:46:24, Tord Romstad wrote:

>On February 16, 2004 at 07:09:29, martin fierz wrote:
>>On February 16, 2004 at 05:57:50, Tord Romstad wrote:
>>>On February 15, 2004 at 17:08:43, martin fierz wrote:
>>>>of course, you have a long-developed engine with a balanced evaluation function.
>>>>mine is 7.5 months old, and therefore is still pretty bad ;-)
>>>I had no idea it was so young.  Considering the young age of your engine,
>>>I think Muse is extremely impressive.
>>well, i have been programming checkers for 7 years now, so i have some
>>experience in writing game-playing programs - that of course got me started with
>>my chess engine very quickly. many things like negamax, hashing, move ordering +
>>it's importance and so on are very easy+clear to me.
>Most of this should apply to me as well right now, when I have started
>working on hexagonal chess.  The difference between normal and hexagonal
>chess from a programming point of view should be comparable (probably
>smaller) to the difference between checkers and chess, and I should be
>able to profit from my experience with computer chess.  Still, I find
>the new game tremendously difficult, and I'm afraid I will have to work
>for years before the new engine is as strong as my chess program.
>>muse now does most of the
>>standard stuff, so it's not too surprising that it's playing sort of sensibly -
>>however, it does lots of stuff in a bad way. for example, i know my evaluation
>>still needs a lot of tuning. my SEE and qsearch-good-check-detection don't
>>detect x-ray attacks. my whole program is slow because of some serious
>>inefficiencies. i wouldn't mind being a factor 2 or so slower than crafty - but
>>a factor 5-6 seems excessive...
>Well, it depends on how complicated your evaluation function is, of course.
>I would guess that strong chess players tend to write evaluation functions
>which are much more sophisticated (and hence slower) than Crafty's.  The
>very low N/s count of the two most well-known chess programs written by
>strong players (Chess System Tal and Diep) seem to support this theory.

that is all nice and good - but if i switch my eval to material only and find
that i'm still much slower than crafty i know something is wrong ;-)

>>apart from that, i am also a rather strong chess player (cough), for a chess
>>programmer at least - which makes it easier for me to find holes in my eval than
>>for others IMO.
>Probably.  I am sure Muse will eventually become extremely strong.
>>i think the worst thing i've seen in gothmog is your scoring of connected
>>passers. hint: even if you have connected passers on d6+c7 as white, they are
>>not worth all that much if black has a bishop on the c8-h3 diagonal, or has a
>>king in front of those pawns. i have seen gothmog lose more than once against
>>muse because it seems to think that these two passers were worth a piece or more
>>- which they are clearly not. of course i can't be 100% sure that your connected
>>passer eval is bad in this respect, but i am rather sure it is - you should
>>check it!
>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
i currently try detecting whether they're blocked when diagonally aligned, but i
guess the above should work even better.

>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...

> 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 :-)


>>>This, too, very much resembles what I do.  The evaluation function doesn't
>>>just return a single value, it computes separate values for king safety,
>>>pawn structure, passed pawns, mobility, and so on.  It also locates pinned
>>>and hanging pieces, and detects some simple mate threats.  All of this
>>>information is used in the search.  Whenever a move is made, the position
>>>is evaluated and I compare the results at the present node with the results
>>>at the previous node.  If a move does not increase any of the evaluation
>>>components, and it does not attack a piece, threaten mate or anything
>>>similar, I prune the move or reduce the search depth.  If a move threatens
>>>mate or dramatically increases the king safety or passed pawn eval, I
>>>make an extension.
>>in fact, i'm not doing this - yet. it's on my todo list of course, but as i
>>wrote i first would like to make my engine "decent" with the standard
>>techniques. once i'm satisfied with it, i'll start fiddling with this kind of
>That's probably what I should have done, too.  But my biggest weakness as
>a chess programmer is my lack of patience.  I can't wait until I have the
>basics perfected before I start adding more advanced stuff.

This page took 0.15 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.