Чи зменшують ентропію алгоритми стиснення без втрат?

За даними Вікіпедії :

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

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

Однак багато алгоритмів стиснення використовують кроки перед ентропійним кодуванням, щоб нібито зменшити ентропію повідомлення.

Згідно з німецькою Вікіпедією

Entropiekodierer werden häufig mit anderen Kodierern kombiniert. Dabei dienen vorgeschaltete Verfahren dazu, die Entropie der Daten zu verringern.

Англійською:

Ентропійні кодери часто поєднуються з іншими кодерами. Попередні кроки служать для зменшення ентропії даних.

тобто bzip2 використовує перетворення Burrow-Wheeler-Transform з подальшим переходом на перехід до фронту перед застосуванням кодування ентропії (в даному випадку кодування Хаффмана).

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

Багато випадкових описів ентропії заплутаються таким чином, оскільки ентропія не настільки акуратна і охайна міра, як іноді подається. Зокрема, стандартне визначення ентропії Шеннона передбачає, що воно застосовується лише тоді, коли, як стверджує Вікіпедія, "інформація через незалежні події є адитивною".

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

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

Марковські процеси

Процес Маркова генерує низку подій, у яких остання подія відбирається з розподілу, який залежить від однієї або декількох попередніх подій. Очевидно, що величезна кількість реальних явищ краще моделюються як Марківські процеси, ніж як дискретні незалежні розподіли ймовірностей. Наприклад: текст, який ви зараз читаєте!

Наївно обчислена швидкість ентропії Шеннона процесу Маркова завжди буде більше або дорівнює справжній швидкості ентропії процесу. Щоб отримати справжню ентропію процесу, потрібно врахувати статистичну залежність між подіями. У простих випадках формула для цього виглядає приблизно так :

Це також можна представити так :

$\mu_i$

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

• Вони побігли до дерева
• Дерево підбігло до них
• Дерево вони бігали

Але ентропія Шеннона оцінить усі три струни як однаково вірогідні. Ентропія процесу Маркова враховує різницю, і як результат, вона призначає менший коефіцієнт ентропії процесу.

Рівень ентропії залежить від моделі

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

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

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

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

Вони зменшують уявну ентропію, властиву структурі вихідного повідомлення. Або іншими словами, вони налаштовують повідомлення, щоб використовувати сили наступних етапів стиснення.

Одним простим прикладом може бути заміна імені в кінцевих тегах xml спеціальним символом. Ви можете прекрасно відтворити оригінальний xml з цього, але компресор не повинен знову включати повне ім'я в цьому місці.

Більш реальним прикладом є стиснення png. Ентропійний компресор DEFLATE, який є комбінацією Лемпеля-Зіффа і Хаффмана. Це означає, що він найкраще працює зі значеннями та шаблонами, які часто повторюються. Більшість сусідніх пікселів мають тенденцію бути подібними кольорами. Отже кожному рядку призначається фільтр, який перетворює вихідні значення пікселів у диференційне кодування. Таким чином, значення, які в кінцевому підсумку кодуються DEFLATE, здебільшого наближаються до 0. У крайньому випадку це перетворить плавний градієнт від усіх різних значень в єдине значення в рядку, над яким LZ або DEFLATE дуже швидко спрацьовують.

Ентропійні кодери не стискають повідомлення до мінімальної кількості бітів, необхідної для його представлення. Я знаю, що це заманливо думати, але це не те, що вони роблять. Вони не чарівні, і цього не можуть досягти.

Натомість вони роблять щось трохи менш магічне - але все ж корисне. Припустимо на даний момент, що ми знали, що кожен символ повідомлення обраний незалежно від деякого розповсюдження. Тоді можна було б побудувати алгоритм стиснення без втрат, який оптимально стискає повідомлення. Ці алгоритми називаються ентропійними кодерами.

Тепер справжні повідомлення зазвичай не мають цього властивості незалежності. Наприклад, якщо ви бачите питання Q, ймовірно, що наступна літера - це U. і так далі. Ще можна застосувати алгоритм кодування ентропії до реального повідомлення, де кожен символ не обраний незалежно від решти. Алгоритм все ще буде без втрат, його ще можна використовувати для стиснення, і на практиці він все ще часто скорочує довжину повідомлення. Однак це не скорочує його до мінімально можливої ​​довжини. Він не стискає повідомлення до чогось, довжина якого дорівнює ентропії повідомлення; він стискає його менше, ніж це.

Як тільки ви усвідомили цю властивість ентропійних кодерів, парадокс випаровується.

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

Слово "Ентропія", якщо його часто використовують трохи вільно, для позначення двох різних речей:

• "Загальна кількість інформації" у повідомленні чи системі

• Інформація "щільність", або наскільки щільно інформація упакована.

Цитата ОП про запис Вікіпедії для https://en.wikipedia.org/wiki/Entropy_(information_theory) стосується першого:

Shannon's entropy measures the information contained in a message

Але (принаймні, коли я це пишу) ця стаття починається з:

Information entropy is the average rate at which information is produced by a stochastic source of data.

Отже, одна - це сума, а одна - швидкість (подібна до відстані проти швидкості). Іноді їх називають "великими" та "інтенсивними" властивостями (див. Https://en.wikipedia.org/wiki/Intensive_and_extensive_properties#Extensive_properties ).

Класичний приклад розрізнення - знаменитий сигнал ліхтаря Пола Ревера: "один якщо сушею, а два, якщо морем". 1 біт загальної інформації (якщо ігнорувати випадок "жоден, якщо я ще не потрапив до Північної Церкви"). Якби Пол додав ще один набір ліхтарів у кожному вікні будівлі, це було б "зайвим": більше інформації немає, тому така ж "загальна" або "велика" ентропія; але набагато більша довжина повідомлення, тим менша "інтенсивна" ентропія.

Якщо він починає так, але змінює використовувати лише один набір ліхтарів, це "стиснення без втрат", як у питанні ОП. "Широка" ентропія однакова, але "інтенсивна" ентропія "відрізняється. Оскільки кількість ліхтарів у другому вікні сильно співвідноситься з кількістю ви побачили в першому, надмірне повідомлення є більш передбачуваним, або менш випадкові, тому значно менша інтенсивна ентропія.

Слід пам’ятати ще дві важливі речі:

• По-перше, ми зазвичай не знаємо "справжньої" ентропії системи в будь-якому сенсі. Наївний спостерігач не знає, чи будуть "3 ліхтарики" різними повідомленнями, чи сигнали в іншому вікні зайві чи ні. Якщо Павло змушує їздити за звичкою, ми можемо порахувати і побачити, чи завжди вікна відповідають один одному. Але, можливо, ми просто не спостерігали досить довго, щоб побачити рідкісні (і, мабуть, важливі!) Винятки.

• По-друге, важливо, як ви вимірюєте. Розглянемо спробу оцінити, скільки повідомляється кожної послідовної літери тексту (це швидкість, настільки "інтенсивна" ентропія, яку іноді називають "відносною ентропією"):

  • Якщо ви просто помітили, що люди надсилають текст навколо 8-бітових одиниць, ваша перша "оцінка" може складати 8 біт на лист.
  • Якщо підрахувати кількість вживаних відмінних букв, ви оціните log2 (26) або 4,7 біт на одну букву (трохи вище, якщо врахувати пробіли, регістр тощо).
  • Якщо ви вважаєте, що "e" - краща ставка для "наступної літери", ніж "z", ви вимірюєте частоту літер і отримуєте приблизно 4,14 (див. Http://people.seas.harvard.edu/~jones/cscie129/ документи / stanford_info_paper / entropy_of_english_9.htm ).
  • Якщо порахувати пари букв, ви виберете такі шаблони, як "qu", "th" тощо, і отримаєте близько 3,56.
  • Якщо ви порахуєте послідовності приблизно до 5 букв, ви отримаєте ще менші значення, і як бонус ви можете досить надійно розрізнити, на якій людській мові йде текст).
  • Якщо ви такі ж важкі та розумні, як Н.Г. Бертон та Ж.Р. Ліклідер у "Довготривалі обмеження в статистичній структурі друкованої англійської мови" (Американський журнал психології 68 (1955)), ви можете отримати послідовності 10, 0000 букв підряд і знайдіть ще одне значення ентропії.

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

Якщо ви змоделюєте теоретичне нескінченне джерело з ідеально випадковим Zipfian-розподілом лексем, ви можете обчислити обширну та інтенсивну ентропію, яку він би мав, і, виявляється, залежить лише від кількості можливих різних лексем. Графіки того, як виглядає кожен тип ентропії зі збільшенням цієї кількості, розміщені в [ http://www.derose.net/steve/writings/dissertation/Diss.0.html] . Двоє поводяться зовсім інакше:

• всього (обширне): http://www.derose.net/steve/writings/dissertation/Graph13.png
• відносна (інтенсивна): http://www.derose.net/steve/writings/dissertation/Graph14.png

Сподіваюсь, що допоможе або принаймні цікаво ...

Я підозрюю, що формулювання в німецькій Вікіпедії помиляється. Компресори збільшують ентропію. Тобто не загальна ентропія, а ентропія на біт : щільність інформації. Наприклад, деяка схема кодування та словника довжини пробігу застосовується для ущільнення даних. Тепер та сама інформація упакована в меншу кількість біт, тому кожен біт містить більше інформації. Подальше кодування Хаффмана робить трохи більше того ж; це просто ще один шар стиснення.