Author: Dave Gomboc
Date: 12:42:46 05/15/99
Go up one level in this thread
On May 15, 1999 at 14:38:41, Andrew Dados wrote: > >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 Good point. Some indication of positions that have been reached once and twice already would have to be preserved for full generality. Of course, this probably kills all hope of a representation as small as we have been considering when not describing a sequence of such positions (e.g. a game). Dave
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.