Author: Robert Hyatt
Date: 10:10:44 11/12/01
Go up one level in this thread
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... >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.