Home 
Search 
Today's Posts 
#1




Junior 9 problems at high analysis depths?
I put Junior 9 on infinite analysis for a particular position and after
almost 19 hours here is what it came up with  25: Griffith,R  Gunston,W, London 4r1r1/ppb2q1k/4b2p/3p1p1N/4ppPn/1BPP1P1P/PP1NQ2R/4R2K w   0 1 Analysis by Junior 9: 28.dxe4 dxe4 29.Bxe6 Qxe6 30.fxe4 µ (1.35) Depth: 3 00:00:00 1kN 28.Qf2 Qe7 29.dxe4 fxe4 µ (1.12) Depth: 3 00:00:00 4kN 28.Qf2 Nxf3 + (1.42) Depth: 6 00:00:00 17kN 28.dxe4 fxe4 29.Qf2 Bd8 30.fxe4 f3 31.Qxa7 µ (0.91) Depth: 6 00:00:00 41kN 28.dxe4 fxe4 29.Nxe4 dxe4 30.Qxe4+ Rg6 31.Rhe2 Bd6 32.Bxe6 Rexe6 33.Qxe6 µ (1.06) Depth: 9 00:00:00 535kN 28.dxe4! µ (0.76) Depth: 12 00:00:02 3076kN 28.dxe4! ³ (0.46) Depth: 15 00:00:29 56986kN 28.dxe4 fxe4 29.Nxe4 dxe4 30.Qxe4+ Rg6 31.Rhe2 Re7 32.Bxe6 Rexe6 33.Qxb7 Rxe2 34.Rxe2 Rb6 35.Qe4+ Kg8 36.c4 ³ (0.29) Depth: 16 00:02:10 249309kN 28.dxe4! = (0.01) Depth: 17 00:05:23 613056kN 28.dxe4! ² (0.31) Depth: 18 00:13:19 1494636kN 28.dxe4 fxe4 29.Nxe4 dxe4 30.Qxe4+ Rg6 31.Rhe2 Re7 32.Bc2 a5 33.Qxb7 Be5 34.Qb5 Nxf3 35.Bxg6+ Qxg6 ² (0.60) Depth: 19 00:38:49 4294623kN 28.dxe4 fxe4 29.Nxe4 dxe4 30.Qxe4+ Rg6 31.Rhe2 Re7 ² (0.60) Depth: 20 01:22:08 469710kN 28.dxe4! ± (0.90) Depth: 21 03:43:21 3652170kN 28.dxe4 fxe4 29.Nxe4 Rg6 30.Ba4 dxe4 31.Bxe8 Qxe8 32.Qxe4 Qf7 33.Rd2 b5 34.b3 a5 35.a4 b4 36.c4 Kh8 ± (0.94) Depth: 22 09:41:44 1108421kN 28.dxe4 fxe4 29.Nxe4 Rg6 30.Ba4 dxe4 31.Bxe8 Qxe8 32.Qxe4 Qd8 33.Rhe2 Bg8 34.Nxf4 Bxf4 35.Qxf4 Qd5 36.Re4 Re6 37.a4 ± (0.87) Depth: 23 18:34:08 3156121kN (Kalinauskas, New Fairfield 27.02.2007) Curious things come to mind  a) At ply depth 20 and 22, there was a significant drop in number of nodes analyzed compared to the odd nodes 19, 21, 23. I'm not sure why even nodes would be like this, especially in a complex position that does not lend itself often to forced moves. b) There was a huge loss in analysis speed as the analysis gets deeper. It starts out at millions of nodes per second and then drops to about 200300 kN/s at high depths, and I saw even as poor as 90100 kN/s at some points. c) After depth 23, Junior did not continue to depth 24 but instead continued to analyze depth 23 at that hugely depressed (ca. 95 kN/s) kilonode rate. I'm not sure why any of these are the case, whether they reflect bugs in Junior or the nature of deep analysis or chess engines themselves, or are unique to the position concerned (however, concern b) tends to occur when deeply analyzing almost anything with Junior, not just this position). Junior certainly does have a few imperfections, such as the two knights bug I brought up a while back and the fact that when presented with some problems it will insist they are mate in 3 when mate in 2 is possible ... plus the artifact move that sometimes appears after a mate, but none of these apply to this position. I'm not sure what's going on here. Oh, by the way d) Yes, 27 ... e4 indeed deserves a question mark, and was no longer possible as Ed. Lasker indicated as early as 1915. 
#2




Junior 9 problems at high analysis depths?
On Feb 27, 5:52 pm, Amarande wrote:
I put Junior 9 on infinite analysis for a particular position and after almost 19 hours here is what it came up with  25: Griffith,R  Gunston,W, London 4r1r1/ppb2q1k/4b2p/3p1p1N/4ppPn/1BPP1P1P/PP1NQ2R/4R2K w   0 1 Analysis by Junior 9: 28.dxe4 dxe4 29.Bxe6 Qxe6 30.fxe4 µ (1.35) Depth: 3 00:00:00 1kN 28.Qf2 Qe7 29.dxe4 fxe4 µ (1.12) Depth: 3 00:00:00 4kN 28.Qf2 Nxf3 + (1.42) Depth: 6 00:00:00 17kN 28.dxe4 fxe4 29.Qf2 Bd8 30.fxe4 f3 31.Qxa7 µ (0.91) Depth: 6 00:00:00 41kN 28.dxe4 fxe4 29.Nxe4 dxe4 30.Qxe4+ Rg6 31.Rhe2 Bd6 32.Bxe6 Rexe6 33.Qxe6 µ (1.06) Depth: 9 00:00:00 535kN 28.dxe4! µ (0.76) Depth: 12 00:00:02 3076kN 28.dxe4! ³ (0.46) Depth: 15 00:00:29 56986kN 28.dxe4 fxe4 29.Nxe4 dxe4 30.Qxe4+ Rg6 31.Rhe2 Re7 32.Bxe6 Rexe6 33.Qxb7 Rxe2 34.Rxe2 Rb6 35.Qe4+ Kg8 36.c4 ³ (0.29) Depth: 16 00:02:10 249309kN 28.dxe4! = (0.01) Depth: 17 00:05:23 613056kN 28.dxe4! ² (0.31) Depth: 18 00:13:19 1494636kN 28.dxe4 fxe4 29.Nxe4 dxe4 30.Qxe4+ Rg6 31.Rhe2 Re7 32.Bc2 a5 33.Qxb7 Be5 34.Qb5 Nxf3 35.Bxg6+ Qxg6 ² (0.60) Depth: 19 00:38:49 4294623kN 28.dxe4 fxe4 29.Nxe4 dxe4 30.Qxe4+ Rg6 31.Rhe2 Re7 ² (0.60) Depth: 20 01:22:08 469710kN 28.dxe4! ± (0.90) Depth: 21 03:43:21 3652170kN 28.dxe4 fxe4 29.Nxe4 Rg6 30.Ba4 dxe4 31.Bxe8 Qxe8 32.Qxe4 Qf7 33.Rd2 b5 34.b3 a5 35.a4 b4 36.c4 Kh8 ± (0.94) Depth: 22 09:41:44 1108421kN 28.dxe4 fxe4 29.Nxe4 Rg6 30.Ba4 dxe4 31.Bxe8 Qxe8 32.Qxe4 Qd8 33.Rhe2 Bg8 34.Nxf4 Bxf4 35.Qxf4 Qd5 36.Re4 Re6 37.a4 ± (0.87) Depth: 23 18:34:08 3156121kN (Kalinauskas, New Fairfield 27.02.2007) These actually look like fairly normal slow down as the analysis progresses. You are doing well if the time taken for exploring each successive ply is less than twice the previous one. However, I think that I have found a bug in the ChessBase engines when they are asked to do infinite analysis on a position where mates in N for the opponent are possible. What I saw happen with both Fritz8 and Shredder10 (on different versions of CB interface) was that initially everything was normal, but when the search depth exceeds the mate in N the analysis of the losing lines became insanely slow (although nodes per second actually increased). The test position to demonstrate this problem is the one I posted in the thread Endgame & Engines (partly in frustration because none of the engines I have can make sense of it). Namely: 8/8/8/8/R1b3p1/3kp1P1/7P/4K3 w   0 72 There are a 13 possible moves of which the worst ones are Rxc4 #11 Kd1 #10 Ra2 #9 Ra6 #9 Kf1 is pretty dumb too but does not lead to a mate in less than 14 which is the practical limit. Test settings were infinite analysis with all the lines displayed. Pentium 4 3G/ 1GB ram. What I have established on both engines is that analysis is fine up to the point where the search depth exceeds the mate in N threshold. And after that the time spent on the worst 4 moves grows exponentially (quite unlike what normally happens with really bad moves). And slowness seems to be related to the number of ply the mate is overrun by. The elapsed timings I have for ply 27 & 28 searches with Shredder 10 a 0h 40 1/13 1h 14 10/13 ie each ply of good move took ~3 mins 17h 13/13 the worst move (resolved as mate in 9 = 18 ply) takes 7h 24h 00 1/13 24h 20 2/13 24h 33 3/13 25h 00 10/13 again the good moves took ~6min each (actually it was more like 20min, 13 min and then the cache took over and each of the others was 2min) Ply 27 spent 34 minutes doing useful analysis and then wasted nearly 23 hours on total garbage! I do not expect to see the thing make any further progress at ply 28 since at the rate that time to search the lost cause moves was increasing my best guess for finishing 11/13 is around 70 hours. This is clearly insane since the program actually knows the winning line and the search should terminate almost instantly (certainly it should be no slower than the minimum raw search to demonstrate a forced mate in N). The same can be demonstrated with Fritz8 although it seemed to be very sensitive to whether or not you had been sparring with it on the position (ie cache clean or cache dirty). At one point I had it stall on me on a ply 18 search taking more than 2 hours on the worst move! You can see it clearly at ply 17 in a 510 min test. The most promising moves take a couple of seconds each and the really bad moves take 510 minutes each (or hours if you are unlucky). I hope this provides sufficient info to allow the problem I have described to be reproduced. Regards, Martin Brown 
Reply 
Thread Tools  
Display Modes  


Similar Threads  
Thread  Forum  
Blunder Check Puzzle  rec.games.chess.computer (Computer Chess) 