Basil A. SidorovЛично для меня бессмысленны оба занятия
это повтор (уже говорилось), поэтому и мне приходится повторяться: майнинг бессмыслен сам по себе , но в внутри блокчейна (даже не криптовалюты, а именно блокчейна!) он выполняет вполне определённую (а значит осмысленную) функцию авторегулировки частоты возникновения новых блоков.

Точно также, например, бессмысленны ( сами по себе ) усилия по разложению на множители гигантских целых чисел. Но внутри проекта поиска простых чисел они совершенно необходимы (не обсуждаю, насколько осмыслен сам этот проект).

Basil A. Sidorov для майнинга хэшей есть чёткий алгоритм и побеждать будет тот, у кого больше вычислительных мощностей при равной архитектуре. Включая архитектуру, специально разработанную под конкретную задачу.

Майнинг -- процесс вероятностный: "побеждает" -- на каждом шаге -- тот, кому повезёт. Но шансы больше у того, у кого более мощное оборудование. Собственно, в "модельной" задаче поиска простых чисел тоже так: "побеждает" (находит каждое новое число) не обязательно именно тот, у кого самый мощный компьютер.

(Да, кстати, можно и явно произнести, что существую проекты (и даже, кажется, реализации) блокчейнов, в которых майнятся не хэши, а именно (новые) простые числа!)

Basil A. Sidorov Чтобы майнить степени сжатия требуется или каждый раз разрабатывать алгоритм сжатия под конкретную последовательность, что выглядит несколько утопично или подбирать некий мифический параметр.

именно -- "или подбирать ... параметр". Наконец мы начали различать подбор параметра и изобретение алгоритма.

А если в процессе "майнинга степени сжатия" будут изобретаться новые, более эффективные алгоритмы сжатия, -- так это же просто пир духа, прямая польза для благодарного Человечества!

Basil A. Sidorov,

ну я же придумал (прямо на коленке) пример (не работающий, наверняка, но пример) алгоритма сжатия, который использует перебор seed ( 21079962 ).

А вы продолжаете про " обычных алгоритмов"! В моей постановке задачи нужен не " обычный ", а специальный ресурсоёмкий алгоритм.

(Какая польза от таклго агоритма -- буде он избретён -- случится вне задачи "майнинга степени сжатия" -- это отдельный разговор.)

Basil A. Sidorov,

дык, я тут играю в поддавки, а вы поддаётесь на эту игру в поддавки.

Но вообще-то, почему порождаемый (на основе ГПСЧ) "словарь" (который, благодаря его порождаемости, не нужно целиком запихивать в архивный файл) не даст преимущества перед хранимыми (в архивном файле) словарями, -- никто мне пока не объяснил.

Basil A. Sidorov,

да-да, вы, наверное, и шифрование сообщений при помощи ГПСЧ будете отрицать. А всего-то: порождаем на основании очередного (записанного на бумажке и у Штирлица, и в Центре) seed случайную последовательность битов и суммируем её (побитово) с отправляемым сообщением.

Basil A. SidorovГамма не порождает информациюа словарь порождает информацию?

... он, собственно, тоже шифрует информацию. Вопрос ровно в том, удастся ли сделать зашифрованное сообщение короче (числом битов), чем исходное.

exp98, нет.

S.G., где в это академии наук дверь?

exp98, вообще не проблема: кто-то малознакомый (не будем показывать пальцем ... на S.G.) нагрубил. Ну, нагрубил и нагрубил.

mayton,

вообще говоря, если мы на Альфа Центавра отправляем сжатый архиватором файл, и хотим чтобы тамошние альфацетавряне его распаковали, то мы должны вместе с файлом архива и (де-)архиватор отправить, и ... операционную систему, и много чего ещё, даже перечислять не возьмусь.

Dima TСжатие ведь идет за счет того что самые частые записи имеют самый короткий идентификатор.
-- это верно, но приписывание различным "частым записям" идентификаторов, более коротких, чем сами эти записи могло бы продвинуться весьма далеко, если бы не необходимость создать для каждой такой замены "словарную статью". Представьте, что в нашем входном потоке в конце концом обнаружилось два вхождения строки длиной 1000 бит, а возможность создавать короткие идентификаторы исчерпана вплоть до идентификатора длиной 998 бит ... Ничего, мы обозначим (и заменим) эту 1000-битную строку 999-битным идентификатором -- сожмём, казалось бы, входную строку ещё на 2 бита! Однако нет, "расход битов" на указание соответствия 1000-битной строки 999-битному идентификатору будет по-любому больше этой "экономии" 2-х битов.

То есть создание словаря прекращается тогда, когда "маржинальные" расходы (в битах) на пополнение словаря становятся равны экономии (битов) от применения новых "словарных статей".

А вот это последнее условие будет совершенно по другому "исчисляться" при использовании "генерируемого словаря" (чем при использовании словаря, вписываемого в архив). При том, что сам по себе "генерируемый словарь" будет, конечно, заметно менее эффективен (по экономии битов при применении "словарных статей"), чем вписываемый в архив "свободный" словарь.

Иван FXSDima TСжатие ведь идет за счет того что самые частые записи имеют самый короткий идентификатор.
-- это верноточнее, не верно: сжатие идет за счет того, что записи имеют более короткий идентификатор, чем они сами. А вот " хорошим " (" лучшим ") сжатие становится "за счет того что самые частые записи имеют самый короткий идентификатор", как вы написали.