Author: Thomas Mayer
Date: 06:02:44 02/02/05
Go up one level in this thread
Hi Tim,
On February 02, 2005 at 04:08:40, Tim Foden wrote:
>On February 01, 2005 at 16:44:48, Thomas Mayer wrote:
>
>>Hi,
>>
>>I had promised some more interesting results of my experiments with
>>KB*KP* endgames... The following analysis are produced by an alpha
>>version of Quark after implementing KBKP bitbase, a recognizer and
>>a special endgame routine for KB*KP* endgames. 5-men tablebases are
>>disabled.
>>The implementation has definitely NO influence at all to Quarks
>>overall speed.
>>
>>[D] 8/p1p5/3p4/p3p3/k4p2/2K3pB/7p/8 w - - 0 1
>
>Just as a contrast, GLC 3.01.2.2 doesn't have any of this info, and thinks this
>is -12 :)...
that's what the normal Quark also would think without the new knowledge...
>>Let's go a bit deeper in the endgame:
>>
>>So we get this position:
>>
>>[D] 8/8/3p4/p1p1p3/5p2/6p1/p1K4p/k6B w - - 0 9
>
> Again GLC 3.01.2.2... this time it sees the draw. But is Bd5 also correct here?
I believe so... :)
> Game stage: Endgame
> Current eval: -12.487
> Ply Time Score Nodes Principal variation
> 6 0.010 -13.329 5925 Kc1 a4 2. Be4 a3 3. Bh1 {ht} c4
[...]
> 16 0.751 -8.833 711149 Bd5 {++} c4 2. Bh1 a4 3. Bf3 a3 4. Be4 c3 5. Bd5
> e4 6. Bxe4 d5 7. Bxd5 f3 8. Bxf3 g2 9. Bxg2
> 16 0.851 -6.329 832954 Bd5 c4 2. Bh1 a4 3. Bf3 a3 4. Be4 c3 5. Bd5 e4 6.
> Bxe4 d5 7. Bxd5 f3 8. Bxf3 g2 9. Bxg2
> 16 0.902 -6.329 890079 Bd5 c4 2. Bh1 a4 3. Bf3 a3 4. Be4 c3 5. Bd5 e4 6.
> Bxe4 d5 7. Bxd5 f3 8. Bxf3 g2 9. Bxg2
> 17 1.102 -6.532 1136830 Bd5 c4 2. Bh1 a4 3. Bf3 a3 4. Be4 c3 5. Kc1 f3 6.
> Bxf3 e4 7. Bxe4 d5 8. Bxd5 h1=B 9. Bxh1
> 17 1.172 -6.532 1237111 Bd5 c4 2. Bh1 a4 3. Bf3 a3 4. Be4 c3 5. Kc1 f3 6.
> Bxf3 e4 7. Bxe4 d5 8. Bxd5 h1=B 9. Bxh1
> 18 1.392 -6.132 1487936 Bd5 {++} c4 2. Bh1 a4 3. Bf3 a3 4. Be4 c3 5. Kc1
> f3 6. Bxf3 e4 7. Bxe4 d5 8. Bxd5 h1=Q+ 9. Bxh1
> c2 10. Kxc2 g2 11. Bxg2
> 18 1.603 -4.186 1744548 Bd5 c4 2. Bh1 a4 3. Bf3 a3 4. Be4 c3 5. Bf3 d5 6.
> Bxd5 e4 7. Bxe4 f3 8. Bxf3 g2 9. Bxg2 h1=Q 10.
> Bxh1
> 18 1.663 -4.186 1825361 Bd5 c4 2. Bh1 a4 3. Bf3 a3 4. Be4 c3 5. Bf3 d5 6.
> Bxd5 e4 7. Bxe4 f3 8. Bxf3 g2 9. Bxg2 h1=Q 10.
> Bxh1
> 19 2.023 -3.786 2277342 Bd5 {++} c4 2. Bh1 a4 3. Bf3 a3 4. Be4 c3 5. Bf3
> d5 6. Bxd5 e4 7. Bxe4 f3 8. Bxf3 g2 9. Bxg2 h1=Q
> 10. Bxh1
> 19 2.253 +0.000 2583163 Bd5 c4 2. Bh1 a4 3. Bf3 a3 4. Be4 c3 5. Bf3 d5 6.
> Bxd5 e4 7. Bxe4 f3 8. Bxf3 g2 9. Bxg2 h1=Q 10.
> Bxh1
as you can see, GLC finds the draw at the same ply Quark does -> but the initial
score of Quark is quite better... well, that is my idea at the moment, I try to
get better scores as fast as possible.
So the recognizer tries to find draws or wins and the eval only tries to
differentiate between sure wins and maybe wins -> the search will guide it
wether it leads to a draw or to a win... In my opinion it is always good when
the eval has an idea about a maybe won position and a for sure won position. So
in the search Quark would definitely prefer the won position to the maybe won
position... And the small 4men bitbases can help here a lot... I really wonder
why Vincent thinks this is a stupid idea ?!
Greets, Thomas
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.