Answers.Body: <p>For a simple numerical example, take the endgame of King + Rook + Pawn vs. King + Rook. The number of possible positions is 64 x 63 x 62 x 61 x 60. Of those, 25% is not valid because the pawn is at the first or last row, and because of the symmetry around the d/e file, we only need to store the positions where the pawn is on the a, b, c or d file. This leaves us with 64 x 63 x 62 x 61 x 60 x 0.75 x 0.5 = 343,103,040 positions*.</p>
  
  <p>For every position, you need to know how many moves to mate or conversion, both with White to move and Black to move. You need 2 bytes for each position, so we get a total of 686,206,080 bytes which is about 654 MB. With ZIP-like algorithms, we can compress the size of the files by about 80%, which leaves us with around 150 MB. You can download the files <a href="http://www.chesskit.com/download/nalimov/">here</a> - note that the tablebases are split between White-to-move and Black-to-move.</p>
  
  <p>For 6- and 7-man endgames, typical sizes are 60 resp. 3600 times as large, so 9 GB resp. 540 GB. Sometimes, symmetry can be exploited further (especially if there are no pawns involved), but this will result in a maximum reduction to 25% of sizes when pawns are involved.</p>
  
  <p>*: actually, some positions are not valid because e.g. both kings attack each other. This number is rather small and if you would filter these, it would take much more time to lookup a certain position in the database.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-17T16:25:42.590Z
Answers.LastActivityDate: 2015-07-17T16:25:42.590Z
Answers.UserDisplayName: Glorfindel
Answers.Body: <p>A tablebase contains information about every possible position with a certain material balance. The number of possible positions grows exponentially with the number of pieces. So while a tablebase covering King and Pawn vs King will <em>not</em> be large, if you add enough pieces the file size will grow out of bound for any storage medium you want to use. The number of <em>all</em> possible chess positions is something like the number of atoms of the sun, so storing everything does not seem to be workable with any concievable technology. </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-17T15:17:53.247Z
Answers.LastActivityDate: 2015-07-17T15:17:53.247Z
Answers.UserDisplayName: Dag Oskar Madsen
Answers.Body: <p>In addition to the other fine answers, it is worth pointing out that tablebases contain every conceivable collection of pieces, even ones that don't make any sense. For example, I just asked about a position with king and three knights vs king and bishop, and was told that it was a mate in 30. And there are a lot of conceivable collections of six pieces, even if you know what two of those pieces are. (Not to mention that there are really two kinds of bishop.)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-17T21:03:40.387Z
Answers.Text: Why does KNNNvKB not make sense? It is a perfectly reasonable possibility. I start with two knights and to avoid a stalemate when I promote I have to promote to a knight, say.
Answers.UserDisplayName: Brian Towers
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-17T23:56:07.313Z
Answers.Text: If promoting to a queen or rook results in stalemate, you should give the king some escape squares and promote later.
Answers.UserDisplayName: limits
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-18T02:53:43.857Z
Answers.Text: @BrianTowers Of course it is possible to reach such a scenario. On the other hand, I cannot imagine a position in which the best move is to promote to a third knight leading to a KNNNKB endgame, but perhaps that is a failure of my imagination. If you can produce one, I would be very interested to see it.
Answers.UserDisplayName: dfan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-18T07:58:25.210Z
Answers.Text: @overboard, dfan Have neither of you seen those problems where white is material down but can promote to a knight forking his opponent's king and queen? The point being that KNNNvKB is a perfectly feasible endgame to reach. It makes perfect sense to include such endgames in the tablebases.
Answers.UserDisplayName: Brian Towers
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-18T08:38:36.817Z
Answers.Text: White to play and win: 8/2q1P1k1/7b/8/8/1N6/2N5/4K3 w - - 0 51
Answers.UserDisplayName: Stephen
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-18T12:29:39.013Z
Answers.Text: @BrianTowers If you prefer, replace my "don't make any sense" with "never arise in practice" or even "are infinitesimally likely to arise in practice". My point was not that they shouldn't be there, but that they are.
Answers.UserDisplayName: dfan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-18T12:30:27.107Z
Answers.Text: @Stephen Thank you! I was fixated on the avoiding-stalemate scenario.
Answers.UserDisplayName: dfan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-22T02:11:08.473Z
Answers.Text: Stalemate avoidance can figure too: kb6/2P3N1/K7/8/8/8/1N6/8 WTM wins only with 1 c8N (not 1 c8B? Be5! draw.)
  Also, "tablebases" are used also for analyzing composed studies, where exotic material configurations are much more common.
Answers.UserDisplayName: Noam D. Elkies
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-17T20:28:45.027Z
Answers.LastActivityDate: 2015-07-17T20:28:45.027Z
Answers.UserDisplayName: dfan
Body: <p>What is the reason that table base files are so large?</p>
  
  <p>I can't think of any other way to phrase that question - but the question alone is rejected by stackoverflow's gateway bot, hence this paragraph added to placate it.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-07-17T15:15:57.467Z
Comments.Text: The gateway bot has a point, why would you expect them to be smaller?  Are you asking why do tablebases contain so many combinations, or why storing it is so large on disk?  Have you noticed an apparent overhead between the size you expect and the actual size?
Comments.UserDisplayName: Corvus
Tags: <tablebases>
Title: Why are tablebase files so large?
ThreadText: # Why are tablebase files so large?
  
  (Asked by: username_0 on 2015-07-17)
  
  What is the reason that table base files are so large?
  
  I can't think of any other way to phrase that question - but the question alone is rejected by stackoverflow's gateway bot, hence this paragraph added to placate it.
  
  **Tags:** tablebases
  
  > **Comments:**
  > **username_1**: The gateway bot has a point, why would you expect them to be smaller?  Are you asking why do tablebases contain so many combinations, or why storing it is so large on disk?  Have you noticed an apparent overhead between the size you expect and the actual size?  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_2 on 2015-07-17. Score: 7
  
  For a simple numerical example, take the endgame of King + Rook + Pawn vs. King + Rook. The number of possible positions is 64 x 63 x 62 x 61 x 60. Of those, 25% is not valid because the pawn is at the first or last row, and because of the symmetry around the d/e file, we only need to store the positions where the pawn is on the a, b, c or d file. This leaves us with 64 x 63 x 62 x 61 x 60 x 0.75 x 0.5 = 343,103,040 positions\*.
  
  For every position, you need to know how many moves to mate or conversion, both with White to move and Black to move. You need 2 bytes for each position, so we get a total of 686,206,080 bytes which is about 654 MB. With ZIP-like algorithms, we can compress the size of the files by about 80%, which leaves us with around 150 MB. You can download the files [here](http://www.chesskit.com/download/nalimov/) - note that the tablebases are split between White-to-move and Black-to-move.
  
  For 6- and 7-man endgames, typical sizes are 60 resp. 3600 times as large, so 9 GB resp. 540 GB. Sometimes, symmetry can be exploited further (especially if there are no pawns involved), but this will result in a maximum reduction to 25% of sizes when pawns are involved.
  
  \*: actually, some positions are not valid because e.g. both kings attack each other. This number is rather small and if you would filter these, it would take much more time to lookup a certain position in the database.
  
  
  ---
  
  ### Answer by username_3 on 2015-07-17. Score: 3
  
  A tablebase contains information about every possible position with a certain material balance. The number of possible positions grows exponentially with the number of pieces. So while a tablebase covering King and Pawn vs King will *not* be large, if you add enough pieces the file size will grow out of bound for any storage medium you want to use. The number of *all* possible chess positions is something like the number of atoms of the sun, so storing everything does not seem to be workable with any concievable technology.
  
  
  ---
  
  ### Answer by username_4 on 2015-07-17. Score: -1
  
  In addition to the other fine answers, it is worth pointing out that tablebases contain every conceivable collection of pieces, even ones that don't make any sense. For example, I just asked about a position with king and three knights vs king and bishop, and was told that it was a mate in 30. And there are a lot of conceivable collections of six pieces, even if you know what two of those pieces are. (Not to mention that there are really two kinds of bishop.)
  
  > **Comments:**
  > **username_5**: Why does KNNNvKB not make sense? It is a perfectly reasonable possibility. I start with two knights and to avoid a stalemate when I promote I have to promote to a knight, say.  
  > **username_6**: If promoting to a queen or rook results in stalemate, you should give the king some escape squares and promote later.  
  > **username_4**: @BrianTowers Of course it is possible to reach such a scenario. On the other hand, I cannot imagine a position in which the best move is to promote to a third knight leading to a KNNNKB endgame, but perhaps that is a failure of my imagination. If you can produce one, I would be very interested to see it.  
  > **username_5**: @overboard, username_4 Have neither of you seen those problems where white is material down but can promote to a knight forking his opponent's king and queen? The point being that KNNNvKB is a perfectly feasible endgame to reach. It makes perfect sense to include such endgames in the tablebases.  
  > **username_7**: White to play and win: 8/2q1P1k1/7b/8/8/1N6/2N5/4K3 w - - 0 51  
  > **username_4**: @BrianTowers If you prefer, replace my "don't make any sense" with "never arise in practice" or even "are infinitesimally likely to arise in practice". My point was not that they shouldn't be there, but that they are.  
  > **username_4**: @username_7 Thank you! I was fixated on the avoiding-stalemate scenario.  
  > **username_8**: Stalemate avoidance can figure too: kb6/2P3N1/K7/8/8/8/1N6/8 WTM wins only with 1 c8N (not 1 c8B? Be5! draw.) Also, "tablebases" are used also for analyzing composed studies, where exotic material configurations are much more common.  
  
  ---
  
  