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 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.