Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: not using nullmove?

Author: martin fierz

Date: 12:19:40 02/17/04

Go up one level in this thread


On February 17, 2004 at 14:09:29, Dieter Buerssner wrote:

>
>On February 17, 2004 at 04:50:16, martin fierz wrote:
>
>Thanks, Martin, for elaborating on it.

you're welcome. just a small side-note: when i came home i glanced at my laptop
which is running a gauntlet match between muse and it's sparring partners. what
do i see: muse as white has KR, crafty as black has KRP. muse is correctly
evaluating it as -0.4 (the score i put in for a drawish KRP-KR), crafty as +1.5.
of course the game ended in a draw. i know that crafty is designed to TBs of
course, and at some point you can obviously say that you don't need to know
about these endings any more, but still - i found it a nice coincidence :-)

cheers
  martin

PS i never really thought about this endgame yet for a long time. the rule i
suggested is the product of about 5 minutes of thinking. perhaps i can come up
with a better rule which only goes wrong in one way if i think a bit longer, or
read my dvoretzky :-)


>>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.
>
>Regards,
>Dieter



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