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
200-300 kN/s at high depths, and I saw even as poor as 90-100 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.

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 5-10 min test. The most
promising moves take a couple of seconds each and the really bad moves
take 5-10 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