Author: Vincent Diepeveen
Date: 15:21:07 01/29/02
Go up one level in this thread
On January 29, 2002 at 02:23:12, Les Fernandez wrote: >On January 29, 2002 at 01:56:59, Angrim wrote: > >>On January 28, 2002 at 19:41:07, Les Fernandez wrote: >> >><big snip> >> >>>Hello Vincent, >>> >>>I actually was not trying to be funny. The novelty is the fact that variants >>>can be extracted from one position, not just mirrored images. Therefore all you >>>need to have in your database one of these key positions and you get all the >>>rest for free. Anyway from a storage point of view it could be of interest >>>since storage is becoming a concern as new egtb's are generated. I played >>>around with 175,168 positions represented in binary (only 3 pieces KRk) and >>>after pkzip was used file size went from about 12MB down to about 700K. >>>Granted >>>this was a text file at the moment, not long integer, but the compression >>>reduction I expect to be very good due to the fact the file is made up of only >>>1's and 0's. >>> >>>Les >> >>funny thing, there are only around 30k unique positions with KR vs K, >>so your 175,168 positions had to include a lot of duplicates. > >Actually there are in fact 175,168 unique positions for white to move and also >understand I am not speaking about compression! In fact I suspect these binary >key files to compress rather well. dead wrong. it will hardly compress as it is a 'key'. such keys compress very bad. >>From a storage point of view, the KRvK endgame table takes 6k >>compressed(per side to move) so until you can beat that you should not >>be talking about saving space for endgame tables. > >First of all I am not trying to compete against the egtb's concepts but keep in >mind that my understanding of them is that they only store only the needed you have to or you will be pathetic. >information to make the next move and DTM and not anything else. The work we do not ask for DTM or DTC, even win/draw/loss is acceptible, but its size must compete bigtime then with current EGTBs. >Eugene has done in this area has been outstanding and a tremendous effort. >Understand that what I am saying is I am able to store all the info about the >position,pieces,ce...... and I am able to generate variants of a particular >position (ie 20..30...40..100 in number) just from one position. This I think >will allow increasing the knowledge in our current databases that exist. >Les the whole theory you guys use is theoretical AND practical not ok. you have unique positions and you have after that mirrorred positions. you guys refedine 'unique' positions to unique + mirrored. This is wrong. secondly for the number of positions in chess it is interesting to know in how many bits you can store ONE position, not how many times you can mirror that position, as this has nothing to do with storage. If you can do it in 162 bits, then obviously there are at least 2^162 positions. If you say i can mirror it 4 times it doesn't mean you can store the stuff in 2^81 suddenly, because every person understands that mirroring only reduces the database lineair whereas your math reduces it exponential. In fact you take the 4th square out of it. in most cases or more. If there are 2^162 board positions (mirrored + unique) and i mirror it a bit then i can reduce perhaps by a factor n, which will however never be 2^81 like you guys assume if you can mirror to the left and right. Secondly your storing. You do not come further than 250 bits though, even a beginning college student can do better soon than that... Last but not least the paper is very unclear written, which is logical otherwise you would not be able to let dissappear 2^81 from the searchspace. Once the number of positions is determined for a certain piece configuration you can of course create a database of that size and start storing win/draw/loss information (mate in how much is IMHO irrelevant). which is a bit less than 2 bits and a bit more than 1 bit to store positions. Vincent >>Angrim
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.