TalkChess.com

As a rookie: by double pawn pushes I really loved seeing pieces flying over occupied rank3/6 squares

The WCCC 1993 was quite some tournament. Hundreds of visitors, the rise of Hiarcs and this amazing combination by the King against (I believe Nimzo).

[d]r7/8/4p2k/3p1bR1/7r/Np6/1P6/K5R1 w - -

1.Rh5+ draw

On the hardware of that time simply amazing...

Here's another bug I was chasing:

Last week I was testing Octochess with very short time controls, fixed move time of only one second. It played utterly horrible. Sometimes if was not doing any calculation at all, doing random moves, while at other times it was missing the time control and thus was loosing the game.

Careful reviewing of the code and sprinkling printf's around the code, I was able to find and fix some issues, though one mysterious bug remained.

Octochess uses mutexes and condition variables for synchronization between the I/O thread, management and calculation threads.

Basically, a timed wait on the condition is used to abort the calculation if the calculation isn't done by the given deadline. In that case, all calculation is interrupted and the best move found so far is being reported. Only problem: With timeouts less or equal than one second, no waiting at all was done and calculation was immediately interrupted. With larger timeouts, exactly one second was missing.

Frustrated I took a break and then revelation struck. Could it have been that simple? Some of you might know that there recently has been a leap second start of July. Some of you might also know that there has a bug in the Linux kernel triggered by the leap second. Back then, I was checking whether my systems were affected, even doing the recommended workarounds and also installed the available kernel updates. However I did not restart my machines as none showed any of the symptoms described on the various news sites. However, this kernel bug has one symptom that hasn't been mentioned much: If calling pthread_cond_timedwait after a leap second, it's off by exactly one second! At that point I had to bite the bullet and destroy my sweet uptime. Of course after the reboot, everthing worked fine, problem solved.

On the bright side, this operating system bug made me fine some other small bugs in the time planning. In the end, Octochess now plays better on short time controls, most likely gaining a few ELO.

In that sense I would like to rephrase Ed's earlier statement: The best bugs are those in other software that produce ELO in your own engine.

Rebel wrote:1.Rh5+ draw

Not found by Houdini...

Well, actually, Houdini needs some time to find it:

r7/8/4p2k/3p1bR1/7r/Np6/1P6/K5R1 w - - 0 1
Analysis by Houdini 2.0c w32 Nlm:
1.R5g3 Rb8
-+ (-4.42 --) Depth: 22/55 00:00:35 108mN, tb=1
1.R5g3 Rb8 2.R3g2 d4 3.Rd2 Rg8 4.Re1 e5 5.Rf2 Bd3 6.Rd2 e4 7.Rc1 Rg6 8.Re1 Rg3 9.Rc1 Kg5 10.Re1 Kf4 11.Rf2+ Rf3 12.Rd2 Rhh3 13.Nb1 Ke5 14.Rg1 Rh8 15.Rg5+ Kf4 16.Rg1 Rg3 17.Rf2+ Ke3
-+ (-4.49) Depth: 22/63 00:01:02 189mN, tb=1
1.R5g3 Rb8 2.R3g2 d4 3.Rd2 Rg8 4.Re1 e5 5.Rf2 Bd3 6.Rd2 e4 7.Rc1 Rg6 8.Re1 Rg3 9.Rc1 Kg5 10.Re1 Kf4 11.Rf2+ Rf3 12.Rd2 Rhh3 13.Nb1 Ke5 14.Rg1 Rh8 15.Rg5+ Rf5 16.Rg1 Ra8+ 17.Na3 Rf1+ 18.Rxf1 Bxf1 19.Rf2 Bd3
-+ (-4.61) Depth: 23/63 00:01:28 271mN, tb=4
1.Rh5+
-+ (-4.28 !) Depth: 23/63 00:01:55 349mN, tb=6
1.Rh5+
-+ (-3.86 !) Depth: 23/63 00:01:55 349mN, tb=6
1.Rh5+
-+ (-2.73 !) Depth: 23/63 00:01:55 349mN, tb=6
1.Rh5+
= (-0.03 !) Depth: 23/63 00:01:55 349mN, tb=6
1.Rh5+ Kxh5 2.Rg5+ Kh6 3.Rg6+ Kh7 4.Rg7+ Kh8 5.Rh7+ Kg8 6.Rg7+ Kf8 7.Rf7+ Ke8 8.Re7+ Kd8 9.Rd7+ Kc8 10.Rc7+ Kb8 11.Rb7+ Kxb7
= (0.00) Depth: 23/63 00:01:55 349mN, tb=6
1.Rh5+ Kxh5 2.Rg5+ Kh6 3.Rg6+ Kh7 4.Rg7+ Kh8 5.Rh7+ Kg8 6.Rg7+ Kf8 7.Rf7+ Ke8 8.Re7+ Kd8 9.Rd7+ Kc8 10.Rc7+ Kb8 11.Rb7+ Kxb7
= (0.00) Depth: 24/63 00:01:55 349mN, tb=6

I didn't know of these ones... and hope never to meet one in person

ernest wrote:Well, actually, Houdini needs some time to find it

I tried many much lower rated engines and almost all find it very quickly.
For example Prédateur sees that Rh5+ draws in 8 seconds.
Starting to understand why Vincent calls top engines "beancounters"

Yes, this position is easy, less than 1 sec for iCE. But I'm starting to wonder whether our engines are weaker because we look into branches that Houdini just throws away. Maybe in average he is using the better approach.

Thomas...

info depth 12 seldepth 24 time 312 nodes 317026 pv g5h5 h4h5 g1g6 f5g6 nps 1016108 score cp 0 hashfull 16 tbhits 12
bestmove g5h5 ponder h4h5
info time 890 nodes 683401 nps 767866

The best bug that FF has is that it is so selective it throws away all the good trees and looks at all the bad ones.

So I can impress you by saying my engine can reach depth 18 in 10 seconds at the starting position.

I can also impress you by saying that, despite reaching depth 25 in the TP in 2 minutes it still can't find it.

The target for FF 1.2 is to *less* specific about which branches it chooses. One of the ways I am doing this is by having more extensions in the search (yes, this is self contradictary, but by searching more, it will search less, if you get what I mean).

Matthew:out

Rebel wrote:What's your best bug ?

Not sure if this is my "best", but it's the one that sticks in my memory the most and could very well exist in most sub-2000 engines, like Myrddin was at the time.

Simple rule: it is a good idea to check that an opponent's move gives checkmate BEFORE you check that it increments the 50-move counter to 100.

jm