Оптимальное LZ-кодирование

[lvd]

не согласен. нечего было лопухаться, когда составляли правила. дал слово - держи!

Дык учтём инфу о длинах файлов - и всё. =)

[Advertiser]

[Hrumer]

2SMT: Как я слышал, изначально в правилах вообще не оговаривался этот пункт, а в дальнейшей переписке "автор" спора согласился, что после упаковки файла результат упаковки мог быть в нескольких файлах... Вот кастати, есть страничка где то в инете Леонида Брухиса(если не ошибаюсь) - там есть пари о сжатии...

[lvd]

Итак, прога написана. Собирается под мсвц, под гцц в линухе и на амиге SAS/C. Умеет паковать оптимальным методом, паковать 'жадным' методом, распаковывать.
Осталось только подобрать тестов-бенчмарков и написать ртфмы. Принимаются предложения по тестам-бенчмаркам (чтоб сравнить оптимальное кодирование с "жадным", которое даёт по длине такие же результаты, как и спековский MegaLZ, и с хрустом-хрумом-рипом) в виде самих файлов =)

[Vitamin]

Принимаются предложения по тестам-бенчмаркам

1) код пзу
2) картинки с разными типами текстур (ordered/floyd-steinberg)
3) тексты (чисто английские и англо-русские)
4) кодовые блоки (сырые и уже ужатые разными пакерами)

[jtn]

уже ужатые разными пакерами

они увеличиваются на 1/8, т.е. на 12,5%. всегда.

[Vitamin]

они увеличиваются на 1/8, т.е. на 12,5%. всегда.

зависит от пакера, которым ужаты. и от метода текущей упаковки. я когда тестировал арифметическое сжатие, пробовал хриповые файлы дожимать- 10..15% выигрывал. а вот для рипа результаты был гораздо хуже- буквально несколько байт (подозреваю что на заголовке)

[lvd]

зависит от пакера, которым ужаты. и от метода текущей упаковки. я когда тестировал арифметическое сжатие, пробовал хриповые файлы дожимать- 10..15% выигрывал. а вот для рипа результаты был гораздо хуже- буквально несколько байт (подозреваю что на заголовке)

А когда ты тестировал LZ-сжатие, насколько у тебя дожималось? =)

[GriV]

которая до шарика на вообще несжимаемых файлах рабочий алгоритм давал увеличение только на три байта [на самом деле чуток меньше] (-8 причём сама таблица сжатия оттуда занимала два с копейками - и ровно 1 бит последовательность добавляемая в сжимаемый файл упаковщиком - как раз та самая управляющая последовательность.
Так что действительно это зависит только от типа используемого упаковщика.

[Vitamin]

А когда ты тестировал LZ-сжатие, насколько у тебя дожималось? =)

ну я ж говорю- хруст на 10...15% ужимался (а это LZSS если я ничего не путаю). в частности, упакованный текст из 10кб ужимался примерно в 8.5. исходы проги лежат в одном из номеров infoguide.

[lvd]

ну я ж говорю- хруст на 10...15% ужимался (а это LZSS если я ничего не путаю). в частности, упакованный текст из 10кб ужимался примерно в 8.5. исходы проги лежат в одном из номеров infoguide.

Чё-та я не впёр - то ты арифм. cжатие тестировал, то LZSS... =)