Chessdb.cn Chess
Ashely Wolfgram
Where would one find the "30-move analysis" online?? (of different openings). In other words::
WHERE IS THE 30 MOVE ANALYSIS OF THE RUY LOPEZ???
WHERE IS THE YUGOSLAV ATTACK THEORY??
WHERE ARE THE KING'S INDIAN DEFENSE THEORY LINES???
WHERE???????????
if you have a chess engine that uses the common UCI, like the one fritz, komodo, houdini etc use, its all on the cloud under opening moves.
or else use an opening database like chesstempo. IF you really want to overkill it, get the latest version of chessbase database.
You see, firstly, when I play my first game of the day, I win (It is reealy easy against players of these ratings). So I get tempted into playng more games, in which I play without thinking properly, & lose half a dozen.
ChessDB is a free chess database which can be used on Microsoft Windows, Linux, Apple Macs running OS X, FreeBSD, as well as most if not all modern UNIX versions. The program has translations into English, Spanish,Czech, Dutch, French, German, Hungarian, Italian, Norwegian, Polish, Portuguese, Russian, Serbian and Swedish. The documentation is excellent, although currently most is only in English, but this situation is changing rapidly.
ChessDB is based very heavily on the highly successful Scid which was the premier free chess database. There are a large number of features.in ChessDB. It is not a cut-down/light/crippled (call it what you want) version of an expensive commercial product, butyou get a complete fully functional program.
As you can see, there are a number of chess databases around. There can be little doubt that at the time of writing (May 2011), there is no better free database. Whether things like Chessbase are better depends on who you talk to.
The Chess Tempo Chess Database provides over two million searchable chess games. The database can be searched via many criteria, including chess players, chess opening, player ratings, game result, and the year the chess game was played. Chess opening statistics can been viewed on the display to the right of the board. To search the chess database, either enter your criteria into the quick search box or use the advanced search by clicking on the advanced search label. To see the chess games in the database for the current position, click on the "Games for Position" tab. You can start from any position by using the paste FEN/moves button directly below the chess board. By default, the database only shows chess games where both players were rated over 2200, you can change the database subset using the database selector at the top of the page.
One of the discussants talk about encoding pieces on a square matrix, using 4 x 64 bits plus some bits more for the additional information (castling, en passant etc):there are six pieces (Pawn, Rook, Knight, Bishop, Queen, King) plus an empty square, that would be 3 bits (2^3), and one more bit for the color of the piece.
There are 32 pieces on the board, and 64 squares. Square index can be represented with a 6-bit number, so to represent the locations of each piece you need 32 six-bit numbers, or a total of 192 bits, which is less than 4x64.
You can do a bit better by realizing that not all positions are possible (e.g. a pawn cannot reach the end row of its own color) and using less than six bits for the position in these cases. Also, a position already occupied by another piece makes that position unavailable for other pieces.
As a piece may also be totally missing from the board, you should start with the kings' positions, as they are always there - and then, encoding another piece's position as the same of a king would mean that the piece has been taken.
Thus, this set of legal chess positions can be described trivially with an integer from zero up to (64^12 * 32^4 * 21^4 * 26^4 * 30^4 * 32^8)-1, or 391935874857773690005106949814449284944862535808450559999, which fits into 188 bits. Encoding and decoding a position to and from this is very straightforward - however, there are multiple numbers that decode into the same position (e.g. white knight 1 at B1 and white knight 2 at G1; and white knight 1 at G1 and white knight 2 at B1).
Due to the fact that no two pieces can occupy the same square, there is a tighter limit but it is a bit difficult to both encode and decode, so probably not useful in a real application. Also, the number shown above is pretty close to 2^188, so I don't think even this tighter encoding would fit into 187 bits.
If you do not need a decodable position representation for comparisons then you could look at Zobrist hashing. This is used by chess engines to produce a 64 bit oneway hash of a position for spotting transpositions in search trees. As it is a oneway hash you obviously cannot reverse the position from the hash. The size of the hash is tunable, but 64 bits seems to be the accepted minimum size that results in few collisions. It would be ideal as a database index key with a fixed length of just 8 bytes. As collisions, though infrequent, are possible you could do a second pass comparing the actual positions to filter out any positions that have hashed to the same value if it is a concern. I use Zobrist hashes in one of my own applications (using SQLite) that I use to manage my openings and it has no trouble in finding transpositions.
Segment 4En passant target square in algebraic notation. If there's no en passant target square, this is "-". If a pawn has just made a two-square move, this is the position "behind" the pawn. This is recorded regardless of whether there is a pawn in position to make an en passant capture
You could use a modified run length encoding where each piece is encoded as a piece number (3 bits), with 0y111 used to skip ahead spaces. As there are many situations where pieces are next to each other, you end up omitting the positional information:
That being said, the additional complexity and uncertainty of a variable length encoding is probably not worth the space savings. Further, it may be worse than a constant width format in certain plays.
32 bytes (4*64 bits) is quite small amount of data. 1000 million chess positions could fit in to 30 gigabytes. 192 bits is 24 bytes this would make in to 23 gigabytes. Probably database use some kind of compression and thus the in disk might be less than these figures. I don't know what kind of limits there are for storage, but because these seems quite tight encodings it might not be worth the effort try to minimize more.
Because ability to find similar positions was required I think the encoding should make it easy to compare different positions. Preferably this could be counted without decoding. For this to work the encoding should probably be constant length (can't think easy way to do this with variable length coding).
Indexing might speed up similarity search. Naive approach would be index all the positions by piece locations in database. This would make 32 indexes (and maybe for additional information also). It would make the search lightning fast at least in theory.
Indexes are going to take quite much space. Probably more than the actual positional data. And still they might not help that much. For example finding positions where black king is in, or near e4 required 9 searches using the index and then hopping around the 30 gigabytes of positional information which is likely need disk access in random locations. And probably finding similar positions is done for more than one piece...
If the storage format is efficient it might just be enough to brute force (like this)through all positional data and check the similarity position by position. This will use the CPU caches efficiently. Also because of the constant length record it is easy to divide the work to multiple processors or machines.
Whether to use piece-centric or board-based storage format depends on how you are going to calculate the similarity of two positions compared to each others. Piece-centric gives easy way to calculate distance of one piece in two different positions. However in piece-centric approach every piece is identified separately thus it is not so easy to find a pawn in certain location. One has to check every pawns location. If the piece identity is not so important, then board-based storage makes it easy to just check if a pawn is in wanted location. On the other hand it is not possible to check which exact pawn there is.