I know this reply is a bit late on an old topic, but Google took me to this posting when I searched for "Number of possible chess positions", and I felt compelled to state that I completely understand what the original author of the post is trying to accomplish here. When I thought of something along the same lines I knew I could not be the only one who wanted to think of solving chess in a different manner than what was normal.

Normally, people would assume you would build some sort of tree, where you store moves that lead to another move and so on in hopes that you'll discover the final node in this tree which can be recursively worked back to find the perfect play. And, according to a lot of smart people, this is improbable (not impossible). I say improbable and not impossible because of a few things:

1. You could get lucky and through some ingenious scoring algorithm discover the perfect play by chance early on. This would mean you would avoid searching down dead ends. Highly unlikely, but still possible. I'd bet on winning the lottery numerous times before this ever happened.
2. Given enough time it could eventually be solved through brute force depth searches. Again, not impossible, just improbable because the amount of time required.

I believe what the original author was trying to get across was actual game states, regardless of the path taken to get there. It's still a large mathematical number if we account for illegal positions. But, it could be significantly reduced if we only take into account legal positions.

Here's an example of what I mean:

The two sequences above are different, yet lead to the same game state in the end. So even though there were 4 different moves made in 2 possible ways, the state of the board at the end of either of those 4 moves is identical.

If a computer were to store game states instead of game paths, you would get a NN (Neural Network) instead of a tree. Each positions would be stored into the database. The computer would calculate possible moves from that single position, serialize the outcomes and compare each of the serialized boards to ones possibly stored in the database to see the score associated to those positions (with max score being win, minimum score being a loss and minimum score + 1 being a tie). Of course, the computer could also store the pointers from one game state to another, which saves in serialization and deserialization time, but that takes space in the database once more.

I actually made a meek attempt at storing serialized game states. First, I started off by researching a less intensive game (Connect4). A lot of this information is actually found here: http://www.connectfour.net/Files/connect4.pdf. The upperbound of game states on Connect4 is 43^3 (>= 10^20). The lowerbound is much smaller (about 1.6 x 10^13). It is still an extremely large number, but much smaller nonetheless. Though, when you account that each game state would take up more than 1 bit of data, databasing all possible game state positions is a large task. Assuming you use a simple 2 bits per square (Player 1, Player 2, Empty) that means you'd need 3.2 x 10^13 bits (approx). When you introduce things like Huffman encoding you can compress down the serialized game state, meaning more storage.

Now, when you apply this to the game of chess, it is still improbable currently, for a couple of reasons:

1. Even with the best compression the lowerbound number of bits needed would be 32 bits to store the board state completely (2 kings, 62 blanks). The worst case scenario I could come up with would take up 204 bits of data.
2. Serializing and Deserializing takes up quite a bit of cpu time, especially if that serialization goes through a function that compresses and decompresses the binary.
3. The number of game states is still extremely large. If the game of connect4 is 1.6 x 10^13, just imagine how many different game states the game of chess would require, especially if you have to take into account the other rules governing the game state.

That being said, I'll say that I still believe it is possible to do so if certain circumstances are met.

Firstly, if we look at what would be needed for serializing the game state. If we huffman encode it, wikipedia has the statistics on this: http://en.wikipedia.org/wiki/Board_representation_(chess)#Huffman_encodings

Although, there are some things I quite don't understand such as when it states only 5 possibile en passants, when to me there are 8. But anyways, moving on...

204 bits for the worst case scenario game state is quite large, especially when compared to the tiny RC-RC (16 bits) move. Though, in the end I think it's still less expensive to compute game states than moves. If you calculate moves you have to build a tree, which means a lot of redundancies. In the example I gave above there are 4 different ways to come to that game state, so that means 4 exactly the same branches beyond that point. Basically, storing game states instead of moves is more expensive to start with, but I think ends up being less expensive in the end.

Also, people are too quick to assume that you need to do a depth-first search to start eliminating bad game states. While this is true if there was no AI involved, having AI means avoiding dead end searches much more often. This, unfortunately, was my Achilles heal when trying to do such an application. I could not come up with a smart algorithm to score the board in such a way that the computer can make a valid assumption to stop digging down that road. It isn't so much as to just declare it as a loss, because quite frankly it might be the winning path. Instead, it would be really soft and strict so that the idea of giving up a Queen is ok because it very well could be the perfect play. Instead it would just recognize things such that, if the computer has 1 rook and a King remaining and the human player has 2 rooks, a Queen, 4 pawns, a Knight and a King remaining... attempting to find the perfect play at this point is moot, because a human player making the perfect play should not lose (I say should not because it is possible that the computer could be in the advantage position to mate in the next move). Though honestly, if we can have AI for the computer to recognize when to resign as a human does, this would narrow our search down. Of course, the game state would not be marked as a loss at that position, but merely have an extremely low score that could be revisited at a later time if necessary.

Also, winning because the player made a stupid mistake is not really winning. The computer does not calculate out a win by luck, but by determining that every possible move the opponent makes would result in a loss. If there is even one door open for the opponent to avoid a loss, that door must be accounted for.

Eventually the database would fill up though, depending on storage size. This means that a pruning method would have to be built in or the computer would run out of storage. The simplest is to look at one game state. If every possible move leads to a game state that has been already serialized as a loss, then that game state is a loss as well. Basically, any move the computer makes is fruitless, avoid getting to that previous state. And, if that previous state is never gotten to, then the game states that come out as a result of a move from that game can be deleted from the database. It is still possible that they can be reached through an alternative path though, which would mean that the computer has a possibility of searching down that door that was once closed again because it was torn down. This is less of an issue the deeper the application digs though. And, pruning can be made to only take affect when it is necessary. Though, doing so would mean that possible game states for pruning would have to be marked so as to not prune off a game state that is marked as a loss, but the previous state could have taken an alternative route to a win. Or, it could be that each game state marked as a loss would have to be checked to see if all children of that game state are already stored as a loss. If so, the children can be cut off. This means recalculating instead of storing which states should be pruned.

I know I said a lot, but basically if we take everything into account I believe the game can be solved.

• The application would run on an extremely fast cpu such that it can serialize/deserialize millions of board states per second.
• The storage space would need to be very large and fast. The larger it is the less pruning and double checking would be needed.
• The scoring algorithm would have to be very well thought out.
• The computer would need to recognize which game states it should give up on (and possibly revisit since they are not marked as a loss yet) to manage its search time efficiently.

If the game of Connect4 only needs to have about 500K game states stored when it has a possibility of 1.6 x 10^13 total game states, I believe that chess can be solved if done properly is all. 

Whoo, took me 4 years to get that all off my chest.