Скрити капани в Arithmetic Coding: Защо компресора ти губи битове напразно

Ако си имплементирал arithmetic coding, сигурно си се гордеел с резултата. Този алгоритъм е елегантен – преобразува битови последователности в точни вероятностни интервали. Но ето проблема: повечето готови примери от мрежата работят под оптимално, без да ти каже никой.

Не говоря за скорост на процесора (макар и тя да е важна). Фокусът е върху compression ratio – основната причина да ползваш entropy coding изобщо.

Класическият код, който те подвежда

Вероятно си виждал стандартния пример. Изглежда логично:

let mut left: u32 = 0;
let mut right: u32 = u32::MAX;

fn encode_bit(bit: bool, probability: f32) {
    let mid = left + ((right - left) as f32 * probability) as u32;
    if !bit {
        right = mid;
    } else {
        left = mid + 1;
    }
    
    // Извеждаме байтове, когато са сигурни
    while left >> 24 == right >> 24 {
        output_byte((left >> 24) as u8);
        left <<= 8;
        right = (right << 8) | 0xff;
    }
}

Държиш интервал [left, right], всеки бит го стеснява според вероятността. Когато байтът е ясен, го изпращаш и освобождаваш място за повече прецизност.

Проблемът? Този код има асиметрия, която липсва в идеалната математика.

Предателството на байт границите

В идеалния случай всички интервали с една и съща дължина се държат еднакво. Но с 32-битови цели – не.

Ето два случая:

1. Интервал от left = 0 никога не пада под 2^24 бита.
2. Интервал от left = 2^31 - 1 може да стигне до 2 бита.

Защо? Условието left >> 24 == right >> 24 зависи от позицията, не от големината.

Ако интервалът пресича байт граница – като [2^31 - 1, 2^31] – става прекалено тесен. Вероятностите се грубо квантизират. Бит с 0.95 вероятност може да се раздели на 50/50, защото няма място за нюанси.

Резултат: компресорът ти харчи повече битове, отколкото entropy theory обещава.

Декодерът крие още проблеми

И в декодера има капан:

fn decode_bit(probability: f32) -> bool {
    let mid = left + ((right - left) as f32 * probability) as u32;
    if x <= mid {
        right = mid;
        bit = false;
    } else {
        left = mid + 1;
        bit = true;
    }
    
    while left >> 24 == right >> 24 {
        left <<= 8;
        right = (right << 8) | 0xff;
        x = (x << 8) | (bytes.next().unwrap() as u32);
    }
    
    bit
}

Той следи left, right и x (кодираното значение). Математически са нужни само две: дължина на интервала (right - left) и относителна позиция (x - left).

Цикълът за прецизност изисква абсолютни позиции. Това свързва логиката с мястото на интервала, а не с размерът му.

Последиците:

• Повече натиск върху регистрите
• По-малко оптимизации от компилатора
• Код, труден за разбиране

Всичко заради условие, което не трябва да знае къде е интервалът – само колко е голям.

Как да го оправиш

Решението е да премахнеш зависимостта от позицията. Извеждай байтове според дължината на интервала, независимо от офсета.

Това звучи лесно, но иска преработка на целия цикъл. Ползата? По-добър compression ratio и по-бърз, прост декодер.

Защо NameOcean се интересува

В NameOcean помагаме разработчици с AI приложения на Vibe Hosting или високопроизводителни системи. Компресираш ли данни за cloud storage, API payloads или големи datasets – тези детайли са ключови.

Много ползват библиотеки без да знаят слабостите им. 5-10% по-добър ratio звучи малко, докато не стигнеш до petabyte или милиони заявки.

Урокът: „учебниците“ не са идеални. Копай по-дълбоко. Проверявай асиметриите. Най-добрите инженери не копират алгоритми – разбираят краищата им.

Ако градиш cloud приложения с високи изисквания, инфраструктурата ти умножава всяка грешка. Малки подобрения хиляди пъти – и спестяваш много. Оптимизирай стека си: детайлите решават.