Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: not using nullmove?

Author: Uri Blass

Date: 02:44:12 02/17/04

Go up one level in this thread


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

>On February 16, 2004 at 18:14:45, Dieter Buerssner wrote:
>
>>On February 16, 2004 at 10:24:26, martin fierz wrote:
>>
>>>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...
>>
>>Martin, can you please elaborate on your rule "anywhere on the pawn's path to a
>>queen". I don't get it. I believe I understand basic draw and won positions in
>>KRPKR (from text books). But I am not able to understand your rule.
>>
>>Regards,
>>Dieter
>
>hi dieter
>
>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. 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.
>
>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 :-)
>
>cheers
>  martin

Yace is not bitboard based program but it seems also simple without bitboards.
I guess that I will add it to my program.

endgames is still one of the weaknesses of movei not only because of not using
hash for pruning and I think that the main problem is missing knowledge.

I do not try to progress as fast as possible in these days and I decided first
to solve the kpk problem and try to evaluate every kpk correctlyby rules so I
still did not add knowledge about kRP vs KR endgames and the time that I use for
programming is to define better rules for KP vs K and I guess that I may need at
least one more week to solve all the cases because I plan to use maybe average
time of 2 hours per day to think or to write code for the KP vs K problem.

I hope to have a code of less than 500 C lines that evaluates every KPK
correctly as a win or draw without using arrays(I use Distance between squares
in king moves or distance between files but it is a simple define that does not
use arrays).

One of the things that I need for my purpose is to think how to make the code
shorter because there are already almost 500 lines when most of them are for
white to move and even with that code I have today 2160 cases with white to move
when my code does not know to decide if it is a win or a draw.

I hope that writing efficient code for that may help me later to write better
rules for other endgames.

I hope to get a significant progress in the next week(otherwise I will probably
not complete that task and start implement not perfect knowledge about more
complicated simple endgames like KQ vs KP or KR vs KP or KRP vs KR or KB vs KP
or KRN vs KR).

Uri



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