user2359: The average number of moves in a game of chess is about 40. This would be an average of about 80 positions in each game, but many positions are shared between games. More sharing occurs at the beginning and end of the game. 
New positions arise as games are played. As we add new games to the database of chess games, how many new positions will be added by each game?
In probability terms, if the number of new positions added by a game is a random variable, what is the expected value?
The practical result of this answer might be how large a key would a position table need in a database.

user2640: The total number of possible positions in chess is estimated to be 10^43, so the key would need to be extremely large.
As to how many new positions you could expect from an incremental game load, that would depend highly on the current state of the database. For example: the first game would necessarily be all new positions, the second would share at least one position with the first (the starting position) and could otherwise either completely duplicate the first game or deviate entirely. 
What seems certain is that as your n rises for positions, the expected value of new positions from an incrementally loaded game would decrease heavily. If you had somehow loaded every game of chess ever played (recorded or otherwise), the expectation of a new position occurring in the next loaded game would be very small indeed.

user2194: Typical large databases like chessbase, chess-db.com, etc. contain up to 10 million chess games in total, which is roughly about 500 millions positions. Thus, if you want to encode/enumerate them in some way it would require at least 32 bit key.
On the other hand, something like the Zobrist hash (see this or this) 
is a one way hash function considered to perform well in encoding chess position in 64 bits without collisions. 

2359: <p>The average number of moves in a game of chess is about 40. This would be an average of about 80 positions in each game, but many positions are shared between games. More sharing occurs at the beginning and end of the game. </p>

<p>New positions arise as games are played. As we add new games to the database of chess games, how many new positions will be added by each game?</p>

<p>In probability terms, if the number of new positions added by a game is a random variable, what is the expected value?</p>

<p>The practical result of this answer might be how large a key would a position table need in a database.</p>
 2640: <p>The total number of possible positions in chess is estimated to be 10^43, so the key would need to be extremely large.</p>

<p>As to how many new positions you could expect from an incremental game load, that would depend highly on the current state of the database. For example: the first game would necessarily be all new positions, the second would share at least one position with the first (the starting position) and could otherwise either completely duplicate the first game or deviate entirely. </p>

<p>What seems certain is that as your n rises for positions, the expected value of new positions from an incrementally loaded game would decrease heavily. If you had somehow loaded every game of chess ever played (recorded or otherwise), the expectation of a new position occurring in the next loaded game would be very small indeed.</p>
 2194: <p>Typical large databases like chessbase, chess-db.com, etc. contain up to 10 million chess games in total, which is roughly about 500 millions positions. Thus, if you want to encode/enumerate them in some way it would require at least 32 bit key.</p>

<p>On the other hand, something like the Zobrist hash (see <a href="http://research.cs.wisc.edu/techreports/1970/TR88.pdf" rel="nofollow">this</a> or <a href="http://web.archive.org/web/20070810003508/http://www.seanet.com/~brucemo/topics/zobrist.htm%29" rel="nofollow">this</a>) 
is a one way hash function considered to perform well in encoding chess position in 64 bits without collisions. </p>
