Author: Bernhard Bauer
Date: 00:54:45 06/12/02
Go up one level in this thread
On June 11, 2002 at 14:15:32, Dieter Buerssner wrote:
>On June 11, 2002 at 08:21:47, Bernhard Bauer wrote:
>
>>On June 10, 2002 at 23:32:22, K. Burcham wrote:
>>
>>>Atilla Koranyi, second prize Bron Memorial Tournament 1986.
>>>White wins the endgame in 15 moves!!
>>>
>>>
>>>How long does it take your favorite program to find g5?
>>>
>>> 7k/5K2/5P1p/3p4/6P1/3p4/8/8 w - - 0 1
>>
>>Yace 99.56 on a P3-450 finds it too!
>>
>> 143196002 10:57.4 0.00 20t 1.Ke7 d2 2.f7 d1=Q 3.f8=Q+ Kh7 4.Qf7+ Kh8 5.g5
>> Qe1+ 6.Kd7 hxg5 7.Qh5+ Kg7 8.Qxg5+ {EGTB} {-80}
>> 163212921 12:31.3 0.01 20t+ 1.g5 hxg5 2.Ke7 d2 3.f7 d1=N
>> 163368822 12:32.1 0.40 20++ 1.g5 hxg5 2.Ke7 d2 3.f7 d1=R 4.f8=Q+ Kh7
>> 163449232 12:32.5 1.40 20++ 1.g5 hxg5 2.Ke7 d2 3.f7 d1=R 4.f8=Q+ Kh7
>> 163507174 12:32.9 6.40 20++ 1.g5 hxg5 2.Ke7 Kg8 3.f7+ Kh7
>> 197940297 14:22.6 Mat15 20t 1.g5 hxg5 2.Ke7 d2 3.f7 d1=Q 4.f8=Q+ Kh7 5.Qf5+
>> Kh6 6.Kf7 Qh5+ 7.Kf6 d4 8.Qe4 d3 9.Qxd3 {EGTB}
>> {-80}
>> 198009708 14:23.2 Mat15 20. 1.g5 hxg5 2.Ke7 d2 3.f7 d1=Q 4.f8=Q+ Kh7 5.Qf5+
>> Kh6 6.Kf7 Qh5+ 7.Kf6 d4 8.Qe4 d3 9.Qxd3 {EGTB}
>> {-80}
>>Congratulation to YACE!!!
>
>Thanks. I fear Yace without TBs could not find it in reasonable time. I tried
>this with my current developement version. First with access to 5-men TBs (I
>only have a small set, including KQPKQ). K6-2 475 (which is somewhat slower than
>your computer, judging from the nodes/s):
>
> 36021734 4:17.2 0.00 20t 1. Ke8 d2 2. f7 d1=Q 3. f8=Q+ Kh7 4. Qf7+ Kh8
> 5. Qf8+ {-80}
> 50815736 6:25.9 0.01 20t+ 1. g5 hxg5 2. Ke7 d2 3. f7 d1=R 4. f8=Q+ Kh7
> 50894554 6:26.4 0.40 20++ 1. g5 hxg5 2. Ke7 d2 3. f7 d1=R 4. f8=Q+ Kh7
> 50949756 6:26.8 1.40 20++ 1. g5 hxg5 2. Ke7 d2 3. f7 d1=R 4. f8=Q+ Kh7
> 53486521 6:41.5 6.40 20++ 1. g5 hxg5 2. Ke7 d2 3. f7 d1=R 4. f8=Q+ Kh7 5.
> Qf5+ Kh8
> 121278955 12:03.8 Mat15 20t 1. g5 hxg5 2. Ke7 d2 3. f7 d1=Q 4. f8=Q+ Kh7 5.
> Qf5+ Kh6 6. Kf7 Qh5+ 7. Kf6 d4 8. Qe4 d3 9.
> Qxd3 {EGTB} 9...Qe8! 10. Qh3+!! Qh5 11. Qf5!!
> g4! 12. Qf4+!! Kh7! 13. Qc7+! Qf7+! 14. Qxf7+!
> Kh8 15. Qg7#! {921}
> 121411479 12:05.8 Mat15 20. 1. g5 hxg5 2. Ke7 d2 3. f7 d1=Q 4. f8=Q+ Kh7 5.
> Qf5+ Kh6 6. Kf7 Qh5+ 7. Kf6 d4 8. Qe4 d3 9.
> Qxd3 {EGTB} 9...Qe8! 10. Qh3+!! Qh5 11. Qf5!!
> g4! 12. Qf4+!! Kh7! 13. Qc7+! Qf7+! 14. Qxf7+!
> Kh8 15. Qg7#! {921}
>
>BTW. The strange "fail high lines" with d1=R may come from the fact that KRPKQ
>is not available.
>
>Now, without access to the 5-men TBs (4-men info available)
>
> 263796631 27:04.6 0.00 22. 1. Ke8 d2 2. f7 d1=Q 3. f8=Q+ Kh7 4. Qf7+ Kh8
> 5. Qf8+ {-80}
> 371975328 38:27.5 0.00 23t 1. Ke8 d2 2. f7 d1=Q 3. f8=Q+ Kh7 4. Qf7+ Kh8
> 5. Qf8+ {-80}
> 504848287 51:46.3 0.01 23t+ 1. g5 hxg5 2. Ke7 d2 3. f7 d1=Q 4. f8=Q+ Kh7 5.
> Qf5+ Kh6 6. Kf7 Qh5+ 7. Kf6H d4H {HT}
> 506037089 51:53.0 0.40 23++ 1. g5 hxg5 2. Ke7 d2 3. f7 d1=Q 4. f8=Q+ Kh7 5.
> Qf5+ Kh6 6. Kf7 Qh5+ 7. Kf6 d4
> 506419892 51:55.1 1.40 23++ 1. g5 hxg5 2. Ke7 d2 3. f7 d1=Q 4. f8=Q+ Kh7 5.
> Qf5+ Kh6 6. Kf7 Qh5+ 7. Kf6 d4
> 526772274 53:44.2 6.40 23++ 1. g5 hxg5 2. Ke7 d2 3. f7 d1=Q 4. f8=Q+ Kh7 5.
> Qf5+ Kh6 6. Kf7 Qh5+ 7. Kf6 d4
> 845165857 1:15:22 Mat15 23t 1. g5 hxg5 2. Ke7 d2 3. f7 d1=Q 4. f8=Q+ Kh7 5.
> Qf5+ Kh6 6. Kf7 Qh5+ 7. Kf6 d4 8. Qe4 d3 9.
> Qxd3 Qe8 10. Qh3+ Qh5 11. Qf5 g4 12. Qf4+ Kh7
> 13. Qc7+ Qf7+ 14. Qxf7+ Kh6 15. Qg6# {921}
> 845773943 1:15:25 Mat15 23. 1. g5 hxg5 2. Ke7 d2 3. f7 d1=Q 4. f8=Q+ Kh7 5.
> Qf5+ Kh6 6. Kf7 Qh5+ 7. Kf6 d4 8. Qe4 d3 9.
> Qxd3 Qe8 10. Qh3+ Qh5 11. Qf5 g4 12. Qf4+ Kh7
> 13. Qc7+ Qf7+ 14. Qxf7+ Kh6 15. Qg6# {921}
>
>I think, you are totally right about the "nullmove killer". The most interesting
>position in the line may be:
>
>[D] 8/4K3/7k/3p1Qp1/8/8/8/3q4 w - - 3 6
>
>I guess many nullmove using programs may fail to find Kf7 here, even when you
>give them lots of time.
>
>Regards,
>Dieter
As I use a chess program most for analysis purposes the question is
"to find the solution or not to find". Of course it's nice to find the solution
in a short time. And if yace finds the right move in the endgame due to
tablebases it's perfectly ok for me.
Fritz6 and Fritz7 find the solution too in spite of using null-move. Don't know
why, may be because of tablebases.
Crafty18.15 in it's original version will not find the solution in reasonable
time due to null move.
Therefore I have changed search.c to:
if (do_null && !tree->in_check[ply] && pieces>bishop_v &&
(pieces>=(queen_v+rook_v) || depth<iteration_depth*20+1)) {
This helps a lot, but I don't think it's the best way to deal with.
But I think now a days something has to be done with the null-move problem.
I'm looking forward to the next release of yace, hopefully with an analysis
feature.
Kind regards
Bernhard
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.