Комментарии 46
Это означает, что если мы найдем функцию (формулу, уравнение) которая породит эту последовательность нулей и единиц в нужном порядке, то вместо музыкального файла, который занимает определенное место, мы можем решить его уравнение с определенными начальными условиями, которое занимает пару байт и получить ту же композицию, видеоряд или документ просто «нагрузив» процессор.
Вы серьезно думаете, что музыкальный файл можно описать (чем угодно), записывающимся в пару байт? Я вас расстрою, но таким образом принципиально нельзя описать более 65536 файлов.
Вы меня нисколько не расстроили, ведь я уверен в том, что это реально и цифра в 65536 файлов ничего не значит для метода который я разрабатываю. Конечно будет не пару байт но и, скорее всего не 30 мегабайт.
Вам слова "теорема Шеннона" о чем-нибудь говорят?
Естественно. И я прекрасно понимаю о чем Вы. Но, я оптимистично настроен) Конечно выше головы не прыгнешь, но залезть можно)
Я правильно понимаю, что вы "оптимистично настроены" опровергнуть теорему Шеннона?
Отнюдь, я не собираюсь ничего опровергать или хлопать по плечу классиков. У меня свой подход. Без нарушения причинно-следственных связей, законов и разрыва континуума.
Но подождите, теорема Шеннона (та, которая об источнике шифрования) говорит нам, что у каждых данных есть нижний порог сжатия, и он вычислим. Ваш подход предлагает сжатие сильнее, чем допустимое этим порогом, или нет?
а кто Вам сказал, что я собираюсь сжимать данные? Конечно, если их сжимать по самому хитрому алгоритму то его эффективность будет экспоненциально падать с уменьшением размера файла. Но об этом и речи не идет.
а кто Вам сказал, что я собираюсь сжимать данные?
Вы. Вы сказали, что собираетесь представлять данные с помощью других данных, меньшего размера. Я неправильно вас понял?
Мой метод не подразумевает процесса сжатия как такового. Скорее больше похоже на адресацию. Вы же не называете процессом сжатия кривой которую Вы описали с помощью регрессивного полиномиального анализа? Вы представили линию или точки как формулу. Я полагаю, что это находится в разных плоскостях с понятием сжатия. Это скорее трансформация. Прочем утверждать ничего не буду.
Мой метод не подразумевает процесса сжатия как такового. Скорее больше похоже на адресацию.
Чтобы работала адресация, необходимо адресуемое пространство. Когда вы вместо файла передаете информацию о нем, нужно, чтобы получатель мог эту информацию проинтерпретировать. С точки зрения теоремы Шеннона, интерпретатор+переданная вами информация — это и есть сжатая информация.
Вы же не называете процессом сжатия кривой которую Вы описали с помощью регрессивного полиномиального анализа? Вы представили линию или точки как формулу.
Представление последовательности из 256 нулей последовательностью "256 0", где первый символ — число повторов второго — это и есть сжатие, к которому прилагается деархиватор, умеющий такие последовательности интерпретировать. С точки зрения алгоритма это ничем не отличается от вашей кривой.
Ок. Я понял. Объясню так. Вы мне рассказали стих. Длинный такой. Если его записать в текстовый файл то он займет терабайт. Но я не хочу хранить у себя этот терабайт. Я попрошу Вас рассказать мне его снова. И получу ту же информацию из источника. Я не уверен что это можно отнести к сжатию информации.
На счет «последовательности из 256 нулей последовательностью „256 0“ я с Вами абсолютно согласен это процесс сжатия.
На счет «последовательности из 256 нулей последовательностью „256 0“ я с Вами абсолютно согласен это процесс сжатия.
Я попрошу Вас рассказать мне его снова.
Для этого вам нужен я. Я — это больше терабайта, поэтому вы ничего не выиграли (а только потеряли).
а это уж как посмотреть :)
но, не на моем винте) Источник информации должен быть источником информации. Генератор шума будет генерировать шум вопрос только в том, есть ли у Вас такой же генератор шума.
но, не на моем винте
Тогда ваш метод сводится к "давайте вместо файлов передавать их адреса в интернете". Круто, но упирается в пропускную способность между вами и источником информации (а это прямо противоречит вашему тексту).
На счет винта это была шутка юмора) Уважаемый, Вы когда нибудь пользовались функцией синуса? Сколько раз Вы подумали, что сжали информацию о синусоиде? На промежутке от 0 до pi на бесконечность мы можем получить таки длинный сигнал. Допустим тот же терабайт синусоиды. Но когда Вам нужно сгенерировать синусоиду той же длины Вы не скачиваете мой файл размером в терабайт. Вы просто задаете функции синус(х) вектор х. Я могу ошибаться, но процессом сжатия в таком случае было бы сжатие терабайтного файла до какого-то размера. Например, нашли бы один период синусоиды, а за ним написали бы число повторений.
Вы просто задаете функции синус(х) вектор х.
… и теперь мне нужно что-то, что умеет генерить синусоиду.
Я могу ошибаться, но процессом сжатия в таком случае было бы сжатие терабайтного файла до какого-то размера.
Вы ошибаетесь. Нет никакой разницы — взять фрагмент и сказать "повторите фрагмент k раз", или взять генератор и сказать "дайте генератору вход k". Более того, первое сводимо ко второму.
На том и остановимся. Извините, но мне нужно заниматься исследованиями, даже несмотря на то, что на Ваш взгляд они бессмысленны.
… но, шмель об этом не знает и продолжает летать.
… но, шмель об этом не знает и продолжает летать.
Я не говорю (пока), что они бессмысленны, я спрашиваю, как конкретно они соотносятся с теоремой Шеннона.
UPD: Ниже уже написали про это.
Тогда я предлагаю просто запустить вычисление числа π с точностью, стремящейся к бесконечности. И на каждом новом вычисленном промежутке искать последовательность байтов вашего файла. Как только вы её найдёте, вы сможете закодировать файл просто одним числом — смещением в π. (Кстати, есть файловая система с похожим принципом: https://github.com/philipl/pifs)
Вообще-то шмель — это вертолёт, а не самолёт, поэтому аэродинамика самолёта к нему не применима.
Если вы этого не знали, то это проблемы ваши, а не шмеля — это совершенно точно.
Если вы пытаетесь обойти теорему Шеннона, то это проблемы ваши, а не Шеннона.
Если вы этого не знали, то это проблемы ваши, а не шмеля — это совершенно точно.
Если вы пытаетесь обойти теорему Шеннона, то это проблемы ваши, а не Шеннона.
и я докажу Вам что это возможно
Вы бы сначала матчасть изучили, факты какие-нибудь поискали. Ну или хотя бы просто логически подумали над тем, что возможно не вы один до этого додумались, и значит есть какие-то причины, почему это не используется везде где только можно)
Чтобы задать уравнение, в точности повторяющее произвольную последовательность чисел, надо задать примерно столько же коэффициентов, сколько чисел в этой последовательности. В некоторых случаях можно задать меньше, если в последовательности есть повторяющиеся или похожие участки. Ваш пример с синусом — это ярко выраженный случай, значения повторяются в точности каждый период.
Кстати, можно задавать приближение не полиномами, а разложением в ряд синусов, это удобнее именно из-за их периодической природы. А еще можно приближать не точно, а примерно, выбрасывая малозначащие коэффициенты. И если применить это к изображениям, видео или музыке, то получаем JPEG / MPEG / MP3.
всё украдено до нас и так лежит в «Пи», осталось лишь придумать адресацию
К тому же я поспорил с коллегами на пиво, что смогу превратить видеофайл в небольшое уравнение.
Собственно, для этого вам нужно понять как работает человеческий мозг, сделать вывод о всех возможных способах восприятия того или иного видео. Потом изобрести самый короткий язык. После чего совсем просто — пересказываете на самом коротком языке смысл видео со всеми его аспектами, которые может воспринять человеческий мозг. Вот и все.
Для декодирования вам нужно создать кластер из искусственных мозгов чтобы они по заданному сценарию воссоздали нужное видео, т.е. как бы отсняли фильм заново.
Вот и все. Ведь важно не само видео — важно то что мы ощущаем, когда его смотрим. Повторите ощущения, саму суть — и не имеет значения насколько точно вы передали мелочи.
Грубо говоря задача сводится к качественному конвертору файлов mp4->txt->mp4
Если руководствоваться принципом ощущений, то нужно выяснить, каким образом они создаются в мозгу. Пока науке известно, что это очень сложно.
Но главное, ведь не ощущения, а то, как мы себя чувствуем после них, то есть пережитое. И человеку важно это самое «послевкусие». Ведь думая о простмотренном фильме мы в первую очередь вспоминаем, понравился он нам или нет и лишь затем концентрируемся на особенностях и деталях сюжета, актерах и игре.
Но главное, ведь не ощущения, а то, как мы себя чувствуем после них, то есть пережитое. И человеку важно это самое «послевкусие». Ведь думая о простмотренном фильме мы в первую очередь вспоминаем, понравился он нам или нет и лишь затем концентрируемся на особенностях и деталях сюжета, актерах и игре.
Обязательно напишите статьи, особенно, когда ничего не получится, неудачи тоже бывает интересно почитать. Держитесь там, всего хорошего и настроения вам.
Не отрицаю что это возможно для сжатия с потерями, но боюсь даже представить сколько времени уйдёт на подбор соответствующей формулы, даже не шибко то сильно и сжимающий 265 кодек работающий с вейвлетами работает ну очень долго.
Что-то припомнилась Sloot Decoding System.
По описанию подхода чем-то похоже. Интересно будет посмотреть, когда и если будет что-нибудь действующее (и не мистификация).
По описанию подхода чем-то похоже. Интересно будет посмотреть, когда и если будет что-нибудь действующее (и не мистификация).
Очередной архиватор Бабушкина.
Но ведь при синусоиде все равно передаешь информацию. Пускай не в файле, а сообщая как читать sin x, как понимать график синусоиды.
Не отрицаю, передавая такие данные как часто встречаемые последовательности и функции и реализуя их в аппаратуре и библиотеке можно снизить размер передаваемого от сервера к клиенту информации. Но это же давно известно… Пример — тот же e-tag в http. Зная как сравнивать e-tag можно сэкономить передачу закэшированного объекта, передавая только заголовки(которые меньше по размеру).
Не отрицаю, передавая такие данные как часто встречаемые последовательности и функции и реализуя их в аппаратуре и библиотеке можно снизить размер передаваемого от сервера к клиенту информации. Но это же давно известно… Пример — тот же e-tag в http. Зная как сравнивать e-tag можно сэкономить передачу закэшированного объекта, передавая только заголовки(которые меньше по размеру).
То что вы предлагате, вполне осуществимо. Но вам не зря толсто намекают на Шеннона. Берете «набор данных» и преобразуете в «формулу» для вычисления. Минимальная длина записи «формулы» будет не такая уж и маленькая, как вам кажется. Считайте за «формулу» весь объем информации нужной для восстановления исходного набора (софт+таблицы+«формула»). Нынешние архивы как с «потерей качества» так и без содержат внутри себя «формулу» и вспомогательные таблицы. Софт — архиватор или плеер — отдельно.
З.Ы. И да, архиваторы с внешними универсальными таблицами вполне себе вымерли как класс.
З.Ы. И да, архиваторы с внешними универсальными таблицами вполне себе вымерли как класс.
Очень интересно будет все же увидеть формулу для видео. Вот только какими методами вы собираетесь ее получить?
Мне тоже интересно было бы посмотреть демонстрацию. Похоже, Вы предлагаете обратимый хэш
Бабушкин, залогинтесь.
DSL
Забавно, что никто не учитывает объем который займет такая формула. А он может быть куда больше чем сама закодированная информация. А еще такая формула будет уникальна для каждого произведения...
Ну давайте попробуем рассмотреть некий очень частный вырожденный случай…
Итак, закодируем фразу "Мама мыла раму" в виде последовательности функций которые из пустой строки "" сделают нам эту фразу:
"".Append("Мама")
.Append(env.Whitespace)
.Append("мыла")
.Append(env.Whitespace)
.Append("раму")В принципе если рассуждать в терминах выполнимости — да, это выполнимо, до какой-то степени. В терминах эффективности — не эффективно.
С переходом от примитивных к более сложным функциям — объем кода уменьшится, вычислительная сложность увеличится.
В какой-то момент вы достигнете некоего предела сложности и у вас получится вариация свертки — алгоритм компрессии. Потом вы обнаружите что разные алгоритмы дают разные результаты на разных наборах данных, начнете использовать их комбинации и придумаете какой-нибудь кодек для определенного типа данных.
Поздравляю, вы выиграли пиво.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ключ к информационной революции