-
Notifications
You must be signed in to change notification settings - Fork 291
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Misleading/Incorrect claim regarding compression. #57
Comments
It is compressed to 0, though. It's just some additional metadata that takes up the space. You could delete all that metadata and your files would still exist in pi. ;) |
And what about the program that is supposed to generate the digits of pi in order for the metadata to pull out the correct bits of data that make up the program? Also one's going to have to figure out where to store that metadata because we're certainly not going to remember all of the positions in the sequence of pi digits that makes up our files; so we do have to set aside some storage space for the metadata. Not to mention that if we're storing small files (I'd say about 50 KiB or less) then the metadata that tells the pifs where to find the right digits in the sequence of pi could turn out a larger filesize than just simply storing the binary data for said file as we do right now. |
((It does turn out larger)) |
@KimChoJapFan I would suggest you have a sense of humor though. πfs is more a mathematical toy that we can play with and have fun. It is not intended for practical use. |
@jeffli678 πfs may be fun but misleading information is not fun. There's no tangible method of gaining 100% compression as it would mean turning a file from any size into 0 bytes in size. |
No one claimed the program is 0 bytes, it's just that all your files are stored in the digits of π, which doesn't necessarily need to be contained on your disc. That's 0 bytes of information of that file stored on your disc, because it already exists. |
@Demonstrandum Okay; but one of the main functions of a filesystem is to be able to access the contents of a storage device, yes? So in other words I could just break in with Euler's Number or any other infinite sequence of digits and it'll be just as effective as using Pi to store the information. That's a nice sentiment but it won't be able to suffice as a filesystem if you can't access your data (the main function of a filesystem as mentioned earlier). Let me know how well you can retrieve the bits of information making up all of your files without knowing the locations within Pi that points to those bits (which is the "metadata" that we've been discussing in this issue for a couple of months now). |
The metadata doesn't actually count as part of the file's size usually, hence the claim of 100% compression. It's ment to be silly, and of course it's not efficient in any way, that's the point. |
@Demonstrandum That's the issue though, there's nothing in the readme for this project that signifies that this is meant to be silly or not meant to be taken seriously. The issue isn't with the idea as much as with the claim that it can reach 100% compression when we all know that it's impossible to compress any file to that extent. I'm not the only person on the internet to realize that 100% compression is not feasible: http://matt.might.net/articles/why-infinite-or-guaranteed-file-compression-is-impossible/ |
Ok, I think most people realise it satirical. Of course it's not really feasible, but people get the joke. It's a novelty filesystem. |
I don't know if that's the case considering many people have been taking the ordeal seriously and there have been "get rich schemes" in the past that worked on similar principles such as using hashing algorithms to store files and then relying upon the future of quantum computing to handle the reversal of said hashes to restore the original files. As much as I hate to say it; the author may want to have some stipulation within these files that reads that this is meant to be taken satirically and that it shouldn't be solely used to handle sensitive information. Even one of the largest sources of satire on the internet has a page that tells the reader that it's satire: https://www.theonion.com/the-onion-is-the-world-s-leading-news-publication-offe-1819653457 |
Oh, stop it. |
r/whoosh |
You seriously think this project needs an explicit mention of it being a joke even when it mentions that it plans to bring PI to the cloud? Do you have severe brain damage or something? |
Aren't all bit sequences available pretty efficiently through counting? I don't even think we need pi. |
The README states "They said 100% compression was impossible? You're looking at it!"
There's a fundamental flaw in this statement:
Compression % = 100 * ( 1 - ( Compressed Filesize / Uncompressed Filesize ) )
So for instance we compress 100 MB of data into a 20 MB archive, then we have a compression of:
100 * ( 1 - ( 20 / 100 ) ) = 100 * ( 1 - 0.2 ) = 100 * 0.8 = 80%
In order for us to have a 100% compression, we'd have to compress our files down to 0 bytes.
We still require massive amounts of storage to index the digits of pi and we still need storage space for the software that is supposed to calculate the digits of pi in order to retrieve our information.
So it's probably best to state that this method is almost 100% compression instead.
The text was updated successfully, but these errors were encountered: