Вторые сутки депривации сна. не делайте так никогда.
На большее я не способен, но этого обычно достаточно. По какой причине я пишу это? Передо мной стоит проблема, которую я не в силах решить, у меня нет достаточного опыта и времени на его получение, я надеюсь, что тут, на моём родном форуме, найдутся достаточно специализированные технари, способные реализовать принципиально новый алгоритм сжатия данных, который, возможно, приоткроет нам завесу тайны мироздания, а возможно и нет. Суть алгоритма в использовании числа пи, как основного шифрового ключа. Я уже давно над этим думаю (но имею возможность только сформулировать вопрос) и вот какую информацию я хочу предоставить, надеюсь, она будет исчерпывающей, но многие знают это и так, ещё со школьного курса и курса теории вероятности.
«π — иррациональное число, то есть его значение не может быть точно выражено в виде дроби m/n, где m и n — целые числа. Следовательно, его десятичное представление никогда не заканчивается и не является периодическим. Иррациональность числа π была впервые доказана Иоганном Ламбертом в 1767 году путём разложения числа в непрерывную дробь. В 1794 году Лежандр привёл более строгое доказательство иррациональности чисел π и π2.»
Это паста из вики, многие с ней знакомы. Что это означает? А это означает, что пи в виде десятичной дроби (интереснее в этом плане выглядит двоичная система, но это на взгляд технаря будет виднее) бесконечно длинное число с бесконечным сочетанием цифр после запятой. Это даёт следующие преимущества – минимальный размер изначальной базы данных, шаблона по которому будет идти шифрование(ниже будет про это) и сжатие, фактически это около 100-150 строк кода, и переменная, пи, до заданного количества знаков после запятой.
Теперь самое интересное – набросок алгоритма, он совсем сырой, не ругайте, не програмлю уже 8 лет:
1.Высчитывается число пи, скажем до десятимиллионного знака после запятой по любой из доступных формул, например, по формуле Гаусса/Пауссона или Беллара. Теперь у нас есть массив данных, огромный массив данных, который при необходимости можно увеличить, конечно лучше, что бы количество знаков после запятой определял алгоритм, подбирал сам, или что бы количество заданных знаков после запятой определяло степень сжатия, выбиралось пользователем.
2. число пи разбивается на переменные (которые константы, конечно же), отдельные кусочки числа пи, каждый из которых имеет свой порядковый номер, в двоичном виде и представляет из себя набор символов длинной от n до x, а ещё от x до n, т.е. в обратном порядке, это будет число XXX(будет пока так), прочитанное алгоритмом справа на лево, и от 1n до 1x, это тоже самое что и XXX, но цифры взяты через одну, аналогично с-1n и-1x, длинна числа XXX динамична, ещё куча вариаций на эту тему (на самом деле тут есть загвоздочка, нужно что бы из числа пи вытаскивались динамичные числа, т.е. возможно, что лучше не разбивать ничего на переменные, использовать его как есть, указывая ниже только начало, порядковый номер знака с которого начинаются данные и порядковый номер знака на котором заканчиваются, ну можно ещё направление, справа на лево, или слева на право, через одно брать, примерно как выше было описано, а степень сжатия регулировать максимальной/минимальной длинной сегмента и количеством знаков после запятой, дальше становится очевидным, что при высчитывании числа пи практически до бесконечности можно всунуть в него ЛЮБОЙ массив информации, он может находиться там в неизменном виде, он точно там находится в неизменном виде, просто очень, очень долго такой анализ современные ПК будут делать, по этой причине лучше использовать сегменты регулируемой длинны, кстати, за счёт сегментации и кол-ва знаков после запятой и идёт шифрование, т.к. это переменные, которые известны только тому, кто их будет задавать)
3. исходные данные пакуются по любому простому алгоритму в полностью числовые, каждому используемому знаку в машинном коде (и набору знаков, т.к. иначе это будет не сжатие а лютый п*****) присваивается порядковый номер, между ними используются разделители, места нахождения этих разделителей потом просто указываются в конце файла, как «порядковые» координаты, реализовать этот момент по моему мнению для програмёра вопрос одной бессонной ночи.
4. алгоритм сводит 2 полученных массива информации и ищет совпадения, максимально длинное число из запакованного (уже) массива информации с максимально длинным сегментом в числе пи, задаёт начало в числе пи и конец плюс разделители между всеми этими циферками, так кусочек за кусочком получается новый набор чисел, он будет тем меньше(по размеру) изначального, на сколько более сложный алгоритм будет использоваться, на сколько «большим» числом пи будут пользоваться и на сколько длинные будут использовать сегменты.
5. Если вы думаете, что это конец, то вы ошибаетесь, полученные данные в которых уже спрятан старый разделитель, можно паковать ещё раз, по п.4 (этот пункт можно ещё повторять, как мне кажется, только не очень рационально), только на этот раз, нужно что бы старый разделитель полностью игнорировался, удалялся, а места его «нахождения» зашифровывались опять же в цифровой формат и через определённый разделитель прятались в конец файла, т.е. при обратной распаковке сначала полностью распаковывается первая часть, а потом уже расставляются новые разделители в файл и опять распаковывается, с расстановкой разделителей, далее по пунктам назад, до исходного файла. Ещё это можно, для чёткости, упаковать винраром.
Конечно алгоритм алгоритмом-то назвать сложно, но идею я попытался передать, это главное, надеюсь многие увидят рациональное зерно во всём этом бреде.
По какой причине я запостил это сюда(и запощу наверное много куда)? Я сам этого делать не буду. Но есть мнение, что в иррациональных числах спрятано очень много информации о вселенной (с учётом того, что число пи не имеет логического окончания и является иррациональным, вся информация), информации к которой мы сможем получить доступ, тут в любом случае нужен «разум улья» нужны сотни различных алгоритмов решения задачи сжатия данных с помощью числа пи, миллионы людей и ПК для расшифровки всего, что скрывает в себе это интересное явление.
Предлагаю обсудить саму тему и её реализацию, для начала, тут.
С уважением -=DiMMaSS=-.

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

И в пункте 2 ошибка. (ничего так и не понял в алгоритме, но только неточность маленькая)

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

с этим полностью согласен, однако это крайне маловероятно, при использовании сложного алгоритма, а не только перебора чисел по порядку справа на лево.
Рисовальщик из меня никакой, я попробую с кусочком файла и комментариями.
Только сколько это займёт времени.

Наоборот, попробуйте прикинуть и поймёте что это не только не "маловероятно" но и скорее всего является первопричиной почему до сих пор никто не сделал ничего подобного...

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

Попробую упростить, даже не упростить, так логичнее выходит, взгляните на число пи в бинарном коде это нолики и единички в совершенно рандомно раскиданном порядке "11,00100100001111110110…" т.е. просто число пи высчитывается в двоичном коде, или 16ти и переводится в двоичную систему, как быстрее выйдет. Исходный файл так же переводится в двоичную систему счисления, ищутся совпадения, получается, что допустим две единички пара нолей и единичка это 1-4 и разделитель, а 11100101001001001001 это допустим 104-122 и разделитель. потом такую информацию очень легко пережать одни циферки получатся. Нужно,что бы алгоритм учитывал когда разумно будет перейти к более маленьким кусочкам, с более крупного, дело в том, что можно зашифровать даже 1 бит, потратив 4(или больше), но будет много длинных кусочков, которые должны компенсировать такие издержки, я считаю.

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

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

Вот это и зря, чаще всего практика объяснит всё тоже самое что прол1 только намного лучше чем он это сделал (понятнее и не так обидно)

Провёл ликбез.
Значит минимальный объём информации с которым можно работать это байт, который принимает одно из 256 (2 ^ 8) различных значений. Не так много в контексте "бесконечности" числа пи. Физический один байт, на машинном уровне, состоит из информационных битов и служебного бита. При последовательной передаче данных, служебный бит используется для разделения информационных байтов. с помощью 2х киррилирующих друг с другом байтов(на пальцах - строка/столбец) можно задать адрес вплоть до 256^2, 4 байта будут указывать на начало и конец необходимой строки, переводить не нужно из одной системы счисления в другую. 65000 знаков очень мало, значит нужно использовать более сложную адресацию, когда это необходимо(8-16-32-64 байта). В голове нарисовал матрицу, строка/столбец с числом пи до произвольного знака после запятой, я уверен, что можно разработать рабочий алгоритм сжатия, просто если становится "нерентабельно" использовать бОльшее количество байтов для записи местоположения "старта" и "финиша" клочка информации в матрице, то этот клочёк можно поделить на части и найти места где это будет или рентабельно или, по крайней мере, сведёт к минимуму потери с таких неудачных мест.
прол1

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

Не баян.

-=dimmass=- то что появляются идеи это хорошо, не слушай никого, развивай фантазию (может что хорошего и придумаешь) но только больше пробуй сам, не надейся на то что другие за тебя всё продумают и опробуют.

Что такое галаперидол не знаю, но (-=dimmass=-) - возможно - это и есть средство для решения ваших проблем. (То, что вы пишите - совершенно нечитабельно и похоже на бред.)

Реально вообще простым преобразованием hex->dex превратить любой файл в dex состоящий полностью из десятичных чисел, без мусора, одни цифры?
Гугл не помог, выдаёт преобразование чисел, подходит?

-=dimmass=-, вы явно неадекватно воспринимаете окружающий мир. (Возможно, вы просто переутомились.)
Судите сами:
1. Вы ставите знак равенства между сжатием данных и шифрованием, но: это далеко не одно и тоже.
2. Тема, что вы инициировали ("Число пи - универсальный ключик к любым данным?") предполагает, что ко всем данным нужен ключ, в то время, как ключ необходим только для расшифровки зашифрованных данных. (Ну и чтоб зашифровать ключ нужен так же.) Чтоб распаковать запакованные данные - ключь не нужен. А если данные даже не запакованы?... Им ключ зачем?

Вчера я действительно утомился. В общем весь день убил на то, что бы ручками переводить кусочек жипега из hex в dex (вроде не маразм) а потом ручками линейным поиском в выборке из 100000 знаков... Суть проблемы в том, что при переводе из хекса в декс теряется кодировка, асци и т.д, в 1,5 раза увеличивается исходный размер(вроде так примерно) но это ерунда, наверное можно реализовать програмно, основная трабла в том, что при использовании линейного последовательного поиска каким бы способом записи я не пользовался, положением в матрице по аналогии с системой координат, или линейной последовательностью, т.е. просто место начала элемента(кусочка данных вида 255 1 0 240, например) и его длинна, на запись уходит банально больше символов чем в итоге за ними прячется, но я надеюсь, что сложные алгоритмы поиска помогут и... Сейчас смотрю в сторону алгоритмов на подобии BWT для поиска закономерностей, обидно, что при использовании такого рода алгоритмов теряется вся суть задумки.
Masterov Так уж получилось, что при "сжатии" данных моим способом, для их последующей распаковки требуется обязательно занть: кол-во символов после запятой в числе пи это 6-7 значный код должен выйти, размер минимального и максимального элементов, ещё один 2-3х значный код и иметь второй файлик, файлик карту архива, не знаю как это ещё назвать использую просто отдельную запись для разделения десятичных чисел, иначе получается каша из цифр.
PS Выборку использовал маленькую, естественно, а ушло больше 10 часов на всё про всё.

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

Может не надо "принудительно"? Мы ведь сейчас не при совке живём, но чуствуется что-то нездоровое в этих постах -=dimmass=-.
-=dimmass=-, ничего личного, но страшно читать посты подобные этому:Может стоит отойти от компа и расслабиться? Лично я сейчас так и сделаю. Всего хорошего.

Хороший совет. (Правильный.)

Лично я предлагаю посмотреть фильм Pi Даррена Аронофски. Суть фильма и мысли автора темы - родственные, так сказать, материи.

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

+1. На самом деле любую информацию можно "пожать" в несколько байтов. Взять те же хэш-функции (CRC, MD5 и пр.). Их используют, например, для подсчета контрольных сумм информации (проверка целостности) или идентификации уникальных объектов (UUID и GUUID). Проблема заключается в том, что описанное преобразование одностороннее и необратимое. Действительно, если подумать, то получается, что множество данных соответствующих одному и тому же значению hash-ф-ции бесконечно, а значение одно!!! С числом Пи аналогично. Действительно, получается, что в числе Пи может быть закодировано что угодно (никто заранее этого не знает). Но все равно нужно где-то хранить адрес последовательности внутри представления числа Пи.
Так же напомню, что в некоторых случаях сжатые данные занимают больше места, чем несжатые. Дело в том, что каждый алгоритм заточен под определенные применения.
На самом деле более интересно почитать про свежую и перспективную методологию фрактального сжатия.