Чи відомий максимум для того, скільки можна стиснути рядок 0 і 1?

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

Це, звичайно, не вірно (і могло бути, що моя пам’ять про те, що він саме заявив, не відповідає). Зрозуміло, що не було б практичним стиснути будь-який рядок з 0 і 1 лише до двох біт, тому що (навіть якщо це було технічно можливо), занадто багато рядків різного типу в кінцевому підсумку стискалися б до тих самих двох біт (оскільки у нас є лише '01 'і' 10 'на вибір).

У всякому разі, це змусило мене замислитись над можливістю стиснення довільної рядкової довжини 0 і 1 за деякою схемою. Чи існує такий тип рядка, чи є відома залежність між довжиною рядка (співвідношення між 0 і 1, мабуть, не має значення) та максимальним стисненням?

Іншими словами, чи є спосіб визначити, яка мінімальна (найменша можлива) довжина, до якої можна стиснути рядок 0 і 1?

(Тут мене цікавить максимальне математичне стиснення, а не те, що наразі технічно можливо.)

Складність Колмогорова є одним із підходів для формалізації цього математично. На жаль, обчислення складності рядка Колмогорова є непереборною проблемою. Дивіться також: Наближення складності Колмогорова .

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

Про неможливість ідеального стиснення вас також може зацікавити наступне.

• Жоден алгоритм стиснення не може стискати всі вхідні повідомлення?
• Функції стиснення практичні лише тому, що "Бітові рядки, які трапляються на практиці, далеко не випадкові"?
• Чи є теоретично доведений оптимальний алгоритм стиснення?

Для будь-якого заданого рядка існує схема стиснення, яка стискає його до порожнього рядка. Отже, не має сенсу запитувати, наскільки може бути стиснена одна струна, а скільки в середньому може стискатися колекція (або розподіл ) рядків. Загалом, зважаючи на колекцію рядків, будь-яка схема стиснення потребує щонайменше журналу 2 N біт або близько того, щоб кодувати рядок із колекції в гіршому випадку.$N$$\log_2 N$

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

Ось проста схема, яка може стискати довільні рядки бітів без втрат, найменший результат - лише один біт:

Якщо рядок є ідентичним збігом для запису 9-ї симфонії Бетховена, четвертого руху, у форматі AAC, який зберігається на жорсткому диску мого комп'ютера, то вихід є єдиним бітом "0".

Якщо рядок є чим-небудь іншим, то вихід - це один біт '1', за яким йде ідентична копія вихідного рядка.

Ця схема зменшує один можливий вхід рівно до одного біта і збільшує кожен другий вхід по довжині. Існує загальний принцип: Якщо алгоритм стиснення може зіставити будь-яку вхідну рядок на стиснуту рядок, і існує відповідний алгоритм декомпресії, який відображає будь-яку стиснуту рядок назад у початкову рядок, а алгоритм стиснення відображає будь-який вхід у більш короткий рядок, тоді він повинен відображати деякі вхідні рядки до довших рядків.

Для кожної схеми стиснення, яку ви можете створити, можна створити дані, які будуть нетискатими. Тож навіть якщо ваша схема стиснення є дуже ефективною для деяких типів даних, вона ніколи не буде послідовно стискатися до певного співвідношення.

Спосіб отримання прикладу нестислимих даних для певного алгоритму стиснення простий: візьміть будь-які дані та запустіть їх через алгоритм стиснення повторно, поки розмір більше не зменшиться.

Тож стисливість рядка бітів насправді не є функцією довжини рядка, а її складності стосовно алгоритму стиснення.

Існує цікавий і зовсім інший алгоритм, який використовується системами резервного копіювання підприємства. Ідея полягає в тому, що якщо у вас є компанія з 10000 комп'ютерів, то багато хто з цих комп'ютерів буде містити багато однакових файлів. Наприклад, електронний лист, надісланий всім в компанії, може виявитися ідентичним файлом на кожному жорсткому диску.

Отже, система резервного копіювання, яка намагається створити резервну копію файлу, очевидно, повинна намагатися стиснути файл, щоб заощадити місце, але спочатку система резервного копіювання перевіряє, чи абсолютно збережений абсолютно однаковий файл! Отже, замість того, щоб робити резервну копію, все , що робить система резервного копіювання, це, наприклад, пам’ятати, що на системі жорсткого диска у вас є номер файлу 1,487,578.

Це особливо ефективно, наприклад, коли на всіх 10 000 користувачів встановлена ​​однакова операційна система та програми. Для одиноких користувачів це зовсім не корисно.