Author: Ricardo Gibert
Date: 07:18:53 08/20/99
Go up one level in this thread
On August 20, 1999 at 00:59:51, KarinsDad wrote: >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. You're right, I misunderstand completely. Your description is too vague and I guess I'll just have to wait until you've worked it out entirely.
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.