Author: Andrew Dados
Date: 11:38:41 05/15/99
Go up one level in this thread
On May 15, 1999 at 14:16:14, KarinsDad wrote: >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 :) Thanks for taking time on that. Main difference seem to be applications. Your schema is excellent for sequentially accessing large sets of positions because it will save *a lot* of space. Random access, as in hashtable, requires all that saved space to be allocated anyway, so that was my point... Also working on 4 bit 'nibbles' as opposed to variable length bit stream is less pain. As of ep/move by rep etc: Define pieces: P,N,B,R,Q,K,EP,CR. (All pieces fit in 3 bits for type + ! bit color) CR is rook with castle rights (including kings rights). Ep is a pawn which can be EP captured.. 1) I simply replace pawn by EP if it can be ep captured. 2) I rethought and came up with repetition mark: make king for side not to move EP as well; since king *must* exist this is not so complicated... One thought here : not much help from repetition info for one single position while our next move can put us in 3-rep :). So this is for 'art' purposes mainly, imo. (unless all moves from last non-reversible position are included no full position description is given, anyway). Andrew
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.