I had an idea for a file transfer system based on digits of pi. You'd give everybody DVDs of digits of pi (or they could calculate them themselves) , and then transfer files faster by just sending them the offset into pi.<p>At the time I thought it could work with a big enough bank of digits of PI on both sides. If transfer was expensive, and calculating digits was cheap then you could give everyone an infinite supply of digits of pi and have a nearly infinite compression system.<p>I discovered that often the offset into pi is much larger than the data you are sending. Turns out it's an expensive way to sent things.<p>Also, it turns out that this area was already well understood. There are no free lunches with entropy.<p>But it was a fun idea to kick around.
I love the idea of this, it has certainly boggled my mind a handful of times when thinking of content-addressed storage. Obviously it can't work, there is no loophole to infinite space or compression. Entropy is a very real thing. But it did lead me down an interesting train of thought.<p>> maximise performance, we consider each individual byte of the file separately, and look it up in π.<p>Ok, so we store a byte and look it up in π. Now we get an offset. The exact offset will depend on the byte of course. But to simplify let's assume that π is "optimal". We will assume that the fist 256 offsets contain the first 256 bytes.<p>So our offset will be in the range 0-255. Storing our offset will then take 1 byte of storage.<p>Oh, I have found the problem.<p>So yes, you can find any data in π. But storing the location of that data will on average take the same amount of space as the data itself.
You can encode every book and information in a small rod. Just take a 1 meter long rod and encode your book into binary, eg 01011110111. Now, take your binary string, and transform it into a decimal number in base 2 by prepending 0. , E.g. x=0.01011110111. As this number is finite and smaller than 1, you can just take your rod and cut it at length x.
Now when you want to retrieve your information you just need to measure x from your rod with a ruler, take the decimal part and convert it into binary, and voila.
You can encode almost infinite amount of data into a simple rod. Assuming you can measure and cut very precisely
"That's right! Every file you've ever created, or anyone else has created or will create! Copyright infringement? It's just a few digits of π! They were always there!"<p>I didn't think that was actually mathematically proven yet. Was some proof accepted recently that makes that quoted sentence true?
Related:<p><i>πfs – A data-free filesystem</i> - <a href="https://news.ycombinator.com/item?id=28699499">https://news.ycombinator.com/item?id=28699499</a> - Sept 2021 (30 comments)<p><i>PiFS – The Data-Free Filesystem</i> - <a href="https://news.ycombinator.com/item?id=26208704">https://news.ycombinator.com/item?id=26208704</a> - Feb 2021 (1 comment)<p><i>Πfs: Never worry about data again</i> - <a href="https://news.ycombinator.com/item?id=21359338">https://news.ycombinator.com/item?id=21359338</a> - Oct 2019 (1 comment)<p><i>The π Filesystem for FUSE: Store Your Data in π</i> - <a href="https://news.ycombinator.com/item?id=19223032">https://news.ycombinator.com/item?id=19223032</a> - Feb 2019 (1 comment)<p><i>pifs - Avoid disk space usage by saving your files in the digits of Pi</i> - <a href="https://news.ycombinator.com/item?id=18687275">https://news.ycombinator.com/item?id=18687275</a> - Dec 2018 (1 comment)<p><i>πfs – A data-free filesystem</i> - <a href="https://news.ycombinator.com/item?id=13869691">https://news.ycombinator.com/item?id=13869691</a> - March 2017 (105 comments)<p><i>Πfs: Stores your data in π</i> - <a href="https://news.ycombinator.com/item?id=10856108">https://news.ycombinator.com/item?id=10856108</a> - Jan 2016 (1 comment)<p><i>Πfs: Never worry about data again</i> - <a href="https://news.ycombinator.com/item?id=10847693">https://news.ycombinator.com/item?id=10847693</a> - Jan 2016 (1 comment)<p><i>File system that stores location of file in Pi</i> - <a href="https://news.ycombinator.com/item?id=8018818">https://news.ycombinator.com/item?id=8018818</a> - July 2014 (98 comments)<p><i>100% Compression Using Pi</i> - <a href="https://news.ycombinator.com/item?id=6698852">https://news.ycombinator.com/item?id=6698852</a> - Nov 2013 (32 comments)
That's just use he library of babel all over again<p><a href="http://libraryofbabel.info/" rel="nofollow noreferrer">http://libraryofbabel.info/</a>
<p><pre><code> In this implementation, to maximise performance, we consider each individual byte of the file separately, and look it up in π.
</code></pre>
LOL so you get to store your data for free, and all it takes is allocating like 8 bytes for every byte. This project is galaxy brain
In this quintessential hacker news post and discussion we see:<p><pre><code> eating the onion
anecdotes of having the same idea
https://en.wikipedia.org/wiki/Normal_number
https://en.wikipedia.org/wiki/Pigeonhole_principle</code></pre>
> In this implementation, to maximise performance, we consider each individual byte of the file separately, and look it up in π.<p>Had me laughing out loud. Priceless!
<i>> You'll never run out of space again - π holds every file that could possibly exist!</i><p>This isn't necessarily true, right? AFAIK this only holds if pi is normal, which we haven't proven.
This is a fallacy. Infinity does not contain all possibilities.<p>There are an infinite number of integers. You can start at 10 and count up forever, never running out of integers. But no matter how high you count, you’ll never count to “orange” - “orange” is not contained in the sequence of infinite integers.<p>You’ll need to first prove that every sequence of integers is contained somewhere in pi, since the number of possible integer sequences grows faster than the “space” for sequences in pi. In other words, I can always pick a digit that creates a valid, non repeating, integer sequence from the pool of possible sequences while never creating the integer sequence “123456789123456789123456789.” You’d need to prove that pi doesn’t do this.<p>Even if pi does contain every sequence of integers and you could map that to bytes which, in turn, maps to a file, this would not compress.<p>Your metadata directory would be larger than the raw files unless you get very lucky and your file is very early in the sequence of pi.<p>A byte can represent 256 unique values. 256 unique values can not compress to less than a byte. So if your index is a digit of pi where your file starts, your file starts after some other number of files. Your index is going to be the index inside of the address space of “all possible files.” This will get large very quickly.
If I were to dumb this down (so I can understand it), is this a fair analogy to the adage "give 1 million monkeys 1 million typewriters and they'll eventually type the entire works of William Shakespeare"?<p>Somewhere in pi (at some insane offset) is the entire work of William Shakespeare.<p>Is that the basic idea here?
Wake me up when it's self-bootstrapped. This repo should contain the metadata for the source code of itself in pi. Or at the very least the metadata for "Everything can be stored in pie" in pi.
I personally thought this during my college days. Never pursued this idea but kept it my mind as a way to compress files and share just index to first meta data, which will then link to next and next and so on.
I irrationally think that I go to too much effort to make a point in our field with over-the-top clever stuff.<p>Nope, I’m undertraining. Get ready for TauOS.