πfs is a revolutionary new file system that, instead of wasting space storing your data on your hard drive, stores your data in π! You'll never run out of space again - π holds every file that could possibly exist! They said 100% compression was impossible? You're looking at it!
Прочитал описание по ссылке. Баланс между толстотой и тонкотой выбран достаточно удачно для того, чтобы пощекотать чувство юмора. То есть это проект-шутка.
Для Ъ: предложен очередной механизм архиватора, способного сжать любые данные. Проекты вечных двигателей никогда не иссякнут :)
That's right! Every file you've ever created, or anyone else has created or will create! Copyright infringement? It's just a few digits of π! They were always there!
Появилось желание ради спортивного интереса найти всевозможные однобайтовые смещения в Пи и посчитать средний коэффициент сжатия для такого алгоритма. :) Где бы выкачать большой двоичный блоб Пи?
В принципе у этой штуки может быть даже практическое применение в будущем. Допустим я нахожусь на Плутоне, а мой друг в это время где-то на Земле. Скорость связи между нами в лучшем случае будет пару kbps, не говоря уже о огромных пингах и т.д. Переслать достаточно увесистый файл будет очень дорого и очень долго, если вообще возможно.
А вот в этом случае он высылает мне смещение, и я уже нахожу файл сам. Времени и вычислительных ресурсов это тоже сожрет будь здоров, но конкретно при такой ситуации подобный подход может быть предпочтительнее традиционного.
Ну, для некоторых данных смещение определенно будет весить больше самого файла, это да. Но мужик ведь сам предлагал сначала файл разбить на более мелкие куски, которые будет проще найти. В общем, если довести до ума, то думаю что можно будет добиться и чего-то хорошего. Хотя понятно что сама идея просто шутка, а я просто решил пофантазировать в порядке бреда :-)
кстати, а если ограничить вычисление пи до какого-нибудь знака и использовать его, как огромный словарь, который не нужно прикладывать к файлу? То есть, вначале архива пишем, например, 10^5, размер блока, и начинаем собирать. Если варианта блока не окажется в словаре, указываем меньший объём для конкретного блока, дописывая к нему оверхедную информацию.
Но это так, веселуха больше, так же ж нужно придумать сокращения для длинных адресов.
Посчитал, правда, не с Пи, а с обыкновенным рандомом. Если брать блоки по 16 бит, то максимальная длина индекса при хорошем сиде будет 20 бит. Средняя длина индекса будет 16 бит.
Тогда можно сделать наоборот, считать данными не фрагмент пи, а его смещение, а хранить сам фрагмент пи :)
Если длина фрагмента будет меньше длины смещения, будут возникать коллизии (в смысле, повторения фрагментов при разных индексах). Чем меньше блок, тем больше число возможных сочетаний коллизий. Я даже попробовал сейчас реализовать такой подход. Но даже на коротеньком сообщении из 12 байт я ни разу не получил полностью корректное исходное сообщение при сжатии 3 байта -> 2 байта.
Если сделают аппаратную вычислялку пи, которая будет считать число в кратчайший срок, то всё будет отлично.
Не будет, в том и дело. Даже простое моделирование на небольших блоках показывает, что число байт остаётся в среднем неизменным. То есть, чтобы это работало, надо иметь возможность менять входной поток данных, пока не найдём оптимальный вариант. Ресурсов надо очень много, а гарантий эффективного сжатия мы при этом не имеем никаких. Возможно, будут отдельные наборы данных, которые «сожмутся» очень хорошо, но это будет скорее исключением из правил.
Нужно пытаться подобрать такие куски, чтобы этого не было
Пока у него куски, для простоты, по одному байту. :)
В случае передачи данных на Марс, думаю, проще будет сначала скачать 100500 файлов самых разных форматов, найти повторяющиеся последовательности, послать список этих последовательностей на Марс на носителе, а потом уже из него посылать смещения.
Или послать весь этот корпус из 100500 файлов целиком и посылать затем информацию, какие куски выбрать.