3 ms·

There are an infinite number of valid offsets, so you just keep looking until you find one that's sufficiently compressible, e.g. 10^10^10+42

by Cpoll 7y ago

jerf 7y ago
That does not work. Given the looooooooong history of people on the internet not believing that, I preemptively invite you to implement it. If you could make it work there's big money to be made. More constructively and with less effort, while https://cs.stackexchange.com/questions/42464/are-there-any-compression-algorithms-based-on-pi https://cs.stackexchange.com/questions/42464/are-there-any-c... on the surface doesn't seem to address your scene, if you think about it for long enough, you'll find it does.
- Cpoll 7y ago
  It wouldn't be practical even if I were right, but I see the issue with my logic. My reasoning amounted to "there are infinite repetitions of any sequence in Pi, therefore for any given sequence there must exist one occurrence with a compressible index." Which, after consideration, I acknowledge is incorrect :)
btilly 7y ago
Same problem. The amount of information that you need to specify a compressible offset plus the compressibility of said offset adds up to at least the amount of information you were trying to encode, and no compression happens. If you ignore either half of the information problem, you can get what looks like compression but really isn't. See https://www.patrickcraig.co.uk/other/compression.php https://www.patrickcraig.co.uk/other/compression.php for a fun story about "data hiding" to show exactly how sneaky the data hiding can be.
- Cpoll 7y ago
  Indeed, I see that problem now. Very interesting story as well, thank you.
heavenlyblue 7y ago
So on average this offset is going to take as many bytes as the output data
- Cpoll 7y ago
  Agreed, I overlooked this obvious fact.
DonHopkins 7y ago
Or you could just be extremely finicky about the numbers you choose to compress.

There are an infinite number of valid offsets, so you just keep looking until you find one that's sufficiently compressible, e.g. 10^10^10+42

by Cpoll 7y ago

There are an infinite number of valid offsets, so you just keep looking until you find one that's sufficiently compressible, e.g. 10^10^10+42

jerf 7y ago

That does not work. Given the looooooooong history of people on the internet not believing that, I preemptively invite you to implement it. If you could make it work there's big money to be made. More constructively and with less effort, while https://cs.stackexchange.com/questions/42464/are-there-any-compression-algorithms-based-on-pi https://cs.stackexchange.com/questions/42464/are-there-any-c... on the surface doesn't seem to address your scene, if you think about it for long enough, you'll find it does.

Cpoll 7y ago
It wouldn't be practical even if I were right, but I see the issue with my logic. My reasoning amounted to "there are infinite repetitions of any sequence in Pi, therefore for any given sequence there must exist one occurrence with a compressible index." Which, after consideration, I acknowledge is incorrect :)

btilly 7y ago

Same problem. The amount of information that you need to specify a compressible offset plus the compressibility of said offset adds up to at least the amount of information you were trying to encode, and no compression happens. If you ignore either half of the information problem, you can get what looks like compression but really isn't. See https://www.patrickcraig.co.uk/other/compression.php https://www.patrickcraig.co.uk/other/compression.php for a fun story about "data hiding" to show exactly how sneaky the data hiding can be.

Cpoll 7y ago
Indeed, I see that problem now. Very interesting story as well, thank you.

heavenlyblue 7y ago

So on average this offset is going to take as many bytes as the output data

Cpoll 7y ago
Agreed, I overlooked this obvious fact.

DonHopkins 7y ago

Or you could just be extremely finicky about the numbers you choose to compress.