George, you are replying to some messages that are one year old. IIRC, we were trying to figure out how to pack things more efficiently.George Tsavdaris wrote:I'm confused.michiguel wrote:Do not worry, the compressor will work on the uncompress files you have. I will later modify the generator to make the compressed.mhalstern wrote:A question for Miguel:
Do you have new Tablebase generating code ready that creates compressed files?
If this is coming shortly, I'd prefer to wait to generate the bases.
In addition, If I generate the uncompressed files, how much will 7-zip be able to compress them.
Thanks
Someone mentioned that 7z compress them to ~4Gb (Gabor, I think).
We have a generated uncompressed EGTB file. We compress it with your compressor with some scheme e.g 4 the default.
We get a compressed tablebase file ready to use with engines, that recognize it. Right?
Right i guess, but then you say we can compress it further with Winzip or 7zip in our case? Yes i understand that we can but the compressed file will have a .7zip extension, so would it be accessible for the engines to use it?? I find it very bizarre if it's true.
Or you say to compress it with 7zip in order to make the whole set of 3,4,5 to fit inside a DVD for example? And then decompress it with 7zip to take the 6.5 GB 3,4,5 compressed set and so engines to be able to use it?
What you need to know today w/o getting confused is:
You generate the uncompressed files --> ~38 GB.
You compressed them to .cp4 format --> ~6.5 GB.
That is recognized by the probing code. That is it, and that is what you find in Josh's site.
What I mentioned is that if you compressed the uncompressed files with 7z you go from 38 --> 4 GB. That is unreadable by the probing code, but it could be potentially used to deliver the whole thing in only one one simple DVD. You may need to decompress the entire set and compress it back with the .cp4 format to get the final 6.5 GB. It could have made sense in the past, nowadays it is probably not worth the trouble.
Miguel
