Author: Dann Corbit
Date: 15:59:35 01/29/02
Go up one level in this thread
On January 29, 2002 at 18:21:07, Vincent Diepeveen wrote: >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. Les is using the wrong terms here. What he means is that the ending database will be small. Currently, his toy system just uses text '0' and '1' instead of bits. >>>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. It's interesting as a Gedankenexperiment, if nothing else. Fresh thinking is always worth pondering. >>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. What if it stores different information? >>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. Not if you know how to use it. To create the entire set from any of its members is a trivial exercise. >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. This experiment won't show how many positions are in the game of chess. Current estimate range from 2^162 and 2^100. If you can find an experiment that will prove the right answer, everyone will be interested to hear it. In the meantime, this experiment of Les' has no connection with that idea at all. >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. That's right. He gets a drastic reduction. There is (of course) a cost to using not only reflections in every direction but also even adding every sliding move to the target square. The cost is that the score is only a limit (and therefore inexact). However, we don't cry about it when our alpha-beta search gives us a window instead of a number. What we have here is a method to have an enormous compression but it gives only a limit instead of an exact value. If that limit happens to be "you can mate from here in 8 moves" or "you can draw from here by moving to this square" then perhaps the information is useful. >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. Left, right, up, down, swap colors, move the sliding piece from up to 15 different target squares -- ALL SORTS OF STEAMY PERVESION!!! >Secondly your storing. You do not come further than 250 bits though, >even a beginning college student can do better soon than that... Exactly. I have a 192 bit minimum storage method (which I did not try all that hard at) and I know of others who have done even better. The original position compression matters not at all. From any of these position encoding schemes, we can generate all of the other moves. In fact, what it really means is that Les' idea works far better than he ever imagined. >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. Good point. Perhaps he should say something like "this is just an example" so that people won't get confused. >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. I never did like the Oracle way of forcing you to say how big the database is to start with. Which brings up another interesting point about Les' database format... You can put any amount of data you want in it (even a subset of the actual solutions) and then start using it right away.
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.