Author: KarinsDad
Date: 21:59:51 08/19/99
Go up one level in this thread
On August 19, 1999 at 23:01:19, Ricardo Gibert wrote: [snip] >Presumably, with 17 cases, you would in effect be dividing up one database into >17 databases. Which one you look in is determined by the search key. Example: >The position I am looking for has 4 pawns so I look in database 4 + 1 = 5th >database. > >Karinsdad is gradually getting more aggressive with this technique to achieve a >more compact form, but he is not really encoding positions in fewer bits, >whether it 160 bits or or 128 bits or whatever, since you must not forget the >bits encoded "by location". > >At first it seems you are getting something for nothing, but you are really >making a trade off at the expense of simplicity, time and flexibility. You must >manage more cases. 2^180 cases is an example of over doing it. Inefficiencies >can develope when you divide up the "cases" in a way such that only a few are >being used most of the time and the other cases use up time and space for little >return. The trick is how to divide things up. The dividing up into cases is a >kind of sort, which is preserved by the database itself to save spacein its >storing of values. I think you misunderstand. Although I have 351 cases, I am using a series of algorithms based on the data. The data determines which case it is in. There are no inefficiences since each case uses the portions of the algorithms that it needs, but not at the expense of any other case. It does not matter if you used it for a database of promotions or a database with no promotions or no database at all and just used it for one position. There is no case 1 stored at this location in a database since there is no database. Case 1 is determined via the structure and the data contained within that structure. From the algorithm's point of view, there is no case 1. Cases 1 to 351 are merely the way I broke it down in an Excel spreadsheet to prove that I didn't miss any possibilities. That's all. It's not as if a program written to do this would have a 351 element Select statement within it. Additionally, my algorithms are not that much more complex than the standard 24 byte algorithms such as the ones used in EPD (at least programatically). From a computer's point of view, my algorithms would only take a slightly greater amount of time to decode the position than decoding a random 24 byte position stored in EPD. Why? Because the majority of the bits have a one to one correspondence to some "real" element of the position (such as where pieces are located or what color a given piece is) and only a few bits are actually used to do "encoding tricks". KarinsDad :) PS. I really think however that I have come close to the limit (using this type of technique). There is only so much crap that can be fit into a 5 pound bag.
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.