Чому кодування Хаффмана усуває ентропію, якої не робить Лемпель-Зів?

У популярному алгоритмі DEFLATE використовується кодування Хаффмана на вершині Lempel-Ziv.

Загалом, якщо у нас є випадкове джерело даних (= 1 бітова ентропія / біт), жодне кодування, включаючи Хаффмана, швидше за все, не може стиснути його в середньому. Якби Лемпель-Зів був «ідеальним» (до якого він підходить для більшості класів джерел, оскільки довжина йде до нескінченності), кодування після Хаффмана не допомогло б. Звичайно, "Лемпель-Зів" не є ідеальним, принаймні, з кінцевою довжиною, тому залишається деяка надмірність.

Саме ця зайва надмірність кодування Хаффмана частково усуває і тим самим покращує стиснення.

Моє запитання: Чому це корінне резервування успішно усувається кодуванням Хаффмана, а не LZ? Які властивості Хаффмана проти LZ обумовлюють це? Чи просто запустити LZ знову (тобто, кодуючи стиснуті дані LZ за допомогою LZ вдруге) здійснити щось подібне? Якщо ні, то чому б і ні? Аналогічно, спочатку стискав би з Хаффманом, а потім - роботою LZ, а якщо ні, то чому?

ОНОВЛЕННЯ: Зрозуміло, що навіть після LZ залишиться деяка надмірність. Кілька людей зробили це. Що не зрозуміло, це те, чому Хаффман краще вирішує цю залишкову надмірність, ніж LZ? Що унікального в цьому на відміну від первинного надмірності джерела, де LZ працює краще, ніж Хаффман?

Спочатку це був коментар, але він отримав занадто довго.

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

Навіщо використовувати Huffman, а не LZ, для другого раунду стиснення? Велика перевага, яку LZ має над Хаффманом, полягає у лікуванні залежностей між символами. Англійською мовою, якщо одна літера є "q", наступна велика ймовірність - "u" тощо. Якщо символи є незалежними подіями, то Хаффман простіший і працює так само добре чи краще для коротких рядків. Що стосується виходу LZ77, моя інтуїція полягає в тому, що символи повинні бути досить незалежними, тому Хаффман повинен працювати краще.

Стиснення даних - це насправді дві речі: моделювання та кодування. Алгоритми сімейства LZ моделюють текст як поєднання точних повторів, що є асимптотично оптимальним для багатьох випадкових джерел і досить добре для багатьох реальних текстів. Однак для деяких входів ця модель може бути дуже поганою. Наприклад, ви не можете використовувати LZ для прямого стиснення суфіксного масиву, навіть якщо суфіксний масив такий же стисливий, як і оригінальний текст.

$(p, \ell, c)$$p$$\ell$$c$

$\log n$$n$

Отже, коротко кажучи, Хаффман перемагає LZ, стискаючи кортежі, оскільки його модель (фіксований розподіл проти точних повторів) є кращою відповідністю для даних.

Я вірю, що відповідь лежить у розмірі словника пошуку.

Дані мають відчуття локальності (тобто, якщо частина даних була використана, цілком ймовірно, вона буде використана знову незабаром), і алгоритм LZ використовує це в побудові словника пошуку. Він генерує трійку з обмеженою кількістю можливих вузлів, щоб швидко тримати пошук . Коли вона досягає обмеження розміру, вона робить ще одне тріє, «забуваючи» про попереднє. Таким чином, йому доведеться знову скласти таблицю пошуку для більш простих символів, але якщо деякі слова більше не використовуються, вони більше не зберігаються в пам'яті, тому можна використовувати меншу кодування.

Тому вихід LZ може бути зменшений додатково за допомогою кодування Хаффмана, оскільки ця надмірність у створенні спроб пошуку може бути виявлена ​​статистичним аналізом.

Можливо, я тут відслідковую, але кодування Хаффмана дивиться на весь вхід, щоб створити його таблицю кодування (дерево), тоді як Лемпель-Зів кодує, як йде далі. Це є і перевагою, і недоліком для Хаффмана. Розбіжність є нав'язливою, а саме, що ми повинні побачити весь вклад, перш ніж ми можемо почати. Перевага полягає в тому, що Хаффман буде враховувати статистику, яка виникає в будь-якому місці вхідних даних, тоді як Лемпель-Зів повинен будувати її поступово. Або кажучи по-іншому, Лемпель-Зів має "напрямок", якого Хаффман не робить.

Але все це лише мій наївний спосіб уявити, як все відбувається. Тут нам знадобиться справжнє підтвердження, щоб побачити, як саме Хаффман перевершує Лемпель-Зів.

Коротка відповідь полягає в тому, що LZ - це «універсальний» алгоритм, оскільки йому не потрібно знати точний розподіл джерела (просто потрібно припущення, що джерело нерухоме та ергодичне). Але Хаффман - ні; вона повинна знати точний розподіл, з якого береться джерело (для виготовлення дерева Хаффмана). Ця додаткова інформація змушує Хаффмана дотримуватися жорстких гарантій стиснення. Однак для алгоритмів стиснення файлів Хаффман може бути менш сприятливим, оскільки спочатку потрібно буде зібрати емпіричну статистику файлу, а потім зробити фактичне стиснення у другій половині, тоді як LZ може бути реалізований в Інтернеті.

Більш детально можна ознайомитися в стандартних текстах теорії інформації, наприклад, Елементи інформаційної теорії Ковер та Томас.