Физик погрузил мяч в стакан с водой и измерилл объём вытесненной жидкости.
Математик измерил диаметр мяча и рассчитал тройной интеграл.
Инженер достал из стола свою «Таблицу объёмов красных резиновых мячиков» и нашёл нужное значение.
Потом пришло понимание, что такая таблица должна быть бесконечно большой и при этом постоянно расширятся прям как наша вселенная. Но в жизни часто приходится пользоваться и таблицами, и функциями, которые могут порождать табличные данные. Иными словами, вместо одного массива данных возможно воспользоваться уравнением, которое, при определенных условиях сможет повторить все значения массива.
Вопрос только в том, что для нас предпочтительнее – хранение готового массива или решение уравнения, которое его порождает?
Хранение подразумевает выделенное место на носителе, а вычисление подразумевает вычислительные способности процессора.
Таким образом, определяются естественные чаши весов: в первой — скорость доступа к элементам готового, записанного куда-нибудь массива не требующей больших вычислительных способностей для считывания значений; в другой — практически отсутствие занимаемого пространства у уравнения и требуемая большая вычислительная способность для порождения информации.
Но в массив, или матрицу можно записать любые значения, в т.ч. и данные мультимедийного контента, например, песни, фото или видео (бинарный файл с нулями и единицами).
Таким образом, для анализа у нас имеется бинарная последовательность определенного размера, состоящая из нулей и единиц.
Это означает, что если мы найдем функцию (формулу, уравнение) которая породит эту последовательность нулей и единиц в нужном порядке, то вместо музыкального файла, который занимает определенное место, мы можем решить его уравнение с определенными начальными условиями, которое занимает пару байт и получить ту же композицию, видеоряд или документ просто «нагрузив» процессор.
Это кажется безумной идеей, ведь найти уравнение, которое может выдать несколько миллиардеров нулей и единиц в той же последовательности что и в оригинале мысленно наталкивает нас на уравнение невообразимых размеров, а то и их систему. Возможно, если воспользоваться, например, полиномиальным регрессивным анализом N-ой степени так и будет, но что если ответ кроется в простом уравнении с несколькими переменными?
К примеру синусоиду можно описать регрессивным полиномом определенного порядка, а можно просто написать sin(x). То есть мы имеем 2 подхода которые ведут к идентичному результату. Только один требует значительных вычислительных способностей, а второй всего нескольких тактов кристалла (для вычисления единичного значения).
Как известно, в бинарном виде информационный файл (со смысловым нагружением) для стороннего наблюдателя является шумом. Ну, или если по-научному — шумовым сигналом. А если совсем по-научному — псевдошумовым сигналом или последовательностью если рассматриваем цифровой файл (ввиду ограниченной разрядности машины). И только имея нужный алгоритм декодирования можно прочитать из этого файла информацию.
Разве не было бы революцией в мире цифровой информации, нахождение порождающих ее функций? Представьте, что облачным хранилищам больше не нужны тысячи физических накопителей информации в стойках. Чтобы посмотреть фильм Вам больше не нужно скачивать файл, а лишь информацию о нем. Насколько тогда разгрузятся линии связи? «Гонка» пропускной способности надолго остановится. И начнется новый этап гонки вычислительных способностей, от чего общество будет только в выигрыше. Это прогрессивный путь развития ИТ технологий.
Меня зовут Siegurd, и я докажу Вам что это возможно!
До скорых встреч!
Комментарии (46)
michael_vostrikov
09.06.2016 22:29+6и я докажу Вам что это возможно
Вы бы сначала матчасть изучили, факты какие-нибудь поискали. Ну или хотя бы просто логически подумали над тем, что возможно не вы один до этого додумались, и значит есть какие-то причины, почему это не используется везде где только можно)
Чтобы задать уравнение, в точности повторяющее произвольную последовательность чисел, надо задать примерно столько же коэффициентов, сколько чисел в этой последовательности. В некоторых случаях можно задать меньше, если в последовательности есть повторяющиеся или похожие участки. Ваш пример с синусом — это ярко выраженный случай, значения повторяются в точности каждый период.
Кстати, можно задавать приближение не полиномами, а разложением в ряд синусов, это удобнее именно из-за их периодической природы. А еще можно приближать не точно, а примерно, выбрасывая малозначащие коэффициенты. И если применить это к изображениям, видео или музыке, то получаем JPEG / MPEG / MP3.
Siegurd
10.06.2016 00:25Это не используется везде где только можно по той причине, что core2duo будет вам считать киношку размером в 30 гиг — очень и очень долго. Но когда наступит эра квантовых компов — минуты, если не секунды.
dkukushkin
09.06.2016 23:36К тому же я поспорил с коллегами на пиво, что смогу превратить видеофайл в небольшое уравнение.
Собственно, для этого вам нужно понять как работает человеческий мозг, сделать вывод о всех возможных способах восприятия того или иного видео. Потом изобрести самый короткий язык. После чего совсем просто — пересказываете на самом коротком языке смысл видео со всеми его аспектами, которые может воспринять человеческий мозг. Вот и все.
Для декодирования вам нужно создать кластер из искусственных мозгов чтобы они по заданному сценарию воссоздали нужное видео, т.е. как бы отсняли фильм заново.
Вот и все. Ведь важно не само видео — важно то что мы ощущаем, когда его смотрим. Повторите ощущения, саму суть — и не имеет значения насколько точно вы передали мелочи.
Грубо говоря задача сводится к качественному конвертору файлов mp4->txt->mp4
zoonman
10.06.2016 01:14Если руководствоваться принципом ощущений, то нужно выяснить, каким образом они создаются в мозгу. Пока науке известно, что это очень сложно.
Но главное, ведь не ощущения, а то, как мы себя чувствуем после них, то есть пережитое. И человеку важно это самое «послевкусие». Ведь думая о простмотренном фильме мы в первую очередь вспоминаем, понравился он нам или нет и лишь затем концентрируемся на особенностях и деталях сюжета, актерах и игре.dkukushkin
10.06.2016 02:33Пока науке известно, что это очень сложно.
Ну дык… Человек же просит амбициозных задач. Вот и пусть займется.
Но главное, ведь не ощущения, а то, как мы себя чувствуем после них, то есть пережитое.
А как сформировать пережитое без ощущений?
Foolleren
10.06.2016 00:20+1Не отрицаю что это возможно для сжатия с потерями, но боюсь даже представить сколько времени уйдёт на подбор соответствующей формулы, даже не шибко то сильно и сжимающий 265 кодек работающий с вейвлетами работает ну очень долго.
DrZlodberg
10.06.2016 09:08Тут была где-то статья, в которой генетикой пытались подобрать формулу. Интересно, если тот подход несколько (изрядно) развить и оптимизировать…
Время поиска будет огромным, но ведь теоретически может и найти.
Temmokan
10.06.2016 07:16Что-то припомнилась Sloot Decoding System.
По описанию подхода чем-то похоже. Интересно будет посмотреть, когда и если будет что-нибудь действующее (и не мистификация).
keydon2
10.06.2016 14:12Но ведь при синусоиде все равно передаешь информацию. Пускай не в файле, а сообщая как читать sin x, как понимать график синусоиды.
Не отрицаю, передавая такие данные как часто встречаемые последовательности и функции и реализуя их в аппаратуре и библиотеке можно снизить размер передаваемого от сервера к клиенту информации. Но это же давно известно… Пример — тот же e-tag в http. Зная как сравнивать e-tag можно сэкономить передачу закэшированного объекта, передавая только заголовки(которые меньше по размеру).
smallplushbear
10.06.2016 14:12То что вы предлагате, вполне осуществимо. Но вам не зря толсто намекают на Шеннона. Берете «набор данных» и преобразуете в «формулу» для вычисления. Минимальная длина записи «формулы» будет не такая уж и маленькая, как вам кажется. Считайте за «формулу» весь объем информации нужной для восстановления исходного набора (софт+таблицы+«формула»). Нынешние архивы как с «потерей качества» так и без содержат внутри себя «формулу» и вспомогательные таблицы. Софт — архиватор или плеер — отдельно.
З.Ы. И да, архиваторы с внешними универсальными таблицами вполне себе вымерли как класс.
Ramdeif
10.06.2016 15:16Очень интересно будет все же увидеть формулу для видео. Вот только какими методами вы собираетесь ее получить?
Gryphon88
10.06.2016 16:35Мне тоже интересно было бы посмотреть демонстрацию. Похоже, Вы предлагаете обратимый хэш
centur
14.06.2016 03:38Забавно, что никто не учитывает объем который займет такая формула. А он может быть куда больше чем сама закодированная информация. А еще такая формула будет уникальна для каждого произведения...
Ну давайте попробуем рассмотреть некий очень частный вырожденный случай…
Итак, закодируем фразу "Мама мыла раму" в виде последовательности функций которые из пустой строки "" сделают нам эту фразу:
"".Append("Мама") .Append(env.Whitespace) .Append("мыла") .Append(env.Whitespace) .Append("раму")
В принципе если рассуждать в терминах выполнимости — да, это выполнимо, до какой-то степени. В терминах эффективности — не эффективно.
С переходом от примитивных к более сложным функциям — объем кода уменьшится, вычислительная сложность увеличится.
В какой-то момент вы достигнете некоего предела сложности и у вас получится вариация свертки — алгоритм компрессии. Потом вы обнаружите что разные алгоритмы дают разные результаты на разных наборах данных, начнете использовать их комбинации и придумаете какой-нибудь кодек для определенного типа данных.
Поздравляю, вы выиграли пиво.
lair
Вы серьезно думаете, что музыкальный файл можно описать (чем угодно), записывающимся в пару байт? Я вас расстрою, но таким образом принципиально нельзя описать более 65536 файлов.
Siegurd
Вы меня нисколько не расстроили, ведь я уверен в том, что это реально и цифра в 65536 файлов ничего не значит для метода который я разрабатываю. Конечно будет не пару байт но и, скорее всего не 30 мегабайт.
lair
Вам слова "теорема Шеннона" о чем-нибудь говорят?
Siegurd
Естественно. И я прекрасно понимаю о чем Вы. Но, я оптимистично настроен) Конечно выше головы не прыгнешь, но залезть можно)
lair
Я правильно понимаю, что вы "оптимистично настроены" опровергнуть теорему Шеннона?
Siegurd
Отнюдь, я не собираюсь ничего опровергать или хлопать по плечу классиков. У меня свой подход. Без нарушения причинно-следственных связей, законов и разрыва континуума.
lair
Но подождите, теорема Шеннона (та, которая об источнике шифрования) говорит нам, что у каждых данных есть нижний порог сжатия, и он вычислим. Ваш подход предлагает сжатие сильнее, чем допустимое этим порогом, или нет?
Siegurd
а кто Вам сказал, что я собираюсь сжимать данные? Конечно, если их сжимать по самому хитрому алгоритму то его эффективность будет экспоненциально падать с уменьшением размера файла. Но об этом и речи не идет.
lair
Вы. Вы сказали, что собираетесь представлять данные с помощью других данных, меньшего размера. Я неправильно вас понял?
Siegurd
Мой метод не подразумевает процесса сжатия как такового. Скорее больше похоже на адресацию. Вы же не называете процессом сжатия кривой которую Вы описали с помощью регрессивного полиномиального анализа? Вы представили линию или точки как формулу. Я полагаю, что это находится в разных плоскостях с понятием сжатия. Это скорее трансформация. Прочем утверждать ничего не буду.
lair
Чтобы работала адресация, необходимо адресуемое пространство. Когда вы вместо файла передаете информацию о нем, нужно, чтобы получатель мог эту информацию проинтерпретировать. С точки зрения теоремы Шеннона, интерпретатор+переданная вами информация — это и есть сжатая информация.
Представление последовательности из 256 нулей последовательностью "256 0", где первый символ — число повторов второго — это и есть сжатие, к которому прилагается деархиватор, умеющий такие последовательности интерпретировать. С точки зрения алгоритма это ничем не отличается от вашей кривой.
Siegurd
Ок. Я понял. Объясню так. Вы мне рассказали стих. Длинный такой. Если его записать в текстовый файл то он займет терабайт. Но я не хочу хранить у себя этот терабайт. Я попрошу Вас рассказать мне его снова. И получу ту же информацию из источника. Я не уверен что это можно отнести к сжатию информации.
На счет «последовательности из 256 нулей последовательностью „256 0“ я с Вами абсолютно согласен это процесс сжатия.
lair
Для этого вам нужен я. Я — это больше терабайта, поэтому вы ничего не выиграли (а только потеряли).
Siegurd
а это уж как посмотреть :)
lair
А как ни смотрите. Когда я рассказываю вам стих, я беру из хранилища, это хранилище не может быть меньше терабайта. Значит, я никак не меньше терабайта.
Siegurd
но, не на моем винте) Источник информации должен быть источником информации. Генератор шума будет генерировать шум вопрос только в том, есть ли у Вас такой же генератор шума.
lair
Тогда ваш метод сводится к "давайте вместо файлов передавать их адреса в интернете". Круто, но упирается в пропускную способность между вами и источником информации (а это прямо противоречит вашему тексту).
Siegurd
На счет винта это была шутка юмора) Уважаемый, Вы когда нибудь пользовались функцией синуса? Сколько раз Вы подумали, что сжали информацию о синусоиде? На промежутке от 0 до pi на бесконечность мы можем получить таки длинный сигнал. Допустим тот же терабайт синусоиды. Но когда Вам нужно сгенерировать синусоиду той же длины Вы не скачиваете мой файл размером в терабайт. Вы просто задаете функции синус(х) вектор х. Я могу ошибаться, но процессом сжатия в таком случае было бы сжатие терабайтного файла до какого-то размера. Например, нашли бы один период синусоиды, а за ним написали бы число повторений.
lair
… и теперь мне нужно что-то, что умеет генерить синусоиду.
Вы ошибаетесь. Нет никакой разницы — взять фрагмент и сказать "повторите фрагмент k раз", или взять генератор и сказать "дайте генератору вход k". Более того, первое сводимо ко второму.
Siegurd
На том и остановимся. Извините, но мне нужно заниматься исследованиями, даже несмотря на то, что на Ваш взгляд они бессмысленны.
… но, шмель об этом не знает и продолжает летать.
lair
Я не говорю (пока), что они бессмысленны, я спрашиваю, как конкретно они соотносятся с теоремой Шеннона.
NeonMercury
UPD: Ниже уже написали про это.
Тогда я предлагаю просто запустить вычисление числа ? с точностью, стремящейся к бесконечности. И на каждом новом вычисленном промежутке искать последовательность байтов вашего файла. Как только вы её найдёте, вы сможете закодировать файл просто одним числом — смещением в ?. (Кстати, есть файловая система с похожим принципом: https://github.com/philipl/pifs)
lair
Ага, а длина этого "просто одного числа" какая будет?
koldyr
Для почти всех последовательностей длина эта будет сравнима с длиной последовательности.
NeonMercury
Это была шутка. Я понимаю, что очень вероятно, что количество разрядов числа будет настолько велико, что будет «весить» даже больше самого исходного файла.
EndUser
Вообще-то шмель — это вертолёт, а не самолёт, поэтому аэродинамика самолёта к нему не применима.
Если вы этого не знали, то это проблемы ваши, а не шмеля — это совершенно точно.
Если вы пытаетесь обойти теорему Шеннона, то это проблемы ваши, а не Шеннона.