• Добро пожаловать на компьютерный форум Tehnari.ru. Здесь разбираемся с проблемами ПК и ноутбуков: Windows, драйверы, «железо», сборка и апгрейд, софт и безопасность. Форум работает много лет, сейчас он переехал на новый движок, но старые темы и аккаунты мы постарались сохранить максимально аккуратно.

    Форум не связан с магазинами и сервисами – мы ничего не продаём и не даём «рекламу под видом совета». Отвечают обычные участники и модераторы, которые следят за порядком и качеством подсказок.

    Если вы у нас впервые, загляните на страницу о форуме и правила – там коротко описано, как задать вопрос так, чтобы быстро получить ответ. Чтобы создавать темы и писать сообщения, сначала зарегистрируйтесь, а затем войдите под своим логином.

    Не знаете, с чего начать? Создайте тему с описанием проблемы – подскажем и при необходимости перенесём её в подходящий раздел.
    Задать вопрос Новые сообщения Как правильно спросить
    Если пришли по старой ссылке со старого Tehnari.ru – вы на нужном месте, просто продолжайте обсуждение.

Компрессия данных любого размера до бесконечности с помощью числа "Пи"

Great Future

Ученик
Регистрация
27 Янв 2019
Сообщения
2
Реакции
0
Баллы
0
Компрессия данных любого размера до бесконечности с помощью числа "Пи"

Доброго времени суток. У меня вопрос к программистам по поводу реальности метода сжатия данных, который
мне пришел в голову. Так как я сам не программист и не математик ), проверить работоспособность схемы не
представляется для меня возможным. В кратце суть схемы на пальцах. С одной стороны есть бесконечное число десятичных знаков числа "Пи",
с другой данные (любой файл) которые легко могут быть конвертированы в такую же десятичную систему. Если взять к примеру объем числа "Пи" весом в 1гб из
расчета 1 знак = 1 байт(здесь могу ошибаться), то получается один миллиард знаков . Вполне естественно предположить что части файла переведенного в десятичную форму
будут в каких то местах полностью совпадать с последовательностью знаков из числа "Пи". Таким образом мы можем собрать любой файл. Дело будет
лишь в количестве этих частей. 1, 10, 100 000 или более. Но при любом раскладе получается что сам код такой сборки будет ничтожно мал по сравнению
с первоначальным объемом самого файла. Представить такой код можно так же в десятичной форме. Например. Точка захода в число "Пи", то есть
количество знаков от его начала и само количество знаков в этой части. Так же можно добавить перед этими двумя числами по одному знаку который будет
обозначать количество знаков в этих двух числах для того что бы отделить одну часть от другой в непрерывном коде из знаков. Так как общее количество
знаков в числе "Пи" не будет превышать одного миллиарда то и эти два добавочных числа не могут быть двузначными. (Например есть совпадающая
последовательность с 765789 от начала числа "Пи" до 1202345. В этом случае код будет выглядеть как 676578971202345) В итоге мы имеем такую же
последовательность десятичных чисел, которую в свою очередь мы сжимаем таким же способом шагом номер два. В конечном счете после
нескольких таких шагов мы имеем последовательность которая со стопроцентной гарантией попадет в число "Пи" одной частью. И код этой части будет иметь
от четырех до шестнадцати знаков. То есть по сути вообще ничто. Зная число шагов и делая обратную операцию мы получаем наш исходный файл. Получается
что мы имеем возможность сжимать любой объем данных будь то гигабайты или терабайты до этого ничтожного размера. Но и это еще не все. Собрав громадный
архив из этих микроскопических файлов мы так же можем их сжимать до бесконечности используя тот же метод. Если это работает, то мы закрываем тему объема
как такового вообще пробив боковую дверь в законе Мура, оставляя лишь одно число "Пи". Было бы здорово передавать бесценные научные данные терабайтных
размеров скажем откуда нибудь с Марса сжав все в несколько байт...Но вполне может быть что я ошибаюсь. Проверить бы все это.
 
Хранение числа "пи" с требуемой точностью занимает ресурсы памяти, вычисление его с той же точностью занимает вычислительные мощности, точное указание нужного участка для нужного участка кода файла тоже имеет размер, вычислительные мощности требуются для обработки всех этих операций. В итоге выигрыша не будет.
 
Хранение числа "пи" с требуемой точностью занимает ресурсы памяти, вычисление его с той же точностью занимает вычислительные мощности, точное указание нужного участка для нужного участка кода файла тоже имеет размер, вычислительные мощности требуются для обработки всех этих операций. В итоге выигрыша не будет.
Дело не ресурсах памяти или вычислительных мощностях. Если бы дело было только в них, то задача решилась бы простым увеличением ресурсов памяти и вычислительных мощностей, благо они постоянно растут, благодаря развитию технологий. Задача предложенного метода состоит в том, чтобы сжать объём передаваемых данных. Но, если нам не нужно будет передавать всю последовательность, а передавать только координаты местоположения совпадающих участков кода, то каком сжатии может идти речь, если информация о координатах местоположения, совпадающих участков кода, будет огромный объём. Представьте, на каком-то участке у нас будет совпадение 2 знаков, а этот участок будет находится на 35820568 месте от запятой после тройки, и эти координаты местоположения участка нужно будет как-то передать.
 
Дело не ресурсах памяти или вычислительных мощностях. Если бы дело было только в них, то задача решилась бы простым увеличением ресурсов памяти и вычислительных мощностей, благо они постоянно растут, благодаря развитию технологий.

Голландский математик Брауэр в первой половине XX века привёл в качестве примера бессмысленной задачи поиск в десятичном разложении π последовательности 0123456789 — по его мнению, нужная для этого
точность никогда не будет достигнута. В конце XX века эта последовательность была обнаружена, она начинается с 17 387 594 880-го знака после запятой.
Педивикия ;)
Представь, сколько времени ты будешь выбирать нужные последовательности, если даже такая, казалось бы, простая и короткая находится настолько далеко. Сколько в итоге места займёт получившийся "сжатый файл" - уже следующий этап.
 
Спасибо. Именно это я и хотел услышать.
 
Хранение числа "пи" с требуемой точностью занимает ресурсы памяти, вычисление его с той же точностью занимает вычислительные мощности, точное указание нужного участка для нужного участка кода файла тоже имеет размер, вычислительные мощности требуются для обработки всех этих операций. В итоге выигрыша не будет.

согласен, компрессия - нагрузка для ЦП, чем сложнее логика, тем дольше будет висеть процесс
 
Назад
Сверху