Genius Compression Algorithm

[A-Man]

Well, after some research, turned out I wasn't the first to think about it =( : https://github.com/philipl/pifs/tree/master/src

But well, the idea is to use the digits of any transcendental number as the memory. Since they're infinite, they're sure to contain every single combination of every data ever produced. Doing such would mean it might take a loot of time to find the perfect combination that represents the file you want to compress, but it would just be a simple reference that reproduces the sequence when the compressed file is run!! How small can that be!?

Some might argue and say that the index of the digit in the transcendental number that starts the sequence of your "compressed" data might be a number that is larger than your file itself! True; that is a flaw. The github project, which I posted its link above, had this idea of dividing bigger files into fragments. That increases the probability of "excavating" your data from Pi with a smaller reference, but they might be more; thus making the "compressed file", or actually the list of references and lengths of the fragments of your data within Pi, larger. Just imagine how far you would be able to compress your files or media!

What do you guys think?

[Kevin]

Hmm yeah, I think the size of the index of the digits must always be greater or equal to uncompressed format. The minimum number of bytes we need to represent a data depends on the number of possibilities. If we have 16 different possibilities and we describe them all by fragments of the PI number, there will still be 16 different possibilities of location in the PI, so as far as I understand, the fact that PI gives an infinite sequence doesn't help even a bit.

I'd think it'll only be useful to replace chunks which occurs often enough, since for example if we have 256 possible chunks which are to be replaced by a reference (i.e. the index of the sample sequence, damn I don't know the terms, hope it's understandable), then the reference itself needs 1 byte (plus, a flag may be required ? idk how it will induce costs). So it must replace only chunks that are large enough (which means most of the possible chunks won't have any replacement). And they will only be useful enough if these larger chunks really does occur in files.

Sorry if I was talking about something entirely different or obvious, I'm actually getting interested in this topic, I'm kinda new to this kind of stuff ;p .

[A-Man]

The fact that Pi has infinite number of digits would mean you would be able to redefine the whole file at once with simply an index and the length of your file. Imagine this file that contains 20,000,000,000 bytes of information. It is sure that the sequence of bytes occur in the digits of Pi, and once you find it, you're just going to store at what digit does it start and how long it is! So say you find all the bytes of your file in the perfect sequence at the 9123854128634893271093845928374892357236478324298375273642035203984718264782365208734623784th digit of Pi. Your 20,000,000,000 bytes file would just be represented by that index and the length. At run time, some equation I checked yesterday, derived from Tylor's work, can be used to easily reproduce your sequence from that nth digit of Pi!! And that's it! You've compressed your 20 GB file into a few KBs (or even bytes!)!!

Now since it would take a looot of time to find such a sequence, we're going to divide those 20,000,000,000 bytes into lets say 20,000 chunks (or even more if we want to process faster, but the compression % would be less) of 1,000,000 bytes each. References of the different chunks in Pi and their length can be what is in the new compressed file. Quantum computers are on the way, and their specialty is parallel processing; You would be able to divide the search work between a huge number of threads/processes with ease!

[Kevin]

wait, let's assume the numbers in PI are 100% random.

if we have a 3-digit number, the chance of any 3 random numbers to match exactly our number is (1 / 10) ^ 3 = 0.001, therefore in average our index will be 1000 (is this correct?). To describe the indexes 0 to 999, we need a 3-digit number D: .

So if we have a 10-digit number, our index would probably be around 10-digits too XD

[A-Man]

You're right !! Feel so dumb >.<
Did some tests that confirmed what you said:


But thanks for pointing that out!
~Solved....