Re: еще дополнение о суперкомпрессии

Имя (желательно полное):

E-Mail:

URL:

Город:

Страна:

Вежливый и подробный комментарий:
(Форматируйте его, пожалуйста, как почту - короткими строками
Еnter в конце строки, пустая строка между параграфами).
> > > > > > Или проще: берем не сжимаемый файл (мы не знаем что это zip архив) и преобразуем его в новый файл (с помощью алгоритма unzip), затем сжимаем например rar'ом - получили снова случайные данные, но файл наверняка будет меньше. > > > > > Это неверно. Если мы возьмем некую случайную последовательность, и распакуем ее unzip, мы получим файл с избыточностью, достаточно точно соответствующей модели избыточности, присутствующей в pkzip. Такой файл будет лучше всего жаться именно pkzip :) > > > > Неверно что? Если мы рассматриваем под случайной последовательностью zip архив (чем он и является), > > > > то это совсем не значит, что распакованный файл будет _лучше_ всего сжат pkzip'ом (что очевидно). > > > Если мы будем распаковывать случайную последовательность unzip, то в подавляющем большинстве случаев то, что получится после распаковки лучше всего будет жаться zip. > > > Причина в том, что статистические свойства распакованной последовательности будут соответствовать модели, принятой в zip. > > Может и так, если алгоритм упаковки будет использовать _только_ статистические данные zip'кие, а если он использует не только их (7zip жмет лучше zip, потому что использует другую статистику нежели zip) > В таком случае получится "суперкомпрессия". Доказательства невозможности подобной вещи я уже приводил. Попробую обьяснить механику. > Пусть мы распаковываем некие случайные данные неким достаточно слабым биективным компрессором C. > Обозначим результат распаковки им случайных данных как C(-1)(random) > Предположим для определенности, что этот компрессор -- PPM order-1, Escape method A. Пусть мы распаковываем 100-й символ, и контекст 1-го порядка, соотвествующий 99-му символу был просмотрен 4 раза, и всегда там встречался пробел. Тогда с вероятностью > 4/5 этот декомпрессор 100-м символом выдаст пробел. Естественно, что наиболее оптимально этот символ закодирует компрессор, который в детерминированном контексте, где некий символ встречался 4 раза присвоит этому символу вероятность 4/5. Продолжая рассуждения приходим к тому, что компрессор, оптимально кодирующий > C(-1)(random) должен обладать всеми свойствами C. То есть, с практической точки зрения, совпадать с C. > > > Не смотри, что на тестах Rar обходит zip -- это вовсе не означает, что для _всех_ файлов Rar будет лучше, чем zip. > > Но если бы rar был хуже для большинства файлов, он не получил своего распространения. А никто не запрещает комбинировать при сжатии несколько алгоритмов, или сразу выбирать из нескольких лучший, это потребует всего несколько бит в архиве. > В отдельных, я бы сказал, уникальных случаях, такой подход действительно позволит добится выигрыша. > > > > Поскольку рар(или 7zip) будет находить в распакованном файле избыточность, которую unzip не добавлял (в соответствии со своей моделью) но она появилась, т.к. используется новый алгоритм упаковки. > > > 7zip может распакованные unzip данные сжать и лучше из-за особенностей LZ. > > > > > Кроме того, один и тот же файл можно по-разному упаковать так, чтобы unzip выдал одинаковые результаты. > > > > но не получиться сжать файл меньше определенного размера так, чтобы unzip его распаковал однозначно, а другой архиватор эту границу может с легкостью преодолеть. > > > > т.е. _любому_ unpack'ку пожно подсунуть два разных файла, которые он распакует совершенно одинакого??? > > > Да, теоретически, за исключением биективных компрессоров. > > значит не любому ;)

Пожалуйста, заполните все поля.
И не нажимайте по два раза на кнопку! Дождитесь ответа сервера.

[an error occurred while processing this directive]