Author: Vincent Diepeveen
Date: 16:54:33 04/02/04
Go up one level in this thread
On April 02, 2004 at 19:32:36, Uri Blass wrote: >On April 02, 2004 at 19:14:22, Vincent Diepeveen wrote: > >>On April 02, 2004 at 18:36:56, Uri Blass wrote: >> >>>On April 02, 2004 at 18:17:23, Uri Blass wrote: >>> >>>>On April 02, 2004 at 17:56:58, Robert Hyatt wrote: >>>> >>>>>On April 02, 2004 at 16:22:19, Jonas Bylund wrote: >>>>> >>>>>>Thank you very much for your detailed answers! >>>>>> >>>>>>When you say Diep already runs in windows mode, does that mean that it runs DOS >>>>>>or "real" windows mode? (sorry about not being clear on that in my original >>>>>>post) >>>>>> >>>>>>10GB for all the 3+4+5+6 tb's would be a HUGE success as would 20GB of course! >>>>> >>>>>It is also "vaporware". 3-4-5-6 tables will _not_ fit into 10 gigabytes. >>>> >>>>Yes but it is possible that tables that are enough to play 3-4-5-6 perfectly may >>>>fit 10 gigabytes. >>>> >>>>Suppose that you have tables that have only 1/32 of the information in the >>>>original 6-piece tables(it has information about exact distance to mate only if >>>>the index of the position is divisible by 32). >>>> >>>>You can still use them in 1/32 of the positions in case that the index of the >>>>position is in the table. >>>> >>>>In case that the index of the position is not divisible by 32 you can search >>>>forward and in order to check if the index of the position is divisble by 32 you >>>>do not need to look at the table. >>>> >>>>Now the question is if programs who use the smaller tables can practically play >>>>6-piece positions perfectly or cannot do it. >>>> >>>>Uri >>> >>>Note also that nalimov admitted that he had no time to work on more efficient >>>table for 6 pieces and the question is also how much can you compress the tables >>>thanks to symmetry. >> >>Ever thought about how many possibilities there is to just compress 1 file? >> >>Take for example a PPM algorithm that knows about how your scheme works. >> >>Compression is a science in itself, actually IMHO more complex than >>computerchess because you do not have infinite system time to compress real huge >>files (like the big 3.6GB egtb files from DIEP). >> >>Chess has a limited number of positions possible. Latest ICGA journal estimate >>was 10^43. >> >>I do not say there is more than 10^43 possibilities to compress a 3.6GB file >>optimal. >> >>>In any case win/draw information can also be productive and in second thought I >>>think that programs may fail in playing perfectly with only 1/32 of the >>>information. >> >>You could convert the nalimov's for example to a format having >>mate in 30, 31 .... n >> >>and everything under mate 30, so mate in 0 .. 29, you put it as 'mate'. >> >>You will figure out that you can play near perfect with that real soon. >> >>Sometimes a mate in 33 will get 34. >> >>I tried several maximin positions with diep without EGTBs and diep still mated >>there very near optimal. That to my own surprise. Now imagine if you have >>bittables available, there is 0% chance (not a perfect 0 but rounded 0) that it >>will *not* mate :) >> >>Of course you will figure out a theoretic situation which simply will not occur >>in practice. Just try it and you'll see. >> >>The chance that you will manage to escape to a 50 move rule is like 0.00000001. >>I just do not see it happen in reality. >> >>For a start you need to get into KNN versus KP or something. >> >>Something really spectacular and always with 2 knights involved :) >> >>Just calculate from the TBS files how many draws there are *because of the 50 >>move rule*. >> >>Reality is simply that not doing probes last few plies in the search is giving a >>factor zillion more chances for incorrect behaviour than this :) >> >>>I thought that only 1/2 of the information may be enough becase it is enough to >>>know positions when it is white to move so by the same logic only 1/32 may be >> >>Note it is a mystery to me where you got factor 32. >> >>Nalimov stores the hard ones in 2 bytes a position, diep stores 5 positions a >>byte. >> >>Factor 10 savings. >> >>All egtbs with 1 byte a position for nalimov, it is a factor 5. > >I guessed that it is possible that you have also better compression of >tablebases (for example when the result is almost always win for the stronger >side) so I guessed factor of 32. > >> >>>enough if you search deeper but in another thought I think that it is not so >>>simple because the position when white to move may get index divisible by 2 but >>>when I go only to divisble by 4 I cannot take care that the position of mate in >>>x when x is even will get index that is divisible by 4. >> >>You should not be busy too theoretic. >> >>What do you want to do. Win the game, or play perfect chess? >> >>I want to win. > >You said in another post that today tablebases are not very important for that >purpose. The influence of EGTBs in games has reduced a lot indeed. When i would've had working EGTBs in februari 1999 i would have won the ipccc1999. Now the influence of EGTBs is not so big. Most tournaments i see no difference. But it is interesting to have them. For a high level computerchess they are really not so interesting anymore as they were. >> >>You? >> >>You want to buy in a few years a 2 TB harddisk to store all 6 men and then you >>go have a try whether that's better than my 7 men? > >No > >I thought about the possibility not to use all the information in the nalimov >tablebases but only part of it. > >Uri Yes i already had posted that a few months ago here. In order to play perfect you need not so much info. Any top engine can find a mate in 16 hands down. You can rid of all those values. If your only interest is to win a won endgame, then w/d/l is fine. With regards to compression factor. Uncompressed all 5 men in diep format are a bit less than 1 TB (a bit less than 5.22T entries). That includes 5 vs 1. So to get it to 10GB a compression of a factor 100 is needed. Not 32. I am not sure you saw the initial post. I hope you realize that the influence of the 5 vs 1 in that 1 TB is for a part dominated by 5 vs 1. They are a lot of bytes uncompressed. But compressed you can not even fill a single cdrom with it. It's all wins. They will for the vaste majority compress to a few hundreds of kilobytes or a few megabyte at most. So 9.5GB left or so to compress the rest to. You know the 3-5 men is a couple of hundreds of files too. the 42 without pawns is a peanut too. the 42p is not so hard either. the 33p and the 33 are by far hardest to compress well.
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.