компрессия данных - > метод арифметического кодирования

можно взять вместо N N0

--- Сообщение объединено, 6 фев 2025 ---

Да это понятно все, я писал в предположении, что мощностей достаточно

 

Ну. Типа. Да. Немного меньше бит. Для 34-битных полей список простых чисел займет
(455052512*34)/8=1933973176=1888645,7*1024=1844,4*1024*1024=1,8 гигабайта. А профита 5 бит всего. На полях длинней сжимать будет лучше, но словарь придется на серверах гугла хранить. В какой-то момент придет в голову, что файл можно ужать аж до URL-ссылки на файл на серверах того же гугла. Это при том, что управляющие коды в кодировании тоже не святым духом, а битами питаются.

--- Сообщение объединено, 6 фев 2025 ---

ЗЫ: нету никакого волшебства колдунского. Сжиматься данным позволяет их избыточность. Избыточность связана с тем, что данные не случайны и подчиняются каким-то внутренним законам, которые можно выявить и оседлать. А если просто взять какую-нибудь красивую математическую функцию и зачем-то решить, что в ней есть большой потанцевал в плане сжатия, потанцевала там скорей всего не будет.

 

Есть такое, что в достаточно большой системе обязан появиться порядок
https://ru.wikipedia.org/wiki/Теория_Рамсея

 

Например файл сформирован некоторым алгоритмом ГПСЧ с некоторым сидом. Тогда можно выявить алгоритм и сид и невероятно сильно эти данные сжать. Только с практической точки зрения тут ничего интересного и перспективного нет.

 

Я не просто так взял простые числа, считается что именно они - источник хаоса

 

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

 

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