LINUX.ORG.RU

Теория почему сжатие данных дальше сокращения избыточности возможно

 , ,


1

2

В своей основе вопрос сжатия это принцип Дирихле: вот у нас строки большого размера, их больше, вот у нас строки меньшего размера, их соответственно меньше. количество клеток не совпадает с количеством голубей, ничего не получается, все расходимся? А вот и нет, можно добиться равенства, причем двумя путями: или меньше голубей, или больше клеток.

1)меньше голубей: Вот у нас множество всех строк, или файлов - вопрос интерпретации, длинны N. Мощность такого множество соответственно 2^N. Теперь посмотрим на множество всех строк длин (N-1) и (N-2) и…(1). Мощность этого множество будет ∑2^N, где N от (N-1) до (1), и равно это 2^N-2. Сравниваем мощности множеств, первое больше на два элемента. Ну а теперь финт ушами - мы просто берем и выкидываем два элемента из первого множества, для удобства это строки состоящие только из 0 или 1. И опаньки, биекция, если не верите можете прям на бумажке нарисовать и сравнить. И что получили в итоге? Получили что любую, кроме двух, строк можно переписать в виде минимум на один бит короче. Убрали бы больше элементов, сократили бы еще сильнее, это просто самый простой вариант.

2)больше клеток: Возьмем множество всех строк длинны от N до 1. Зададим функцию F(n), и обратную ей G(n), которая берет на вход один элемент и выдает другой. Во общем то все. F(n) функция абсолютно арбитрарная, просто применяешь F(n) несколько раз, пока нужный результат не получишь и все. Другое дело что хотелось бы побыстрее, поэтому -

2.1)столько же клеток, но в другом порядке: Вот возьмем множество всех строк размера N и упорядочим его следующим образом. Для этого мы берем функцию X(n), делает она следующие - берет бинарную строку и возвращает натуральное число от 1 до 2^N. Как она должна его считать честно не знаю, но она должна делать что-то приблизительно следующие: строим бинарное дерево(?) сравнений, сначала сравниваем половинки строки друг с другом. потом четвертинки, и вот тут уже не знаю, нужно ли сравнивать каждую с каждой или хватит сравнений 1 к 2, и 3 к 4. потом осьмушки итд. в конце сравниваем соседние биты, вот тут каждый с каждым точно лишнее. Потом переводим эти сравнения в значения с весами, например строки в которых есть повторения половинок должны быть ниже чем те у которых повторяются четвертинки, а те у которых нет повторений ни четвертинок ни половинок должны стоять выше, ближе к началу, к числу 1. Потом делаем над этими значениями некие операции и ВЖУХ! получаем натуральное число, он же порядковый номер. К примеру если N=8, то строка 11111111 должна иметь номер 256, строка 00000000 номер 255, строка 11111110 номер 254 итд. Вот что это за ВЖУХ! и нужно выяснить. Сначала я думал что можно просто обойтись тем что можно представить строку как число сочетаний из количества единиц по N, и все сочетания, где количество единиц приближается к половине длинны, просто поставить спереди, но потом прикинул что например строка 00001111 при таком подходе будет стоять выше чем строка 00101001, а это фатальный недостаток. Ну вот, допустим выясняли как ВЖУХ! выглядит, нашли порядковый номер в упорядоченном по повторениям списке. А теперь просто подставляем вместо этой строки другую строку с тем же номером, но в списке упорядоченном просто лексикографически. Ну а дальше например отправляешь данную строку в метод 1).

Остается только реализовать это все в софте. А вот это я не умею. Может кто-нибудь напишет?


Ответ на: комментарий от Obezyan

прочитайте по слогам: существует по крайней мере одна n-битовая строка

а кстати да, действительно написано именно «по крайней мере». ну так это некорректная формулировка. смотрим формулу которую там написали ниже

1+2+4+…2^(n-1)=2^(n)-1

что она значит? что множество всех строк длинны n больше множества всех строк длины меньше n, включая пустую строку, на один элемент. если убрать из множества всех строк длинны n одну строку, любую, то эти множества станут равнозначны, биекция. я даже пример таблиц для n=4,5 и 8 привел, не включая пустую строку. собственно если сейчас вы не запостите те две строки для n=8 которые мы выкинули, то разговор с «вами» я считаю оконченным. считайте это капча, если «вы» не способны проделать подобное простое действие то я в полном праве считать что вы не человек, а зверь из книги откровений, картинка в профиле очень сильно намекает на это. в конце-концов это интернет, ты никогда незнаешь с кем ты разговариваешь.

Опровергать теорему математически

аргумент против примерно следующий. пусть у нас есть некий алфавит, пусть для примера в 128 символов. просто исходя из принципа Дирихле можно заключить что в любой строке размером в 129 таких символов будет хотя бы 2 одинаковых символа. понятно почему это? в любой строке длинной 256 все символы имеют хотя 2 повторения. устремим теперь длину в бесконечность. допустим у нашей строки нормальное распределение символов, каждый символ имеет одинаковую вероятность появления. однако, одинаковая вероятность появления одного символа не означает что пара символов тоже будут иметь одинаковую вероятность появления. что, получилось что и пара символов в нашей строке имеет одинаковую вероятность появления? не беда, проверяем тройку. потом четверку. в итоге имеем что вероятность никаких повторений стремиться к нулю при увеличении длины строки => чем строка больше тем больше вероятность что её можно сократить хоть как-нибудь.

Скажите, как вы относитесь к теории плоской земли и вечному двигателю?

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

q250
() автор топика
Ответ на: комментарий от q250

что она значит? что множество всех строк дли[н]ы n больше множества всех строк длины меньше n, включая пустую строку, на один элемент.

Где вы предлагаете хранить ту самую длину, меньшую n?

pasquale
()
Ответ на: комментарий от pasquale

Где вы предлагаете хранить ту самую длину, меньшую n?

это уже четвертый раз когда меня об этом спросили в треде. длину оригинальной строки мы храним в теле архиватора => архиватор принимает на вход файлы ТОЛЬКО определенной длинннннны.

математика или разработка алгоритма компрессии?

и первое, и второе, и компот.

Это лучший форум математиков: https://dxdy.ru/

был там как то раз, создавал тему про замощение плоскости нерегулярными восьмиугольниками, в конце еще добавил «ребят, а вы в курсе что ковид19 это начало книги откровений?», удалили за час без объяснения причин. на редите тоже все грустно, даже запостить ничего не успел получил шадоубан.

q250
() автор топика
Ответ на: комментарий от q250

аргумент против примерно следующий. пусть у нас есть некий алфавит, пусть для примера в 128 символов.

вполне достаточно алфавита из 0 и 1, проводите рассуждения в нем и не путайте себя алфавитом из большего количества символов.

ваш утекший не пойми куда бит, утек потому, что вы делаете для фиксированной длины исходного файла. знание о фиксированной длине - это тоже знание. то есть информация. вы пустили эту информацию побоку, «записали на бумажке» и передали не в «упакованном» файле, а еще одним грубо говоря «файлом». думайте в этом направлении уже.

теорема имени меня.

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

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от q250

притащил религию на форум по математике

удалили за час без объяснения причин

Странно, конечно. Почти так же странно, что что и здесь оно висит в Development, хотя явно относится к S&E — месту для всякого антинаучного мракобесия.

на редите тоже все грустно, даже запостить ничего не успел получил шадоубан

Это заговор 🥸

anonymous
()
Ответ на: комментарий от q250

длину оригинальной строки мы храним в теле архиватора

Мы не говорим о длине оригинальной строки. Мы говорим о переменной длине строки, в которую вы отображаете оригинальную.

pasquale
()
Ответ на: комментарий от alysnix

вполне достаточно алфавита из 0 и 1

ну ок. пусть наша вероятность появления символов «0» и «1» одинакова и равна 0,5. означает ли это что вероятность появления условно сказано символов «00» и «01» и «10» и «11» одинакова и равна 0,25?

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

не, он просто куда-то утек. случай -1 бит уникальный и требует убирания из множества только двух строк, если пустая не используеться, или только одной, если используеться. вот начиная со случая -2 бит начинает происходить то что в книжке бибизьяна написанно, приходиться убирать очень много строк, аж половину. для -3 бит еще сверху убрать четвертую часть итд. хотя честно говоря я бы не сильно расстроился для случаев -2 и более бит, пришлось бы пожертвовать взаимной однозначностью, ну и что такого? ну будет архиватор возвращать не единичный файл а два, какой-то из них наш оригинальный, а второй какой угодно, простейший пример зеркальное отражение 0 на 1 и 1 на 0. наш файл прочитаеться нормально, а другой скорее всего нет. ну а если да, то штож,поздравляю, мы перевыполнили план сжатия данных.

’>знание о фиксированной длине - это тоже знание. то есть информация. вы пустили эту информацию побоку, «записали на бумажке» и передали не в «упакованном» файле, а еще одним грубо говоря «файлом».

ну да, все так. а это плохо?

Мы не говорим о длине оригинальной строки. Мы говорим о переменной длине строки, в которую вы отображаете оригинальную.

так, а что не так с переменной длинной отображенной строки?

Так форум не о ковиде, а о математике.

так и вопрос был по математике. про ковид там в конце было в P.S. заметка уровня забавного факта. вот тут тоже забавные факты про электромагнетизм проскакивают, однако посты не трут а тред не сносят.

q250
() автор топика
Ответ на: комментарий от q250

Задача про кроликов и клетки

https://foxford.ru/wiki/matematika/printsip-dirihle?ysclid=lpfcwr8ss015886996... Принцип Дирихле

Определение Принципом Дирихле традиционно называют следующее утверждение:

если в 50 клетках сидит 51 кролик, то по крайней мере в одной клетке сидит не менее двух кроликов.

Доказательство

Доказательство этого принципа очевидно. Действительно, пусть это утверждение неверно, тогда в каждой клетке сидит не более одного кролика, и, следовательно, в 50 клетках — не более 50 кроликов, а их должно быть 51. Получили противоречие.

В математической терминологии принцип Дирихле звучит так:

если элемент разбит на множеств, то по крайней мере одно множество содержит не менее двух элементов.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 1)
Ответ на: комментарий от q250

ну ок. пусть наша вероятность появления символов «0» и «1» одинакова и равна 0,5. означает ли это что вероятность появления условно сказано символов «00» и «01» и «10» и «11» одинакова и равна 0,25?

разумеется да. гуглите «произведение вероятностей назависимых событий»

alysnix ★★★
()
Ответ на: комментарий от Forum0888

просто выкидываем все клетки где есть один кролик. уменьшая число кроликов и число клеток каждый раз на один. в конце концов остается одна клетка и два кролика.

alysnix ★★★
()
Ответ на: комментарий от q250

ну да, все так. а это плохо?

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

упакованная последовательность должна содержать ВСЮ информацию из исходной последовательности. ничего дополнительного по телефону васе от пети передавать нельзя.

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

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 3)
Ответ на: комментарий от Forum0888

Ещё

Для того, чтобы применить принцип Дирихле к компрессии нужно
выяснить нет ли одинаковых элементов (здесь вариации на тему), а не просто отбрасывать элементы.

Да и полезен ли он для алгоритмов компрессии?

В них и так понятно, что для компрессии нужно выявить некую общность в данных.

Это весьма интересная задача.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 3)
Ответ на: комментарий от q250

разговор с «вами» я считаю оконченным.

Именно так, не вижу смысла далее метать бисер.

вы не человек, а зверь из книги откровений, картинка в профиле очень сильно намекает на это.

Да, я Обезъян и не стесняюсь этого.

Obezyan
()
Ответ на: комментарий от q250

это шутка что ли?

По вопросу о превозмогании невозможности остаётся только шутить в стиле покрути ещё вот эдак, может тогда сможешь донести до нас свою мысль.

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

А хеш-функции знаешь как хорошо жмут?

ratvier ★★
()
Ответ на: комментарий от ratvier

разумеется да. гуглите «произведение вероятностей назависимых событий»

я наверно просто не понимаю что такое вероятность. вот пример строка 01010101. «0» и «1» поровну, а вот «00» и «01» и «10» и «11» нет. как вы это объясните? или строка не достаточно случайная? а такая - 01011001 ?

упакованная последовательность должна содержать ВСЮ информацию из исходной последовательности. ничего дополнительного по телефону васе от пети передавать нельзя.

кому должна, кооперативу «озеро»? или вы из тех людей кто каждый раз WinRar перекачивает? так то это именно это самое, сама по себе программа WinRar это именно «по телефону васе от пети». да нам удалось выявить некие общие закономерности в начальных данных, в данном случае их размер, и передать его отдельно, в теле архиватора. все еще не вижу никаких проблем. не вижу проблем и с вашим примером упаковки в 1 бит, если ваша прикладная работа требует сжать именно ту последовательность максимально, то почему нет, пример полностью корректный.

Да и полезен ли он для алгоритмов компрессии?

они на нем основаны как бы. ~голосом Рыбникова~ это БАЗА

В том, что ее нужно где-то хранить, и это сводит на нет сжатие.

зачем хранить длинну получившийся строки? далеко ходить не будет, пример для понимания из таблицы N=8

01110000 переводиться в 110001.

зачем нужно хранить длину «110001»? для чего? вот оригинальную длину, 8, хранить нужно да. а тут зачем? требуются пояснения.

Да, я Обезъян и не стесняюсь этого.

нет, ты робот, цифровая имитация жизни, который капчу пройти не смог.

может тогда сможешь донести до нас свою мысль.

а что её доносить то? на картиночки с таблицами посмотри, сразу понятно станет.

А хеш-функции знаешь как хорошо жмут?

кстати не видел ни одной реализации. вот если серьезно, не как шутку, воспринять идую использовать хеш-функции для сжатия, то как будет выглядеть процесс «разархивирования»? любой алгоритм или линейный, или его можно заставить работать линейно, т.е. хеш-функция будет выплевывать обратно файлы по порядку. остаётся только указать номер, или диапазон номеров, где был наш оригинальный файл.

забавно, что никому в голову не пришла идея прокрутить фарш еще раз. вот что будет если алгоритм из пункта 1) использовать на строке еще раз, в этот раз мы добавляем log(n) в сам файл? а потом еще. а потом еще. и так пока в не упремся в запретные виды входный строк. я то знаю, мне просто интересно как внимательно народ тред читает и воспринимает.

q250
() автор топика
Ответ на: комментарий от pasquale

в смысле как? это буквально четыре разных строки, их не нужно отличать, они различны сами по себе. взяли 01110000 перевели в 110001, записали на диск 110001, все, где-то на диске теперь хранится файл именно с таким содержимым. я ход мыслей не понимаю, где проблема то?

q250
() автор топика
Ответ на: комментарий от q250

архиватор принимает на вход файлы ТОЛЬКО определенной длинннннны

тогда достаточно дерево Фано али какое другое дерево Хеминга(свободное от префиксов) построить на буквах - вот эти вот последовательности определённой длины - с их частотами ожидаемыми на входе в архиватор - тогда каждая такая последовательность будет оптимально(если частоты соразмерны с какой либо отрицательной степенью двойки(для случая бинарного дерева и кодирования) кодироватся путём в дереве Хемминга например

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

qulinxao3 ★★
()
Ответ на: комментарий от q250

вот если серьезно, не как шутку, воспринять идую использовать хеш-функции для сжатия, то как будет выглядеть процесс «разархивирования»?

Гугли про поиск коллизий и атаки на слабые хэш-функции.

anonymous
()
Ответ на: комментарий от q250

я наверно просто не понимаю что такое вероятность. вот пример строка 01010101. «0» и «1» поровну, а вот «00» и «01» и «10» и «11» нет. как вы это объясните? или строка не достаточно случайная? а такая - 01011001

вероятность это подбрасывание монетки. кидайте монетку и пишите очередной бит. орел - 1, решка - ноль. 8 раз кинете монетку - получите случайное 8 битное число.

вероятность ЛЮБОГО 8 битного числа - 1/256, при таких подбрасываниях. и неважно какое это число. то есть в среднем из 256 экспериментов произвольное 8 битное число будет встречаться один раз.

такие случайные числа невозможно упаковать. каждый новый бит никак не зависит от предыдущих битов.

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от anonymous

тогда достаточно дерево Фано али какое другое дерево Хеминга(свободное от префиксов) построить на буквах - вот эти вот последовательности определённой длины - с их частотами ожидаемыми на входе в архиватор - тогда каждая такая последовательность будет оптимально(если частоты соразмерны с какой либо отрицательной степенью двойки(для случая бинарного дерева и кодирования) кодироватся путём в дереве Хемминга например

ссылку на вики про что это можно?

Гугли про поиск коллизий и атаки на слабые хэш-функции. https://intuit.ru/studies/courses/553/409/lecture/9375?page=1 ой, да это я так сказал, примера ради. мне бы со своим разобраться.

премиса 1: вероятность ЛЮБОГО 8 битного числа - 1/256

премиса 2:такие случайные числа невозможно упаковать

вывод: любые 8 битные числа нельзя упаковать. что неправда.

На диск нельзя записать «110001».

воот. мне так и не показал как решать подобное из коробки.

Там анонимуса не пускают. Или пускают?

караул, куркули наших бьют.

q250
() автор топика
Ответ на: комментарий от q250

вывод: любые 8 битные числа нельзя упаковать. что неправда.

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

alysnix ★★★
()
Ответ на: комментарий от q250

Бауэр Ф., Гооз Г. Информатика. М., «Мир», 1990 г. — Т. 1.

классический уч-#$-ник c проинфляционировавшим термином в названии

qulinxao3 ★★
()
Последнее исправление: qulinxao3 (всего исправлений: 1)
Ответ на: комментарий от unC0Rr

компрессор вообще работать не будет. автор пребывает в уверенности что сжать можно любую последовательность бит. откуда немедленно следует, что все что угодно можно сжать либо в 0, либо в 1. откуда немедленно следует, что вся сложность мира содержится в нуле и единице. откуда немедленно следует вызов санитаров и медикаментозное лечение

alysnix ★★★
()
Ответ на: комментарий от unC0Rr

Как будет работать алгоритм разжатия?

ТС тут неподалёку уже предлагал выполнять функции криптографического хэширования в обратном порядке. Видимо, как-то так и будет.

anonymous
()
Ответ на: комментарий от alysnix

Не, я-то понимаю, что у ТС всё сжатие сводится к отбрасыванию ведущего префикса из нулей, а длина оставшейся части последовательности хранится магически и не является частью сжатых данных. Мне просто интересно обобщение идеи с точки зрения ТС.

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

если у меня есть компрессор для строки длиной N, и есть строка длиной k*N, могу я разбить свою строку на k строк длиной N и сжать? Как будет работать алгоритм разжатия?

если отдельно, отдельной программой, из файла длиной k*N получить k файлов длиной N, то какой-то будет какой-то смысл, а так нет, алгоритм из пункта 1) не смотрит на внутреннее строение.

что сжать можно любую последовательность бит

почти так. сжатие это вопрос существования биекции между множеством более длинных строк ко множеству менее длинных строк. в пункте 1) я показал что существует биекция, за минусом двух строк, всех файлов длины N бит ко всем файлам длин N-1 и N-2 и…1 бит, т.е. существует алгоритм сжатия.

все что угодно можно сжать либо в 0, либо в 1.

мощность множества «либо 0, либо 1» равна 2, мощность множества «все что угодно» не равна двум, биекции нет, значит сжать нельзя. вот мощность множества «любые 2 конкретные строки» равна 2 и его можно проецировать на множество «либо 0, либо 1».

q250
() автор топика
Ответ на: комментарий от unC0Rr

всё сжатие сводится к отбрасыванию ведущего префикса из нулей

ООО, хоть кто читает, смотрит на картинки и даже их анализирует. да, там действительно происходит почти это, еще значение на единицу уменьшаем. и это действительно смотрится не очень эффективным сжатием. ну так а что нам мешает перетасовать элементы из левой колонки в выгодном для нас порядке? поставить в начале списка строку не 000…001 а строку с максимальной энтропией.

кстати-кстати, если уж заниматься анализом, то вопрос: не хочешь подумать что будет со строкой если фарш пропустить до предела, пока не упремся в запретные строки для входа? интересный комбинаторный вопрос, однако если не охота думать а узнать хочется то чирикни.

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

почему оставшейся? это первоначальную длину log(N) хранить как-раз нужно. ну мы её и храним либо дописывая к сжатым данным, либо «магически» в теле архиватора, т.е. архиватор сжимает файлы СТРОГО определённого размера, не битом больше не меньше.

Но если я разобью файл на k файлов и сожму каждый по отдельности, что помешает мне собрать файл из результатов компрессии?

ничего не помешает.

q250
() автор топика
Ответ на: комментарий от q250

почему оставшейся?

Потому что на картинке (https://imgur.com/a/dLMLSVV) 00000001 превращается в 0, а 00111111 в 000000. Длина входных данных одинакова, а выходные очевидно отличаются не численным значением, а длиной. Разве не так?

ничего не помешает.

Допустим, k = 2, N = 8. Мою строку 0000000100111111 я разобью на две - 00000001 и 00111111, сожму в пару из 0 и 000000, запишу в файл (опустим детали записи битов вместо байтов). Как мне из последовательности 0000000 получить исходную строку?

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

Разве не так?

нет, это буквально две разные строки.

Мою строку 0000000100111111

сейчас на диске храниться:

файл 1, содержимое=0000000100111111

я разобью на две - 00000001 и 00111111

сейчас на диске храниться:

файл 2, содержимое=00000001

файл 3, содержимое=00111111

сожму в пару из 0 и 000000, на данном этапе на диске храниться:

файл 4, содержимое=0

файл 5, содержимое=000000

пока все нормально

запишу в файл

вот тут встает проблема, если их записать прям подряд в виде 0000000 их действительно обратно не разбить. нужен или символ разделения, а зачем если файловая система работает как этот символ, или действительно указать длину оригинальных строк, можно только одной.

q250
() автор топика
Ответ на: комментарий от q250

файловая система работает как этот символ

Отлично, предлагаю архиватор: берём файл и разбиваем его на меньшие файлы на каждом предопределённом символе, например из «1234» будем делать файлы «1» и «34». Как собрать исходный - очевидно. Осталось только подсчитать экономию места на диска. И это мы ещё даже не распределили часть информации в само имя файла или ещё какие-нибудь метаданные.

unC0Rr ★★★★★
()
Последнее исправление: unC0Rr (всего исправлений: 1)