4 ms·
I couldn't read this without thinking of πfs (Pi FS). Pi being an irrational number contains all other numbers. Therefor rather than sending someone a file (eg
by BuildTheRobots 7y ago
I couldn't read this without thinking of πfs (Pi FS).
Pi being an irrational number contains all other numbers. Therefor rather than sending someone a file (eg a video) all you need to do is search the never-ending π and send people the offset instead. 100% compression here we go.
https://github.com/philipl/pifs/ https://github.com/philipl/pifs/
In reality though, searching through Pi to find that offset - especially for bigger files, can take a while.
- noiv 7y agoIs the offset of an arbitrary sequence in PI really shorter than the actual sequence?
- anoother 7y agoNo
- rytill 7y agoNailed it
- Cpoll 7y agoThere 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 agoThat 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 agoIt 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 agoSame 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 agoIndeed, I see that problem now. Very interesting story as well, thank you.
- heavenlyblue 7y agoSo on average this offset is going to take as many bytes as the output data
- Cpoll 7y agoAgreed, I overlooked this obvious fact.
- DonHopkins 7y agoOr you could just be extremely finicky about the numbers you choose to compress.
- Oblouk 7y agoThis 100% Given first 500 digits: 3.1415926535897932384626433832795028841971 6939937510582097494459230781640628620899 8628034825342117067982148086513282306647 0938446095505822317253594081284811174502 8410270193852110555964462294895493038196 4428810975665933446128475648233786783165 2712019091456485669234603486104543266482 1339360726024914127372458700660631558817 4881520920962829254091715364367892590360 0113305305488204665213841469519415116094 3305727036575959195309218611738193261179 3105118548074462379962749567351885752724 89122793818301194912 Let's encode: 10,72,7 //index, length 48,2|139,2|13,1 Even with a fixed length we run into the same issue.
- deleted 7y ago[deleted]