Fruit and basic endgame evaluation in general.

Programming Topics (Computer Chess) and technical aspects as test techniques, book building, program tuning etc

Moderator: Andres Valverde

Fruit and basic endgame evaluation in general.

Postby eric_oldre » 27 Nov 2005, 06:53

I was examining the endgame evaluation functions of fruit (2.1) and I had some questions.

1st) I like the mul[] idea in fruit, where it detects drawish (not certain draws) in the endgame based on material and adjusts the score towards ValueDraw if situations occur that tend to end in draws. (by the way, does anyone know what "MUL" stands for? Or is short for?)

I had thought about doing something a little bit similar in latista with the 50 move rule. IE, if the 50 move count starts to grow then perhaps move the score more towards a draw, I was thinking of this to try and have latista force the action when it thinks it is ahead, more to make the game exciting than for strength. Although I suppose I'd have some search instability though.

2nd) I like how fruit examines different combinations of material and can in certain cases say that this is a draw for sure, or in other cases go into deeper heuristics to discover the draw (or win?).

Since I certainly don't want to just copy the exact algorithms that Fruit uses for each case, I'd like to learn more about some of these basic endgames. Does anyone have links, or good book recommendations they recommend for some of this stuff?

examples, how to evaluate KBKP, KPBKP, etc?

Thanks for any help you might have.

Eric
eric_oldre
 
Posts: 28
Joined: 14 Dec 2004, 20:42
Location: Minnetonka, Minnesota

Re: Fruit and basic endgame evaluation in general.

Postby Alessandro Scotti » 27 Nov 2005, 11:13

Hi Eric,
i think "mul" is short for "multiply". As of now in Kiwi there is only one real heuristic-based endgame evaluator, for KPK. All the rules have been taken from an Italian book on endgames (so that's probably not very helpful but anyway: "Il finale negli scacchi", by E. Paoli) and a lot of experiments with EGTB. For example, I have implemented "near-perfect" evaluators for KNNK and KBBK by only looking at EGTBs.
User avatar
Alessandro Scotti
 
Posts: 306
Joined: 20 Nov 2004, 00:10
Location: Rome, Italy

Re: Fruit and basic endgame evaluation in general.

Postby Pradu » 30 Nov 2005, 15:17

I thought KNNK was drawn but in the moxt exceptional cases.
User avatar
Pradu
 
Posts: 343
Joined: 12 Jan 2005, 19:17
Location: Chandler, Arizona, USA

Re: Fruit and basic endgame evaluation in general.

Postby Alessandro Scotti » 30 Nov 2005, 15:39

Pradu wrote:I thought KNNK was drawn but in the moxt exceptional cases.


It is. This comment is attached to my KNNK recognizer:

Code: Select all
    Note: there are more than 25 million positions and they are all draw except for
    1232 wins (mate in one, which can't usually be forced) and 240 checkmates.


I have manually coded all the "special" cases above, mainly for fun! ;-) The corresponding function takes about 90 lines of code in Kiwi.
User avatar
Alessandro Scotti
 
Posts: 306
Joined: 20 Nov 2004, 00:10
Location: Rome, Italy

Re: Fruit and basic endgame evaluation in general.

Postby Alvaro Begue » 30 Nov 2005, 16:27

In an old checkers engine, I had some conditions like this: If we are in an extremely drawish endgame (like KNNK in chess) and the reversible-move counter (the one you use for the 50-move rule) is greater than 2 and there has been an irreversible move from the root to the current board, stop the search and return a draw score.

It basically means that if you manage to survive a couple of moves, you achieve a draw. I think this approach would work just fine for KNNK in chess, but I haven't tried it.
Alvaro Begue
 
Posts: 33
Joined: 03 Aug 2005, 23:48
Location: Stony Brook, New York, U.S.A.

Re: Fruit and basic endgame evaluation in general.

Postby Sven Schüle » 01 Dec 2005, 00:12

Alessandro Scotti wrote:The corresponding function takes about 90 lines of code in Kiwi.

Hi Alessandro,

knowing that all KNNK mate positions have the mated king in a corner, all "mate in one" positions could perhaps be recognized perfectly by only checking these six conditions (W = "winner side", L = "loser side"):

a) L king in corner
b) W to move
c) W king in opposition or knight distance to L king (i.e., W king attacks two of three squares near L king)
d) both W knights are on squares of the same colour as the L king's corner square (redundant due to e+f but might result in a speedup)
e) the square near L king which is not attacked by W king is attacked by a W knight
f) W can give check with the other knight (not the one from e)

I did not implement it yet in Surprise, so I have not checked it, but IMHO there are no exceptions from this system. Does anyone know a better (simpler) system?

So you might be able to implement it in much less than 90 lines,
Code: Select all
unless
(
  you
  +
  write
  -
  your
  (
    code
    ,
    like
    *
    in
    /
    this
    ->
    example
    (
    )
  )
)
;

:wink: :wink:

Sven
User avatar
Sven Schüle
 
Posts: 240
Joined: 26 Sep 2004, 20:19
Location: Berlin, Germany

Re: Fruit and basic endgame evaluation in general.

Postby Alessandro Scotti » 01 Dec 2005, 12:05

Sven Sch?le wrote:knowing that all KNNK mate positions...

So you might be able to implement it in much less than 90 lines,


Hi Sven,
you are probably right but it's now too late to save me! :D

Edit: there's actually several non-corner mates, e.g.

[diag]8/8/8/8/8/N2N4/4K3/2k5 b - -[/diag]
8/8/8/8/8/N2N4/4K3/2k5 b - -
User avatar
Alessandro Scotti
 
Posts: 306
Joined: 20 Nov 2004, 00:10
Location: Rome, Italy


Return to Programming and Technical Discussions

Who is online

Users browsing this forum: No registered users and 39 guests

cron