Исходное сообщение
"Первый стабильный выпуск zlib-ng, высокопроизводительного фо..." Отправлено Аноним, 17-Мрт-21 22:39
Zophli ровно обратную задачу решает: хрен с ней с скоростью, зато максимально плотное сжатие в пределах этого формата. Фокус в том что один и тот же формат сжатия можно кодировать разными способами. При этом получается разная степень сжатия. Для относительно простых форматов - есть даже некая теория "optimal parsing". Для сильно некоторых форматов, совсем простых, как LZ4 - реализуем полностью оптимальный парсинг (лучше которого чисто теоретически сжать те данные невозможно, в пределах выбранного формата). Более сложные варианты форматов - используют эмпирические приближенные к оптимальному подходы, с мощным match finder и множеством попыток кодирования потока чтобы отобрать наиболее удачные варианты. А для двухстадийных схем по типу LZ+Huffman (как в zlib) - оптимальность парсинга LZ ничего не говорит о том как оно будет по оптимальности кодирования хаффману и это еще более приблизительно. Однако zophli пытается нечто довольно близкое к оптимуму для формата и обычно может сжать плотнее остальных. Ценой ломового жрача ресурсов, конечно. Зато это занимает чуть меньше места и формат остается стандартный, не требует изменений существующих декодеров. И можно скостить еще немного места "на халяву" (без переделки софта).

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> Zophli ровно обратную задачу решает: хрен с ней с скоростью, зато максимально > плотное сжатие в пределах этого формата. > Фокус в том что один и тот же формат сжатия можно кодировать > разными способами. При этом получается разная степень сжатия. Для относительно простых > форматов - есть даже некая теория "optimal parsing". Для сильно некоторых > форматов, совсем простых, как LZ4 - реализуем полностью оптимальный парсинг (лучше > которого чисто теоретически сжать те данные невозможно, в пределах выбранного формата). > Более сложные варианты форматов - используют эмпирические приближенные к оптимальному > подходы, с мощным match finder и множеством попыток кодирования потока чтобы > отобрать наиболее удачные варианты. А для двухстадийных схем по типу LZ+Huffman > (как в zlib) - оптимальность парсинга LZ ничего не говорит о > том как оно будет по оптимальности кодирования хаффману и это еще > более приблизительно. Однако zophli пытается нечто довольно близкое к оптимуму для > формата и обычно может сжать плотнее остальных. Ценой ломового жрача ресурсов, > конечно. Зато это занимает чуть меньше места и формат остается стандартный, > не требует изменений существующих декодеров. И можно скостить еще немного места > "на халяву" (без переделки софта).
	Введите код, изображенный на картинке: