Ми знаємо, що π нескінченний, і цілком ймовірно, що він містить усі можливі кінцеві рядки цифр ( диз'юнктивна послідовність ).

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

Вже є формула типу BBP (як частина експериментальної математики), яка дозволяє обчислити n- й двійковий розряд pi. Таким чином, зберігаючи позицію нашого початку та довжину даних, ми можемо теоретично дістати дані, що цікавлять нас. Є деякі аргументи проти того, що наші метадані (наприклад, зміщення наших даних) можуть бути більшими, ніж вилучені дані. Символи матриці та π можуть бути закодовані в base-256, щоб зробити її більш ефективною (див . Жарт ).

Виходячи з вище, головне моє питання:

• Чи є алгоритми стиснення, засновані на PI?

Якщо ні, чи є сенс? Або були якісь дослідження в цій галузі?

А може бути, π не є правильним, то що робити з константою Ейлера або Тау (τ)? Чи має це значення?

^{Графічні зображення: Комікси динозаврів}

Дивись також:

• Чи можна будь-яку кінцеву бітову рядок знайти в pi протягом розумного часу? при SO
• Чи не зберігання індексу в π буде таким же великим (або більшим), ніж вихідні дані? на 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$

Див. Також інформаційна ентропія .

Приклад

$log_2(938933556)$$29.8$$30$

$\pi$$597,507,393$$log_2(597507393)$$29.2$$30$

Може, ми можемо скинути цифри?

• $1,124$
• $1,216$
• $11,727$

$36$

• $15,312,393$
• $8$

$27$$30$

$N$

Чи є алгоритми стиснення, засновані на PI?

так, https://github.com/divinity76/pi_compression

чи є сенс?

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

Або були якісь дослідження в цій галузі?

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

декомпресія дуже швидка.

Чи є алгоритми стиснення, засновані на PI?

$\pi$$\pi$

$X$$\pi$$X$

$\pi$$\pi$

навіть якщо було показано, що будь-яка математична константа володіє чудовою властивістю "містити всі рядки", простий аргумент полягає в тому, що алгоритм стиснення витратить "занадто багато часу" на пошук позиції рядка, а опис його розташування часто займає довгий (ер) рядок цифр.

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