fine #70 revisited

[bob]

Most are familiar with the position, but it has an interesting bit of history behind it. Monty published a chapter on his endgame program Peasant in the Chess Skill book. He gave several positions, including fine 70. At the time, nothing could touch that position. Later that year, Dave Cahlander (CDC) reported that chess 4.x solved the position, requiring either 23 plies and 26 minutes, or 26 plies and 23 minutes, I do not remember which.

Of course today everyone smashes this one instantly. Mike Byrne reported an interesting result as we were getting ready for the ACCA event last weekend, namely that without EGTBs Crafty found a mate in 3 minutes with this position. Thought I would try it on my older 8-core box:

Code: Select all

               55     5:32  Mat39   1. Kb1 Kb7 2. Kc1 Kb8 3. Kc2 Kb7 4.
                                    Kc3 Kb6 5. Kd2 Ka6 6. Kd3 Kb6 7. Ke2
                                    Kc7 8. Kd1 Kd7 9. Kc2 Kc8 10. Kd2 Kd8
                                    11. Kc3 Kc7 12. Kd3 Kb6 13. Ke2 Kc7
                                    14. Kf2 Kd7 15. Kg3 Ke7 16. Kh4 Kf6
                                    17. Kh5 Kf7 18. Kg5 Kg7 19. Kxf5 Kf7
                                    20. Kg5 Kg7 21. f5 Kf7 22. f6 Kf8 23.
                                    Kg4 Kg8 24. Kf4 Kf8 25. Kg5 Kg8 26.
                                    Kg6 Kh8 27. Kf7 Kh7 28. Ke6 Kg6 29.
                                    f7 Kg7 30. Ke7 Kg6 31. f8=Q Kg5 32.
                                    Kxd6 <HT>           

Just lets you know how far the hardware and software have come in 30 years or so... The full PV is not shown, even with my recent PV hashing stuff, apparently the path hash needs to be bigger. Will re-try to see...

[Uri Blass]

Most are familiar with the position, but it has an interesting bit of history behind it. Monty published a chapter on his endgame program Peasant in the Chess Skill book. He gave several positions, including fine 70. At the time, nothing could touch that position. Later that year, Dave Cahlander (CDC) reported that chess 4.x solved the position, requiring either 23 plies and 26 minutes, or 26 plies and 23 minutes, I do not remember which.

Of course today everyone smashes this one instantly. Mike Byrne reported an interesting result as we were getting ready for the ACCA event last weekend, namely that without EGTBs Crafty found a mate in 3 minutes with this position. Thought I would try it on my older 8-core box:

Code: Select all

               55     5:32  Mat39   1. Kb1 Kb7 2. Kc1 Kb8 3. Kc2 Kb7 4.
                                    Kc3 Kb6 5. Kd2 Ka6 6. Kd3 Kb6 7. Ke2
                                    Kc7 8. Kd1 Kd7 9. Kc2 Kc8 10. Kd2 Kd8
                                    11. Kc3 Kc7 12. Kd3 Kb6 13. Ke2 Kc7
                                    14. Kf2 Kd7 15. Kg3 Ke7 16. Kh4 Kf6
                                    17. Kh5 Kf7 18. Kg5 Kg7 19. Kxf5 Kf7
                                    20. Kg5 Kg7 21. f5 Kf7 22. f6 Kf8 23.
                                    Kg4 Kg8 24. Kf4 Kf8 25. Kg5 Kg8 26.
                                    Kg6 Kh8 27. Kf7 Kh7 28. Ke6 Kg6 29.
                                    f7 Kg7 30. Ke7 Kg6 31. f8=Q Kg5 32.
                                    Kxd6 <HT>           

Just lets you know how far the hardware and software have come in 30 years or so... The full PV is not shown, even with my recent PV hashing stuff, apparently the path hash needs to be bigger. Will re-try to see...

The pv of Crafty before the HT has 63 plies and I see no checks in the pv.
The depth is only depth 55.
How it is possible when Crafty has only the check extension?

[Uri Blass]

looking again at the pv it seems that the pv is wrong

1. Kb1 Kb7 2. Kc1 Kb8 3. Kc2 Kb7 4. Kc3 Kb6 5. Kd2 Ka6 6. Kd3 Kb6 7. Ke2 Kc7 8. Kd1

It seems that 8.Kd1 is a drawing move when 8.Kf3 is winning.

[bob]

Most are familiar with the position, but it has an interesting bit of history behind it. Monty published a chapter on his endgame program Peasant in the Chess Skill book. He gave several positions, including fine 70. At the time, nothing could touch that position. Later that year, Dave Cahlander (CDC) reported that chess 4.x solved the position, requiring either 23 plies and 26 minutes, or 26 plies and 23 minutes, I do not remember which.

Of course today everyone smashes this one instantly. Mike Byrne reported an interesting result as we were getting ready for the ACCA event last weekend, namely that without EGTBs Crafty found a mate in 3 minutes with this position. Thought I would try it on my older 8-core box:

Code: Select all

               55     5:32  Mat39   1. Kb1 Kb7 2. Kc1 Kb8 3. Kc2 Kb7 4.
                                    Kc3 Kb6 5. Kd2 Ka6 6. Kd3 Kb6 7. Ke2
                                    Kc7 8. Kd1 Kd7 9. Kc2 Kc8 10. Kd2 Kd8
                                    11. Kc3 Kc7 12. Kd3 Kb6 13. Ke2 Kc7
                                    14. Kf2 Kd7 15. Kg3 Ke7 16. Kh4 Kf6
                                    17. Kh5 Kf7 18. Kg5 Kg7 19. Kxf5 Kf7
                                    20. Kg5 Kg7 21. f5 Kf7 22. f6 Kf8 23.
                                    Kg4 Kg8 24. Kf4 Kf8 25. Kg5 Kg8 26.
                                    Kg6 Kh8 27. Kf7 Kh7 28. Ke6 Kg6 29.
                                    f7 Kg7 30. Ke7 Kg6 31. f8=Q Kg5 32.
                                    Kxd6 <HT>           

Just lets you know how far the hardware and software have come in 30 years or so... The full PV is not shown, even with my recent PV hashing stuff, apparently the path hash needs to be bigger. Will re-try to see...

The pv of Crafty before the HT has 63 plies and I see no checks in the pv.
The depth is only depth 55.
How it is possible when Crafty has only the check extension?

Transposition table PV grafting...

[bob]

looking again at the pv it seems that the pv is wrong

1. Kb1 Kb7 2. Kc1 Kb8 3. Kc2 Kb7 4. Kc3 Kb6 5. Kd2 Ka6 6. Kd3 Kb6 7. Ke2 Kc7 8. Kd1

It seems that 8.Kd1 is a drawing move when 8.Kf3 is winning.

This is hash PV grafting. This is a problem that remains, because when I get a hash hit, I can graft the existing PV from that hit, but I have no way to check to see if this path would include a repetition, since the hash information can not possibly tell me that... Apparently, if there were no repetition/50-move rules in force, Kd1 would be ok... If you set it up from that position (prior to Kd1) with this:

8/2k5/3p4/p2P1p2/P2P1P2/8/4K3/8 w - -

Which gets rid of the repetition list, the position is just as winnable as it always was...

Nothing to do to fix that except to completely break hashing by including path information in the hash signature...

[bob]

looking again at the pv it seems that the pv is wrong

1. Kb1 Kb7 2. Kc1 Kb8 3. Kc2 Kb7 4. Kc3 Kb6 5. Kd2 Ka6 6. Kd3 Kb6 7. Ke2 Kc7 8. Kd1

It seems that 8.Kd1 is a drawing move when 8.Kf3 is winning.

This is hash PV grafting. This is a problem that remains, because when I get a hash hit, I can graft the existing PV from that hit, but I have no way to check to see if this path would include a repetition, since the hash information can not possibly tell me that... Apparently, if there were no repetition/50-move rules in force, Kd1 would be ok... If you set it up from that position (prior to Kd1) with this:

8/2k5/3p4/p2P1p2/P2P1P2/8/4K3/8 w - -

Which gets rid of the repetition list, the position is just as winnable as it always was...

Nothing to do to fix that except to completely break hashing by including path information in the hash signature...

Addendum -- looking for a longer PV was stupid. The PV array has 64 entries, so Crafty can never show a PV longer than 63 complete moves. Don't know why I didn't think of that when I posted the initial result. If the mate is deeper than 32, it can never show the full PV unless I decide to make the PV array longer... However, with the repetition issue, the real mate is shorter than 36, but it would be difficult to find it without searching to depth 60+...

[Uri Blass]

You are right.

practically Kd1 is still winning but the analysis of chess programs do not see it because they consider first repetition as a draw.

I used yace for the analysis that suggested that Kd1 is drawing.

I thought that I can trust yace not to evaluate repetition of history game position as a draw(because I remember cases when it did not give 0.00 to a repetition move that wins unlike other programs) but it seems that I cannot trust it

[Jouni]

This is spark territory:

Analysis by spark-0.4 2CPU

1.Kb1 Kb7 2.Kc1 Kc7 3.Kd1 Kd7 4.Kc2 Kc8 5.Kd2 Kd8 6.Kc3 Kc7 7.Kd3 Kb6 8.Ke2 Kc7 9.Kf2 Kd7 10.Kg3 Ke7 11.Kh4 Kf6 12.Kh5 Kf7 13.Kg5 Kg7 14.Kxf5 Kf7 15.Kg5 Kg7 16.f5 Kf7
+- (#32) Depth: 58/68 00:01:36 601mN

Jouni

[jwes]

looking again at the pv it seems that the pv is wrong

1. Kb1 Kb7 2. Kc1 Kb8 3. Kc2 Kb7 4. Kc3 Kb6 5. Kd2 Ka6 6. Kd3 Kb6 7. Ke2 Kc7 8. Kd1

It seems that 8.Kd1 is a drawing move when 8.Kf3 is winning.

This is hash PV grafting. This is a problem that remains, because when I get a hash hit, I can graft the existing PV from that hit, but I have no way to check to see if this path would include a repetition, since the hash information can not possibly tell me that... Apparently, if there were no repetition/50-move rules in force, Kd1 would be ok... If you set it up from that position (prior to Kd1) with this:

8/2k5/3p4/p2P1p2/P2P1P2/8/4K3/8 w - -

Which gets rid of the repetition list, the position is just as winnable as it always was...

Nothing to do to fix that except to completely break hashing by including path information in the hash signature...

When you get a hash hit with a non-drawish score, you could check the pv cache for repetitions. This would be good for analysis and might be good for games since it could avoid a 3-fold rep.

[bob]

looking again at the pv it seems that the pv is wrong

1. Kb1 Kb7 2. Kc1 Kb8 3. Kc2 Kb7 4. Kc3 Kb6 5. Kd2 Ka6 6. Kd3 Kb6 7. Ke2 Kc7 8. Kd1

It seems that 8.Kd1 is a drawing move when 8.Kf3 is winning.

This is hash PV grafting. This is a problem that remains, because when I get a hash hit, I can graft the existing PV from that hit, but I have no way to check to see if this path would include a repetition, since the hash information can not possibly tell me that... Apparently, if there were no repetition/50-move rules in force, Kd1 would be ok... If you set it up from that position (prior to Kd1) with this:

8/2k5/3p4/p2P1p2/P2P1P2/8/4K3/8 w - -

Which gets rid of the repetition list, the position is just as winnable as it always was...

Nothing to do to fix that except to completely break hashing by including path information in the hash signature...

When you get a hash hit with a non-drawish score, you could check the pv cache for repetitions. This would be good for analysis and might be good for games since it could avoid a 3-fold rep.

Doesn't do any good. What should I do then, just ignore the PV? and use the hash score? This is _very_ rare, in general. Obviously for positions like Fine where you can hit 50 plies in no time it becomes an issue...

Just because I see a draw in the path does not mean that root move is a draw. Obviously Kb1 wins. And even though the PV (due to grafting) has a repetition, the move still wins... I am not sure how you could learn anything from this...