>>03641
Ебать ты Катющик от мира информатики, смотри к чему сводится твое "открытие":
1. Любое кроме нуля число можно записать непустым и без нулей в начале, т. е. 0001 = 1, 0010 = 10, 0011 = 11, 0100 = 100 и так далее
2. Так как первая цифра после этого не ноль, то это единица и зная это можно ее отбросить, получится 0001 › {пустота}, 0010 › 0, 0011 › 1, 0100 › 00 и т. п.
Действительно, таким образом все кроме одной последовательности фиксированной длины n можно отобразить на последовательности длин меньших n, вот только исходная длина в результате нигде не фиксируется, следовательно то же 00 может быть произведено от 100, 0100, 00100, 00000100 и еще до бесконечности аналогичных строк {n нулей}100. При этом 50% возможных входных строк (начинающиеся с 1) сократятся на 1 бит, 25% (начинающиеся на 01) — на 2 бита, 12.5% (на 001) — на 3, и лишь 0.39% получится сократить хотя бы на байт (00000001) и всё это НЕ учитывая запись информации об исходной длине, а длину или количество убранных нулей тоже надо где-то сохранять и притом отдельно от "сжатых" данных, что также несет дополнительную информацию. Возьмем некоторый реальный файл, скажем текст "Я шиз" в стандартной кодировке Windows-1251, в битах это 1101111100100000111110001110100011100111, сжатие Zogoschiz Digital Coding System отбросит первый бит, то есть останется 1011... и т. д., как длину сокращения записываем ноль, так как было убрано ноль нулей, допустим мы не зогошизы и нахуй нам не нужон аж целый 1 бит (тем более испокон веков минимальная практическая единица — это 8 бит ака байт), хотим и дальше сжимать чудо-способом, следующая попытка отбросит еще одну единичку и также запишет длину 0, дальше выходит 1, 0, 0, 0, 0, 2, 5 (ого!), 0, 0, 0, 0, 3, 0, 0, 1, 3, 0, 0, 2, 0, 0 (здесь "сжатый" великим алгоритмом файл уже пуст). Вместо 40 бит получили набор из 23 чисел (и добавим еще 0 как длину итоговой строки без единиц, ведь те уже не "сжимаются"), которые еще вопрос как упаковать и удастся ли это меньше чем в те же 40 бит, фактически это просто количества нулей на участках, разделенных по единицам. В общем, выходит полное фуфло, который было бы сколь-либо практично лишь если бы объем входного файла был сплошняком забит ненужными нулевыми байтами, ну так при эмуляции различных архаичных систем тоже не ты придумал хранить в дампе не всю память от 0000 до FFFF, а только значимую часть, и в целом этот примитив максимально далек от даже самых основ теории сжатия данных. У тебя фундаментальная ошибка в том, что ты противопоставляешь "исходные" 2^n файлов "сжатым" 2^(n-m) файлам, тогда как реальные "исходные" файлы куда чаще имеют размеры из этих 2^(n-m) (было бы странно, если бы верхнюю границу алгоритма выделенную скажем для фильма занимала бы и картинка и текст) и подгонять их всех под верхнюю границу можно разве что мусорными данными, которые потом сей "алгоритм сжатия" обратно же и откатит, принцип кота Матроскина — чтобы продать что-то ненужное, надо перед этим купить что-то ненужное (где в качестве валюты выступает память компьютера). С последующих ссылок тоже порофлил, скрин бессмысленного говнокода с генерацией случайных чисел и неприкрыто шуточный проект про волшебное число пи, где есть все последовательности цифр (внезапно все они же есть в натуральном ряду чисел, но если его общая структура известна заранее, то вычисление очередных цифр пи — задача, которая выполняется нихуевыми мощностями и где ставятся рекорды, мотивированные явно не игрушкой в "спрятать в пи словарь русского мата" (не говоря о том что уже "Я шиз" едва ли удастся спрятать, к примеру, цифры 0123456789 встречаются впервые лишь в 18-ом триллиарде знаков, а всего вычислено 100 триллионов)