Author: Ricardo Gibert
Date: 18:45:45 01/30/02
Go up one level in this thread
On January 30, 2002 at 21:23:53, Dann Corbit wrote: >On January 30, 2002 at 21:17:55, Ricardo Gibert wrote: >[snip] >>I mistook your "mid-endgame" for "middlegame". My bad. >> >>But let's assume all you want to set up is a database of "only" 8-man positions. >>It takes 4 + 7*6 = 46 bits to represent each one. Rounding down that's about >>6E13 positions. >> >>Now lets say you set up your database with 10 trillion positions. We'll overlook >>the problem of populating it with information ;-) >> >>Thanks to a "brilliant" scheme that lets 1 position represent an equivalence >>class of say 100 positions on average, you only need to store 100 billion >>positions on disk at only one byte per position. That's an impressive 1E11 >>positions. >> >>But this means you will only have 1E11/6E13 = 1 in 600 chance of scoring a hit. >>How practical is that? >> >>It isn't. With Nalimov EGTBs, you *know* you will get a hit with 5 or fewer >>pieces to look up. With 8-man you won't. But let's say you get your hit, then >>what will you do on the positions following the current one. Do you expect to >>find those too in this database? >> >>Aside from my 2nd, 3rd & 4th paragraphs making some rather unreasonable >>assumptions to make things "close" for this new idea, what happens when we >>consider 9-man and 10-man databases? Kinda gets tougher doesn't it? > >I think you are right. 8-10 piece "approximate" tablebase files would be >problematic at best, unless someone comes up with a brilliant idea that makes >them work. > >I wonder (though) about fully encoding 7-man tablebase files with Les' idea. >Maybe they could become small enough to be practical. On the other hand, I >don't think you could effectively build them unless you had a Nalimov table to >begin with. Chicken needs the egg which needs the chicken. > >Maybe 6-men files then. It takes a ferocious amount of time and resources to generate 6-man. This "idea" multiplies" the amount of time required to create them. I too have come up with several ideas to increase their compressability, but they too suffer from the same problem of requiring an unreasonable amount of time to carry out for the bigger databases. There are probably zillions of ideas that do the same. The problem is finding the ones that speed things up rather than slow things down. Those are the ones that are hard to come by. Nalimov is no dummy. He too can think of such ideas. He's the expert and we're the amateurs. The other diffence between us and him is he has made his ideas work. Not so easy for us, unfortunately :-(
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.