Author: Nino
Date: 14:40:54 01/04/02
Go up one level in this thread
On January 04, 2002 at 17:17:32, Dann Corbit wrote: >On January 04, 2002 at 17:10:42, Nino wrote: >>On January 04, 2002 at 05:14:16, Dann Corbit wrote: >>>Suppose that we want to make a tablebase file that is not quite so good as a >>>Nalimov tablebase file, but it still gives us a lot of information and is very >>>compact. Let's consider this winning position >>>[D]r6r/8/8/3k4/8/3K4/6R1/4QR2 w - - acn 2125; acs 0; bm Qe4+; ce 32760; dm 4; pv >>>Qe4+ Kc5 Rc2+ Kb5 Rb1+ Ka5 Ra2#; >>> >>>Now, as anyone knows, the queen being a sliding piece with a lot of available >>>options, any of these positions will result in the same sort of direct mate in >>>4, because we will arrive at the same position, or a mirror of it: >>>r6r/8/8/3k4/8/3KQ3/6R1/5R2 w - - ce 32760; pv Qe4+; >>>r6r/8/8/3k4/8/3K4/4Q1R1/5R2 w - - ce 32760; pv Qe4+; >>>r6r/8/8/3k4/8/3K4/6R1/4QR2 w - - ce 32760; pv Qe4+; >>>r6r/8/8/3k4/5Q2/3K4/6R1/5R2 w - - ce 32760; pv Qe4+; >>>r6r/8/8/3k4/6Q1/3K4/6R1/5R2 w - - ce 32760; pv Qe4+; >>>r6r/8/8/3k4/7Q/3K4/6R1/5R2 w - - ce 32760; pv Qe4+; >>>r6r/8/8/3k4/1Q6/3K4/6R1/5R2 w - - ce 32760; pv Qe4+; >>>r6r/8/8/3k4/Q7/3K4/6R1/5R2 w - - ce 32760; pv Qe4+; >>>r6r/8/8/4k3/8/3QK3/1R6/2R5 w - - ce 32760; pv Qd4+; >>>r6r/8/8/4k3/8/4K3/1R1Q4/2R5 w - - ce 32760; pv Qd4+; >>>r6r/8/8/4k3/8/4K3/1R6/2RQ4 w - - ce 32760; pv Qd4+; >>>r6r/8/8/4k3/6Q1/4K3/1R6/2R5 w - - ce 32760; pv Qd4+; >>>r6r/8/8/4k3/7Q/4K3/1R6/2R5 w - - ce 32760; pv Qd4+; >>>r6r/8/8/4k3/2Q5/4K3/1R6/2R5 w - - ce 32760; pv Qd4+; >>>r6r/8/8/4k3/1Q6/4K3/1R6/2R5 w - - ce 32760; pv Qd4+; >>>r6r/8/8/4k3/Q7/4K3/1R6/2R5 w - - ce 32760; pv Qd4+; >>>5r2/6r1/3kq3/8/3K4/8/8/R6R b - - ce 32760; pv Qe5+; >>>5r2/4q1r1/3k4/8/3K4/8/8/R6R b - - ce 32760; pv Qe5+; >>>4qr2/6r1/3k4/8/3K4/8/8/R6R b - - ce 32760; pv Qe5+; >>>5r2/6r1/3k4/5q2/3K4/8/8/R6R b - - ce 32760; pv Qe5+; >>>5r2/6r1/3k4/6q1/3K4/8/8/R6R b - - ce 32760; pv Qe5+; >>>5r2/6r1/3k4/7q/3K4/8/8/R6R b - - ce 32760; pv Qe5+; >>>5r2/6r1/3k4/1q6/3K4/8/8/R6R b - - ce 32760; pv Qe5+; >>>5r2/6r1/3k4/q7/3K4/8/8/R6R b - - ce 32760; pv Qe5+; >>>2r5/1r6/3qk3/8/4K3/8/8/R6R b - - ce 32760; pv Qd5+; >>>2r5/1r1q4/4k3/8/4K3/8/8/R6R b - - ce 32760; pv Qd5+; >>>2rq4/1r6/4k3/8/4K3/8/8/R6R b - - ce 32760; pv Qd5+; >>>2r5/1r6/4k3/6q1/4K3/8/8/R6R b - - ce 32760; pv Qd5+; >>>2r5/1r6/4k3/7q/4K3/8/8/R6R b - - ce 32760; pv Qd5+; >>>2r5/1r6/4k3/2q5/4K3/8/8/R6R b - - ce 32760; pv Qd5+; >>>2r5/1r6/4k3/1q6/4K3/8/8/R6R b - - ce 32760; pv Qd5+; >>>2r5/1r6/4k3/q7/4K3/8/8/R6R b - - ce 32760; pv Qd5+; >>> >>>Now, if we take these positions, and lexically sort them, we can store the >>>minimum one into a database and be able to generate all the others from it. >>> >>>Then, if we have some position and want to see if it is stored in the database, >>>we could simply perform the same transformation and lookup the lexically >>>smallest entry to see if it exists. We know that for any analysis our database >>>contains, the best move will be at least as good as the value stored (there >>>might be a better move, but the selected move will be "At Least" as good as the >>>presented analysis. >>> >>>As you can see, this would also allow partial database files, and it will allow >>>their use before they are completed. >>> >>>The data can therefore be remarkably compressed in some instances. I have no >>>figures for averages, as I have not carefully studied it yet. But in the >>>position above, a single EPD string maps to 32 answers. Therefore the net >>>storage needed for that particular position is 1/32 times the size of a binary >>>EPD record. >>> >> >>Dan how can this be possible?? You cant store all that information in so few >>bits. What you are saying basically is impossible. Computer 101 says that a >>bit can only have 2 states ...etc etc. Any other commnets from members out >>here? Since I dont see any they are probably laughing about this "NEW IDEA" >> >>Perhaps it is time for you to explain this in a bit more detail or am I the only >>one who does not understand. > >It gets even stranger. Suppose that you have 100 positions that result from >that 64 bit key. Each position will require less than a single bit on average. > >The information is fuzzy information, in that it is not perfect. There might be >a shorter mate (for instance). But one single key can hold all the information >needed for a whole cluster of positions. One of those things to file under >"strange but true" -- have you looked at the folder in the FTP site here: > >>>Here is some information on the idea, which came from Les Fernandez: >>>ftp://cap.connx.com/pub/les/Least/ Listen I dont have a programming language on my system. Is there any way you can send me just an exe file of this app?? I would be curious to see this demo. BTW when you say "fuzzy" do you mena inaccurate?? And if so how can we count on that??? > >In particular, this file: >ftp://cap.connx.com/pub/les/Least/egtbc.ppt > >is a powerpoint presentation that explains how it works. Furthermore, the VB >application with source code in that same folder is a *working* demonstration of >the idea. He has not added a filter to remove illegal moves (I am just using >KKE for that right now) but you can easily see how it works. > >>>A very nice thing about this sort of database is that it is fairly easy to >>>produce partial files with lots of pieces in them.
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.