[an error occurred while processing this directive]
[an error occurred while processing this directive]
|
Автор: Serge Osnach, Kiev, Ukraine, 19 ноября 2002 года в 13:49:30 В ответ на : Re: Вопрос: А есть ли где-нибудь матописание суперкомрессии без потерь? от Сергей в 19 ноября 2002 года в 13:00:08: > > > Интересуют описания суперкомрессии без потерь > > Это есть в теории множеств. :) > > Достаточно просто доказывается, что > > таких алгоритмов не существует. > Так и предполагал, что в ответ услышу что-то подобное… Вообще-то я попробовал найти в теории множеств такое доказательство, посмотрел и в учебниках и в инете – что-то там я ничего не нашел. Максимум, что я нашел в виде доказательства невозможности существования такого алгоритма в инете – что-то типа «отображением множества всегда является множество», что в общем-то ни о чем не говорит. Множество архивов (цепочек с примерным равенством 1 и 0 в них) гораздо менее мощное, чем множество всех остальных файлов той же длины. Доказательство довольно простое: Кроме того, а что твой компрессор будет делать с файлами, у которых количество "0" значительно больше, чем количество "1"? > В то же время есть такой пример – под ДОС была такая замечательная программка-заставка «Полет над песками Марса», размером что-то порядка 1 или 2 килобайт. У меня возник вопрос – а если то же самое мы опишем в МП4 формате (до повтора) – сколько это займет места? Это неплохой пример избыточности, не используемой в настоящее время видеокодерами. К сожалению, данная избыточность довольно-таки редко встречается. :-) > Значит можно для данного случая создать какой-то алгоритм, позволяющий получить суперкомпрессию. За счет чего она получается – данные описываются в виде функции. Но это для частного случая – а можно ли применить для любого? Можно попробовать, если попытаться построить функцию, значения которой будут близки к данным, а потом отдельно закодировать разницу между данными и полученной функцией. > Возникла тут у меня на основании этих рассуждений одна идейка (в реализации не совсем такая, как описал выше, но в общем-то в первом приближении недалеко от этого), написал несколько тестовых программок – и вдруг неожиданно для самого себя увидел, что вроде бы она (идея) должна работать. Если заработал упаковщик, это еще ни о чем не говорит. Нужно, чтобы работал распаковщик. :-) > Но есть очень большие сомнения что такой алгоритм потянет современный компьютер… Вполне возможно, что эффект архивации и будет достигнут, но необходимое для вычисления нужной функции время будет измеряться днями или годами или столетиями. Точно математику к сожалению пока не досчитал – слишком уж она при кажущейся простоте идеи получается навернутой – и в теоретическом плане и при возможной реализации в программе. > И, естественно, у меня возник вопрос – а может я пытаюсь изобрести велосипед? Скорее, это сродни вечному двигателю. > Может уже есть что-то подобное, описанное математиками и уже известно примерно, что при достижении компьютерами определенной мощности такие архиваторы появятся? В любом случае математику я наверное досчитаю – надеюсь, что в течении ближайшего месяца. Но имеют ли смысл мои телодвижения в данном направлении? Вот как раз этот вопрос я и хотел для себя прояснить, может все это уже давно известно и не стоит тратить впустую время... > > Любой архиватор/компрессор сжимает Возможны, не спорю. Но есть такое понятие, как "реальные файлы" -- то есть такие файлы, которые обычно люди сжимают на практике. И тот человек, который наиболее полно использует избыточность реальных файлов, и получает хорошо жмущий архиватор. > > "Теоретически несжимаемые данные" обладают тем свойством, что в них подобные закономерности отсутствуют. Возьми архив, сделанный любым архиватором, использующим арифметический кодер, и посмотри на статистику в этом случае. Архивы, .mp3 и тому подобное -- это специальный подвид реальных файлов. В том же .mp3, который пожат Хаффманом на выходе действительно имеются закономерности, позволяющие его немного дожать. zz.mp3 : 202016 bytes Возможно, имеет некий смысл сделать компрессор для малоизбыточных файлов. |