Вопрос программистам. Почему до сих пор не разработан абсолютный математический архиватор? Неужели в нём нет нужды? Есть загвоздка в первоначальном расчёте большого кол-ва данных, но потом всё это окупится, разве нет? Ниже приведу своё понятие, а вы, пожалуйста, объясните я где-то ошибаюсь или просто никому это не надо?
Любой файл можно представить как последовательность цифр 0 и 1. Почему бы не взять произвольное количество этих цифр (к примеру сто) и не представить в виде числа (для простоты объяснения я буду переводить эти числа в десятичную систему) условно говоря, мы взяли первые сто нулей и единичек нашего файла, решили что это число и перевели в десятичную систему счисления, пусть (условно) у нас получилось число 8 589 934 592. Пусть оно (опять же условно) занимает десять "ячеек" данных. (каждая его цифра занимает одну "ячейку"). Но постойте! Ведь это число является результатом возведения двойки в тридцать третью степень! 2^33=8589934592. Занчит, мы можем записать это число в более короткой форме 2^33 и это число займёт у нас всего 4 "ячейки" памяти. Верно? Предположим, что для всех стозначных двоичных чисел у нас есть своя математическая формула, приводящая к их решению (ну или не для всех, а для большинства, не суть важно) При первой итерации получаем ужатый в несколько раз файл, состоящий из простых задачек, которые нужно решить. Что-то вроде 2^33|7^12+1|43^23-12| ну и так далее... Разумеется формулы будут давать только целые числа, чтобы различные процессоры считали их всегда одинаково, не ошибаясь на округлениях. Во второй итерации, представленный файл снова можно представить как набор 0 и 1 и снова ужать, получив новый файл, состоящий из формул, но меньше предыдущего. (разумеется математические знаки будут иметь уникальную двоичную сигнатуру, дабы после решения примера программа-архиватор поняла, что в результате получила "формулу" а не готовый ответ, таким образом, при должном терпении файл любого размера можно ужать до размера одной формулы, условной двойки в тридцатой степени, плюс техническая информация (кол-во шагов для распаковки, контрольная сумма и прочее). Разумеется предельное сжатие, потребует для распаковки большего кол-ва вычислительных мощностей, но поскольку файлы чаще всего конечного размера то и мощности нужны конечные и уверен, не заоблачно большие. Так почему все суперкомпьютеры Земли, Boinс проекты и прочее, до сих пор не ищут максимально короткие математические выражения для условных стоциферных (или любых "удобноциферных") чисел? Ведь это здорово бы снизило затраты на дата центры! Или я в чём-то не прав? Объясните пожалуйста!
Другие языки программирования и технологии
Почему до сих пор не создан математический архиватор?
вот есть у меня подозрение, что поиск для произвольного числа формулы, которая была бы короче, чем это число - это NP-полная задача. да и то, не факт, что этот поиск будет успешен.
вот, например, есть у нас алфавит {0,1,2,3,4,5,6,7,8,9,+,-*,/}
как записать в этом алфавите формулу для числа, скажем, 8593 обойдясь максимум тремя знаками? 1+2? 4/3? 8*6?
вот, например, есть у нас алфавит {0,1,2,3,4,5,6,7,8,9,+,-*,/}
как записать в этом алфавите формулу для числа, скажем, 8593 обойдясь максимум тремя знаками? 1+2? 4/3? 8*6?
"Математик", почитай для начала, что такое "биекция", на первом курсе учат.
Чтобы твой алгоритм работал, функция преобразования должна быть биективной, то есть, для любого входного значения должно существовать одно выходное значение, и наоборот. Соответственно, мощность обоих множеств будет одинакова. Но ты сейчас пытаешься запихнуть большое множество в маленькое (если хочешь получить гораздо меньший объём выходных данных, по которым можно однозначно восстановить входные данные). Никакой биекцией тут и не пахнет.
Отсюда вывод: прежде чем предлагать что-то математическое, изучите хотя бы основы математики, теорию множеств проходят на первом курсе как бэ))
Чтобы твой алгоритм работал, функция преобразования должна быть биективной, то есть, для любого входного значения должно существовать одно выходное значение, и наоборот. Соответственно, мощность обоих множеств будет одинакова. Но ты сейчас пытаешься запихнуть большое множество в маленькое (если хочешь получить гораздо меньший объём выходных данных, по которым можно однозначно восстановить входные данные). Никакой биекцией тут и не пахнет.
Отсюда вывод: прежде чем предлагать что-то математическое, изучите хотя бы основы математики, теорию множеств проходят на первом курсе как бэ))
Серега Осипов
Ну а почему она не будет биективной? Любому выражению со всеми известными (2+2=) соотвествует только одно решение (4). Нам просто надо выбрать такие выражения в которых количество данных после решения выражения было бы большим, чем само выражение.
А ничего, что по твоему алгоритму для записи первых 100 единичек в 10-чном формате вместо 12,5 байт внезапно начинает требоваться 31 или сколько там? А на второй стадии мы утеряли нахрен всю информацию. Ну давай вместо "Утра в сосновом бору" "Грязный квадрат" смотреть.
Дальнейший бред не читал.
Дальнейший бред не читал.
Серега Осипов
Десятичный формат выбран для примера, не обязательно использовать его. Вы принцип математики понимаете? С чего мы утеряем всю информацию? Информация не будет утеряна.
А теперь представь, что тебе нужно сжать всевозможные данные длинной 10 битов. Всего таких вариантов для сжатия 2^10 = 1024. А сжимаешь ты в более короткий вид от 2^0 до 2^9 (1023 варианта). Таким образом математика тебе говорит, что сжать всё не получится в принципе. Как минимум два набора данных будут указывать на одно и то же сжатие. А найти подобные короткие записи вообще задача с точки зрения вычислительных затрат непростая. Это сколько компьютер по твоему должен считать, чтобы найти из огромного количества вариантов запись 43^23-12? Такая запись это скорее исключение из правил. Большинство записей будут намного длиннее. Многие современные форматы и без того максимально ужаты, исходя из самих данных. Сжать текст максимально эффективно не составляет никакого труда без всяких формул.
Серега Осипов
Считать надо много, вы правы. Но для того и компьютеры, чтобы считать. Для того и ежегодный рост вычислительных мощностей. Не совсем понял как два набора данных будут указывать на одно и тоже сжатие. У выражения со всеми известными только одно решение.
колесо уже давно круглое
Тогда проще тупо хранить "начальную позицию" в константе "пи" и размер файла :)
Например предположив, что наш файл содержит "395224737190702179860943702770539217176" - достаточно записать смещение 531 и размер 39, что будет явно меньше чем изначальный файл :)
Например предположив, что наш файл содержит "395224737190702179860943702770539217176" - достаточно записать смещение 531 и размер 39, что будет явно меньше чем изначальный файл :)
На самом деле так выглядят действтельные числа.
Но, во-первых, у чисел есть формат и любое число занимает фиксированное количество байт.
Во-вторых у чисел фиксированная длинна мантиссы для удобства буду десятичную систему использовать чтобы было понятно
Пусть у нас 8 цифр 6 мантисса и 2 порядок.
Таким образом мы можем записать цифры до 9.99*10^99 включительно
Но по факту 123456*10^2=12345600
Обрати внимание что последние цифры не значащие они всегда равны нулю а значит это не полнлценное восьми значное число.
Дальше всегда рещервируется в памяти все 8 разрядов даже если число короткое.
Это означает что преимущество сжатия длинных цифр
Заметь что 8 двоичными цифрами можно закодировать 10^8 степени чисел. При этом количество цифр будет тоже изменится только их порядок.
Но как я уже выше говорил
В памятм 0 будет записан как 1.00000 +00 и будет столько же места занимать сколько и 9.99999+99
Те же 8 символов.
Почему так происходит?
Потому что мы заранее не знаем каким значением мы иницмюиализируем переменную и резервируем область достаточную чтоб хранить весь диапозон.
Но, во-первых, у чисел есть формат и любое число занимает фиксированное количество байт.
Во-вторых у чисел фиксированная длинна мантиссы для удобства буду десятичную систему использовать чтобы было понятно
Пусть у нас 8 цифр 6 мантисса и 2 порядок.
Таким образом мы можем записать цифры до 9.99*10^99 включительно
Но по факту 123456*10^2=12345600
Обрати внимание что последние цифры не значащие они всегда равны нулю а значит это не полнлценное восьми значное число.
Дальше всегда рещервируется в памяти все 8 разрядов даже если число короткое.
Это означает что преимущество сжатия длинных цифр
Заметь что 8 двоичными цифрами можно закодировать 10^8 степени чисел. При этом количество цифр будет тоже изменится только их порядок.
Но как я уже выше говорил
В памятм 0 будет записан как 1.00000 +00 и будет столько же места занимать сколько и 9.99999+99
Те же 8 символов.
Почему так происходит?
Потому что мы заранее не знаем каким значением мы иницмюиализируем переменную и резервируем область достаточную чтоб хранить весь диапозон.
На дата центры давно нагрузка снижена. "В видимой части Вселенной порядка 10^80 атомов", то бишь число из 100 нулей, он же гугл должен указать на примерно популярный файл во вселенной, то бишь на начало этого файла. Так что всего 16 байт укажут тебе уникальный адрес датацентра нашей вселенной и отстается тебе этот файл только прочитать и все дела, не надо никакие архиваторы.
Олег Куликов
Это только атомов 10^80. А их комбинаций? Ведь информация - не кол-во атомов, а расположение их в определённом порядке.
бабушкин, ты что ль? можешь начинать писать алгоритм, когда напишешь и окажется что он работает, при том работает быстро, ты станешь миллиардером.
Серега Осипов
Чтобы писать алгоритм, надо сперва понять, нет ли ошибки в постановке задачи. Вы мне можете указать на ошибку в постановке задачи?
8 бит это значение от 0 до 255.
"255" занимает 3 байта
255 занимает 1 байт
всё уже сжато
"255" занимает 3 байта
255 занимает 1 байт
всё уже сжато
>> Любой файл можно представить как последовательность цифр 0 и 1.
Он и так прекрасно выглядит из 0 и 1. Для удобства в HEX.
>> Почему бы не взять произвольное количество этих цифр (к примеру сто) и не представить в виде числа
Ну да, числа от 0 до 2^100-1 (в десятичной)
>> и перевели в десятичную систему счисления,
Зачем? Переведи в 62ричную? 0-9a-zA-Z. Еще меньше клеточек будет занимать. А если в 256тиричную? Еще меньше. Логично? Ну вот он, файл, именно так и записан. Как раз байтами.
Бред. Сохрани его в закладки, никому не показывай, перечитай лет через 5-10 (оптимистично), если поумнеешь.
Он и так прекрасно выглядит из 0 и 1. Для удобства в HEX.
>> Почему бы не взять произвольное количество этих цифр (к примеру сто) и не представить в виде числа
Ну да, числа от 0 до 2^100-1 (в десятичной)
>> и перевели в десятичную систему счисления,
Зачем? Переведи в 62ричную? 0-9a-zA-Z. Еще меньше клеточек будет занимать. А если в 256тиричную? Еще меньше. Логично? Ну вот он, файл, именно так и записан. Как раз байтами.
Бред. Сохрани его в закладки, никому не показывай, перечитай лет через 5-10 (оптимистично), если поумнеешь.
Серега Осипов
Да я уже как раз и перечитал через десять лет... до сих пор не поумнел <>)) Объясни в чём дело-то? Можно и в 62ричную перевести. Где именно бред? На какой стадии?
Вадим Килин
А почему нет? Нельзя рассмотреть файл как одно число? Т. е. взять двоичное представление файла и рассматривать его как одно число?
Как хранить это на железе? При двоичной системе 1- высокое напряжение, 0 - низкое. Как хранить это при десятиричной системе?
Серега Осипов
Всё будет храниться в двоичной системе... десятичная приведена для примера.
Сергей Баранов
Почитайте, как физически хранится на железе 3бита в одной физической ячейке флеш-накопителя в технологии TLC (Three level cell).

Допустим Вы запишите 8589934592 как 2^33. Тогда следующее число 8589934593 можно записать 2^33+1. И какая от этого выгода? Знаков почти столько же. А во многих комбинациях знаков будет ещё больше. Тогда какой в этом смысл?
Потому что нельзя сжать то - что уже сжато априори)
Сожми воду, хотя бы в 10 раз, на порядок!
Сожми воду, хотя бы в 10 раз, на порядок!
Серега Осипов
Я не сжимаю воду, я пытаюсь сжать числа. А они прекрасно сжимаются.
Похожие вопросы
- Почему до сих пор, в мире не создана программа-диагност патологий человека?
- Аудитория интернета уже далеко не школьники с нулевым уровнем дохода. Но почему до сих пор никто не хочет платить
- Почему до сих пор кто-то учит C, Java, C++ и JavaScript?
- Кто из вас до сих пор пользуется старыми кнопочными телефонами ?
- Если JPEG это контейнер то почему для открытия этих файлов используются не архиваторы?
- Люди Почему в наше время до сих никто не создал процессор дома? или озу или видео карту? Неужели это так сложно?
- Почему в ВУЗах до сих пор преподают Pascal, несмотря на то что лучшим языком считается C?
- Почему Delphi 7 до сих пор так популярна?
- Почему в школах до сих пор учат турбо паскаль?
- Почему в С/С++ до сих пор не устранена проблема с выходом массива за границы?
Из этого следует, что числа от 9802 до 9999 (4 знака) пятью не записать.
Более того "короче" в каком представлении?
Т. к. даже в BCD для 9999 надо 2 байта. А для формулы?