Доброго времени суток. У меня вопрос к программистам по поводу реальности метода сжатия данных, который 
мне пришел в голову. Так как я сам не программист и не математик ), проверить работоспособность схемы не 
представляется для меня возможным. В кратце суть схемы на пальцах. С одной стороны есть бесконечное число десятичных знаков числа "Пи", 
с другой данные (любой файл) которые легко могут быть конвертированы в такую же десятичную систему. Если взять к примеру объем числа "Пи" весом в 1гб из 
расчета 1 знак = 1 байт(здесь могу ошибаться), то получается один миллиард знаков . Вполне естественно предположить что части файла переведенного в десятичную форму 
будут в каких то местах полностью совпадать с последовательностью знаков из числа "Пи". Таким образом мы можем собрать любой файл. Дело будет 
лишь в количестве этих частей. 1, 10, 100 000 или более. Но при любом раскладе получается что сам код такой сборки будет ничтожно мал по сравнению 
с первоначальным объемом самого файла. Представить такой код можно так же в десятичной форме. Например. Точка захода в число "Пи", то есть 
количество знаков от его начала и само количество знаков в этой части. Так же можно добавить перед этими двумя числами по одному знаку который будет 
обозначать количество знаков в этих двух числах для того что бы отделить одну часть от другой в непрерывном коде из знаков. Так как общее количество 
знаков в числе "Пи" не будет превышать одного миллиарда то и эти два добавочных числа не могут быть двузначными. (Например есть совпадающая 
последовательность с 765789 от начала числа "Пи" до 1202345. В этом случае код будет выглядеть как 676578971202345) В итоге мы имеем такую же 
последовательность десятичных чисел, которую в свою очередь мы сжимаем таким же способом шагом номер два. В конечном счете после 
нескольких таких шагов мы имеем последовательность которая со стопроцентной гарантией попадет в число "Пи" одной частью. И код этой части будет иметь 
от четырех до шестнадцати знаков. То есть по сути вообще ничто. Зная число шагов и делая обратную операцию мы получаем наш исходный файл. Получается 
что мы имеем возможность сжимать любой объем данных будь то гигабайты или терабайты до этого ничтожного размера. Но и это еще не все. Собрав громадный 
архив из этих микроскопических файлов мы так же можем их сжимать до бесконечности используя тот же метод. Если это работает, то мы закрываем тему объема 
как такового вообще пробив боковую дверь в законе Мура, оставляя лишь одно число "Пи". Было бы здорово передавать бесценные научные данные терабайтных 
размеров скажем откуда нибудь с Марса сжав все в несколько байт...Но вполне может быть что я ошибаюсь. Проверить бы все это.

TL;DR: идея не нова и не жизнеспособна.

Если обобщить: у нас есть некий словарь в котором есть фразы на все случам жизни и мы вместо передачи фразы хотим передавать ссылку на фразу из словаря. Именно такой принцип используется в архиваторах. Но дьявол кроется в мелочах: тут нужен баланс длинны фразы, если будет слишком короткая - то ссылка на фразу будет занимать столько же место, сколько сама фраза. Если слишком длинная, то будет крайне мало совпадений и размер словаря возрастет и сожрет всю выгоду от сжатия. Словари архиваторов делаются на основе входных данных, потому что только так можно получить выгоду от сжатия: выбросив из словаря неиспользуемые в этих конкретных входных данных фразы. Например мы хотим использовать словарь с длинной фразы 4 байта, количество возможных фраз в этом словаре составит 2^32, т.е. те же 4 байта. Если не сократить размер словаря, то ссылки на фразу из словаря будут занимать слишком много места и выгоды не будет. Поэтому словари делают адаптивными к входным данным, используют фразы разной длинны, общие словари на весь архив и другие ухищрения.

Что же до самого числа Пи, то это просто некий предгенерированный словарь не адаптированный под входные данные. Если кодировать короткими фразами, то ссылки сожрут всю выгоду. А если пытаться кодировать длинными фразами (файл целиком предельный случай), то тут все зависит от удачи, может кто-то и найдется недалеко. Но в общем случае нет оснований считать что ссылка будет короче, чем в случае со словарем который просто содержит полный набор фраз. Плюс тут еще проблема в том, что надо этот самый словарь как-то хранить ибо генерация его нетривиальная задача которая требует много вычислительных ресурсов.

Спасибо за подробный ответ. Понял что ошибался.