Идея алгоритма сжатия методом деления.

[mrChester]

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

Сжатие может и будет достаточно сильным, но времени затрачиваться будет очень много.
Число 0,4578999887 можно представить, как 4578999887/10^10. (*)
Теперь на нужно числа 4578999887 и 10^10 разложить на простые множители, для того чтобы сократить дробь (*).
Процесс факторизации требует полиномиальное время.
На трудноразрешимости факторизации больших чисел основаны некоторые алгоритмы шифрования...
Сжатие данным способом - утопия

[alexBlack]

Еще вариант поиска M и N - последовательное приближение в дереве Штерна-Брокко

Числитель / Знаменатель Значение Абс. ошибка
...
881 / 1924 0.457900208 0.000000219200208
1365 / 2981 0.457900034 0.000000044845790
1849 / 4038 0.457899950 -0.000000038229470
3214 / 7019 0.457899986 -0.000000002947044

получено здесь

[Alex Cones]

получено здесь

Замечательный сайт, показывающий принцип в действии. Ввел что-то вроде 0.47239872492 получил за 20 итераций уже нехилое количество нулей в абсолютной ошибке.

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

[mrChester]

Сообщение от Alex Cones

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

И много информации хранится в числе 0.47239872492?
А если файл мегабайты занимать будет?
Есть алгоритмы факторизации которые на нормальном компе разложат число порядка 10^30 имеющего всего 2 простых делителя за доли секунд. но скорость поиска делителей увеличивается полиномиально.
Последовательное приближение также при увеличении объема информации будет затрачивать гораздо больше времени.
Спорим?

[Tronix]

Офигеть. Да тут даже и спорить нечего. Я не могу до 16 знаков после запятой подобрать брутфорсом для рандомных данных.

[Alex Cones]

Я не могу до 16 знаков после запятой подобрать брутфорсом для рандомных данных.

ПРИЧЕМ ЗДЕС БРУТФОРС???
Смотрим сюда и вникаем: http://leoblog.ru/?Laboratoriya:Priblizhenie_drobei

А если файл мегабайты занимать будет?

Пусть 1 мегабайт. Это у нас 1024 * 1024 * 2 = 2097152 шестнадцатиричных чисел. Умножим примерно на 1.6, чтобы примерно узнать количество цифр десятичных: 3 355 443. 3 миллиона. Не так много, если заточить алгоритм на длинную арифметику и вставки из ассемблера. что-то около 5-10 минут, не более. Прикинем степень сжатия:
3 числа с 50-100 символами на выходе, 104448 байт на входе. - 0,28 %. В случае увиличения размера файла можно дать право выбора - дольше, но больше сжатие, быстрее, но сжатие меньше - регулировать размер блоков.

[the_deer_one]

Alex Cones
Продемонстрируй.

Вот тебе число к примеру:
0.67897672

Вот раздели его на множители так, что-бы они на твои 72% меньше знакомест занимали.

[Alex Cones]

График сжатия примерно такой:
С увеличением объема данных увеличивается степень сжатия. При столь малых количествах сжатие не будет иметь смысла. Расчеты выше, если Вы не заметили, привелены для 1-го мегабайта.

на твои 72%

О_о Где Вы там увидели 72%? Там написано 99.72%

[the_deer_one]

Alex Cones

При столь малых количествах сжатие не будет иметь смысла.

Хорошо. Сожми своим способом хоть одно число, весящее метр.

[Alex Cones]

Сожми своим способом хоть одно число, весящее метр.

Угу, знаете, что сейчас ситуация напоминает? "Что? Астронавт великий? А ну дай мне грунт с Плутона, да килограмм 400. И немедленно!"

Так же и здесь - я рассчитал теоретические цифры. Модуля то у меня нет. И будет ли он писаться кем-либо - неизвестно. Я привел теоретические расчеты. Хотите посмотреть алгоритм сжатие, читайте пост #10.