3 ms·

He said he would accept multiple files; he did not however agree to change the rules of the game, which unambiguously required "a decompressor and a compressed

by rprasad 14y ago

He said he would accept multiple files; he did not however agree to change the rules of the game, which unambiguously required "a decompressor and a compressed file." A compressed file, as in a single file, which has been compressed. Patrick returned roughly 200 files, none of which were compressed. Thus, he did not complete the challenge, technically or legally. EDIT: This is the crucial part: the files were not compressed by gzip. They were merely collected into a single archive (no compression), and some of the data from each file was moved into the file's name (no compression). IOW, the archive size of each chunk of data was the same as the filesystem size.

Dylan16807 14y ago
Your rejection based on the rule change makes no sense. Mike very clearly agreed to a change in the rules of the game. "can I send you a [de]compressor and several compressed files whose total file size is less than the original uncompressed file and from which I can regenerate the original uncompressed file." "Sure" Also your rejection based on the files not being compressed is not going to work. I can get around it in only a few seconds of effort: Let's say I have a theory that gzip works more efficiently when you don't have too many 1 bits in a row. I make a script to extract all the 0xFF bytes and compress each chunk (I might have to strip headers or use a compression algorithm that's better at dealing with random data without expansion, but that's not a huge hurdle.). Is this compression somehow not good enough? It's definitely a meaningful transform of the original data, with the chunks coming out wildly differently. In fact allowing both a decompressor and a compressed file is a bad idea in the first place. If you get a sufficiently compact language and large file you can achieve compression on any file by the original wording. Split the data between the two files, this will give you n free bits based on where you split. Then make your decompressor, as part of some process subjectively qualifying as 'decompression', incorporate these extra bits. Mike should have simply said "a .tar with the compressed file and decompressor, which is smaller than the original file".

by rprasad 14y ago

Dylan16807 14y ago

Your rejection based on the rule change makes no sense. Mike very clearly agreed to a change in the rules of the game. "can I send you a [de]compressor and several compressed files whose total file size is less than the original uncompressed file and from which I can regenerate the original uncompressed file." "Sure" Also your rejection based on the files not being compressed is not going to work. I can get around it in only a few seconds of effort: Let's say I have a theory that gzip works more efficiently when you don't have too many 1 bits in a row. I make a script to extract all the 0xFF bytes and compress each chunk (I might have to strip headers or use a compression algorithm that's better at dealing with random data without expansion, but that's not a huge hurdle.). Is this compression somehow not good enough? It's definitely a meaningful transform of the original data, with the chunks coming out wildly differently. In fact allowing both a decompressor and a compressed file is a bad idea in the first place. If you get a sufficiently compact language and large file you can achieve compression on any file by the original wording. Split the data between the two files, this will give you n free bits based on where you split. Then make your decompressor, as part of some process subjectively qualifying as 'decompression', incorporate these extra bits. Mike should have simply said "a .tar with the compressed file and decompressor, which is smaller than the original file".