Your best bug ?
Moderators: hgm, Rebel, chrisw
-
- Posts: 71
- Joined: Fri Mar 16, 2012 10:16 am
Re: Your best bug ?
As a rookie: by double pawn pushes I really loved seeing pieces flying over occupied rank3/6 squares
-
- Posts: 7005
- Joined: Thu Aug 18, 2011 12:04 pm
- Full name: Ed Schröder
Re: Your best bug ?
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...
[d]r7/8/4p2k/3p1bR1/7r/Np6/1P6/K5R1 w - -
1.Rh5+ draw
On the hardware of that time simply amazing...
-
- Posts: 138
- Joined: Tue Aug 23, 2011 10:25 pm
- Location: Germany
Re: Your best bug ?
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.
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.
nanos gigantium humeris insidentes
-
- Posts: 2041
- Joined: Wed Mar 08, 2006 8:30 pm
Re: Your best bug ?
Not found by Houdini...Rebel wrote:1.Rh5+ draw
-
- Posts: 2041
- Joined: Wed Mar 08, 2006 8:30 pm
Re: Your best bug ?
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
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
-
- Posts: 238
- Joined: Tue Jul 12, 2011 1:31 pm
Re: Your best bug ?
I didn't know of these ones... and hope never to meet one in person
Two first meanings of the dutch word "leren":
1. leren [vc] (learn, larn, acquire) acquire or gain knowledge or skills.
2. leren [v] (teach, learn, instruct) impart skills or knowledge to.
1. leren [vc] (learn, larn, acquire) acquire or gain knowledge or skills.
2. leren [v] (teach, learn, instruct) impart skills or knowledge to.
-
- Posts: 2559
- Joined: Fri Nov 26, 2010 2:00 pm
- Location: Czech Republic
- Full name: Martin Sedlak
Re: Your best bug ?
I tried many much lower rated engines and almost all find it very quickly.ernest wrote:Well, actually, Houdini needs some time to find it
For example Prédateur sees that Rh5+ draws in 8 seconds.
Starting to understand why Vincent calls top engines "beancounters"
-
- Posts: 686
- Joined: Thu Mar 03, 2011 4:57 pm
- Location: Germany
Re: Your best bug ?
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...
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
-
- Posts: 1334
- Joined: Sun Jul 17, 2011 11:14 am
Re: Your best bug ?
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
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
Some believe in the almighty dollar.
I believe in the almighty printf statement.
I believe in the almighty printf statement.
-
- Posts: 1357
- Joined: Wed Mar 08, 2006 10:15 pm
- Location: San Francisco, California
Re: 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.Rebel wrote:What's your best bug ?
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