Author: Tony Werten
Date: 22:55:52 11/12/01
Go up one level in this thread
On November 12, 2001 at 13:10:44, Robert Hyatt wrote: >On November 12, 2001 at 11:36:27, Dieter Buerssner wrote: > >>On November 12, 2001 at 09:37:23, Robert Hyatt wrote: >> >>>On November 11, 2001 at 21:42:56, Jeremiah Penery wrote: >>> >>>>On November 10, 2001 at 15:02:15, Robert Hyatt wrote: >>>> >>>>>Actually it may be bigger. 200mb is the size of the compressed tables. The >> ^^^^^ ^^^^^^^^^^ >>>> >>>>The size of the "four" directory on your FTP site is only about 30MB. If you >>>>store only W/L/D instead of distance to mate, you must be able to save at least >>>>half that much space. >>> >>> >>>They are compressed, remember. >> >>Yes. But Jeremiah rightfully pointed out that your number above is wrong. >> > >OK... I missed that line. I originally thought the 3/4 piece files were >compressed down to about 200mb. Because the original Edwards files were >_far_ bigger than that. If I recall correctly, the threes plus the fours, >plus KRBKR and KRNKR tables were around 2 gigs. > >I was off by a factor of 10 however, so 30 megs (compressed). Probably 200 >uncompressed. 50 or so for win/lose/draw. > >It _could_ be more than 50 for win/lose/draw depending on the indexing scheme >of course. > >>>And most are full of nothing but zeros (draws) >>>which compress to almost nothing. But for win/lose/draw it is not clear that >>>you would want to have them in a compressed form as the decompression would >>>be expensive, suddenly, since there would be no I/O if they are locked into >>>memory. If they are uncompressed, they are over 200 megs (from memory, I have >>>not done this in a long while). My first guess was that you end up with 50+ >>>megs, if not more, assuming you don't compress the 3/4 files... >> >>I don't know the compression ratio of the 4-men tables. However, I think, that >>it may be not that difficult for a modern computer, to store all of the 4-men >>tables in memory uncompressed as win/draw/loss, when using the same indexing >>scheme of the Nalimov tables. For the tables, where both sides can win, the >>space advantage compared to uncompressed Nalimov tables would be a factor of 5. >>In 1 byte, one could store 5 positions because 3^5 < 2^8. Many tables would only > > >The compression rate for 3-4 piece files is very high, because many of them >are simple draws. IE many are 2K bytes or less. Yet they obviously represent >tables of size 64^4th roughly. Which should be around 16 megs. The nalimov >indexing/compression certainly helps a _lot_ but not as much as the compression >done outside of the indexing. There is no reason compression on w/l/d could not >be done, but the current code wouldn't do it, and the nalimov indexing would >not be a direct port since it assumes one position per byte, not the compressed >form which would take some work to support. > >I think the Nimzo guys claimed that they took the "important" 4 piece files >and converted them to win/lose/draw and ended up with 16 megs... Kind of correct. They take 16 Mb in XiniX. The Nimzo guys compressed them and got it down to 8 Mb. Tony > > > > > >>need win/draw or loss/draw, which makes a factor of 8. Other tables may not be >>needed at all. For example KQQK with the Q side moving is allways a win (at >>least I think so). With the lonely K side moving, a table look-up may be >>substitited by a stalemate detection routine. Depending on the program, this can >>also be fast. >> >>Actually, using such w/d/l tables might mix very well with the interior node >>detection schemes discussed by Heinz. >> >>Regards, >>Dieter
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.