То есть всего три символа (00, a0 и завершающий 256) с длинами кодов 8. Это очевидно не оптимальное кодирование, при таком раскладе у них длины кодов не должны быть больше чем 2.
и перед этим, то же самое, хотя и менее грубо. когда Вы записываете длины для команд у Вас получаются длины
0 0 2 2 2
но для трёх символов оптимальный код будет всегда иметь вид 1-2-2 (2-1-2 или 2-2-1 -- последовательность тут не важна).
Спасибо огромное! Действительно помогло. Мне и в голову не приходило такое. Я ведь большие массивы пробовал с кодами меньшей длины и всё равно что-то не получалось. Тут уже всё сократил до минимума (8-битные коды были выбраны чисто из-за того, чтобы меньший перечень HCLEN использовать).
Так получается, что нужно обязательно использовать все длины кодов с единицы? (Потому как пробовал только двойки - не прошло). Тогда мне не понятно почему нужно было создавать этот перечень длин в таком странном порядк, где единица предпоследняя...
> Тогда мне не понятно почему нужно было создавать этот перечень длин в таком странном порядк, где единица предпоследняя...
обычно единица не требуется, у Вас просто очень мало символов, тут по хорошему вообще не нужно было ничего сжимать, меньше места бы занимало. Схема рассчитана на то, чтобы быть оптимальной в среднем случае, а не в каждом.
Да это ж для пробы было, просто вручную уже запереписывался этими кодами... А вручную надо, чтобы понять все нюансы. Просто смущало то, что начинал я с массива в где-то 110 байт и там было что сжимать. Пользовал 3х значные коды (как мне казалось, что одной длины ведь удобнее), но тоже что-то не получалось, хотя... мне кажется я догадываюсь где там могли быть ещё ошибки. В общем ладно, будем ещё экперементировать. А вам спасибо ещё раз!
у Вас Хаффман плохой, а zlib видимо его проверяет.
массив получающихся длин литералов-длин-смещений вот такой:
[8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 8, 0]
То есть всего три символа (00, a0 и завершающий 256) с длинами кодов 8. Это очевидно не оптимальное кодирование, при таком раскладе у них длины кодов не должны быть больше чем 2.
и перед этим, то же самое, хотя и менее грубо. когда Вы записываете длины для команд у Вас получаются длины
0 0 2 2 2
но для трёх символов оптимальный код будет всегда иметь вид 1-2-2 (2-1-2 или 2-2-1 -- последовательность тут не важна).
Reply
Действительно помогло. Мне и в голову не приходило такое. Я ведь большие массивы пробовал с кодами меньшей длины и всё равно что-то не получалось. Тут уже всё сократил до минимума (8-битные коды были выбраны чисто из-за того, чтобы меньший перечень HCLEN использовать).
Так получается, что нужно обязательно использовать все длины кодов с единицы? (Потому как пробовал только двойки - не прошло). Тогда мне не понятно почему нужно было создавать этот перечень длин в таком странном порядк, где единица предпоследняя...
Reply
Reply
обычно единица не требуется, у Вас просто очень мало символов, тут по хорошему вообще не нужно было ничего сжимать, меньше места бы занимало. Схема рассчитана на то, чтобы быть оптимальной в среднем случае, а не в каждом.
Reply
В общем ладно, будем ещё экперементировать. А вам спасибо ещё раз!
Reply
Leave a comment