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