Комментарии 7
Помню, когда давно изучал программирование в школе (на QBASIC). Учитель показал нам функцию RND. И с её помощью мы сделали вывод на экран кругов со случайными координатами, радиусами и цветом. И мы все сделали эту программу и запустили.
И у всех получилось изображение случайных кругов на экране. Случайные-то они были случайные, но почему-то у всех одинаковые! Тогда учитель нам подсказала, что надо добавить строчку RANDOMIZE TIMER, которая делала результат зависимым от системного времени нажатия чуть ли не в миллисекундах.
И тогда — о, чудо — кружки стали не только случайными, но и неповторимыми. Почему-то мне это хорошо запомнилось, т.к. было очень наглядно и понятно.
А в статье не хватает такой практической наглядности, в чём именно будет проявляться эта неслучайность в Питоне.
Всё верно, и поэтому при генерации потока случайных значений нужно периодически обновлять seed псевдослучайного генератора из более надёжного источника случайных значений. Это позволит избежать зацикливания и больший перекосов при сохранении высокой скорости генерации потока случайных значений. Но этом почему-то никогда не говорят. Можно даже другой псевдослучайный генератор, как источник seed для основного генератора, использовать и получаться весьма неплохие длинные последовательности, но есть нюансы.
У меня другой опыт был в школе. Делал программу генерации звёздного неба.
Звезды были действительно в случайных координатах. Добавил рандом для цвета и звезды выстроились в стройные диагональные линии.
Преподаватель не смог объяснить :)
Я с помощью Random пытался нарисовать шум на экране клона ZX Spectrum. А на экране появились заметно повторяющиеся фрагменты.
Я знал что рандом не рандомен, но не знал как именно это устроено (Я имею в виду что примерно представлял как это сделано это были довольно размытые представления, но статья всё разложила по полочкам)
в Java в тестах генераторах больших наборов UUID использовал seed для возврата к нужным UUID (айди документов) для обновления и удаления. Очень удобно. Генеришь миллионов 200 документов, затем события для случайной выборки (удаление) - ничего в памяти держать не нужно кроме сдвига (количества вызовов random).
Интересно что мешает подмешивать тепловой шум, шум электрического тока, э/м полей?
Понятно что распределение будет не "белое" а какое нибудь "дробовое", но ведь можно этот внешний источник использовать для периодического сдвига ГПСЧ, они как правило на регистрах сдвига. Ну не будет это красивая кривая распределения, зато точно не периодический воспроизводимый ряд.
Некоторые ГПСЧ используются наоборот, с коротким периодом, например М-последовательность для модулирования несущей частоты РЛС, для уменьшения боковых лепестков диаграммы направленности. Сигнал должен быть достаточно случаен на достаточно долгом отрезке времени, по совпадению сигнала делается синхронизация (выясняем что прошел период). В загоризонтных РЛС приходится принимать сигнал намного меньше уровнем чем шум, его "вытягивают" когерентными приемниками в которых случайность шума в разных усилителях увеличивает уровень полезного сигнала на выходе (в сумматоре) - шумы независимы в разных приемниках в усилителях и частично гасят друг друга, а полезный сигнал увеличивается линейно.
Когерентный прием это "сила" которая используется и живыми организмами, например клетками детекторами электрического поля в носу акулы - сигнал от нервых импульсов акула чувствует на расстоянии до 2х метров.
пардон, "Остапа занесло"...
А мой опыт со случайными числами начался с калькулятора МК-61 . Тогда я и начал подозревать что команда вывода СЧ совсем не случайное число .
Псевдослучайный рандом в Python