Что мы знаем, так это то, что π бесконечно и вполне вероятно, что оно содержит все возможные конечные цепочки цифр ( дизъюнктивная последовательность ).

Недавно я видел некоторый прототип πfs, который предполагает, что каждый файл, который вы создали (или кто-либо еще) или вы создадите, он уже там, так что это вопрос его извлечения. Существует также piFile, который может конвертировать ваши файлы в метаданные pi.

Уже есть формула типа BBP (как часть экспериментальной математики), которая позволяет нам вычислить n- ю двоичную цифру числа pi. Таким образом, сохраняя положение нашего начала и длину данных, мы можем теоретически извлечь интересующие нас данные. Есть некоторые аргументы против этого, что наши метаданные (например, смещение наших данных) могут быть больше, чем извлеченные данные. Матричные символы и π могут быть закодированы в base-256, чтобы сделать его более эффективным (см. Шутку ).

Исходя из вышеизложенного, мой главный вопрос:

• Существуют ли алгоритмы сжатия на основе PI?

Если нет, имеет ли это смысл? Или были какие-то исследования в этой области?

Или, может быть, π не является правильным, так как насчет константы Эйлера или Тау (τ)? Будет ли это иметь какое-либо значение?

^{Изображение предоставлено: комиксы динозавров}

Смотрите также:

• Может ли какая-либо конечная цепочка битов быть найдена в пи в течение разумного промежутка времени? в СО
• Не будет ли хранение индекса в π таким же большим (или большим), чем исходные данные? на GitHub

Ваше предложение не имеет особого смысла по многим причинам. Прежде всего, при попытке сжать большой файл, скажем, файл размером байт, вам нужно будет найти место в двоичном расширении которое соответствует вашему файлу. Поскольку длина файла составляет бит, можно ожидать, что это место будет около -го бита. Так что было бы довольно сложно найти. Это не только потому, что мы должны углубляться в расширение, но также и потому, что мы ожидаем попробовать разных мест, прежде чем найти попадание.π 128 2 128 2 $16$$\pi$$128$$2^{128}$$2^{128}$

Во-вторых, хотя в некоторых случаях ваша схема приведет к сильному сжатию, это произойдет только тогда, когда определенная строка появится сравнительно рано в расширении . Нет причин, по которым вы захотите сжать строку такого типа. Напротив, другие алгоритмы сжатия пытаются найти структуру в данных и имеют гарантии, которые показывают, что если такая структура существует, то они всегда могут ее использовать.$\pi$

Изменение с любым другим номером не изменит картинку. Алгоритм слишком специфичен, сжимая только те строки, которые нам не нужны; и очень неэффективно в фазе сжатия.$\pi$

На основании ответа Ювала, с немного другим объяснением и примером, чтобы помочь осветить проблему.

теория

Возьмите файл длиной байт ( бит). Алгоритм сжатия выглядит следующим образом:$16$$128$

1. Определите, где двоичное расширение соответствует содержимому.$\pi$
2. Сохраните смещение и количество последовательных битов ( ).$128$

Смещение для содержимого файла должно быть около ^-го бита; однако нахождение смещения занимает много времени, поскольку оно требует:$2^{128}$

• глубокий поиск битового паттерна; и
• глядя на разных мест (в среднем).$2^{128}$

Совпадения, которые происходят достаточно рано в для достижения значительного сжатия, изменяться не будут. То есть невозможно использовать для сжатия интересных данных реального мира, потому что строки из реального слова вряд ли возникнут рано.$\pi$$\pi$

Смотрите также, информационная энтропия .

пример

Давайте сжимаем номер социального страхования (SSN): 938-933-556 . Вычислите число битов для кодирования этого значения, используя , который равен ~ и должен быть округлен до (поскольку биты неделимы).29,8 $log_2(938933556)$$29.8$$30$

В этот SSN начинается со смещения , для которого необходимо бит или ~ а также должно быть округлено до . Может быть более раннее смещение, но вряд ли потребуется значительно меньше битов.597 , 507 , 393 л о г 2 ( 597507393 ) $\pi$$597,507,393$$log_2(597507393)$$29.2$$30$

Может быть, мы можем разделить цифры?

• 938 , смещение , 11 бит$1,124$
• 933 , смещение , 11 бит$1,216$
• 556 , смещение , 14 бит$11,727$

Это бит, еще худший результат. Возможно другой кусок?$36$

• 9,389,335 , смещение , 24 бита$15,312,393$
• 6 , смещение , 3 бита$8$

Это бит, что лучше, чем , но есть проблемы. Во-первых, добавление неоднородного фрагментирования требует больше информации, чтобы указать, где фрагменты начинаются и останавливаются. Во-вторых, еще больше времени требуется, чтобы найти оптимальный фрагмент для достижения наименьшего количества битов. В-третьих, сохранение трех битов едва ли можно считать сжатием.$27$$30$

Различные трансцендентные числа будут иметь один и тот же статистический результат, более или менее. Даже если вы сбриваете волосы, скажем, на два бита, константа, которую вы использовали, должна быть указана. Три бита позволяют алгоритму выбирать одно из восьми разных чисел. Как следствие, алгоритм будет намного медленнее из-за поиска последовательностей вместо одной.$N$

Существуют ли алгоритмы сжатия на основе PI?

да, https://github.com/divinity76/pi_compression

имеет ли это смысл?

Нет, хранение смещений обычно занимает больше места на диске, чем вы сохраняете, по крайней мере, с помощью описанной выше реализации (хотя есть три примечательных особенности, которые можно улучшить, он рассматривает только первые 2 ^ 32 байта двоичного представления числа pi, и это использует чрезмерное количество битов для хранения количества совпадающих байтов на смещение, а именно 8 битов, в то время как тестирование показывает, что 3 бита было бы оптимальным, и рассматривает только полные байтовые совпадения, поэтому, если где-то есть 15-битовое совпадение, оно будет рассматривается только как 8-битное совпадение. Также, если последние 4 бита байта совпадают, но не бит № 3, и первые 4 бита следующего байта совпадают, но не бит № 5, это не считается совпадением в все)

Или были какие-то исследования в этой области?

хм, конечно, именно поэтому я написал вышеприведенную реализацию, и результаты, по-видимому, заключаются в том, что в пределах первых 4 ГБ числа пи вы, вероятно, найдете 4 совпадающих байта из… почти всего, что очень сложно, если не невозможно, чтобы получить какое-либо сжатие, я по крайней мере не смог. (но моя реализация не является оптимальной, как объяснено выше) - также сжатие очень медленное, но моя реализация однопоточная, но алгоритм допускает многопоточность, если кто-то может быть подвергнут сомнению при написании кода, что позволило бы масштабировать производительность с количество доступных ядер.

декомпрессия очень быстрая, хотя.

Существуют ли алгоритмы сжатия на основе PI?

этот вопрос , кажется, мотивировано идеей , что есть некоторые «научно - популярные» предположение , что или другие математические константы содержат все возможные последовательности цифр, но это не доказано. алгоритм сжатия на основе , имеющий произвольные последовательности цифр не исключен , но будет зависеть от следующего свойства. т.е. «AFAIK» его открытая проблема / вопрос , является ли следующий вопрос (не) разрешима (и то же самое справедливо и для других классических констант):$\pi$$\pi$

входная последовательность . вывод, Y / N, содержит последовательностьπ $X$$\pi$$X$

не существует "основных" алгоритмов сжатия, основанных на но в (T) CS трудно / проблематично провести строгую границу вокруг "основного потока" . в отличие от популярного использования термина, относящегося к набору «широко используемых» или «стандартных» алгоритмов, «алгоритм сжатия» в CS является очень широкой концепцией. технически да, «алгоритм сжатия, основанный на существует», потому что его легко построить «надуманным» (упражнение для читателя), но нет, никакие стандартные алгоритмы не основаны на последовательностях цифр в математических константах.$\pi$$\pi$

даже если было показано, что любая математическая константа обладает замечательным свойством «содержать все строки», простой аргумент состоит в том, что алгоритм сжатия будет тратить «слишком много времени» на поиск положения строки, а описание ее расположения часто занимает длинная (эр) строка цифр.

см. также / контраст / попытайтесь примириться с аналогичным вопросом с высоким голосом, как можно решить, содержит ли pi некоторую последовательность цифр . (cs.se) (подсказка: название можно считать несколько вводящим в заблуждение)