Сработает ли такой архиватор?

[Griffon2-7]

Берем файл, читаем побайтно. В некий временный файл записываем в виде текста бинарные значения байтов исходного файла, то есть, например, байт со значением 201 записывается как 11001001. В итоге получаем текстовый файл, состоящий только из нулей и единиц (можно также предположить наличие некоторого header-а). Тепеть архивируем получившийся временный файл (размер которого в 8 раз больше исходного) любым архиватором, который как известно архивирует текст гораздо эффективнее, чем предположим mp3-файл.
Вопрос в следующем, сожмется ли больший файл сильнее, чем если бы сжимался исходный маленький?

[Tivin]

А одно и тоже. Просто текстовые они по своей сути содержат больший потенциал для сжатия.

[Agregat]

Зависит от данных.

[Ektich]

Из man page gzip:
Gzip uses the Lempel-Ziv algorithm used in zip and PKZIP.
The amount of compression obtained depends on the size of
the input and the distribution of common substrings. Typ*
ically, text such as source code or English is reduced by
60-70%.

Ты увеличиваешь размер файла в 8 раз, а потом сжимаешь на чуть больше половины... по моему не получится...

[Agregat]

если только не получится очень хороший набор данных... которые например одним RLE можно скатать практически в 0 ;)

[Griffon2-7]

Хрен поймет одним словом. Все руки не доходят сесть и попробовать...
Просто если такая возможность есть, получится, что можно еще раз сжать получившийся архив, потом еще, еще, еще... В конце концов все превратится черт его знает во что... Следовательно есть какой-то теоретический предел, максимальный КПД...

[Tivin]

Просто если такая возможность есть, получится, что можно еще раз сжать получившийся архив, потом еще, еще, еще...
Чанцав, ведь при архивации добавляется соответствующая информация, так что предел довольно близок.

Так, например, очень маленькие файлы даже с первого архивирования получаются больше оригинала

[Agregat]

предел Дав определяется избытком информации в данных :)

[nm]

Господин Гриффон-5 :)

Есть понятие энтропии. которое очень четко позволяет сказать теоретический предел сжатия данных.

пусть у нас есть алфавит -- [ A, B, C ]

и текст состоящий из этого алфавита -- AABADCAAи тако далее.
пусть у нас есть функции - SIZEOF(Text), COUNT(Text, Symbol) - количество вхождений данного символа в текст.

вероятнсоть вхождения данного символа в текст -- P(Text, Symbol) = COUNT(Text, Symbol)/SIZEOF(Text).
Необходимое количество бит для кодирования всех вхождений данного символа --
Bits(Text, Symbol) = - COUNT(Text, Symbol) * LN(P(Text, Symbol))/LN(2)

минус, т.к. когарифм от вероятности всегда отрицательный

минимальная длина в который может быть закодирован текст (она-же энтропия) -- SUM(Bits(Text, Symbol) foreach Symbol in [A,B,C])

так что что хочешь делай, но меньше этого лимита не сожмешь :)

кстати .... я тут знаю один архиватор. для Doom2. сжимает его ровно в 1 байт. правда умеет сжимать и распаковывать только Doom :) ты понял к чему я клоню ? :)

[nm]

пример: если есть текст состоящий из 10 букв A и 10 букв B(поправка -- об их последовательности я ваще ничего не говорю, это не важно), ты его сожмешь минимум в 20 бит. т.к. каждый из них для кодирования требует ровно 1 бит.
если же текст состоит из 2 букв А и 18 букв B, то ты его сожмешь в 9.38 бит -- причем для кодирования А тебе потребуется 3.32 бита на символ, а для кодирования B -- 0.15 бит на символ

так. и еще -- насчет _дробных_ бит не удивляться -- это нормальное понятие в теории всего этого дела ;) и как ни странно и в практике тоже -- так арифмитечиское кодирование позволяет закодировать именно дробное количество бит на символ :)

[W_z_rd]

Ne vdavayas` v podrobnosti - ninakoy raznici ne budet.

[nm]

Ne vdavayas` v podrobnosti - ninakoy raznici ne budet.

будет ;)
оно увеличится в объеме:)
т.к. ни один архиватор не кодирует идеально до теоритического размера :)))))

[Nikita]

NM
No arxivator mojet prodelat` tvoyu operaciyu naoborot. I kstate on eto skoree vsego sdelayet, Zametiv chto kod sostoit iz 2 odinakovix posledovatel`nostey. a potom esli budet umnim yesh`o raz proidyotsya po tvoyemu file-u...
No ya dumayu vremennii file vsyoravno budet bol`she, t.k. yemu nujno budet derjat` informacuyu kodiruyush`uyu ASCII 0 i 1 ... chtobi potom mojno bilo vosstanovit` ;)

[nm]

accemic26 -- это теоритический минумум. доказательство и всяческие подробности всего этого дела есть в работах Шеннона.

если сумеешь предложить и доказать что-либо другое -- бросай все, чем ты занимался до сих пор, и доказывай -- докторскую точно сумеешь защитить ;)

[Agregat]

верьте Шеннону он не врет

[nm]

йо, Агрегат, бразер, и ты тут ? :)

[Nikita]

NM
Ya nemnogo znakom s teoriyey informacii, s entropiyey aka sobstvennoy informaciyey daje formulu pomnyu P = SIGMA(-Pn*log(BASE)(Pn)) <---- vrode tak ... .
BASE esli 2-ka v bitax, Vot tol`ko ne ponyal chto tebe ne ponravilos` v moix rossujdeniyax ...
Ekzamen sdan ?

[nm]

наконец сформулировалось -- этот топик мне напоминает изобретательство вечного двигателя :) НЛ