Pull to refresh

Comments 19

Не ручаюсь за достоверность, но в Спектрумах вроде бы был специальный порт 255 для чтения «случайных» чисел с пассивной шины данных.
Там был регистр регенерации динамической памяти R у Z80. Собственно, в вышеприведённом алгоритме ld a,r и используется.
Таки да, я поэтому и поставил ковычки. Но в играх с динамическими сценами (где иногда и использовалась эта особенность ) получить псевдослучайное значение было можно.
где иногда и использовалась эта особенность


Если честно, никогда не встречал рекомендаций по такому использованию этого порта. Вот привязка к выводу на экран — да, это делали. Но как генератор случайных чисел… Всегда использовали регистр R.

Я далек от темы программирования микроконтроллеров, потому мне было бы интересно узнать что-нибудь об области применения ДПСЧ в ней.


Возможно, не помешала бы более конкретная постановка задачи:


  • Везде, кроме, кроме C++ rand, идет речь о розыгрыше равномерного распределения чисел с плавающей точкой на открытом или закрытом множестве от 0 до 1, а не какого-либо другого. В C++ rand на выходе целое число — это же другая задача?
  • По области применения ДПСЧ часто делятся на криптографические и вычислительные (метод Монте-Карло). От криптографических датчиков в первую очередь требуется непредсказуемость последовательности (сложность определения алгоритма генерации по полученной последовательности), от вычислительных — близость статистических характеристик (мат. ожидание, дисперсия, корреляции и т.п.) получаемой последовательности к теоретическим значениям и быстродействие (критично). Например, PRNG — исключительно вычислительный датчик, и его использование для задач шифрования не подходит.

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

ДПСЧ… От криптографических датчиков..

Может вы о ГПСЧ (?) Генератор ПсевдоСлучайных Чисел, не датчик.

От криптографических датчиков в первую очередь требуется непредсказуемость последовательности (сложность определения алгоритма генерации по полученной последовательности)

Нет, для криптографически стойких генераторов требования не такие.
Если по простому, то в хороших криптостойких генераторах: алгоритм открыт, неизвестен только ключ (зерно / seed), наблюдая за работой генератора нельзя предсказать следующее число (с большой вероятностью) и нельзя найти ключ.

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

Всё просто: все алгоритмы из этой статьи не подходят для криптографии.
Если по простому, то в хороших криптостойких генераторах: алгоритм открыт, неизвестен только ключ (зерно / seed), наблюдая за работой генератора нельзя предсказать следующее число (с большой вероятностью) и нельзя найти ключ.

Имел в виду алгоритм вместе со всеми своими параметрами — то, что нужно для восстановления всей последовательности по какому-то известному участку.


Всё просто: все алгоритмы из этой статьи не подходят для криптографии.

Согласен. Но для чего же они подходят в контексте МК? Это загадка, но, похоже, лишь для одного меня.
Вопрос, разумеется, адресован главным образом к автору.

Автомат Вольфрама с правилом 30 забыли. :)
RAND_MAX описана в файле stdlib.h и равна 32'767

Нет. Значение зависит от платформы. Например, на современном Линуксе её значение 2147483647.

int64_t A = (((((rand() << 16) | rand()) << 16) | rand()) << 16) | rand();

Так нельзя писать по двум причинам:
1. Сдвиг на 16 бит, хотя минимальное значение RAND_MAX 32767, а это 15 бит.
2. Если RAND_MAX больше 65535, то в числе будет больше единичных битов, для объединения надо использовать xor.

Так нельзя писать по двум причинам:

По трём. Есть большая вероятность, что результат (rand()<<16) приведётся к 32-битному int (где-то, кстати, есть 64-битный инт?). Ещё один сдвиг на 16 от него ничего не оставит.

Слона-то я и не заметил :)
Хорошее замечание, исправил этот момент в статье
использовать std::random_device для получения зерна лучше чем от time(NULL), однако в случае с компилятором MinGW в Windows функция практически не работает

Вот на эту тему хотелось бы подробностей.
Пока что нагуглилось что оно RESOLVED FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85494
Опс. Там target=10.0

Спасибо! Надо в копилку «житейских» хитростей сохранить ;)
Sign up to leave a comment.

Articles