Author: KarinsDad
Date: 11:16:14 05/15/99
Go up one level in this thread
On May 15, 1999 at 13:35:43, Andrew Dados wrote: > >ok.. so 25 bytes... If I now define 2 unused pieces (coded in 3 bits) as >'eppawn' and 'castle rook', and also use 'eppawn' somewhere for side to move >(impossible) to flag repetition I also end up in 25 bytes fixed size.. means in >all hash applications, where all it counts is maximum size (cause of fixed >record size) we end up even :). While coding such a schema versus yours is *way* >less pain... always lazy I was.... > >-Andrew- Yes, excellent! I was hoping you would see the white space in your schema and use it to compress. You have 4 unused pieces left in your schema (the blanks are handled by the bitmap and there are 12 different colored pieces on a chess board). So, you use up one of these 4 with a castle rook (color does not matter since you know the color based on location). You use up one of these 4 with an EP pawn (color does not matter since you know the color based on location). The EP pawn can be used for side to move if it is on a proper pawn location bit in the bitboard if there is EP and on a not possible EP pawn location (for example, maybe the king) in the bitboard if there is no EP. This is a little tricky since you could have the king on a legal EP square with pawns around him, so you have to find the king in the data first. If he is not there, then it is not an EP pawn, but rather the king. But, this is doable. So, you dropped 4 bits out for castle rooks and 4 bits out for EP. However, how do you handle move by repetition? I do not understand what you wrote. I could see using the first king for one of the bits of the move by rep and the second king for the other bit for move by rep, but you would have to use up both of your remaining unused pieces to do this. And of course, if a king is being used for EP, it cannot be used for move by rep and vice versa. So, this would work. But consider the following. Is your code REALLY that much easier to write and debug? It is starting to get a lot more complex than originally. Granted, you have fixed sizes for your piece table portion (all of them are 4 bits), but you are having to juggle a lot more info in more complex manners than in your original simpler manner. And although both of our schemas can handle all possible positions in 25 bytes, the one Eugene and I wrote about can REALLY handle all POSSIBLE positions from real games in 23 bytes (actually, it can do it in 22 bytes for all intents and purposes). It would be interesting to examine a 10 million game database and see if all positions in it could be handled in 22 bytes. My money is on the opinion that a position WOULD NOT be found that breaks the 22 byte model (however, two players could play a game that could not be handled in 22 bytes if their sole purpose was to break the model, but it would be an extremely bizarre game). Upping our schema to 23 bytes increases the confidence by many many many orders of magnitude. KarinsDad :)
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.