Author: Dann Corbit
Date: 18:23:53 01/30/02
Go up one level in this thread
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.
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.