Kirill Kryukov wrote:Do you mean you never compress the thing? Is it because the compression ratio is too low, or because it slows down the querying too much? My chess DTM files compress to about 3 positions per byte in DTM (distance to mate - this is what you call distance to win/lose) metric.
Endgame tablebase solved for generator#
That should make the computer-computer endgames more interesting, and the tablebase generator effort would become more worthwhile. Maybe a special set of rules would make sense.ġ) If a program announces mate at any point before the 50 move rule would stop the game, the counter resets.Ģ) If the announcement was "Mate in X" and X + 1 moves elapse, the defending side is awarded the draw.ģ) If "X" is ridiculously large and deemed a deliberate exaggeration to circumvent the 50-move rule, the declaring program is given a forfeited loss. computer tournaments, I say wave the rule and let the programs play it out. What player would want to play out a 100-move ending in R + B vs. In my opinion, that rule was designed for human play, and it should remain in the domain of human vs. Also Nalimov tables (the most popular format in chess, distance to win, up to 6 pieces currently) are suffering from not accomodating this rule. Kirill Kryukov wrote:It causes a lot of issues and debates in chess endgame solving, and limits the usefulness of Win-Draw-Loss tables. This is where we are with 7-piece chess endgames now. No database, no solver, no source, no online access, nothing. How much data are you planning to actually share with people? (I saw many projects where the result is just the announcement "I solved endgame X in game Y", some statistics, and some long winning lines, and that's all. But I guess you'll only look into it after completing your plan with 10-piece checkers. May be I or someone else can help with computation resources. Well then I hope you will have interest in applying it to other checkers variants too. So, just replacing the move generator should allow other games to be solved in the same way. 4 kings + 1 checkers, etc.) it places every piece on every possible square, generates the moves, looks up known results, solves what is possible to solve, and continues until it can make no more resolutions. 4 kings + 1 checker, 4 kings + 1 checker vs. The solver goes through each permutation of possible material distributions (5 kings vs. The indexing functions (if the board size is different) The longest known 10-piece win for red to move so far:Įd Trice wrote:The algorithm will work for any checkers variant. This would be 39 trillion positions, where the "American trillion" = 1000 x 1000 x 1000 x 1000. I plan on solving up to 10 piece endgames by the end of 2011. Since that time, I revamped every aspect of the solver: new move generator, new buffering structure and technique, new indexing functions, and ability to solve wins as long as 1021 plies.
Each endgame had its own challenges, especially since we only had 1.5 GB of RAM and a 500 MHz processor was used to generate about half of the set.
Endgame tablebase solved for code#
Most of that code was "thrown together", if you know what I mean. I did solve tb7 for checkers with a programming buddy of mine named Gil Dodgen (this was back in 2003) and we published the data in ICGA.
This is not off-topic here, thanks for posting!Īre you planning to extend your generator to 7 pieces or more?
0 kommentar(er)
