Live data from Hacker News

File system that stores location of file in Pi

github.com

101–102 of 102 posts

Re: File system that stores location of file in Pi

#101
I'm not sure I understand how this would compress files. I mean, the only way it could is if the decimal place in Pi at which the byte occurs is significantly less than the value of the byte itself. Statistically, this would happen less than 50% of the time, the other 50+% of the time occurring at a higher decimal place. I don't see this providing any real compression benefit.

For example, the byte 0xFF, which is the number 255, first occurs at the 1168th value of Pi.This means instead of storing 255, you're now storing 1168, or 0x490, requiring an extra half-byte. However, 0x328, or number 808, first occurs at the 105th value of pi, or 0x69, requiring one less half-byte.

How does this system provide better compression? The way I see it, the best case scenario would be if no sequence from 000 to 255 was ever repeated in Pi (or rather, not until every pattern in that sequence has been covered), in this case the compression ratio should be exactly 0%, no net gain or loss.

Re: File system that stores location of file in Pi

#102
post #100
post #87

Earlier quoted context omitted.

"It is flatly impossible to compress all data all of the time." Might I add "...such that the uncompressed data is recoverable." Pedantically speaking, any data passing through a cryptographic hash algorithm is being compressed.

Pedantically, that's not compression.

Indeed it is: https://en.wikipedia.org/wiki/One-way_compression_function
Post reply on HN