Page for 1. e3 c5 It was my general impression that this is harder than b6, but who knows. Vladica Andrejic inquired what I knew about this line, so I decided to try running it again (my old trees are on a different computer, with a much less enhanced version of the solver). I think White does best with 2. Bb5, in which case Qc7 is the only Black try. The log-ratio (in the sense of Nilatac) was above 4 at one point, but now is around 2 or 3. The proof of 1. e3 c5 2. Bb5 c4 is actually the longest proof I have done so far (at least in one file). e3c5.Bb5c4.proof.bz2 (123MB) bc98dbe659efe4ae07eb2e764382d401 e3c5.Bb5g5.proof.bz2 (30MB) d6b886919f8b3edb49b698b4c2cd5a7a e3c5.Bb5Nh6.proof.bz2 (53MB) 41d0bf3eb410e7764f2c968f5345cbb6 e3c5.Bb5easy.proof.bz2 (19MB) c128df1e74172dbbfd57b1e3ec855544 Now Nh6 was easier to solve than g5 (two days versus a week or so), but seems to have many more extended endgame ploddings and thus a larger file. One critical line is: 2. Bb5 Qc7 3. Bxd7 Bxd7 4. Qf3 Qxh2 5. Rxh2 h6 where I don't think Rxh6 leads anywhere in the end (yet, see below). It looks like 6. Qxb7 might be a better chance for White, leading to 6. Qxb7 Bh3 7. gxh3 c4 8. Qxb8 Rxb8 9. c3 Rxb2 10. Bxb2, and Black has a number of moves (f5/e5/h5/Kd7/Kd8/e6/g5). White is up R+N, but has very poor piece coordination. (Back to work, after a month of lull) Dec 1: My latest idea is 4. g3 Qxg3 5. fxg3 Bg4 6. Qxg4 ... Dec 4: Currently 6. Rxh6 is trending reasonably well. 6. Rxh6 Nxh6 7. Qxb7 Bh3 8. Nxh3 g5 9. Nxg5 Ng8 10. Nxf7 Kxf7 11. Qxe7 Nxe7 12. b4 cxb4 13. Ba3 bxa3 14. Nxa3 Bh6 15. Nc4 Bxe3 16. dxe3 Na6 17. f4 Ng8 18. Nb2 Rh6 19. g3 is currently around +3. Previously 19. Nd1 was tried, but that eventually went nowhere (after Nb8). ["Eventually" meaning millions of 100M node pn-searches..., the main idea was eg: 19. Nd1 Nb8 20. Nf2 Rh1 21. Nxh1 Nd7 22. Ng3 a5 23. c4 Nf8 24. f5 Ne6 25. fxe6 Kxe6 26. Ke2 Kf5! 27. Nxf5 Ne7 28. Nxe7 Rc8 29. Nxc8 a4 30. Rb1 a3 31. Rb2 axb2 and Black draws -- the pawns are not sufficiently advanced; or 24. Ne2 Nh7 25. Nd4 Ng5 26. fxg5 Ke6 27. Nxe6 Nh6!]. I started a new try.Rxh6.book and now only 19. g3 Kg7 (+3) is unsolved (there is one loop in the final proof here, that I haven't bothered with yet). Then again, 19. Nd1 was +5 at one point, so who knows? In fact, 19. g3 takes a fairly long time (even with 100M node searches) to look even halfway decent, so it's rather subtle what's going on. Black does seem to have some defensive chances with splitting the White pawns up, for instance there was a propensity to stall at +5 in Ke8 lines, with White having KNR+aceg and Black K+a. I cannot say that I am that optimistic about being able to solve Kg7, really. 20. Na4 Rb6 21. Nxb6 axb6 22...? Black plays Rb8/Nc7/Ne6 (if Pf5) Current trend (Jan 21): 22. Kd2 is bouncing between +5 and +6 (previously was around +3, among other moves). It seems that Black's plan is Na6/c7/e6 after White plays f5, thus hobbling the pawns... ergo, White should stall on f5 as long as possible. However: 22. Kd2 Rb8 23. Rd1 Kf7 24. g4 Ke7 25. f5 Nc7 26. c4 Rc8 and White is +5 or +6, but seems just to shuffle around... Of course, in any one example I can probably circumvent this (25. g5), but the spectre of such lines possibly being commonplace makes me wary. Solving the 4-vs-KK endgames has also been useful. Current situation after 22. Kd2: BOOK 450703 450703 450702 a572540cacf527f7 Val: -5.565 3363/7817710 999999 g7f7 +5.565 7817710/3363 999999 0 0 [[CRACK]] The (old) code took so long (many minutes) to resolve all the transpositions that I thought ClusterMaster had hung (or entered an infinite loop), but one of the main Black tries is now solved, and 22. Kd2 is over +7. However, I still see some stalls going on at +8 after 22. Kd2 Kf7 23. Ke2 Kg7, for instance Kc5/Rg5/Pe3/Pc2 vs Kh8/Pa3 (a previous line had stalls at +10 with eg Pa2/Pc2/Rh6/Kd6 vs Pb5/Ka7 or the like). ... As usual with these things, back-tracking and taking a different line (23. g4 rather than 23. f5, incidentally "losing"/ignoring all those positions just solved) now turns rapidly into +8, ... a minute later +12, and SOLVED!! ======================================================================== If everything goes right with assembly, the full proof should be available... The wintree was produced with no errors (about 132K positions), but: Copy 944 to 1773677: 131661559 records from KNOWN/0x9a/0xe1e2fcb1b88bf19a -rw-r--r-- 0 Jan 13 17:38 KNOWN/0x9a/0xe1e2fcb1b88bf19a Seems to be a "size 0" error in KNOWN... This must have been when I overflowed the hard drive with a runaway logger... e2e3 c7c5 f1b5 d8c7 b5d7 c8d7 d1f3 c7h2 h1h2 h7h6 h2h6 g8h6 f3b7 d7h3 g1h3 g7g5 h3g5 h6g8 b7e7 g8e7 g5f7 e8f7 b2b4 c5b4 c1a3 b4a3 b1a3 f8h6 a3c4 h6e3 d2e3 b8a6 f2f4 e7g8 c4b2 h8h6 g2g3 f7g7 b2a4 h6b6 a4b6 a7b6 e1d2 g7f7 g3g4 g8e7 f4f5 e7f5 g4f5 f7g7 a1e1 a8e8 e1d1 e8e3 d2e3 g7f8 e3e4 f8e8 d1e1 e8d8 f5f6 d8c8 e4e5 c8b8 f6f7 b8c7 e1f1 c7b7 f7f8k b7c7 e5f6 a6b8 f1e1 b8a6 f8e8 b6b5 Copy 945 to 1773678: 131661559 records from KNOWN/0x09/0x9b930b6a0d858809 -rw-r--r-- 0 Jan 13 17:38 KNOWN/0x09/0x9b930b6a0d858809 Same as above with a6b8 rather than b6b5, etc. I expect roughly 1000 of these "size 0" problems, given how long the hard drive overflow was extant, compared to the total search time for this tree. In fact, the total count seems to be 135. The final node count is only about 41 million (it was over 100 million before transpositions in final rehash reduced it), less than the 2. Bb5 c4 line. The above "size 0" fixing task is done: the verifier now reports 10 loops to be resolved... e3c5.Bb5Qc7.proof.bz2 (66MB) 663d35c19843f64976d0db7d05f5649b $ ./verify PROOFS/e3c5.done 0 VERIFY WIN-TREE FAULT LOOPS Loading win-tree PROOFS/e3c5.done Move list: e2e3 c7c5 f1b5 Tree size is 228501054 [1743mb] Allocating 1961mb for HASH and KNOW arrays With TBs TB_Cache is 1024mb + (1mb) info string Reading directory FLAT/2/ info string Reading directory FLAT/3/ info string Reading directory FLAT/4/ ================================================ tb4 6494628 trans 11464161 terminal 16162269 internal 200874624 forced 102646243 5+6 19360081+20365167 nomoves 9667641 nopieces 5945675 patt 3721966 FICS 3721966 MAXREV 95 OK So of the 228501054 nodes: *) 11464161 are just transposition pointers (recall, moves are stored on arcs). *) 16162269 of them are terminal, and thus 200874624 are internal. *) More than half (102646243) of the internal nodes have forced moves(!) This is quite typical of Losing Chess (the sequences tend to be overly full of Black captures), and one could indeed reduce the file size by exploiting this. *) 6494628 of the terminal positions were in 4-piece TBs, while 9667641 had no moves, with 5945675 have no pieces, and 3721966 being stalemate. *) 19360081 of the positions have 5 pieces, and 20365167 have 6, which gives some idea of the possible savings from larger TBs *) The maximal reversible sequence (ignoring transpositions) is 95 moves, which is what one expects when using the default MAX_REV. This certainly contains gratuitously long move chains, which can be dispelled with a bit of work (I did this for some of the other proofs, getting 1. e3 b5 down to a MAXREV 88 for instance -- there is no *difficulty* in reducing it further, but it is not automated, and thus time-consuming).