Computer Chess Club Archives




Subject: Re: not using nullmove?

Author: Dieter Buerssner

Date: 11:09:29 02/17/04

Go up one level in this thread

On February 17, 2004 at 04:50:16, martin fierz wrote:

Thanks, Martin, for elaborating on it.

>there is more to KRP-KR than this simple rule of course. but for it's
>simplicity, it works pretty well. i'm not saying you should use it. you have a
>strong engine with a good eval, and i expect your KRP-KR eval to be much better
>than this.

Well, unfortunatley not. I have the rules you mention inside the engine (as
general endgame principles), but only with small scores. If KRP-KR is reached,
probably my engine will move identical as if your moves were used, but there is
no real big difference between probably drawish vs. probably won positions
(unless the search sees the win). I actually started to code a specific routine
for KRPKR, but I gave up very soon (the effort seemed too much, keeping in mind
that I also added TB support at that time, which would solve most problems. Not
all, of course, because the position might arise in the search after the
TB-support. OTOH I wrote also code for KRPKR W/D/L "bitbase" from RAM, so for my
preferred environment, there would be no problem at all).

>but anybody who has no special eval for KRP-KR should find the
>following rule useful:
>take your pawn. produce the "crowning path", which is just all squares in front
>of the pawn. e.g. white pawn on e4, crowning path is e5,e6,e7,e8. if the black
>king is on any of these squares, evaluate the position as slightly better for
>white only. if not, evaluate it as very good for white.
>probably you can add left(crowningpath) and right(crowningpath) to the drawing
>zone. i.e. you say if the white pawn is on e4 and the black king anywhere within
>the rectangle d5-f5-f8-d8 you evaluate as a near draw.

I'll do some tests with this soon.

>of course there are drawing positions with the king outside this zone, and lost
>positions within. but it's much better than nothing and *very* simply specially
>if you have bitboards :-)

It will be easy anyway. While I don't use many bitboards, just a few are no
problem. The ones needed here can easily be generated at evaluation time and
initialization time. I would like a rule better, that only goes wrong in one
direction. Preferably, it would tell me, when it is a sure draw (missing some
draws, by this), but never tell me, it is a probable draw and possibly a win. I
fear (from other experiments) that a rule that can go wrong in either direction,
will introduce many search artifacts/inefficiences. A rule that only goes wrong
to one side can also be used very efficiently for pruning.


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