Main Date: 18 Aug 2008 11:42:38 From: Guest Subject: Sanny: Some test positions for you Sanny; Here are some standard test positions for you to use with GetClub chess. The classic Bratko-Kopec test and the Win-At-Chess test. There are many other test sets, but these are classics that most people use. The Bratko-Kopec tests are particularly intersting, since they've been around so long and so many programs have done it. They aren't extensive enough, which is why people use additional test sets, but they are classics that most people use. These are done in fairly basic EPD strings. The first part is the FEN description, followed by 'bm' which stands for 'best move', followed by an identification string. (There are more complicated forms of EPD, that can have a move to avoid or multiple acceptable moves, etc. But these are fairly simple ones for you.) FEN starts at A8 and goes across to H8, then A7-H7, etc. Lowercase is black. Uppercase is white. Numbers are how many blank squares. Slashes indicate a new row. This is followed by w/b for side to move, followed by Castling (K=Kingside, Q=Queenside. Uppercase is white, lower case is black. - means no castling status. Kkq would mean White kingside, black bothsides. This is followed by the enpassant square. - means no enpassant possible. These are optionally follwed by half move clock & full move clock. You wont have that in these tests. Simply feed each position into GetClub and have it search, then compare the result, and report the results. Try searches for 5 seconds, 10 seconds and 30 seconds. A test script is easy to do. Or you can program the testing stuff into the program itself. That's what most people do because it makes testing easy that way. You just say "epdtest filename" and it grabs the test file, runs the tests, saves the results to a file and when you come back the results are ready for you. No human participation required. (Note: These tests have gotten a lot of research done on them. As a result, there are some who disagree with the results for various moves. However, the standard results are 'good enough' at this stage. No program gets all the right answers at the quicker time controls (without being specifically tuned to do so), so a few positions with different moves aren't significant right now.) Here are the classic Bratko-Kopec tests. ****Begin 1k1r4/pp1b1R2/3q2pp/4p3/2B5/4Q3/PPP2B2/2K5 b - - bm Qd1+; id "BK.01"; 3r1k2/4npp1/1ppr3p/p6P/P2PPPP1/1NR5/5K2/2R5 w - - bm d5; id "BK.02"; 2q1rr1k/3bbnnp/p2p1pp1/2pPp3/PpP1P1P1/1P2BNNP/2BQ1PRK/7R b - - bm f5; id "BK.03"; rnbqkb1r/p3pppp/1p6/2ppP3/3N4/2P5/PPP1QPPP/R1B1KB1R w KQkq - bm e6; id "BK.04"; r1b2rk1/2q1b1pp/p2ppn2/1p6/3QP3/1BN1B3/PPP3PP/R4RK1 w - - bm Nd5 a4; id "BK.05"; 2r3k1/pppR1pp1/4p3/4P1P1/5P2/1P4K1/P1P5/8 w - - bm g6; id "BK.06"; 1nk1r1r1/pp2n1pp/4p3/q2pPp1N/b1pP1P2/B1P2R2/2P1B1PP/R2Q2K1 w - - bm Nf6; id "BK.07"; 4b3/p3kp2/6p1/3pP2p/2pP1P2/4K1P1/P3N2P/8 w - - bm f5; id "BK.08"; 2kr1bnr/pbpq4/2n1pp2/3p3p/3P1P1B/2N2N1Q/PPP3PP/2KR1B1R w - - bm f5; id "BK.09"; 3rr1k1/pp3pp1/1qn2np1/8/3p4/PP1R1P2/2P1NQPP/R1B3K1 b - - bm Ne5; id "BK.10"; 2r1nrk1/p2q1ppp/bp1p4/n1pPp3/P1P1P3/2PBB1N1/4QPPP/R4RK1 w - - bm f4; id "BK.11"; r3r1k1/ppqb1ppp/8/4p1NQ/8/2P5/PP3PPP/R3R1K1 b - - bm Bf5; id "BK.12"; r2q1rk1/4bppp/p2p4/2pP4/3pP3/3Q4/PP1B1PPP/R3R1K1 w - - bm b4; id "BK.13"; rnb2r1k/pp2p2p/2pp2p1/q2P1p2/8/1Pb2NP1/PB2PPBP/R2Q1RK1 w - - bm Qd2 Qe1; id "BK.14"; 2r3k1/1p2q1pp/2b1pr2/p1pp4/6Q1/1P1PP1R1/P1PN2PP/5RK1 w - - bm Qxg7+; id "BK.15"; r1bqkb1r/4npp1/p1p4p/1p1pP1B1/8/1B6/PPPN1PPP/R2Q1RK1 w kq - bm Ne4; id "BK.16"; r2q1rk1/1ppnbppp/p2p1nb1/3Pp3/2P1P1P1/2N2N1P/PPB1QP2/R1B2RK1 b - - bm h5; id "BK.17"; r1bq1rk1/pp2ppbp/2np2p1/2n5/P3PP2/N1P2N2/1PB3PP/R1B1QRK1 b - - bm Nb3; id "BK.18"; 3rr3/2pq2pk/p2p1pnp/8/2QBPP2/1P6/P5PP/4RRK1 b - - bm Rxe4; id "BK.19"; r4k2/pb2bp1r/1p1qp2p/3pNp2/3P1P2/2N3P1/PPP1Q2P/2KRR3 w - - bm g4; id "BK.20"; 3rn2k/ppb2rpp/2ppqp2/5N2/2P1P3/1P5Q/PB3PPP/3RR1K1 w - - bm Nh6; id "BK.21"; 2r2rk1/1bqnbpp1/1p1ppn1p/pP6/N1P1P3/P2B1N1P/1B2QPP1/R2R2K1 b - - bm Bxe4; id "BK.22"; r1bqk2r/pp2bppp/2p5/3pP3/P2Q1P2/2N1B3/1PP3PP/R4RK1 b kq - bm f6; id "BK.23"; r2qnrnk/p2b2b1/1p1p2pp/2pPpp2/1PP1P3/PRNBB3/3QNPPP/5RK1 w - - bm f4; id "BK.24"; ****End Here are the Win At Chess positions **Begin 2rr3k/pp3pp1/1nnqbN1p/3pN3/2pP4/2P3Q1/PPB4P/R4RK1 w - - bm Qg6; id "WAC.001"; 8/7p/5k2/5p2/p1p2P2/Pr1pPK2/1P1R3P/8 b - - bm Rxb2; id "WAC.002"; 5rk1/1ppb3p/p1pb4/6q1/3P1p1r/2P1R2P/PP1BQ1P1/5RKN w - - bm Rg3; id "WAC.003"; r1bq2rk/pp3pbp/2p1p1pQ/7P/3P4/2PB1N2/PP3PPR/2KR4 w - - bm Qxh7+; id "WAC.004"; 5k2/6pp/p1qN4/1p1p4/3P4/2PKP2Q/PP3r2/3R4 b - - bm Qc4+; id "WAC.005"; 7k/p7/1R5K/6r1/6p1/6P1/8/8 w - - bm Rb7; id "WAC.006"; rnbqkb1r/pppp1ppp/8/4P3/6n1/7P/PPPNPPP1/R1BQKBNR b KQkq - bm Ne3; id "WAC.007"; r4q1k/p2bR1rp/2p2Q1N/5p2/5p2/2P5/PP3PPP/R5K1 w - - bm Rf7; id "WAC.008"; 3q1rk1/p4pp1/2pb3p/3p4/6Pr/1PNQ4/P1PB1PP1/4RRK1 b - - bm Bh2+; id "WAC.009"; 2br2k1/2q3rn/p2NppQ1/2p1P3/Pp5R/4P3/1P3PPP/3R2K1 w - - bm Rxh7; id "WAC.010"; r1b1kb1r/3q1ppp/pBp1pn2/8/Np3P2/5B2/PPP3PP/R2Q1RK1 w kq - bm Bxc6; id "WAC.011"; 4k1r1/2p3r1/1pR1p3/3pP2p/3P2qP/P4N2/1PQ4P/5R1K b - - bm Qxf3+; id "WAC.012"; 5rk1/pp4p1/2n1p2p/2Npq3/2p5/6P1/P3P1BP/R4Q1K w - - bm Qxf8+; id "WAC.013"; r2rb1k1/pp1q1p1p/2n1p1p1/2bp4/5P2/PP1BPR1Q/1BPN2PP/R5K1 w - - bm Qxh7+; id "WAC.014"; 1R6/1brk2p1/4p2p/p1P1Pp2/P7/6P1/1P4P1/2R3K1 w - - bm Rxb7; id "WAC.015"; r4rk1/ppp2ppp/2n5/2bqp3/8/P2PB3/1PP1NPPP/R2Q1RK1 w - - bm Nc3; id "WAC.016"; 1k5r/pppbn1pp/4q1r1/1P3p2/2NPp3/1QP5/P4PPP/R1B1R1K1 w - - bm Ne5; id "WAC.017"; R7/P4k2/8/8/8/8/r7/6K1 w - - bm Rh8; id "WAC.018"; r1b2rk1/ppbn1ppp/4p3/1QP4q/3P4/N4N2/5PPP/R1B2RK1 w - - bm c6; id "WAC.019"; r2qkb1r/1ppb1ppp/p7/4p3/P1Q1P3/2P5/5PPP/R1B2KNR b kq - bm Bb5; id "WAC.020"; 5rk1/1b3p1p/pp3p2/3n1N2/1P6/P1qB1PP1/3Q3P/4R1K1 w - - bm Qh6; id "WAC.021"; r1bqk2r/ppp1nppp/4p3/n5N1/2BPp3/P1P5/2P2PPP/R1BQK2R w KQkq - bm Ba2 Nxf7; id "WAC.022"; r3nrk1/2p2p1p/p1p1b1p1/2NpPq2/3R4/P1N1Q3/1PP2PPP/4R1K1 w - - bm g4; id "WAC.023"; 6k1/1b1nqpbp/pp4p1/5P2/1PN5/4Q3/P5PP/1B2B1K1 b - - bm Bd4; id "WAC.024"; 3R1rk1/8/5Qpp/2p5/2P1p1q1/P3P3/1P2PK2/8 b - - bm Qh4+; id "WAC.025"; 3r2k1/1p1b1pp1/pq5p/8/3NR3/2PQ3P/PP3PP1/6K1 b - - bm Bf5; id "WAC.026"; 7k/pp4np/2p3p1/3pN1q1/3P4/Q7/1r3rPP/2R2RK1 w - - bm Qf8+; id "WAC.027"; 1r1r2k1/4pp1p/2p1b1p1/p3R3/RqBP4/4P3/1PQ2PPP/6K1 b - - bm Qe1+; id "WAC.028"; r2q2k1/pp1rbppp/4pn2/2P5/1P3B2/6P1/P3QPBP/1R3RK1 w - - bm c6; id "WAC.029"; 1r3r2/4q1kp/b1pp2p1/5p2/pPn1N3/6P1/P3PPBP/2QRR1K1 w - - bm Nxd6; id "WAC.030"; rb3qk1/pQ3ppp/4p3/3P4/8/1P3N2/1P3PPP/3R2K1 w - - bm Qxa8 d6 dxe6; id "WAC.031"; 6k1/p4p1p/1p3np1/2q5/4p3/4P1N1/PP3PPP/3Q2K1 w - - bm Qd8+; id "WAC.032"; 8/p1q2pkp/2Pr2p1/8/P3Q3/6P1/5P1P/2R3K1 w - - bm Qe5+ Qf4; id "WAC.033"; 7k/1b1r2p1/p6p/1p2qN2/3bP3/3Q4/P5PP/1B1R3K b - - bm Bg1; id "WAC.034"; r3r2k/2R3pp/pp1q1p2/8/3P3R/7P/PP3PP1/3Q2K1 w - - bm Rxh7+; id "WAC.035"; 3r4/2p1rk2/1pQq1pp1/7p/1P1P4/P4P2/6PP/R1R3K1 b - - bm Re1+; id "WAC.036"; 2r5/2rk2pp/1pn1pb2/pN1p4/P2P4/1N2B3/nPR1KPPP/3R4 b - - bm Nxd4+; id "WAC.037"; 4k3/p4prp/1p6/2b5/8/2Q3P1/P2R1PKP/4q3 w - - bm Rd8+; id "WAC.038"; r1br2k1/pp2bppp/2nppn2/8/2P1PB2/2N2P2/PqN1B1PP/R2Q1R1K w - - bm Na4; id "WAC.039"; 3r1r1k/1p4pp/p4p2/8/1PQR4/6Pq/P3PP2/2R3K1 b - - bm Rc8; id "WAC.040"; 1k6/5RP1/1P6/1K6/6r1/8/8/8 w - - bm Ka5 Kc5; id "WAC.041"; r1b1r1k1/pp1n1pbp/1qp3p1/3p4/1B1P4/Q3PN2/PP2BPPP/R4RK1 w - - bm Ba5; id "WAC.042"; r2q3k/p2P3p/1p3p2/3QP1r1/8/B7/P5PP/2R3K1 w - - bm Be7 Qxa8; id "WAC.043"; 3rb1k1/pq3pbp/4n1p1/3p4/2N5/2P2QB1/PP3PPP/1B1R2K1 b - - bm dxc4; id "WAC.044"; 7k/2p1b1pp/8/1p2P3/1P3r2/2P3Q1/1P5P/R4qBK b - - bm Qxa1; id "WAC.045"; r1bqr1k1/pp1nb1p1/4p2p/3p1p2/3P4/P1N1PNP1/1PQ2PP1/3RKB1R w K - bm Nb5; id "WAC.046"; r1b2rk1/pp2bppp/2n1pn2/q5B1/2BP4/2N2N2/PP2QPPP/2R2RK1 b - - bm Nxd4; id "WAC.047"; 1rbq1rk1/p1p1bppp/2p2n2/8/Q1BP4/2N5/PP3PPP/R1B2RK1 b - - bm Rb4; id "WAC.048"; 2b3k1/4rrpp/p2p4/2pP2RQ/1pP1Pp1N/1P3P1P/1q6/6RK w - - bm Qxh7+; id "WAC.049"; k4r2/1R4pb/1pQp1n1p/3P4/5p1P/3P2P1/r1q1R2K/8 w - - bm Rxb6+; id "WAC.050"; r1bq1r2/pp4k1/4p2p/3pPp1Q/3N1R1P/2PB4/6P1/6K1 w - - bm Rg4+; id "WAC.051"; r1k5/1p3q2/1Qpb4/3N1p2/5Pp1/3P2Pp/PPPK3P/4R3 w - - bm Re7; id "WAC.052"; 6k1/6p1/p7/3Pn3/5p2/4rBqP/P4RP1/5QK1 b - - bm Re1; id "WAC.053"; r3kr2/1pp4p/1p1p4/7q/4P1n1/2PP2Q1/PP4P1/R1BB2K1 b q - bm Qh1+; id "WAC.054"; r3r1k1/pp1q1pp1/4b1p1/3p2B1/3Q1R2/8/PPP3PP/4R1K1 w - - bm Qxg7+; id "WAC.055"; r1bqk2r/pppp1ppp/5n2/2b1n3/4P3/1BP3Q1/PP3PPP/RNB1K1NR b KQkq - bm Bxf2+; id "WAC.056"; r3q1kr/ppp5/3p2pQ/8/3PP1b1/5R2/PPP3P1/5RK1 w - - bm Rf8+; id "WAC.057"; 8/8/2R5/1p2qp1k/1P2r3/2PQ2P1/5K2/8 w - - bm Qd1+; id "WAC.058"; r1b2rk1/2p1qnbp/p1pp2p1/5p2/2PQP3/1PN2N1P/PB3PP1/3R1RK1 w - - bm Nd5; id "WAC.059"; rn1qr1k1/1p2np2/2p3p1/8/1pPb4/7Q/PB1P1PP1/2KR1B1R w - - bm Qh8+; id "WAC.060"; 3qrbk1/ppp1r2n/3pP2p/3P4/2P4P/1P3Q2/PB6/R4R1K w - - bm Qf7+; id "WAC.061"; 6r1/3Pn1qk/p1p1P1rp/2Q2p2/2P5/1P4P1/P3R2P/5RK1 b - - bm Rxg3+; id "WAC.062"; r1brnbk1/ppq2pp1/4p2p/4N3/3P4/P1PB1Q2/3B1PPP/R3R1K1 w - - bm Nxf7; id "WAC.063"; 8/6pp/3q1p2/3n1k2/1P6/3NQ2P/5PP1/6K1 w - - bm g4+; id "WAC.064"; 1r1r1qk1/p2n1p1p/bp1Pn1pQ/2pNp3/2P2P1N/1P5B/P6P/3R1RK1 w - - bm Ne7+; id "WAC.065"; 1k1r2r1/ppq5/1bp4p/3pQ3/8/2P2N2/PP4P1/R4R1K b - - bm Qxe5; id "WAC.066"; 3r2k1/p2q4/1p4p1/3rRp1p/5P1P/6PK/P3R3/3Q4 w - - bm Rxd5; id "WAC.067"; 6k1/5ppp/1q6/2b5/8/2R1pPP1/1P2Q2P/7K w - - bm Qxe3; id "WAC.068"; 2k5/pppr4/4R3/4Q3/2pp2q1/8/PPP2PPP/6K1 w - - bm f3 h3; id "WAC.069"; 2kr3r/pppq1ppp/3p1n2/bQ2p3/1n1PP3/1PN1BN1P/1PP2PP1/2KR3R b - - bm Na2+; id "WAC.070"; 2kr3r/pp1q1ppp/5n2/1Nb5/2Pp1B2/7Q/P4PPP/1R3RK1 w - - bm Nxa7+; id "WAC.071"; r3r1k1/pp1n1ppp/2p5/4Pb2/2B2P2/B1P5/P5PP/R2R2K1 w - - bm e6; id "WAC.072"; r1q3rk/1ppbb1p1/4Np1p/p3pP2/P3P3/2N4R/1PP1Q1PP/3R2K1 w - - bm Qd2; id "WAC.073"; 5r1k/pp4pp/2p5/2b1P3/4Pq2/1PB1p3/P3Q1PP/3N2K1 b - - bm Qf1+; id "WAC.074"; r3r1k1/pppq1ppp/8/8/1Q4n1/7P/PPP2PP1/RNB1R1K1 b - - bm Qd6; id "WAC.075"; r1b1qrk1/2p2ppp/pb1pnn2/1p2pNB1/3PP3/1BP5/PP2QPPP/RN1R2K1 w - - bm Bxf6; id "WAC.076"; 3r2k1/ppp2ppp/6q1/b4n2/3nQB2/2p5/P4PPP/RN3RK1 b - - bm Ng3; id "WAC.077"; r2q3r/ppp2k2/4nbp1/5Q1p/2P1NB2/8/PP3P1P/3RR1K1 w - - bm Ng5+; id "WAC.078"; r3k2r/pbp2pp1/3b1n2/1p6/3P3p/1B2N1Pq/PP1PQP1P/R1B2RK1 b kq - bm Qxh2+; id "WAC.079"; r4rk1/p1B1bpp1/1p2pn1p/8/2PP4/3B1P2/qP2QP1P/3R1RK1 w - - bm Ra1; id "WAC.080"; r4rk1/1bR1bppp/4pn2/1p2N3/1P6/P3P3/4BPPP/3R2K1 b - - bm Bd6; id "WAC.081"; 3rr1k1/pp3pp1/4b3/8/2P1B2R/6QP/P3q1P1/5R1K w - - bm Bh7+; id "WAC.082"; 3rr1k1/ppqbRppp/2p5/8/3Q1n2/2P3N1/PPB2PPP/3R2K1 w - - bm Qxd7; id "WAC.083"; r2q1r1k/2p1b1pp/p1n5/1p1Q1bN1/4n3/1BP1B3/PP3PPP/R4RK1 w - - bm Qg8+; id "WAC.084"; kr2R3/p4r2/2pq4/2N2p1p/3P2p1/Q5P1/5P1P/5BK1 w - - bm Na6; id "WAC.085"; 8/p7/1ppk1n2/5ppp/P1PP4/2P1K1P1/5N1P/8 b - - bm Ng4+; id "WAC.086"; 8/p3k1p1/4r3/2ppNpp1/PP1P4/2P3KP/5P2/8 b - - bm Rxe5; id "WAC.087"; r6k/p1Q4p/2p1b1rq/4p3/B3P3/4P3/PPP3P1/4RRK1 b - - bm Rxg2+; id "WAC.088"; 1r3b1k/p4rpp/4pp2/3q4/2ppbPPQ/6RK/PP5P/2B1NR2 b - - bm g5; id "WAC.089"; 3qrrk1/1pp2pp1/1p2bn1p/5N2/2P5/P1P3B1/1P4PP/2Q1RRK1 w - - bm Nxg7; id "WAC.090"; 2qr2k1/4b1p1/2p2p1p/1pP1p3/p2nP3/PbQNB1PP/1P3PK1/4RB2 b - - bm Be6; id "WAC.091"; r4rk1/1p2ppbp/p2pbnp1/q7/3BPPP1/2N2B2/PPP4P/R2Q1RK1 b - - bm Bxg4; id "WAC.092"; r1b1k1nr/pp3pQp/4pq2/3pn3/8/P1P5/2P2PPP/R1B1KBNR w KQkq - bm Bh6; id "WAC.093"; 8/k7/p7/3Qp2P/n1P5/3KP3/1q6/8 b - - bm e4+; id "WAC.094"; 2r5/1r6/4pNpk/3pP1qp/8/2P1QP2/5PK1/R7 w - - bm Ng4+; id "WAC.095"; r1b4k/ppp2Bb1/6Pp/3pP3/1qnP1p1Q/8/PPP3P1/1K1R3R w - - bm Qd8+; id "WAC.096"; 6k1/5p2/p5np/4B3/3P4/1PP1q3/P3r1QP/6RK w - - bm Qa8+; id "WAC.097"; 1r3rk1/5pb1/p2p2p1/Q1n1q2p/1NP1P3/3p1P1B/PP1R3P/1K2R3 b - - bm Nxe4; id "WAC.098"; r1bq1r1k/1pp1Np1p/p2p2pQ/4R3/n7/8/PPPP1PPP/R1B3K1 w - - bm Rh5; id "WAC.099"; 8/k1b5/P4p2/1Pp2p1p/K1P2P1P/8/3B4/8 w - - bm b6+; id "WAC.100"; 5rk1/p5pp/8/8/2Pbp3/1P4P1/7P/4RN1K b - - bm Bc3; id "WAC.101"; 2Q2n2/2R4p/1p1qpp1k/8/3P3P/3B2P1/5PK1/r7 w - - bm Qxf8+; id "WAC.102"; 6k1/2pb1r1p/3p1PpQ/p1nPp3/1q2P3/2N2P2/PrB5/2K3RR w - - bm Qxg6+; id "WAC.103"; b4r1k/pq2rp2/1p1bpn1p/3PN2n/2P2P2/P2B3K/1B2Q2N/3R2R1 w - - bm Qxh5; id "WAC.104"; r2r2k1/pb3ppp/1p1bp3/7q/3n2nP/PP1B2P1/1B1N1P2/RQ2NRK1 b - - bm Qxh4; id "WAC.105"; 4rrk1/pppb4/7p/3P2pq/3Qn3/P5P1/1PP4P/R3RNNK b - - bm Nf2+; id "WAC.106"; 5n2/pRrk2p1/P4p1p/4p3/3N4/5P2/6PP/6K1 w - - bm Nb5; id "WAC.107"; r5k1/1q4pp/2p5/p1Q5/2P5/5R2/4RKPP/r7 w - - bm Qe5; id "WAC.108"; rn2k1nr/pbp2ppp/3q4/1p2N3/2p5/QP6/PB1PPPPP/R3KB1R b KQkq - bm c3; id "WAC.109"; 2kr4/bp3p2/p2p2b1/P7/2q5/1N4B1/1PPQ2P1/2KR4 b - - bm Be3; id "WAC.110"; 6k1/p5p1/5p2/2P2Q2/3pN2p/3PbK1P/7P/6q1 b - - bm Qf1+; id "WAC.111"; r4kr1/ppp5/4bq1b/7B/2PR1Q1p/2N3P1/PP3P1P/2K1R3 w - - bm Rxe6; id "WAC.112"; rnbqkb1r/1p3ppp/5N2/1p2p1B1/2P5/8/PP2PPPP/R2QKB1R b KQkq - bm Qxf6; id "WAC.113"; r1b1rnk1/1p4pp/p1p2p2/3pN2n/3P1PPq/2NBPR1P/PPQ5/2R3K1 w - - bm Bxh7+; id "WAC.114"; 4N2k/5rpp/1Q6/p3q3/8/P5P1/1P3P1P/5K2 w - - bm Nd6; id "WAC.115"; r2r2k1/2p2ppp/p7/1p2P1n1/P6q/5P2/1PB1QP1P/R5RK b - - bm Rd2; id "WAC.116"; 3r1rk1/q4ppp/p1Rnp3/8/1p6/1N3P2/PP3QPP/3R2K1 b - - bm Ne4; id "WAC.117"; r5k1/pb2rpp1/1p6/2p4q/5R2/2PB2Q1/P1P3PP/5R1K w - - bm Rh4; id "WAC.118"; r2qr1k1/p1p2ppp/2p5/2b5/4nPQ1/3B4/PPP3PP/R1B2R1K b - - bm Qxd3; id "WAC.119"; r4rk1/1bn2qnp/3p1B1Q/p2P1pP1/1pp5/5N1P/PPB2P2/2KR3R w - - bm g6; id "WAC.120"; 6k1/5p1p/2bP2pb/4p3/2P5/1p1pNPPP/1P1Q1BK1/1q6 b - - bm Bxf3+; id "WAC.121"; 1k6/ppp4p/1n2pq2/1N2Rb2/2P2Q2/8/P4KPP/3r1B2 b - - bm Rxf1+; id "WAC.122"; 6k1/1b2rp2/1p4p1/3P4/PQ4P1/2N2q2/5P2/3R2K1 b - - bm Bxd5 Rc7; id "WAC.123"; 6k1/3r4/2R5/P5P1/1P4p1/8/4rB2/6K1 b - - bm g3; id "WAC.124"; r1bqr1k1/pp3ppp/1bp5/3n4/3B4/2N2P1P/PPP1B1P1/R2Q1RK1 b - - bm Bxd4+; id "WAC.125"; r5r1/pQ5p/1qp2R2/2k1p3/4P3/2PP4/P1P3PP/6K1 w - - bm Rxc6+; id "WAC.126"; 2k4r/1pr1n3/p1p1q2p/5pp1/3P1P2/P1P1P3/1R2Q1PP/1RB3K1 w - - bm Rxb7; id "WAC.127"; 6rk/1pp2Qrp/3p1B2/1pb1p2R/3n1q2/3P4/PPP3PP/R6K w - - bm Qg6; id "WAC.128"; 3r1r1k/1b2b1p1/1p5p/2p1Pp2/q1B2P2/4P2P/1BR1Q2K/6R1 b - - bm Bf3; id "WAC.129"; 6k1/1pp3q1/5r2/1PPp4/3P1pP1/3Qn2P/3B4/4R1K1 b - - bm Qh6 Qh8; id "WAC.130"; 2rq1bk1/p4p1p/1p4p1/3b4/3B1Q2/8/P4PpP/3RR1K1 w - - bm Re8; id "WAC.131"; 4r1k1/5bpp/2p5/3pr3/8/1B3pPq/PPR2P2/2R2QK1 b - - bm Re1; id "WAC.132"; r1b1k2r/1pp1q2p/p1n3p1/3QPp2/8/1BP3B1/P5PP/3R1RK1 w kq - bm Bh4; id "WAC.133"; 3r2k1/p6p/2Q3p1/4q3/2P1p3/P3Pb2/1P3P1P/2K2BR1 b - - bm Rd1+; id "WAC.134"; 3r1r1k/N2qn1pp/1p2np2/2p5/2Q1P2N/3P4/PP4PP/3R1RK1 b - - bm Nd4; id "WAC.135"; 6kr/1q2r1p1/1p2N1Q1/5p2/1P1p4/6R1/7P/2R3K1 w - - bm Rc8+; id "WAC.136"; 3b1rk1/1bq3pp/5pn1/1p2rN2/2p1p3/2P1B2Q/1PB2PPP/R2R2K1 w - - bm Rd7; id "WAC.137"; r1bq3r/ppppR1p1/5n1k/3P4/6pP/3Q4/PP1N1PP1/5K1R w - - bm h5; id "WAC.138"; rnb3kr/ppp2ppp/1b6/3q4/3pN3/Q4N2/PPP2KPP/R1B1R3 w - - bm Nf6+; id "WAC.139"; r2b1rk1/pq4p1/4ppQP/3pB1p1/3P4/2R5/PP3PP1/5RK1 w - - bm Rc7; id "WAC.140"; 4r1k1/p1qr1p2/2pb1Bp1/1p5p/3P1n1R/1B3P2/PP3PK1/2Q4R w - - bm Qxf4; id "WAC.141"; r2q3n/ppp2pk1/3p4/5Pr1/2NP1Qp1/2P2pP1/PP3K2/4R2R w - - bm Re8 f6+; id "WAC.142"; 5b2/pp2r1pk/2pp1pRp/4rP1N/2P1P3/1P4QP/P3q1P1/5R1K w - - bm Rxh6+; id "WAC.143"; r2q1rk1/pp3ppp/2p2b2/8/B2pPPb1/7P/PPP1N1P1/R2Q1RK1 b - - bm d3; id "WAC.144"; r1bq4/1p4kp/3p1n2/p4pB1/2pQ4/8/1P4PP/4RRK1 w - - bm Re8; id "WAC.145"; 8/8/2Kp4/3P1B2/2P2k2/5p2/8/8 w - - bm Bc8; id "WAC.146"; r2r2k1/ppqbppbp/2n2np1/2pp4/6P1/1P1PPNNP/PBP2PB1/R2QK2R b KQ - bm Nxg4; id "WAC.147"; 2r1k3/6pr/p1nBP3/1p3p1p/2q5/2P5/P1R4P/K2Q2R1 w - - bm Rxg7; id "WAC.148"; 6k1/6p1/2p4p/4Pp2/4b1qP/2Br4/1P2RQPK/8 b - - bm Bxg2; id "WAC.149"; r3r1k1/5p2/pQ1b2pB/1p6/4p3/6P1/Pq2BP1P/2R3K1 b - - bm Ba3 Bf8 e3; id "WAC.150"; 8/3b2kp/4p1p1/pr1n4/N1N4P/1P4P1/1K3P2/3R4 w - - bm Nc3; id "WAC.151"; 1br2rk1/1pqb1ppp/p3pn2/8/1P6/P1N1PN1P/1B3PP1/1QRR2K1 w - - bm Ne4; id "WAC.152"; 2r3k1/q4ppp/p3p3/pnNp4/2rP4/2P2P2/4R1PP/2R1Q1K1 b - - bm Nxd4; id "WAC.153"; r1b2rk1/2p2ppp/p7/1p6/3P3q/1BP3bP/PP3QP1/RNB1R1K1 w - - bm Qxf7+; id "WAC.154"; 5bk1/1rQ4p/5pp1/2pP4/3n1PP1/7P/1q3BB1/4R1K1 w - - bm d6; id "WAC.155"; r1b1qN1k/1pp3p1/p2p3n/4p1B1/8/1BP4Q/PP3KPP/8 w - - bm Qxh6+; id "WAC.156"; 5rk1/p4ppp/2p1b3/3Nq3/4P1n1/1p1B2QP/1PPr2P1/1K2R2R w - - bm Ne7+; id "WAC.157"; 5rk1/n1p1R1bp/p2p4/1qpP1QB1/7P/2P3P1/PP3P2/6K1 w - - bm Rxg7+; id "WAC.158"; r1b2r2/5P1p/ppn3pk/2p1p1Nq/1bP1PQ2/3P4/PB4BP/1R3RK1 w - - bm Ne6+; id "WAC.159"; qn1kr2r/1pRbb3/pP5p/P2pP1pP/3N1pQ1/3B4/3B1PP1/R5K1 w - - bm Qxd7+; id "WAC.160"; 3r3k/3r1P1p/pp1Nn3/2pp4/7Q/6R1/Pq4PP/5RK1 w - - bm Qxd8+; id "WAC.161"; r3kbnr/p4ppp/2p1p3/8/Q1B3b1/2N1B3/PP3PqP/R3K2R w KQkq - bm Bd5; id "WAC.162"; 5rk1/2p4p/2p4r/3P4/4p1b1/1Q2NqPp/PP3P1K/R4R2 b - - bm Qg2+; id "WAC.163"; 8/6pp/4p3/1p1n4/1NbkN1P1/P4P1P/1PR3K1/r7 w - - bm Rxc4+; id "WAC.164"; 1r5k/p1p3pp/8/8/4p3/P1P1R3/1P1Q1qr1/2KR4 w - - bm Re2; id "WAC.165"; r3r1k1/5pp1/p1p4p/2Pp4/8/q1NQP1BP/5PP1/4K2R b K - bm d4; id "WAC.166"; 7Q/ppp2q2/3p2k1/P2Ppr1N/1PP5/7R/5rP1/6K1 b - - bm Rxg2+; id "WAC.167"; r3k2r/pb1q1p2/8/2p1pP2/4p1p1/B1P1Q1P1/P1P3K1/R4R2 b kq - bm Qd2+; id "WAC.168"; 5rk1/1pp3bp/3p2p1/2PPp3/1P2P3/2Q1B3/4q1PP/R5K1 b - - bm Bh6; id "WAC.169"; 5r1k/6Rp/1p2p3/p2pBp2/1qnP4/4P3/Q4PPP/6K1 w - - bm Qxc4; id "WAC.170"; 2rq4/1b2b1kp/p3p1p1/1p1nNp2/7P/1B2B1Q1/PP3PP1/3R2K1 w - - bm Bh6+; id "WAC.171"; 5r1k/p5pp/8/1P1pq3/P1p2nR1/Q7/5BPP/6K1 b - - bm Qe1+; id "WAC.172"; 2r1b3/1pp1qrk1/p1n1P1p1/7R/2B1p3/4Q1P1/PP3PP1/3R2K1 w - - bm Qh6+; id "WAC.173"; 2r2rk1/6p1/p3pq1p/1p1b1p2/3P1n2/PP3N2/3N1PPP/1Q2RR1K b - - bm Nxg2; id "WAC.174"; r5k1/pppb3p/2np1n2/8/3PqNpP/3Q2P1/PPP5/R4RK1 w - - bm Nh5; id "WAC.175"; r1bq3r/ppp2pk1/3p1pp1/8/2BbPQ2/2NP2P1/PPP4P/R4R1K b - - bm Rxh2+; id "WAC.176"; r1b3r1/4qk2/1nn1p1p1/3pPp1P/p4P2/1p3BQN/PKPBN3/3R3R b - - bm Qa3+; id "WAC.177"; 3r2k1/p1rn1p1p/1p2pp2/6q1/3PQNP1/5P2/P1P4R/R5K1 w - - bm Nxe6; id "WAC.178"; r1b2r1k/pp4pp/3p4/3B4/8/1QN3Pn/PP3q1P/R3R2K b - - bm Qg1+; id "WAC.179"; r1q2rk1/p3bppb/3p1n1p/2nPp3/1p2P1P1/6NP/PP2QPB1/R1BNK2R b KQ - bm Nxd5; id "WAC.180"; r3k2r/2p2p2/p2p1n2/1p2p3/4P2p/1PPPPp1q/1P5P/R1N2QRK b kq - bm Ng4; id "WAC.181"; r1b2rk1/ppqn1p1p/2n1p1p1/2b3N1/2N5/PP1BP3/1B3PPP/R2QK2R w KQ - bm Qh5; id "WAC.182"; 1r2k1r1/5p2/b3p3/1p2b1B1/3p3P/3B4/PP2KP2/2R3R1 w - - bm Bf6; id "WAC.183"; 4kn2/r4p1r/p3bQ2/q1nNP1Np/1p5P/8/PPP3P1/2KR3R w - - bm Qe7+; id "WAC.184"; 1r1rb1k1/2p3pp/p2q1p2/3PpP1Q/Pp1bP2N/1B5R/1P4PP/2B4K w - - bm Qxh7+; id "WAC.185"; r5r1/p1q2p1k/1p1R2pB/3pP3/6bQ/2p5/P1P1NPPP/6K1 w - - bm Bf8+; id "WAC.186"; 6k1/5p2/p3p3/1p3qp1/2p1Qn2/2P1R3/PP1r1PPP/4R1K1 b - - bm Nh3+; id "WAC.187"; 3RNbk1/pp3p2/4rQpp/8/1qr5/7P/P4P2/3R2K1 w - - bm Qg7+; id "WAC.188"; 3r1k2/1ppPR1n1/p2p1rP1/3P3p/4Rp1N/5K2/P1P2P2/8 w - - bm Re8+; id "WAC.189"; 8/p2b2kp/1q1p2p1/1P1Pp3/4P3/3B2P1/P2Q3P/2Nn3K b - - bm Bh3; id "WAC.190"; 2r1Rn1k/1p1q2pp/p7/5p2/3P4/1B4P1/P1P1QP1P/6K1 w - - bm Qc4; id "WAC.191"; r3k3/ppp2Npp/4Bn2/2b5/1n1pp3/N4P2/PPP3qP/R2QKR2 b Qq - bm Nd3+; id "WAC.192"; 5bk1/p4ppp/Qp6/4B3/1P6/Pq2P1P1/2rr1P1P/R4RK1 b - - bm Qxe3; id "WAC.193"; 5rk1/ppq2ppp/2p5/4bN2/4P3/6Q1/PPP2PPP/3R2K1 w - - bm Nh6+; id "WAC.194"; 3r1rk1/1p3p2/p3pnnp/2p3p1/2P2q2/1P5P/PB2QPPN/3RR1K1 w - - bm g3; id "WAC.195"; rr4k1/p1pq2pp/Q1n1pn2/2bpp3/4P3/2PP1NN1/PP3PPP/R1B1K2R b KQ - bm Nb4; id "WAC.196"; 7k/1p4p1/7p/3P1n2/4Q3/2P2P2/PP3qRP/7K b - - bm Qf1+; id "WAC.197"; 2br2k1/ppp2p1p/4p1p1/4P2q/2P1Bn2/2Q5/PP3P1P/4R1RK b - - bm Rd3; id "WAC.198"; r1br2k1/pp2nppp/2n5/1B1q4/Q7/4BN2/PP3PPP/2R2RK1 w - - bm Bxc6 Rfd1; id "WAC.199"; 2rqrn1k/pb4pp/1p2pp2/n2P4/2P3N1/P2B2Q1/1B3PPP/2R1R1K1 w - - bm Bxf6; id "WAC.200"; 2b2r1k/4q2p/3p2pQ/2pBp3/8/6P1/1PP2P1P/R5K1 w - - bm Ra7; id "WAC.201"; QR2rq1k/2p3p1/3p1pPp/8/4P3/8/P1r3PP/1R4K1 b - - bm Rxa2; id "WAC.202"; r4rk1/5ppp/p3q1n1/2p2NQ1/4n3/P3P3/1B3PPP/1R3RK1 w - - bm Qh6; id "WAC.203"; r1b1qrk1/1p3ppp/p1p5/3Nb3/5N2/P7/1P4PQ/K1R1R3 w - - bm Rxe5; id "WAC.204"; r3rnk1/1pq2bb1/p4p2/3p1Pp1/3B2P1/1NP4R/P1PQB3/2K4R w - - bm Qxg5; id "WAC.205"; 1Qq5/2P1p1kp/3r1pp1/8/8/7P/p4PP1/2R3K1 b - - bm Rc6; id "WAC.206"; r1bq2kr/p1pp1ppp/1pn1p3/4P3/2Pb2Q1/BR6/P4PPP/3K1BNR w - - bm Qxg7+; id "WAC.207"; 3r1bk1/ppq3pp/2p5/2P2Q1B/8/1P4P1/P6P/5RK1 w - - bm Bf7+; id "WAC.208"; 4kb1r/2q2p2/r2p4/pppBn1B1/P6P/6Q1/1PP5/2KRR3 w k - bm Rxe5+; id "WAC.209"; 3r1rk1/pp1q1ppp/3pn3/2pN4/5PP1/P5PQ/1PP1B3/1K1R4 w - - bm Rh1; id "WAC.210"; r1bqrk2/pp1n1n1p/3p1p2/P1pP1P1Q/2PpP1NP/6R1/2PB4/4RBK1 w - - bm Qxf7+; id "WAC.211"; rn1qr2Q/pbppk1p1/1p2pb2/4N3/3P4/2N5/PPP3PP/R4RK1 w - - bm Qxg7+; id "WAC.212"; 3r1r1k/1b4pp/ppn1p3/4Pp1R/Pn5P/3P4/4QP2/1qB1NKR1 w - - bm Rxh7+; id "WAC.213"; r2r2k1/1p2qpp1/1np1p1p1/p3N3/2PPN3/bP5R/4QPPP/4R1K1 w - - bm Ng5; id "WAC.214"; 3r2k1/pb1q1pp1/1p2pb1p/8/3N4/P2QB3/1P3PPP/1Br1R1K1 w - - bm Qh7+; id "WAC.215"; r2qr1k1/1b1nbppp/p3pn2/1p1pN3/3P1B2/2PB1N2/PP2QPPP/R4RK1 w - - bm Nxf7; id "WAC.216"; r3kb1r/1pp3p1/p3bp1p/5q2/3QN3/1P6/PBP3P1/3RR1K1 w kq - bm Qd7+; id "WAC.217"; 6k1/pp5p/2p3q1/6BP/2nPr1Q1/8/PP3R1K/8 w - - bm Bh6; id "WAC.218"; 7k/p4q1p/1pb5/2p5/4B2Q/2P1B3/P6P/7K b - - bm Qf1+; id "WAC.219"; 3rr1k1/ppp2ppp/8/5Q2/4n3/1B5R/PPP1qPP1/5RK1 b - - bm Qxf1+; id "WAC.220"; r3k3/P5bp/2N1bp2/4p3/2p5/6NP/1PP2PP1/3R2K1 w q - bm Rd8+; id "WAC.221"; 2r1r2k/1q3ppp/p2Rp3/2p1P3/6QB/p3P3/bP3PPP/3R2K1 w - - bm Bf6; id "WAC.222"; r1bqk2r/pp3ppp/5n2/8/1b1npB2/2N5/PP1Q2PP/1K2RBNR w kq - bm Nxe4; id "WAC.223"; 5rk1/p1q3pp/1p1r4/2p1pp1Q/1PPn1P2/3B3P/P2R2P1/3R2K1 b - - bm Rh6 e4; id "WAC.224"; 4R3/4q1kp/6p1/1Q3b2/1P1b1P2/6KP/8/8 b - - bm Qh4+; id "WAC.225"; 2b2rk1/p1p4p/2p1p1p1/br2N1Q1/1p2q3/8/PB3PPP/3R1RK1 w - - bm Nf7; id "WAC.226"; 2k1rb1r/ppp3pp/2np1q2/5b2/2B2P2/2P1BQ2/PP1N1P1P/2KR3R b - - bm d5; id "WAC.227"; r4rk1/1bq1bp1p/4p1p1/p2p4/3BnP2/1N1B3R/PPP3PP/R2Q2K1 w - - bm Bxe4; id "WAC.228"; 8/8/8/1p5r/p1p1k1pN/P2pBpP1/1P1K1P2/8 b - - bm Rxh4 b4; id "WAC.229"; 2b5/1r6/2kBp1p1/p2pP1P1/2pP4/1pP3K1/1R3P2/8 b - - bm Rb4; id "WAC.230"; r4rk1/1b1nqp1p/p5p1/1p2PQ2/2p5/5N2/PP3PPP/R1BR2K1 w - - bm Bg5; id "WAC.231"; 1R2rq1k/2p3p1/Q2p1pPp/8/4P3/8/P1r3PP/1R4K1 w - - bm Qb5 Rxe8; id "WAC.232"; 5rk1/p1p2r1p/2pp2p1/4p3/PPPnP3/3Pq1P1/1Q1R1R1P/4NK2 b - - bm Nb3; id "WAC.233"; 2kr1r2/p6p/5Pp1/2p5/1qp2Q1P/7R/PP6/1KR5 w - - bm Rb3; id "WAC.234"; 5r2/1p1RRrk1/4Qq1p/1PP3p1/8/4B3/1b3P1P/6K1 w - - bm Qxf7+ Rxf7+; id "WAC.235"; 1R6/p5pk/4p2p/4P3/8/2r3qP/P3R1b1/4Q1K1 b - - bm Rc1; id "WAC.236"; r5k1/pQp2qpp/8/4pbN1/3P4/6P1/PPr4P/1K1R3R b - - bm Rc1+; id "WAC.237"; 1k1r4/pp1r1pp1/4n1p1/2R5/2Pp1qP1/3P2QP/P4PB1/1R4K1 w - - bm Bxb7; id "WAC.238"; 8/6k1/5pp1/Q6p/5P2/6PK/P4q1P/8 b - - bm Qf1+; id "WAC.239"; 2b4k/p1b2p2/2p2q2/3p1PNp/3P2R1/3B4/P1Q2PKP/4r3 w - - bm Qxc6; id "WAC.240"; 2rq1rk1/pp3ppp/2n2b2/4NR2/3P4/PB5Q/1P4PP/3R2K1 w - - bm Qxh7+; id "WAC.241"; r1b1r1k1/pp1nqp2/2p1p1pp/8/4N3/P1Q1P3/1P3PPP/1BRR2K1 w - - bm Rxd7; id "WAC.242"; 1r3r1k/3p4/1p1Nn1R1/4Pp1q/pP3P1p/P7/5Q1P/6RK w - - bm Qe2; id "WAC.243"; r6r/pp3ppp/3k1b2/2pb4/B4Pq1/2P1Q3/P5PP/1RBR2K1 w - - bm Qxc5+; id "WAC.244"; 4rrn1/ppq3bk/3pPnpp/2p5/2PB4/2NQ1RPB/PP5P/5R1K w - - bm Qxg6+; id "WAC.245"; 6R1/4qp1p/ppr1n1pk/8/1P2P1QP/6N1/P4PP1/6K1 w - - bm Qh5+; id "WAC.246"; 2k1r3/1p2Bq2/p2Qp3/Pb1p1p1P/2pP1P2/2P5/2P2KP1/1R6 w - - bm Rxb5; id "WAC.247"; 5r1k/1p4pp/3q4/3Pp1R1/8/8/PP4PP/4Q1K1 b - - bm Qc5+; id "WAC.248"; r4rk1/pbq2pp1/1ppbpn1p/8/2PP4/1P1Q1N2/PBB2PPP/R3R1K1 w - - bm c5 d5; id "WAC.249"; 1b5k/7P/p1p2np1/2P2p2/PP3P2/4RQ1R/q2r3P/6K1 w - - bm Re8+; id "WAC.250"; k7/p4p2/P1q1b1p1/3p3p/3Q4/7P/5PP1/1R4K1 w - - bm Qe5 Qf4; id "WAC.251"; 1rb1r1k1/p1p2ppp/5n2/2pP4/5P2/2QB4/qNP3PP/2KRB2R b - - bm Re2; id "WAC.252"; k5r1/p4b2/2P5/5p2/3P1P2/4QBrq/P5P1/4R1K1 w - - bm Qe8+; id "WAC.253"; r6k/pp3p1p/2p1bp1q/b3p3/4Pnr1/2PP2NP/PP1Q1PPN/R2B2RK b - - bm Nxh3; id "WAC.254"; 3r3r/p4pk1/5Rp1/3q4/1p1P2RQ/5N2/P1P4P/2b4K w - - bm Rfxg6+; id "WAC.255"; 3r1rk1/1pb1qp1p/2p3p1/p7/P2Np2R/1P5P/1BP2PP1/3Q1BK1 w - - bm Nf5; id "WAC.256"; 4r1k1/pq3p1p/2p1r1p1/2Q1p3/3nN1P1/1P6/P1P2P1P/3RR1K1 w - - bm Rxd4; id "WAC.257"; r3brkn/1p5p/2p2Ppq/2Pp3B/3Pp2Q/4P1R1/6PP/5R1K w - - bm Bxg6; id "WAC.258"; r1bq1rk1/ppp2ppp/2np4/2bN1PN1/2B1P3/3p4/PPP2nPP/R1BQ1K1R w - - bm Qh5; id "WAC.259"; 2r2b1r/p1Nk2pp/3p1p2/N2Qn3/4P3/q6P/P4PP1/1R3K1R w - - bm Qe6+; id "WAC.260"; r5k1/1bp3pp/p2p4/1p6/5p2/1PBP1nqP/1PP3Q1/R4R1K b - - bm Nd4; id "WAC.261"; 6k1/p1B1b2p/2b3r1/2p5/4p3/1PP1N1Pq/P2R1P2/3Q2K1 b - - bm Rh6; id "WAC.262"; rnbqr2k/pppp1Qpp/8/b2NN3/2B1n3/8/PPPP1PPP/R1B1K2R w KQ - bm Qg8+; id "WAC.263"; r2r2k1/1R2qp2/p5pp/2P5/b1PN1b2/P7/1Q3PPP/1B1R2K1 b - - bm Rab8; id "WAC.264"; 2r1k2r/2pn1pp1/1p3n1p/p3PP2/4q2B/P1P5/2Q1N1PP/R4RK1 w k - bm exf6; id "WAC.265"; r3q2r/2p1k1p1/p5p1/1p2Nb2/1P2nB2/P7/2PNQbPP/R2R3K b - - bm Rxh2+; id "WAC.266"; 2r1kb1r/pp3ppp/2n1b3/1q1N2B1/1P2Q3/8/P4PPP/3RK1NR w Kk - bm Nc7+; id "WAC.267"; 2r3kr/ppp2n1p/7B/5q1N/1bp5/2Pp4/PP2RPPP/R2Q2K1 w - - bm Re8+; id "WAC.268"; 2kr2nr/pp1n1ppp/2p1p3/q7/1b1P1B2/P1N2Q1P/1PP1BPP1/R3K2R w KQ - bm axb4; id "WAC.269"; 2r1r1k1/pp1q1ppp/3p1b2/3P4/3Q4/5N2/PP2RPPP/4R1K1 w - - bm Qg4; id "WAC.270"; 2kr4/ppp3Pp/4RP1B/2r5/5P2/1P6/P2p4/3K4 w - - bm Rd6; id "WAC.271"; nrq4r/2k1p3/1p1pPnp1/pRpP1p2/P1P2P2/2P1BB2/1R2Q1P1/6K1 w - - bm Bxc5; id "WAC.272"; 2k4B/bpp1qp2/p1b5/7p/1PN1n1p1/2Pr4/P5PP/R3QR1K b - - bm Ng3+; id "WAC.273"; 8/1p6/p5R1/k7/Prpp4/K7/1NP5/8 w - - bm Rb6; id "WAC.274"; r1b2rk1/1p1n1ppp/p1p2q2/4p3/P1B1Pn2/1QN2N2/1P3PPP/3R1RK1 b - - bm Nxg2 b5; id "WAC.275"; r5k1/pp1RR1pp/1b6/6r1/2p5/B6P/P4qPK/3Q4 w - - bm Qd5+; id "WAC.276"; 1r4r1/p2kb2p/bq2p3/3p1p2/5P2/2BB3Q/PP4PP/3RKR2 b - - bm Rg3 Rxg2; id "WAC.277"; r2qkb1r/pppb2pp/2np1n2/5pN1/2BQP3/2N5/PPP2PPP/R1B1K2R w KQkq - bm Bf7+; id "WAC.278"; r7/4b3/2p1r1k1/1p1pPp1q/1P1P1P1p/PR2NRpP/2Q3K1/8 w - - bm Nxf5; id "WAC.279"; r1r2bk1/5p1p/pn4p1/N2b4/3Pp3/B3P3/2q1BPPP/RQ3RK1 b - - bm Bxa3; id "WAC.280"; 2R5/2R4p/5p1k/6n1/8/1P2QPPq/r7/6K1 w - - bm Rxh7+; id "WAC.281"; 6k1/2p3p1/1p1p1nN1/1B1P4/4PK2/8/2r3b1/7R w - - bm Rh8+; id "WAC.282"; 3q1rk1/4bp1p/1n2P2Q/3p1p2/6r1/Pp2R2N/1B4PP/7K w - - bm Ng5; id "WAC.283"; 3r3k/pp4pp/8/1P6/3N4/Pn2P1qb/1B1Q2B1/2R3K1 w - - bm Nf5; id "WAC.284"; 2rr3k/1b2bppP/p2p1n2/R7/3P4/1qB2P2/1P4Q1/1K5R w - - bm Qxg7+; id "WAC.285"; 3r1k2/1p6/p4P2/2pP2Qb/8/1P1KB3/P6r/8 b - - bm Rxd5+; id "WAC.286"; rn3k1r/pp2bBpp/2p2n2/q5N1/3P4/1P6/P1P3PP/R1BQ1RK1 w - - bm Qh5; id "WAC.287"; r1b2rk1/p4ppp/1p1Qp3/4P2N/1P6/8/P3qPPP/3R1RK1 w - - bm Nf6+; id "WAC.288"; 2r3k1/5p1p/p3q1p1/2n3P1/1p1QP2P/1P4N1/PK6/2R5 b - - bm Qe5; id "WAC.289"; 2k2r2/2p5/1pq5/p1p1n3/P1P2n1B/1R4Pp/2QR4/6K1 b - - bm Ne2+; id "WAC.290"; 5r1k/3b2p1/p6p/1pRpR3/1P1P2q1/P4pP1/5QnP/1B4K1 w - - bm h3; id "WAC.291"; 4r3/1Q1qk2p/p4pp1/3Pb3/P7/6PP/5P2/4R1K1 w - - bm d6+; id "WAC.292"; 1nbq1r1k/3rbp1p/p1p1pp1Q/1p6/P1pPN3/5NP1/1P2PPBP/R4RK1 w - - bm Nfg5; id "WAC.293"; 3r3k/1r3p1p/p1pB1p2/8/p1qNP1Q1/P6P/1P4P1/3R3K w - - bm Bf8 Nf5 Qf4; id "WAC.294"; 4r3/p4r1p/R1p2pp1/1p1bk3/4pNPP/2P1K3/2P2P2/3R4 w - - bm Rxd5+; id "WAC.295"; 3r4/1p2k2p/p1b1p1p1/4Q1Pn/2B3KP/4pP2/PP2R1N1/6q1 b - - bm Rd4+ Rf8; id "WAC.296"; 3r1rk1/p3qp1p/2bb2p1/2p5/3P4/1P6/PBQN1PPP/2R2RK1 b - - bm Bxg2 Bxh2+; id "WAC.297"; 3Q4/p3b1k1/2p2rPp/2q5/4B3/P2P4/7P/6RK w - - bm Qh8+; id "WAC.298"; 1n2rr2/1pk3pp/pNn2p2/2N1p3/8/6P1/PP2PPKP/2RR4 w - - bm Nca4; id "WAC.299"; b2b1r1k/3R1ppp/4qP2/4p1PQ/4P3/5B2/4N1K1/8 w - - bm g6; id "WAC.300"; ****End ----== Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.pronews.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= - Total Privacy via Encryption =---   Date: 28 Aug 2008 00:45:40 From: Simon Krahnke Subject: Re: GetClub Updated Results. * Tony M <tmokonen@yahoo.com > (00:15) schrieb: > I don't think FinalFun 0.1 would be competitive with your program, it > is very basic, with what appears to be a material only evaluation, > with equal moves in order of how they were generated. (I believe, > maybe Simon can confirm this). You got it all right. Actually below the root there is move ordering at all (besides the TT's best move). Since its opening is totally silly, using an external book is mandatory when playing anything that's not POS. And yes, I guess in a match Getclub would win against Finalfun. If Getclub manages to mate it. :-) mfg, simon .... l   Date: 24 Aug 2008 15:43:03 From: Simon Krahnke Subject: Re: GetClub Updated Results. * Tony M <tmokonen@yahoo.com > (02:39) schrieb: > Strength matters not a whit to me. After all, my Tony's Chess is only > 1500ish, yet I still enjoy watching it compete in tournaments like > Chesswar and Le System Du Suisse. I'll just as gleefully download the > latest version of, say, POS as I would the latest version of Fruit. OK, if that's the same POS by Folkert van Heusden we are talking about. I posted some matches against it in the past. You can find them in Google Groups. > Being a weak player, I'd rather play a program that might actually > give me the occasional chance to win. Finalfun gives you that chance every time if you find out how to exploit it's silly opening. > A jar would be fine, though source is always nice. You address is working? Can I send about 200kB there or should I send an URL? mfg, simon ....     Date: 24 Aug 2008 17:03:34 From: Tony M Subject: Re: GetClub Updated Results. On Sun, 24 Aug 2008 15:43:03 +0200, Simon Krahnke <overlord@gmx.li > wrote: >* Tony M <tmokonen@yahoo.com> (02:39) schrieb: > >> Strength matters not a whit to me. After all, my Tony's Chess is only >> 1500ish, yet I still enjoy watching it compete in tournaments like >> Chesswar and Le System Du Suisse. I'll just as gleefully download the >> latest version of, say, POS as I would the latest version of Fruit. > >OK, if that's the same POS by Folkert van Heusden we are talking about. >I posted some matches against it in the past. You can find them in >Google Groups. > That would be the same POS, yes. I mentioned it because it's been posted about in this newsgroup, and it's at or near the bottom of most rating lists. It's kind of an experimental program, it doesn't even have an alpha-beta based search. >> Being a weak player, I'd rather play a program that might actually >> give me the occasional chance to win. > >Finalfun gives you that chance every time if you find out how to >exploit it's silly opening. > >> A jar would be fine, though source is always nice. > >You address is working? Can I send about 200kB there or should I send an >URL? > The address should be working, and Yahoo allows up to, I believe, 10MB per message. Thanks Simon. >mfg, simon .... Tony   Date: 24 Aug 2008 15:11:38 From: Simon Krahnke Subject: Re: GetClub Updated Results. * Guest <none@example.none > (02:31) schrieb: >>>>> But some people don't feel it's a good judge of a good position. Good >>>>> positions have good mobility because they are good positions. Not: >>>>> good positions are good positions because they have good mobility. >>>> >>>> But that actually doesn't matter when all you need is a correlation. >>> >>> The issue is the extra time it takes to do the mobility scoring. >>> >>> Some feel that the time is better spent doing other things. Things that >>> actually measure the 'good position' aspect. >> >> Sure, but that's got nothing too do with the above misconception. > > You were saying "Mobility is good enough because there is a correlation." Well, if there is a correlation. It might be that some bad position show good mobility, too. > I was saying, "So what? It's too expensive to be worth it. Many feel its > better to spend the time doing other stuff instead." That's the difference between not effective and not efficient enough. It easy to step out and proudly declare it's not worth the time. A researcher would benchmark it. :-) >>> I haven't checked to see what the top open source programs do. >>> >>> Pesonally, I don't want to do mobility simply because of the extra time. >>> But I'm rarely concerned about how well my program actually plays. I had >>> more fun just programming it. >> >> Yes, we probably can't beat Rybka and Co. Or even Crafty. So why try. :-) > > If it makes us feel any better, Hyatt can't beat Rybka either. > > He's been doing computer chess 40 years now. He runs on much more extreme > hardware. And he still can't match Rybka etc. > Hyatt has spent so much time doing computer chess, it's a wonder he's found > time to become a professor and actually teach and have a family. I guess that somehow helps him teaching. :-) mfg, simon .... l   Date: 24 Aug 2008 01:37:42 From: Simon Krahnke Subject: Re: GetClub Updated Results. * Guest <none@example.none > (17:49) schrieb: > "Simon Krahnke" <overlord@gmx.li> wrote in message > news:87ljynlw7r.fsf@xts.gnuu.de... >> >>> I've never actually run them or even looked at them. (I don't have a >>> current program, so... (shrug)) >> >> Do you think about starting one? > > I did a couple chess a few years ago, but I 'burned out' on it. > > I reached a point where I didn't want to even think about computer chess. > > Lately, my interest is starting to come back, but I'm not sure if I would > have enough long term interest to actually start from scratch. > > I might take an old one and gut it and refactor it, etc. > > I don't know yet. I've got another project going and I should probably get > done with it before starting anything new. > > >>>> Actually the move Bh2+ is found at depth 3/5 with a score of 1.99 >>>> (there's that error again). >>> >>> Are you using floating point to hold the score? >> >> Of course not. I actually read that thread recently. Too late to add my >> comment to it. :-( > > I was just curious, because some people do prefer to use a float. They more > easily think of adding a quarter pawn as .25. But then there is no centipawn alias 0.01. > There aren't many advantages, though. I'd say there are none. > I guess one of the few is that you can set a score to NaN and some of > the other floating point constants. Not a huge advantage though. You could just as well use special integer values. >>> 3) pawn based mobility. (As if there were only pawns on the board.) >> >> Aka blocked and passed pawns? > > Just pawns in general. As if the board contained only the pawns and the one > piece you are counting the moves for at that particular time. Ah, pawns *and* the piece you are testing. > The idea is that pawns move so rarely that they are the biggest influence in > how many squares a piece can move to. All the other pieces are likely to > move instead of being captured. > > (shrug) > > I have no idea which would be 'best'. Just that a lot of things have been > tried. > > >> >>> But some people don't feel it's a good judge of a good position. Good >>> positions have good mobility because they are good positions. Not: good >>> positions are good positions because they have good mobility. >> >> But that actually doesn't matter when all you need is a correlation. > > The issue is the extra time it takes to do the mobility scoring. > > Some feel that the time is better spent doing other things. Things that > actually measure the 'good position' aspect. Sure, but that's got nothing too do with the above misconception. > I haven't checked to see what the top open source programs do. > > Pesonally, I don't want to do mobility simply because of the extra time. > But I'm rarely concerned about how well my program actually plays. I had > more fun just programming it. Yes, we probably can't beat Rybka and Co. Or even Crafty. So why try. :-) > I'm sure a random number generator isn't going to help a program with a good > evaluator. But if you have a very poor eval (such as just material and a > few minor things), maybe it would help. If you start fresh you usually have no evaluation at all, so it's surely worth a try. You can later do regression test on that. It won't work with mtd(f), but that doesn't work so well in chess anyway. Time to try pvs. mfg, simon .... l     Date: 23 Aug 2008 19:31:16 From: Guest Subject: Re: GetClub Updated Results. "Simon Krahnke" <overlord@gmx.li > wrote in message news:87d4jzl2ux.fsf@xts.gnuu.de... >* Guest <none@example.none> (17:49) schrieb: > >> I was just curious, because some people do prefer to use a float. They >> more >> easily think of adding a quarter pawn as .25. > > But then there is no centipawn alias 0.01. Not everybody works in centipawns. Some people do pawns as a value of 64 instead of 100. So binary fractions work well for them. >> There aren't many advantages, though. > > I'd say there are none. > >> I guess one of the few is that you can set a score to NaN and some of >> the other floating point constants. Not a huge advantage though. > > You could just as well use special integer values. True. But the advantages of NaN etc. is that it stays NaN no matter what you do to it. Not a big advantage no, but it can be useful for setting error conditions or error values and so on. Maybe that's my numerical background showing, though. >>>> But some people don't feel it's a good judge of a good position. Good >>>> positions have good mobility because they are good positions. Not: >>>> good >>>> positions are good positions because they have good mobility. >>> >>> But that actually doesn't matter when all you need is a correlation. >> >> The issue is the extra time it takes to do the mobility scoring. >> >> Some feel that the time is better spent doing other things. Things that >> actually measure the 'good position' aspect. > > Sure, but that's got nothing too do with the above misconception. You were saying "Mobility is good enough because there is a correlation." I was saying, "So what? It's too expensive to be worth it. Many feel its better to spend the time doing other stuff instead." >> I haven't checked to see what the top open source programs do. >> >> Pesonally, I don't want to do mobility simply because of the extra time. >> But I'm rarely concerned about how well my program actually plays. I had >> more fun just programming it. > > Yes, we probably can't beat Rybka and Co. Or even Crafty. So why try. :-) If it makes us feel any better, Hyatt can't beat Rybka either. He's been doing computer chess 40 years now. He runs on much more extreme hardware. And he still can't match Rybka etc. Hyatt has spent so much time doing computer chess, it's a wonder he's found time to become a professor and actually teach and have a family. ----== Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.pronews.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= - Total Privacy via Encryption =---   Date: 24 Aug 2008 01:43:49 From: Simon Krahnke Subject: Re: GetClub Updated Results. * Tony M <tmokonen@yahoo.com > (18:16) schrieb: > On Sat, 23 Aug 2008 04:30:24 +0200, Simon Krahnke <overlord@gmx.li> wrote: > >> Finalfun is a Java program. > > Hi Simon, is Finalfun available for download? I wouldn't mind giving > it a try. Why? It's not really worth the time. Need the source or just the jar file? Everyone wants to have my programs. When I mentioned my simple raytracer over in comp.lang.ruby two people were after it. Must be a star programmer. :- > mfg, simon .... l     Date: 28 Aug 2008 08:48:13 From: Sanny Subject: Re: GetClub Updated Results. On Aug 28, 8:17=A0pm, Tony M <tmoko...@yahoo.com > wrote: > On Thu, 28 Aug 2008 15:16:27 GMT, Tony M <tmoko...@yahoo.com> wrote: > >Liectenstein > > Grr, Liechtenstein. =A0I *really* need sleep. Good night and sweet dreams. Bye Sanny Play Chess at: http://www.GetClub.com/Chess.html     Date: 24 Aug 2008 00:39:30 From: Tony M Subject: Re: GetClub Updated Results. On Sun, 24 Aug 2008 01:43:49 +0200, Simon Krahnke <overlord@gmx.li > wrote: >* Tony M <tmokonen@yahoo.com> (18:16) schrieb: > >> On Sat, 23 Aug 2008 04:30:24 +0200, Simon Krahnke <overlord@gmx.li> wrote: >> >>> Finalfun is a Java program. >> >> Hi Simon, is Finalfun available for download? I wouldn't mind giving >> it a try. > >Why? It's not really worth the time. Need the source or just the jar file? > >Everyone wants to have my programs. When I mentioned my simple raytracer >over in comp.lang.ruby two people were after it. Must be a star >programmer. :-> > >mfg, simon .... l Strength matters not a whit to me. After all, my Tony's Chess is only 1500ish, yet I still enjoy watching it compete in tournaments like Chesswar and Le System Du Suisse. I'll just as gleefully download the latest version of, say, POS as I would the latest version of Fruit. Being a weak player, I'd rather play a program that might actually give me the occasional chance to win. A jar would be fine, though source is always nice. Tony   Date: 23 Aug 2008 15:03:36 From: Simon Krahnke Subject: Re: GetClub Updated Results. * Guest <none@example.none > (05:29) schrieb: >> I think Finalfun scores nada on silent but deadly. > > With just material, I'm not surprised. I didn't actually test that through, so it just means we think the same about that. > I don't know what would be needed for that one, but I'd expect it'd be more > than mobility and a little pawn knowledge. Maybe a few piece square tables? Piece/square tables are actually the simplest thing to do (though hard to do right). We did them in Basicfun at the university course. > I've never actually run them or even looked at them. (I don't have a > current program, so... (shrug)) Do you think about starting one? >>> Most of the mates are shallow enough they'll be solved instantly. Even a >>> Java programs shouldn't need 30 seconds. >> >> Finalfun is a Java program. > > Maybe you ought to offer it to Sanny.... :-) Well, there's Jester. I never looked at it. >> Of course. Finalfun doesn't do *any* reductions (not even null move). So >> that means 3 fully searched plies. > > Because of how you do king captures & check's, you might be detecting it a > move earlier though. > > With the "Wait until the king is captured" method, it can take one extra > plain ply. Only a q-search ply, because it's a capture. > (Check extensions mean you'll still see it, but it'll be counted > as one more ply.) Yeah, but that's the second number. >> Actually the move Bh2+ is found at depth 3/5 with a score of 1.99 >> (there's that error again). > > Are you using floating point to hold the score? Of course not. I actually read that thread recently. Too late to add my comment to it. :-( >> There wasn't even a time limit :-). One game I operated we both had >> implemented XBoard, so the game could run automatically. That was good >> because the other engine took minutes for each move. > > Well then heck, you should have let it run for a full day between moves! 1. No, there some kind of implied time limit. Some thing like "reasonable". 2. That actually doesn't help much in a simple program, the bf is too high. > The Russians weren't happy with the way their program wasn't beating the US > program, so they expanded the search width to full width and let it think > for much longer. The result being their program then won. So much for selective search. :-) >> The only thing I remember about the Smalltalk program is its annoying >> way to enter move. Our own interface had drag&drop. They had a pop-up >> window that asked for name of the start square, then a second window >> popped up, asking for the target square, then a third pop-up window asked >> for confirmation of that move. > > (shudder) > > I guess whoever programed it didn't actually put much thought in playing it. And probably didn't play it much. I did only watch my partners operate it, showing me how annoying it was. > Actually there are several definitions of 'mobility'. > > 1) Legal mobility. > > 2) pseudo-legal mobility. Which kind you use probably is the same as your usual generator. > 3) pawn based mobility. (As if there were only pawns on the board.) Aka blocked and passed pawns? > But some people don't feel it's a good judge of a good position. Good > positions have good mobility because they are good positions. Not: good > positions are good positions because they have good mobility. But that actually doesn't matter when all you need is a correlation. > A few days ago I was going through the forums, saving interesting threads to > my drive and I happened to see it. > > http://www.talkchess.com/forum/viewtopic.php?topic_view=threads&p=205916&t=22731 Thanks! I might try that some day. mfg, simon .... l     Date: 23 Aug 2008 10:49:34 From: Guest Subject: Re: GetClub Updated Results. "Simon Krahnke" <overlord@gmx.li > wrote in message news:87ljynlw7r.fsf@xts.gnuu.de... > >> I've never actually run them or even looked at them. (I don't have a >> current program, so... (shrug)) > > Do you think about starting one? I did a couple chess a few years ago, but I 'burned out' on it. I reached a point where I didn't want to even think about computer chess. Lately, my interest is starting to come back, but I'm not sure if I would have enough long term interest to actually start from scratch. I might take an old one and gut it and refactor it, etc. I don't know yet. I've got another project going and I should probably get done with it before starting anything new. >>> Actually the move Bh2+ is found at depth 3/5 with a score of 1.99 >>> (there's that error again). >> >> Are you using floating point to hold the score? > > Of course not. I actually read that thread recently. Too late to add my > comment to it. :-( I was just curious, because some people do prefer to use a float. They more easily think of adding a quarter pawn as .25. And as long as you work in fractional binary, it'll still be accurate. There aren't many advantages, though. I guess one of the few is that you can set a score to NaN and some of the other floating point constants. Not a huge advantage though. >> The Russians weren't happy with the way their program wasn't beating the >> US >> program, so they expanded the search width to full width and let it think >> for much longer. The result being their program then won. > > So much for selective search. :-) Selective Search was pretty niave back then. There have been a few major selective search programs over the years, but to my knowledge only 4 of them have stood out among their peers at the time. MacHack VI, by Greenblatt of course. Chess 3.6, by Slate & Atkin. Awit by Tony Marsland. Chaos by Swartz & Alexander. Awit & Chaos were the only ones still around in the mid 80's. They weren't massive successes, but they usually did 'middle of the pack' among the other programs. >> 3) pawn based mobility. (As if there were only pawns on the board.) > > Aka blocked and passed pawns? Just pawns in general. As if the board contained only the pawns and the one piece you are counting the moves for at that particular time. The idea is that pawns move so rarely that they are the biggest influence in how many squares a piece can move to. All the other pieces are likely to move instead of being captured. (shrug) I have no idea which would be 'best'. Just that a lot of things have been tried. > >> But some people don't feel it's a good judge of a good position. Good >> positions have good mobility because they are good positions. Not: good >> positions are good positions because they have good mobility. > > But that actually doesn't matter when all you need is a correlation. The issue is the extra time it takes to do the mobility scoring. Some feel that the time is better spent doing other things. Things that actually measure the 'good position' aspect. I haven't checked to see what the top open source programs do. Pesonally, I don't want to do mobility simply because of the extra time. But I'm rarely concerned about how well my program actually plays. I had more fun just programming it. >> A few days ago I was going through the forums, saving interesting threads >> to >> my drive and I happened to see it. >> >> http://www.talkchess.com/forum/viewtopic.php?topic_view=threads&p=205916&t=22731 > > Thanks! I might try that some day. It is really odd. It's something that you would first think couldn't possibly work, but after you read the details and you think about it, you really start to wonder. I guess that's the mark of a researcher. Get a strange idea and actually try it instead of assuming it couldn't work. I wish I had Don Beal's original paper. I suppose I could email him and ask for a copy, but... I'm sure a random number generator isn't going to help a program with a good evaluator. But if you have a very poor eval (such as just material and a few minor things), maybe it would help. Interesting though. ----== Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.pronews.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= - Total Privacy via Encryption =---   Date: 23 Aug 2008 13:27:25 From: Simon Krahnke Subject: Re: Sanny: Some test positions for you * Sanny <softtanks@hotmail.com > (08:35) schrieb: > Though after improvement GetClub scored 44% it missed some Mate > Positions So I revert back to original. > > I will again test in the evening to see if the new score. > > Beginner Solving 39% is good enough. It means Easy Level will sove > arround 60% of them. But that's just a guess, right? You never know, until you test. mfg, simon .... l   Date: 23 Aug 2008 13:24:54 From: Simon Krahnke Subject: Re: Beginner Level Results * Guest <none@example.none > (05:41) schrieb: > The catch is, that if between the repetition positions, your castling > ability changes, like you are in check but you block it instead of moving > your king, then technically your castling rights changed. > > There was a period there where you could not castle. > > It's temporary, but still your rights had changed. Ah, now I get it. mfg, simon .... l   Date: 23 Aug 2008 05:17:34 From: Simon Krahnke Subject: Re: Beginner Level Results * Guest <none@example.none > (03:37) schrieb: > Also, some time back there was a discussion about the wording of the draw by > repetition when castling status changes were involved. Here by castling status you mean what the castling field in FEN specifies. > The way its worded can make it sound like if your castling status changes > even briefly, then it wont be an exact repetition. > > That's occured in a few tournaments too. I guy I know sent me a link about > that. The TD agreed the wording of the rules does certainly make it sound > that way, and that if you interpret it literally then it would be, but that > traditionally chess isn't played that way, so temporary castling status > changes don't effect repetition. So that way you have to ignore castling rights for repetition? > Other TD's can rule their own way, though. If they are more literal minded, > then... I guess most engine programmers are more literally minded on this. After all, it's nice to use the same key for repetition detection and for transposition table lookup. mfg, simon .... l     Date: 22 Aug 2008 22:41:41 From: Guest Subject: Re: Beginner Level Results "Simon Krahnke" <overlord@gmx.li > wrote in message news:874p5cmnch.fsf@xts.gnuu.de... >* Guest <none@example.none> (03:37) schrieb: > >> Also, some time back there was a discussion about the wording of the draw >> by >> repetition when castling status changes were involved. > > Here by castling status you mean what the castling field in FEN specifies. No. Actual castling rights during a game. > >> The way its worded can make it sound like if your castling status changes >> even briefly, then it wont be an exact repetition. >> >> That's occured in a few tournaments too. I guy I know sent me a link >> about >> that. The TD agreed the wording of the rules does certainly make it >> sound >> that way, and that if you interpret it literally then it would be, but >> that >> traditionally chess isn't played that way, so temporary castling status >> changes don't effect repetition. > > So that way you have to ignore castling rights for repetition? Right. At least in between the moves. The thing is, apparently the way the rules are worded is something like this: (I'm going from memory here, so this might not be exact.) Draw by repetition requires that a position to have previously occured with the same position, side to move, and rights. In other words, you have to still be able to castle. The catch is, that if between the repetition positions, your castling ability changes, like you are in check but you block it instead of moving your king, then technically your castling rights changed. There was a period there where you could not castle. It's temporary, but still your rights had changed. The way the rules are supposedly worded is that can be taken to mean even temporary changes in your castling status can void a repeition claim. And apparently the issue has actually come up in some tournaments. Somebody had claimed a repetition but the other person pointed out the castling issue. The one link I was shown said the Tournament Director did rule in favor of the reptition. He agreed that the rules did indeed say that, but that wasn't what it was supposed to mean and that wasn't how chess was normally done. That by tradition, it was a repetition in spite of the wording of the rules. (shrug) Fortunately most of my programs never put that much effort into following the rules. I was always more concerned about having fun programming than getting every single rule exactly right. ----== Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.pronews.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= - Total Privacy via Encryption =---   Date: 23 Aug 2008 04:30:24 From: Simon Krahnke Subject: Re: GetClub Updated Results. * Guest <none@example.none > (00:44) schrieb: > There are testing suites with much more emphesis on positional abilities, > but he's not ready for that. I think Finalfun scores nada on silent but deadly. >> I ran Finalfun 5s on every of the 300 positions and it score 188/300 = >> 62.7%. >> >> 188 of 300 matching moves >> 2008-08-22 22:40:48, Total time: 00:31:22 >> Rated time: 10:31 = 631 Seconds >> >> It spent rarely any time on the hits, they were mostly solved in less than >> 1s. > > Most of the mates are shallow enough they'll be solved instantly. Even a > Java programs shouldn't need 30 seconds. Finalfun is a Java program. > Many of the others are materialistic enough they'll at least get the right > answer without too much effort. > > That leaves a hundred or so that requires some effort. That's obviously the 112 ones Finalfun couldn't solve. :-) >>> You shouldn't be missing any mate-in-2 positions. None. >> >> Finalfun finds them at depth 3. > > Depends on how you count & report them. Of course. Finalfun doesn't do *any* reductions (not even null move). So that means 3 fully searched plies. > Depending on the kind of search extensions you have, some programs can find > mate at a much shallower iterative search depth than others. Some mates end in captures. One can find them in q-search. >> Position 9 is a mate in 5 (Finalfun says so), it's found in 4s at depth >> 5/9. > > Yup. Actually the move Bh2+ is found at depth 3/5 with a score of 1.99 (there's that error again). > I wouldn't expect GC's beginner level to get that or #8, which is mate in 7. > >> Mmpf, all the other engines tell me it's a mate in 4. > > Depends on how it's counted & reported. > > Not all programs even find the shortest mate. Because of the way they > search, they sometimes just find *a* mate rather than the closest one. Yeah, Finalfun obviously missed a shorter mate here. But it found it at depth 5, I would expect an accurate mate score at depth 8. I'm just now trying that. It took 6s now, a video stream in the background in the background probably slows it down :-). But that shows again how timing matters. With the 5s limit it wouldn't reach depth 5 under this conditions. It's too damn slow. I just interrupted and cheat by saying "go infinite searchmoves Bh2+" in the arena debug window. It's much faster now only searching the right move. But it's still at +M5 at depth 9/19. Mmpf. So depth 10/22. Still at +M5. Stop. But what am I hunting? Rerun Shredder 8 on it: +M4, but just 2 plies pv. Let's play them. Still +M4. Wtf? Now it gives a complete pv exactly identical to Finalfun's. Cheater. Now all the engines agree it's a mate in 5.     Date: 28 Aug 2008 23:51:44 From: Simon Krahnke Subject: Re: GetClub Updated Results. * Tony M <tmokonen@yahoo.com > (16:33) schrieb: > I didn't implement analysis mode yet, sorry. The program does not > check for keyboard input during the search. Ah, of course. I do the search in an extra thread. It's quite easy to do in Java. > BookThinker is a utility that comes with the chess engine Thinker. Thanks. mfg, simon .... l     Date: 28 Aug 2008 23:39:07 From: Simon Krahnke Subject: Re: GetClub Updated Results. * Tony M <tmokonen@yahoo.com > (17:16) schrieb: > Sorry, Simon, I missed your first question. No sleep last night. :) > I'm from Vancouver, BC, Canada. Nearly everyone seems to be from the american west coast here. :-) > I actually was going to ask you the same thing, one of your addresses > says Germany, and the other says Liectenstein. Germany is right, Hamburg to be exact. mfg, simon .... l     Date: 23 Aug 2008 16:16:42 From: Tony M Subject: Re: GetClub Updated Results. On Sat, 23 Aug 2008 04:30:24 +0200, Simon Krahnke <overlord@gmx.li > wrote: >* Guest <none@example.none> (00:44) schrieb: > >> There are testing suites with much more emphesis on positional abilities, >> but he's not ready for that. > >I think Finalfun scores nada on silent but deadly. > >>> I ran Finalfun 5s on every of the 300 positions and it score 188/300 = >>> 62.7%. >>> >>> 188 of 300 matching moves >>> 2008-08-22 22:40:48, Total time: 00:31:22 >>> Rated time: 10:31 = 631 Seconds >>> >>> It spent rarely any time on the hits, they were mostly solved in less than >>> 1s. >> >> Most of the mates are shallow enough they'll be solved instantly. Even a >> Java programs shouldn't need 30 seconds. > >Finalfun is a Java program. > Hi Simon, is Finalfun available for download? I wouldn't mind giving it a try. Tony     Date: 22 Aug 2008 22:29:41 From: Guest Subject: Re: GetClub Updated Results. "Simon Krahnke" <overlord@gmx.li > wrote in message news:878wuompj3.fsf@xts.gnuu.de... >* Guest <none@example.none> (00:44) schrieb: > >> There are testing suites with much more emphesis on positional abilities, >> but he's not ready for that. > > I think Finalfun scores nada on silent but deadly. With just material, I'm not surprised. I don't know what would be needed for that one, but I'd expect it'd be more than mobility and a little pawn knowledge. Maybe a few piece square tables? I've never actually run them or even looked at them. (I don't have a current program, so... (shrug)) >> Most of the mates are shallow enough they'll be solved instantly. Even a >> Java programs shouldn't need 30 seconds. > > Finalfun is a Java program. Maybe you ought to offer it to Sanny.... There are a number of Java chess programs he could have looked at first. I still wonder about the structure of his program and the algorithms it uses. I bet right about now, he's feeling pretty bummed out about his program's performance. It went from a 2800 rating to being unable to detect mating positions in a test suite. That's got to be a bit of an ego deflater. >>>> You shouldn't be missing any mate-in-2 positions. None. >>> >>> Finalfun finds them at depth 3. >> >> Depends on how you count & report them. > > Of course. Finalfun doesn't do *any* reductions (not even null move). So > that means 3 fully searched plies. Because of how you do king captures & check's, you might be detecting it a move earlier though. With the "Wait until the king is captured" method, it can take one extra plain ply. (Check extensions mean you'll still see it, but it'll be counted as one more ply.) > Actually the move Bh2+ is found at depth 3/5 with a score of 1.99 > (there's that error again). Are you using floating point to hold the score? That'd do it. Just a little round-off error. Converting to/from centipawns could cause that maybe. >> At least they didn't make you follow all the rules, exactly. > > There wasn't even a time limit :-). One game I operated we both had > implemented XBoard, so the game could run automatically. That was good > because the other engine took minutes for each move. Well then heck, you should have let it run for a full day between moves! I remember reading that's what the Russian team did way back in the 60's with the ITEP vs. Kotok-McCarthy program. Both were selective search programs and they only ran a few minutes search. The moves were phoned back & forth every day. The Russians weren't happy with the way their program wasn't beating the US program, so they expanded the search width to full width and let it think for much longer. The result being their program then won. > The only thing I remember about the Smalltalk program is its annoying > way to enter move. Our own interface had drag&drop. They had a pop-up > window that asked for name of the start square, then a second window > popped up, asking for the target square, then a third pop-up window asked > for confirmation of that move. (shudder) I guess whoever programed it didn't actually put much thought in playing it. >> Not everybody does mobility though. It's fairly time consuming and many >> feel it doesn't actually provide enough for the cost. > > I actually have no idea on how to implement that. Isn't that a move > generator that doesn't generate moves? Pretty much. Actually there are several definitions of 'mobility'. 1) Legal mobility. 2) pseudo-legal mobility. 3) pawn based mobility. (As if there were only pawns on the board.) 4) distinct square mobility. (If two of your pieces can move to the same square, it's only counted once.) And there are probably others. #4 is actually pretty easy to do with bitboards. You can use the Kogge-Stone (spelling?) method to find all the moves for all the pieces of the same type. OR them together and then do a bitcount. The K-S method takes a full 64 bit bitboard and shifts & ands them around until it's 'moved' to all the squares. The bitboard stuff has really gotten interesting the past few years. Far more interesting than the old rotated method. But some people don't feel it's a good judge of a good position. Good positions have good mobility because they are good positions. Not: good positions are good positions because they have good mobility. Me... (shrug) Mobility does slow things down, but I haven't tried #4 with the bitboard methods so it might be okay. >> Speaking of mobility, I was reading one of the testing threads by Hyatt >> recently and he mentioned that you can actually use a random number >> generator for the mobility score! [...] > > Interesting. Can you give a pointer to that? The recent testing threads > on Talkchess are really huge. I know!! There's more than 100 pages worth. I got lost in them. I finally just gave up and am waiting for him to post results of his new tests. (He's finally getting reliable testing results. Now he's trying to bring the testing size down to something that's more easily managed but yet sensitive enough to detect small changes in the program's playing ability.) A few days ago I was going through the forums, saving interesting threads to my drive and I happened to see it. http://www.talkchess.com/forum/viewtopic.php?topic_view=threads&p=205916&t=22731 I email regularly with a couple people who are also interested in computer chess and follow the forum, and they too were surprised by this. They had missed it and I had to give them the link so they could read it for themselves. Once you actually start thinking about it, it does make a bit of sense. It's not going to have the reliability of a real mobility score, but if you random generator is good, then.... Unfortunately I don't have Don Beal's original paper, so I don't know any real results. Just what Hyatt is repeating. In another thread, he says "5. Beal even found that random evaluation was enough to let a full-width search play reasonably. Nobody had thought that prior to his experiment" I guess that just goes back to "If you don't test, you don't know". I'm not so sure I'd trust it in a real program, but it would be interesting to see some test results about it. ----== Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.pronews.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= - Total Privacy via Encryption =---       Date: 23 Aug 2008 17:26:25 From: Andy Walker Subject: Re: GetClub Updated Results. In article <1219461891_546@isp.n >, Guest <none@example.none> wrote: [mobility:] >But some people don't feel it's a good judge of a good position. Good >positions have good mobility because they are good positions. Not: good >positions are good positions because they have good mobility. Right. In the early days of computer chess, mobility was often thought of as Very Important, because it was an important part of human positional estimation, and because it seemed to correlate strongly with whether positions were good or bad. The impression I have is that it was eventually dropped, because it wasn't really telling you anything new [eg, more material usually means more mobility, but its the extra material that's good not the extra mobility] and because in the end it only counts if it leads to tactics [eg, more mobility means I can perhaps switch my attack faster than you can switch your defence, but that only matters if the attack wins something, which shows up in the tactics]. For humans, it's a useful guide near the root of the tree, but computers do their evaluations at the leaves. If it's making a comeback, that's Quite Interesting in its own right, and one wonders what the reasons are. >>> Speaking of mobility, I was reading one of the testing threads by Hyatt >>> recently and he mentioned that you can actually use a random number >>> generator for the mobility score! [...] >Unfortunately I don't have Don Beal's original paper, so I don't know any >real results. Just what Hyatt is repeating. [...] >In another thread, he says "5. Beal even found that random evaluation was >enough to let a full-width search play reasonably. Nobody had thought that >prior to his experiment" I guess that just goes back to "If you don't >test, you don't know". I think some of the claims made "on behalf of" Don's results go way beyond what Don himself claimed or measured. A random evaluation correlates [after minimaxing] quite strongly with number of moves and so with material, and so plays much better than mere random moves. Further, such a program still reliably detects mates and stalemates within the tree, and so will play or avoid any forced [stale]mate in the same way as [but faster than, because of the simple evaluation!] any other chess engine. The result was that a random engine searching [say] to depth 10 heavily defeated the same engine searching to depth 9, and produced *some* quite intelligent play [eg "trying" not to lose its own queen but to win the opponent's]. Don never claimed that the play was good, merely that it was better than you might expect. [I discussed this fairly extensively with Don at the time, and eventually set an exam question on the topic, which stirred up the external examiner (Jon Mestel, by some sort of serendipity) more than the students ....] -- Andy Walker Nottingham         Date: 23 Aug 2008 13:06:39 From: Guest Subject: Re: GetClub Updated Results. "Andy Walker" <anw@cuboid.uk > wrote in message news:g8ph81$1gm$1$8300dec7@news.demon.co.uk... > In article <1219461891_546@isp.n>, Guest <none@example.none> wrote: > [mobility:] >>But some people don't feel it's a good judge of a good position. Good >>positions have good mobility because they are good positions. Not: good >>positions are good positions because they have good mobility. > > Right. In the early days of computer chess, mobility was often > thought of as Very Important, because it was an important part of human > positional estimation, and because it seemed to correlate strongly with > whether positions were good or bad. The impression I have is that it > was eventually dropped, because it wasn't really telling you anything > new [eg, more material usually means more mobility, but its the extra That and the cost involved. In older programs it took quite a bit of time to get the mobility. With some of the newer ways to compute mobility, the cost is much less. Cheap enough that you could do it if you want to. > If it's making a comeback, that's Quite Interesting in its > own right, and one wonders what the reasons are. I don't know if top programs do it. I don't look at their source or ask. To be honest, I doubt it though. But some mid level and low level programs do it because it's a classic idea and it's so easy to do these days. The big disadvantage before was the cost involved. Without that penalty there's no great reason to avoid it. Whether it actually helps or not, I cna't say. Might be worth testing publicly though. > I think some of the claims made "on behalf of" Don's results > go way beyond what Don himself claimed or measured. A random Hyatt isn't saying it played well. Just that it played better than expected and better than just material alone. That it played better than you'd expect. That it was a somewhat cheap way to do a fake form of mobility scoring. Naturally you wouldn't expect any program that does just material and mobility (fake or real) to play great. My big question is: Does the error rate of a random mobility score (and the extra nodes involved) outweigh the benefit of a faster eval. With real mobility scoring, it's slow enough that it hurts your searching speed so you don't search as deep. With the random one, it's fast enough there's little effect on speed, so you can still search very fast. But you may have to search more nodes because of the random factor. So which would be better? That's what I want to know. Since neither one would be able to handle openings or end games, you'd have to start at a middle game and do a fixed number of moves and then run the position through a judging program to see who was really ahead. Repeat that a few thousand times to get reliable results. Then, what about a little bit of knowledge, such as pawns. Would the random mobility still be useful or would it interfere. I don't know if Beal tested those kinds of things or not. If not, real tests would have to be done. Assuming anybody is truely interested in this beyond the elty factor. I'm not planning to do these tets, but I think it might be interesting. > the opponent's]. Don never claimed that the play was good, merely > that it was better than you might expect. Right. I didn't say it was great play and Hyatt didn't either. I don't think anybody would expect it be great. Just a quick way to pretend to do mobility scoring. > [I discussed this fairly extensively with Don at the time, > and eventually set an exam question on the topic, which stirred up > the external examiner (Jon Mestel, by some sort of serendipity) > more than the students ....] Thanks for the personal / direct info. Always nice to hear info from somebody close to the source. ----== Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.pronews.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= - Total Privacy via Encryption =---   Date: 23 Aug 2008 01:58:53 From: Simon Krahnke Subject: Re: Beginner Level Results * Guest <none@example.none > (00:25) schrieb: > "Simon Krahnke" <overlord@gmx.li> wrote in message >> The castling doesn't reset the 50 move rule counter. > > Apparently not. > > I haven't read the FIDE rules in years, but I used to think it did (and so > did some other authors.) Any irreversible move resets the counter. The engines I tested in Arena preferred 0-0 too, not getting the half move clock. > I guess we read wrong. > > The FIDE rules are actually a little fuzzy in some areas. Not here: It explicitly mentions captures and pawn moves. The concept of irreversiblity (sp?) is obviously behind that, but is not mentioned. > However, even if Alex & the others were wrong, it's still a great test > position because a lot of programs just don't pay attention to the 50 move > rule part when entering a FEN position. I guess my Finalfun reads that in correctly but doesn't care about the 50 rule. I know I never implemented repetition. > Even Winboard / XBoard ignores it and doesn't even pass it to engines. Arena too. >> So the above the above board will drawn after both players make a move >> and black claims draw. > > Yup. > > Actually, since this is 50 move rule, I'm not sure he has to make the claim. > I think it's automatic. (As I said, some areas of the rules are fuzzy.) > But claiming it wont hurt. 50 move and repetition aren't automatic, you have too claim them. mfg, simon .... l     Date: 22 Aug 2008 20:37:58 From: Guest Subject: Re: Beginner Level Results "Simon Krahnke" <overlord@gmx.li > wrote in message news:87d4k0mwjm.fsf@xts.gnuu.de... >* Guest <none@example.none> (00:25) schrieb: > >> I guess we read wrong. >> >> The FIDE rules are actually a little fuzzy in some areas. > > Not here: It explicitly mentions captures and pawn moves. The concept of > irreversiblity (sp?) is obviously behind that, but is not mentioned. That's how I had always heard it explained. Apparently a lot of people got it that way. >> Actually, since this is 50 move rule, I'm not sure he has to make the >> claim. >> I think it's automatic. (As I said, some areas of the rules are fuzzy.) >> But claiming it wont hurt. > > 50 move and repetition aren't automatic, you have too claim them. Okay. I always claim it anyway. (Even claiming a draw has to be done carefully if you are doing it computer vs. computer. The xboard protocol doesn't give you wa to do it like normal, so you have to do it differently under xboard than if you do it with a human.) Insufficient material, such as lone king, is automatic though. There's been some discussion recently about that. Also, some time back there was a discussion about the wording of the draw by repetition when castling status changes were involved. The way its worded can make it sound like if your castling status changes even briefly, then it wont be an exact repetition. That's occured in a few tournaments too. I guy I know sent me a link about that. The TD agreed the wording of the rules does certainly make it sound that way, and that if you interpret it literally then it would be, but that traditionally chess isn't played that way, so temporary castling status changes don't effect repetition. Other TD's can rule their own way, though. If they are more literal minded, then... > > mfg, simon .... l ----== Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.pronews.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= - Total Privacy via Encryption =---   Date: 22 Aug 2008 23:50:29 From: Simon Krahnke Subject: Re: Beginner Level Results * Guest <none@example.none > (22:42) schrieb: > 1rk4B/6N1/8/8/8/3p1p1p/3P1P1P/4K2R w K - 98 150 > > "A lot of engines I tested evaluate this position as won by White, even > Rybka The two possible involved bugs are: missing reading of 50-move count > from FEN, and treatment of castling move as an irreversible move which > resets 50-move count. Alex" Do I understand that right: Once the half move clock reaches 100 one can claim a draw, so black and white each have exactly one chance to avoid draw? All the pawns are blocked and there are no immediately playable captures. The castling doesn't reset the 50 move rule counter. So the above the above board will drawn after both players make a move and black claims draw. mfg, simon .... l     Date: 22 Aug 2008 17:25:13 From: Guest Subject: Re: Beginner Level Results "Simon Krahnke" <overlord@gmx.li > wrote in message news:87r68gn2hm.fsf@xts.gnuu.de... >* Guest <none@example.none> (22:42) schrieb: > >> 1rk4B/6N1/8/8/8/3p1p1p/3P1P1P/4K2R w K - 98 150 >> >> "A lot of engines I tested evaluate this position as won by White, even >> Rybka The two possible involved bugs are: missing reading of 50-move >> count >> from FEN, and treatment of castling move as an irreversible move which >> resets 50-move count. Alex" > > Do I understand that right: Once the half move clock reaches 100 one can > claim a draw, so black and white each have exactly one chance to avoid > draw? That's the 50 move rule. Many people (including my old program) get the halfmove & full move clock wrong or just ignore it when entering a position. I ignored it because I thought it didn't matter. Laziness on my part. But it does matter. (And in fact, some programs actually use a FEN string (or similar) to save its position as game state for resuming games. For them, it obviously would matter.) And acording to Alex (and some of the posts that replied to his message), a lot of programs actually got it wrong. It's just one of those interesting positions that aren't likely to be encountered in real games, but are great debugging positions. > All the pawns are blocked and there are no immediately playable Right. So technically a draw even though it looks like it'd be a win for White. > captures. The castling doesn't reset the 50 move rule counter. Apparently not. I haven't read the FIDE rules in years, but I used to think it did (and so did some other authors.) Any irreversible move resets the counter. I guess we read wrong. The FIDE rules are actually a little fuzzy in some areas. However, even if Alex & the others were wrong, it's still a great test position because a lot of programs just don't pay attention to the 50 move rule part when entering a FEN position. Even Winboard / XBoard ignores it and doesn't even pass it to engines. > > So the above the above board will drawn after both players make a move > and black claims draw. Yup. Actually, since this is 50 move rule, I'm not sure he has to make the claim. I think it's automatic. (As I said, some areas of the rules are fuzzy.) But claiming it wont hurt. > > mfg, simon .... l > ----== Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.pronews.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= - Total Privacy via Encryption =---   Date: 22 Aug 2008 23:07:46 From: Simon Krahnke Subject: Re: GetClub Updated Results. * Guest <none@example.none > (19:39) schrieb: > I'm only looking at the first 20 positions at the moment... I've gone through the first 10 positions of wac with my Finalfun. It finds all of them except the seconds. Rybka and Toga II solve that at depth 14. A little odd among all that Mate-in-x. I ran Finalfun 5s on every of the 300 positions and it score 188/300 = 62.7%. 188 of 300 matching moves 2008-08-22 22:40:48, Total time: 00:31:22 Rated time: 10:31 = 631 Seconds It spent rarely any time on the hits, they were mostly solved in less than 1s. > You shouldn't be missing any mate-in-2 positions. None. Finalfun finds them at depth 3. > I can accept that a beginner wouldn't be able to find a mate in 5 or mate in > 7, etc. I don't mind a beginner level in a program missing those. Position 9 is a mate in 5 (Finalfun says so), it's found in 4s at depth 5/9. Mmpf, all the other engines tell me it's a mate in 4. > The best positional play in the world doesn't mean anything if you miss > major tactical issues. After all, checkmating your opponent is the object > of the game. I remember when we were programming our first chess program at a university course. The was a tournament at the end the semester where all team's programs were to play all the others twice. The rules said that not accepting a legal or generating an illegal move was a loss for that program. So our objective was to let it play legal chess, with all the castling, en-passant and under-promotion stuff. Then came piece/square tables and some opening patches so that it could play a real game. And the we took care that it could it actually win an end game by finding mates. With my own engine FInalfun I even reversed it: It can't play any real game because of its pure materialistic view nearly all position look the same. But it does find some mates. mfg, simon .... l     Date: 28 Aug 2008 15:03:42 From: Simon Krahnke Subject: Re: GetClub Updated Results. * Tony M <tmokonen@yahoo.com > (09:11) schrieb: Where are you from, Tony? > You can download my program at http://tmokonen.110mb.com/tonyschess/ > if you want to try it out or test against it. Thanks. Why is there no analysis mode? It's far easier to implement than time controls. What is a BookThinker? mfg, simon .... l       Date: 28 Aug 2008 15:16:27 From: Tony M Subject: Re: GetClub Updated Results. On Thu, 28 Aug 2008 15:03:42 +0200, Simon Krahnke <overlord@gmx.li > wrote: >* Tony M <tmokonen@yahoo.com> (09:11) schrieb: > >Where are you from, Tony? > >> You can download my program at http://tmokonen.110mb.com/tonyschess/ >> if you want to try it out or test against it. > >Thanks. Why is there no analysis mode? It's far easier to implement than >time controls. > >What is a BookThinker? > >mfg, simon .... l Sorry, Simon, I missed your first question. No sleep last night. :) I'm from Vancouver, BC, Canada. I actually was going to ask you the same thing, one of your addresses says Germany, and the other says Liectenstein.         Date: 28 Aug 2008 15:17:29 From: Tony M Subject: Re: GetClub Updated Results. On Thu, 28 Aug 2008 15:16:27 GMT, Tony M <tmokonen@yahoo.com > wrote: >Liectenstein Grr, Liechtenstein. I *really* need sleep.       Date: 28 Aug 2008 14:33:44 From: Tony M Subject: Re: GetClub Updated Results. On Thu, 28 Aug 2008 15:03:42 +0200, Simon Krahnke <overlord@gmx.li > wrote: >* Tony M <tmokonen@yahoo.com> (09:11) schrieb: > >Where are you from, Tony? > >> You can download my program at http://tmokonen.110mb.com/tonyschess/ >> if you want to try it out or test against it. > >Thanks. Why is there no analysis mode? It's far easier to implement than >time controls. > >What is a BookThinker? > >mfg, simon .... l I didn't implement analysis mode yet, sorry. The program does not check for keyboard input during the search. It sort of works with time controls, but incremental time controls remain a problem. Increasing the movesleft parameter in the .ini file decreases the amount of time used. BookThinker is a utility that comes with the chess engine Thinker. http://www.geocities.com/thechessthinker/download.html Basically, it provides opening book functionality for engines that don't have a book, to run in GUIs that don't have a native book format (eg Winboard). The download for Thinker doesn't come with a book, but it does come with a utility to make books from PGN files. I can send you a book that I made myself, it's given me decent results so far. I usually use native Arena books without a problem. I hope to have an own book with the next release of Tony's Chess, when I get off my lazy butt to do it :). Tony     Date: 28 Aug 2008 14:57:10 From: Simon Krahnke Subject: Re: GetClub Updated Results. * Sanny <softtanks@hotmail.com > (09:21) schrieb: > 74 moves game !!! > > It means Tiny and GetClub are nearly equal. But GetClub is taking 15 > sec/ move and Tony taking 8 sec / move. > > Just a moment ago the game was improved a bit. I don't know the above > game was played after the improvement or befire that. > > If this game was played before the improvement. Then Tony will find it > much difficult to win new games. But if the game was played after the > improvement, Then Both programs are equal. A match lost isn't an indicator of equalness. mfg, simon .... l     Date: 28 Aug 2008 00:21:45 From: Sanny Subject: Re: GetClub Updated Results. 74 moves game !!! It means Tiny and GetClub are nearly equal. But GetClub is taking 15 sec/ move and Tony taking 8 sec / move. Just a moment ago the game was improved a bit. I don't know the above game was played after the improvement or befire that. If this game was played before the improvement. Then Tony will find it much difficult to win new games. But if the game was played after the improvement, Then Both programs are equal. Bye Sanny Play Chess at: http://www.GetClub.com/Chess.html     Date: 22 Aug 2008 17:44:40 From: Guest Subject: Re: GetClub Updated Results. "Simon Krahnke" <overlord@gmx.li > wrote in message news:87vdxsn4gt.fsf@xts.gnuu.de... >* Guest <none@example.none> (19:39) schrieb: > >> I'm only looking at the first 20 positions at the moment... > > I've gone through the first 10 positions of wac with my Finalfun. It > finds all of them except the seconds. Rybka and Toga II solve that at > depth 14. A little odd among all that Mate-in-x. Yeah. But I didn't write the book. That's also why WAC is not used for major engine testing. But it does make a decent beginning test. It's a decent first testing suite for Sanny. A little bit of positional, a lot of tactical, and a lot of mates. There are testing suites with much more emphesis on positional abilities, but he's not ready for that. > > I ran Finalfun 5s on every of the 300 positions and it score 188/300 = > 62.7%. > > 188 of 300 matching moves > 2008-08-22 22:40:48, Total time: 00:31:22 > Rated time: 10:31 = 631 Seconds > > It spent rarely any time on the hits, they were mostly solved in less than > 1s. Most of the mates are shallow enough they'll be solved instantly. Even a Java programs shouldn't need 30 seconds. Many of the others are materialistic enough they'll at least get the right answer without too much effort. That leaves a hundred or so that requires some effort. >> You shouldn't be missing any mate-in-2 positions. None. > > Finalfun finds them at depth 3. Depends on how you count & report them. Depending on the kind of search extensions you have, some programs can find mate at a much shallower iterative search depth than others. A lot of programs actually report different depths. I don't worry too much about it. > >> I can accept that a beginner wouldn't be able to find a mate in 5 or mate >> in >> 7, etc. I don't mind a beginner level in a program missing those. > > Position 9 is a mate in 5 (Finalfun says so), it's found in 4s at depth > 5/9. Yup. I wouldn't expect GC's beginner level to get that or #8, which is mate in 7. > > Mmpf, all the other engines tell me it's a mate in 4. Depends on how it's counted & reported. Not all programs even find the shortest mate. Because of the way they search, they sometimes just find *a* mate rather than the closest one. > >> The best positional play in the world doesn't mean anything if you miss >> major tactical issues. After all, checkmating your opponent is the >> object >> of the game. > > I remember when we were programming our first chess program at a > university course. The was a tournament at the end the semester where > all team's programs were to play all the others twice. The rules said > that not accepting a legal or generating an illegal move was a loss for > that program. So our objective was to let it play legal chess, with all > the castling, en-passant and under-promotion stuff. Then came > piece/square tables and some opening patches so that it could play a real > game. And the we took care that it could it actually win an end game by > finding mates. At least they didn't make you follow all the rules, exactly. It's amazing how many of the rules are a such a pain to program. > > With my own engine FInalfun I even reversed it: It can't play any real > game because of its pure materialistic view nearly all position look the > same. But it does find some mates. Adding a little mobility would help. And piece square tables. Not everybody does mobility though. It's fairly time consuming and many feel it doesn't actually provide enough for the cost. Speaking of mobility, I was reading one of the testing threads by Hyatt recently and he mentioned that you can actually use a random number generator for the mobility score! The idea is that positions with a higher number of children positions (who gets scored) has a higher chance of getting a high random number pseuo-mobility score. Positions with fewer childred to get scored tend to get a lower random number because there are fewer chances to get a high number. It's just probabilities. I haven't tried it, but one of these years I might dig out my program and try just material & a random number generator and see how well it does on some tests. > > mfg, simon .... l ----== Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.pronews.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= - Total Privacy via Encryption =---       Date: 26 Aug 2008 22:05:16 From: David Richerby Subject: Re: GetClub Updated Results. Guest <none@example.none > wrote: > Speaking of mobility, I was reading one of the testing threads by > Hyatt recently and he mentioned that you can actually use a random > number generator for the mobility score! > > The idea is that positions with a higher number of children > positions (who gets scored) has a higher chance of getting a high > random number pseuo-mobility score. You can go even further and use a random number generator for the entire evaluation function! As you say, a node with a large number of children has a higher chance of getting a high random evaluation. And, also, a large number of children implies high mobility, which generally implies lots of material. So a completely random evaluation function tends to reward material and mobility, which correlate to good positions. :-) Dave. -- David Richerby Salted Painting (TM): it's like a www.chiark.greenend.org.uk/~davidr/ Renaissance masterpiece but it's covered in salt!         Date: 26 Aug 2008 22:07:52 From: David Richerby Subject: Re: GetClub Updated Results. David Richerby <davidr@chiark.greenend.org.uk > wrote: > Guest <none@example.none> wrote: >> Speaking of mobility, I was reading one of the testing threads by >> Hyatt recently and he mentioned that you can actually use a random >> number generator for the mobility score! > > You can go even further and use a random number generator for the > entire evaluation function! Oops. I now see that you'd already said this by the time I posted. I'd skim-read the next couple of articles in the thread but hadn't noticed it. Apologies for the repetition. Dave. -- David Richerby Transparent Book (TM): it's like a www.chiark.greenend.org.uk/~davidr/ romantic el but you can see right through it!   Date: 22 Aug 2008 21:43:25 From: Simon Krahnke Subject: Re: Beginner Level Results * Guest <none@example.none > (03:37) schrieb: > "Simon Krahnke" <overlord@gmx.li> wrote in message > news:87ej4hoq7k.fsf@xts.gnuu.de... >>* Guest <none@example.none> (00:00) schrieb: >> >> Thanks for the detailed explanations. >> >>> That was due to my move sorting. I had accidently changed things so >>> likely >>> captures would be tried first. The king wasn't considered 'likely' to be >>> captured so sometimes it would never get around to noticing the king >>> could >>> be captured. It'd just go ahead and search the position as if it was >>> legal. >> >> I did that king capture checking in move generation. Someone told me >> that way the code gets executed too often. How do you ensure the king >> capture is found before some beta cut? > > Simply do the king first. OK. I can safely try my best move, since I wouldn't have one if this position was illegal. Then I generate and score my captures. I iterate through them looking for a king capture score. Then I know if the board is illegal and if not I can go for the rest of the moves. > Some people do indeed explicit checks in the move generator. There are two > variations. > > The first is that it never generates an illegal move. It makes the search > easy, but it takes time to verify though. I've thought about that. You have to check every king move target square for attacks, know which pieces are pinned, know about double check, know which squares stop the check when occupied by one of my pieces that can go there. > Others go ahead and generate pseudo-legal moves, but if the king is > ever captured, then it aborts and returns an invalid flag. That's what I did. Thanks for all the input. >> My lame engine has a strange bug: In material only evaluation it >> sometimes has an evaluation of 1 centipawn. I'm not the mood to check >> that out. > > Not being familiar with your engine, I can't even guess. I'm not expecting you to. > I'd put some debugging code into the eval and dump the board whenever it > happens. I can't be the eval. It would never return a score like that. > Then put a few more checks into the search to catch other spots. It must be some artefact of the search. I think I'll see if my next engine reproduces the bug and track it down there and fix it back. That will keep my Java involvement at a minimum :-) > Not the low level diagnostic kind of stuff most beginners need. One could compile the mating from the usual test position suites. en-passant and promotion are probably best made up or from the basic literature. Same for stalemate. And Can't one search for repetition and 50 move rule in real game collections and go from there? mfg, simon .... l     Date: 22 Aug 2008 15:42:06 From: Guest Subject: Re: Beginner Level Results "Simon Krahnke" <overlord@gmx.li > wrote in message news:8763psomxu.fsf@xts.gnuu.de... >* Guest <none@example.none> (03:37) schrieb: > >> Simply do the king first. > > OK. I can safely try my best move, since I wouldn't have one if this > position was illegal. Then I generate and score my captures. I iterate > through them looking for a king capture score. Then I know if the board > is illegal and if not I can go for the rest of the moves. Right. If the king is in the move list, then you know that position was illegal, the result of being in check. So you back up a score appropriately. You'll need to check for that being the 'best move' returned and then decide if it was mate or just stalemate. But you probably do something similar already. >> The first is that it never generates an illegal move. It makes the >> search >> easy, but it takes time to verify though. > > I've thought about that. You have to check every king move target square > for attacks, know which pieces are pinned, know about double check, know > which squares stop the check when occupied by one of my pieces that can > go there. It supposedly can be done somewhat efficiently. With some of the advanced data structures that some people do, there's so much data already that such things can be done without too much effort for each generated move. (At least as not as much as a niave way that most people would do it.) The catch is that most moves generated will never actually be made. So every little bit of extra effort you do will be wasted. So most people just don't do it that way. It does make the search a little easier, and it's the more obvious way for beginners. It just isn't the fastest way. >> Others go ahead and generate pseudo-legal moves, but if the king is >> ever captured, then it aborts and returns an invalid flag. > > That's what I did. Thanks for all the input. No problem. If there's an interesting conversation going on, I don't mind helping. You probably would get more info from the TalkChess forum, though. >> Not the low level diagnostic kind of stuff most beginners need. > > One could compile the mating from the usual test position suites. > en-passant and promotion are probably best made up or from the basic >