Interesting position from Jouni Uski

[MartinBryant]

Ah, well, now, maybe there WAS a bug way back then!!!

Could you try it again with the latest version 2007a available at
http://www.colossus.demon.co.uk/chess/c ... essuci.htm

[GeoffW]

Thanks for the updated link Martin

I didnt upgrade as your earlier 2006 version was easily good enough to give my prog a heavy thrashing

The old version was the explanation, the 2007a version gets it right instantly. Mystery explained, for Colossus at least.

Geoff

[bob]

Hi Bob

I am intrigued now, lets have another peek at what is going on with Crafty on my setup. (Single CPU P4, WinXp, Chess Arena 1.1)

I know the later Chess Arena betas, have fen bugs, but as far as I am aware 1.1 is OK.

I forget which version of Crafty I originally tried so I downloaded it again. I got the 20.14 BH version

What I am seeing now is that if I try to start Crafty analysing this position I get no output coming back at all !

here is the debug, I cant spot anything obviously wrong with what Arena is sending

961813>1:new
961813>1:random
961813>1:level 0 45 5
961828<1:tellicsnoalias kibitz Hello from Crafty v20.14 BH!
961828<1:tellicsnoalias set 1 Crafty v20.14 BH (1 cpus)
961875>1:post
961875>1:hard
961875>1:easy
961875>1:ping 3
961907<1:pong 3
961985>1:name GeoffW1
961985>1:force
961985>1:setboard 5K2/8/2qk4/2nPp3/3r4/6B1/B7/3R4 w - e6 0 1
981547>1:analyze
981547<1:tellicsnoalias kibitz Hello from Crafty v20.14 BH!
981547<1:Analyze Mode: type "exit" to terminate.
982938>1:.
982938<1:stat01: 0 0 0 0 0
983938>1:.
983938<1:stat01: 0 0 0 0 0
984938>1:.
984938<1:stat01: 0 0 0 0 0
985938>1:.
985938<1:stat01: 0 0 0 0 0
986938>1:.
986938<1:stat01: 0 0 0 0 0
987938>1:.
987938<1:stat01: 0 0 0 0 0
988938>1:.
990016>1:exit
990219>1:force

If I now manually edit the position so that I clear the ep square, it analyses as expected, here is the debug

1166860>1:new
1166860>1:random
1166860>1:level 0 45 5
1166891<1:tellicsnoalias set 1 Crafty v20.14 BH (1 cpus)
1166922>1:post
1166922>1:hard
1166922>1:easy
1166922>1:ping 1
1166953<1:pong 1
1167047>1:name Crafty
1167110>1:new
1167110>1:random
1167110>1:level 0 45 5
1167125<1:tellicsnoalias kibitz Hello from Crafty v20.14 BH!
1167125<1:tellicsnoalias set 1 Crafty v20.14 BH (1 cpus)
1167172>1:post
1167172>1:hard
1167172>1:easy
1167172>1:ping 2
1167188<1:pong 2
1167282>1:name Crafty
1167282>1:force
1167282>1:setboard 5K2/8/2qk4/2nPp3/3r4/6B1/B7/3R4 w - - 0 1
1213266>1:analyze
1213266<1:tellicsnoalias kibitz Hello from Crafty v20.14 BH!
1213266<1:Analyze Mode: type "exit" to terminate.
1213407<1: 11 1 13 214017 1. Bxe5+ Kxe5 2. Re1+ Kd6 3. dxc6 Kxc6 4. Kg8 Rd8+ 5. Kh7 Nd7 6. Bf7 Nf6+ 7. Kg7 Ng4 8. Re8
1213532<1: 12 1 27 435650 1. Bxe5+ Kxe5 2. Re1+ Kd6 3. dxc6 Kxc6 4. Kg8 Rd8+ 5. Kh7 Nd7 6. Bf7 Nf6+ 7. Kg7 Ng4 8. Re8 Rxe8 9. Bxe8+
1213594<1: 12 1 33 531365 1. Bxe5+ Kxe5 2. Re1+ Kd6 3. dxc6 Kxc6 4. Kg8 Rd8+ 5. Kh7 Nd7 6. Bf7 Nf6+ 7. Kg7 Ng4 8. Re8 Rxe8 9. Bxe8+
1213860<1: 13 1 60 1025611 1. Bxe5+ Kxe5 2. Re1+ Kd6 3. dxc6 Kxc6 4. Kg8 Rd8+ 5. Kh7 Nd7 6. Bf7 Nf6+ 7. Kg7 Ng4 8. Re8 Rxe8 9. Bxe8+ Kc5
1214000<1: 13 1 74 1236142 1. Bxe5+ Kxe5 2. Re1+ Kd6 3. dxc6 Kxc6 4. Kg8 Rd8+ 5. Kh7 Nd7 6. Bf7 Nf6+ 7. Kg7 Ng4 8. Re8 Rxe8 9. Bxe8+ Kc5
1214719<1: 14 1 146 2544879 1. Bxe5+ Kxe5 2. Re1+ Kd6 3. dxc6 Kxc6 4. Kg8 Rd8+ 5. Kh7 Nd7 6. Bf7 Nf6+ 7. Kg7 Ng4 8. Re8 Rxe8 9. Bxe8+ Kc5 10. Kh8
1214907>1:.
1214922<1:stat01: 166 2881853 14 16 23
1215032<1: 14 1 175 3039902 1. Bxe5+ Kxe5 2. Re1+ Kd6 3. dxc6 Kxc6 4. Kg8 Rd8+ 5. Kh7 Nd7 6. Bf7 Nf6+ 7. Kg7 Ng4 8. Re8 Rxe8 9. Bxe8+ Kc5 10. Kh8
1215391>1:exit
1215594>1:force

On that evidence I would still say looks like a Crafty Bug, but I am sure I will be corrected if someone spots a mistake by me or Arena's Winboard protocol

Geoff

What is happening is that you get no analysis output. The search stops after 4 plies since a mate was found in every search. With so few nodes searched, the output is not produced...

add "noise 0" to your crafty.rc and you will see the actual analysis starting at ply=1. This "noise" feature was added 10 years ago to stop output from scrolling the screen wildly when playing tournaments. The first N plies take no time and seeing that analysis is not so interesting...

Crafty sees the mate just fine. It just doesn't display any output since the default "noise" value is higher than the node count produced by the 1-2-3-4 ply searches before it quits.

[Zlaire]

So basically Crafty can't 'analyze' pretty much any mate in one problems on default settings?

[sje]

Symbolic has a similar feature where the early, quickly generated trace text is not emitted. There are two differences in the implementation:

1. The amount of output to skip is not based on a line count, but rather on elapsed wall clock time. Currently, the first three seconds of output is skipped.

2. Symbolic knows about the isatty() function and can ignore early output suppression if the output stream is not connected to a terminal.

[GeoffW]

Thanks Bob

Yes indeed that was the explanation. I have to say I dont like that feature though, leads to confusion like this.

Wouldn't it have been better to just print the the final PV at the end of the small depth searches, so what, it scrolls a few lines of text up the screen.

Regards Geoff

[bob]

So basically Crafty can't 'analyze' pretty much any mate in one problems on default settings?

Depends on what you mean by "analyze". You can always make "noise 0" the default. It just makes the program _very_ chatty, particularly in endgames.

[bob]

Thanks Bob

Yes indeed that was the explanation. I have to say I dont like that feature though, leads to confusion like this.

Wouldn't it have been better to just print the the final PV at the end of the small depth searches, so what, it scrolls a few lines of text up the screen.

Regards Geoff

I don't use "analyze" enough to have noticed this. I will at least see if I can make do something better. Here's the problem issue however:

Someone once suggested that if it sees a mate, it displays that output regardless of the "noise" setting. But that introduces a different form of confusion. At (say) depth=3, the first move searched leads to a forced mate (a loss), so it would display that. But then it would find a better move, but now not yet having satisfied the "noise" requirement, it wouldn't display that. Leaving the "I am mated" analysis as the only thing visible...

It can be fixed, but it is a bit messy...

[jwes]

Thanks Bob

Yes indeed that was the explanation. I have to say I dont like that feature though, leads to confusion like this.

Wouldn't it have been better to just print the the final PV at the end of the small depth searches, so what, it scrolls a few lines of text up the screen.

Regards Geoff

I don't use "analyze" enough to have noticed this. I will at least see if I can make do something better. Here's the problem issue however:

Someone once suggested that if it sees a mate, it displays that output regardless of the "noise" setting. But that introduces a different form of confusion. At (say) depth=3, the first move searched leads to a forced mate (a loss), so it would display that. But then it would find a better move, but now not yet having satisfied the "noise" requirement, it wouldn't display that. Leaving the "I am mated" analysis as the only thing visible...

It can be fixed, but it is a bit messy...

My suggestion is to ensure the PV has been printed when the search terminates.

[bob]

Thanks Bob

Yes indeed that was the explanation. I have to say I dont like that feature though, leads to confusion like this.

Wouldn't it have been better to just print the the final PV at the end of the small depth searches, so what, it scrolls a few lines of text up the screen.

Regards Geoff

I don't use "analyze" enough to have noticed this. I will at least see if I can make do something better. Here's the problem issue however:

Someone once suggested that if it sees a mate, it displays that output regardless of the "noise" setting. But that introduces a different form of confusion. At (say) depth=3, the first move searched leads to a forced mate (a loss), so it would display that. But then it would find a better move, but now not yet having satisfied the "noise" requirement, it wouldn't display that. Leaving the "I am mated" analysis as the only thing visible...

It can be fixed, but it is a bit messy...

My suggestion is to ensure the PV has been printed when the search terminates.

That is easy to say, but it is more complex to actually do. I make the decision to print (or not print) the PV at time T. The iteration ends at time T+n.