Pull to refresh

Comments 29

Нет, просто такая задача не стояла. К тому же, было бы проблематично его считать для столь больших чисел. Если перегонять в double, будет потеря значащих разрядов. Хотя я согласен, что это было бы интересно.
Вот чую, через n месяцев, ТС забудет о том что его велосипед до конца не проверен,
и подключит его к другому проекту с другими требованиями,
и начнутся у всех проблемы,
и помянут топик-стартера не добрым слов,
и заодно всю программистскую братию,
и долго код будет правится-дебажится,
и долго еще будет слышен слог неприличный на просторах паутины,

Занесло что-то меня — просто всегда был и буду против таких велосипедов.
Тем паче, что ниже уже привели вполне хорошие велосипеды ГСЧ.
А зачем самому мучится — возмите стандартный нист-овый тест для ГСЧ и вперед… Там же документация как и с чем его едят.
В в реализации NIST, выложенной на их сайте, есть ошибки. Кроме того, их реализация не оптимальна и медлительна. Спектральнный тест основан на эмпирической статистике, при увеличении длины выборки это приводит к ошибкам.
1. Для проверки качества генераторов разработаны специальные наборы тестов. Самый известный — Diehard
2. В C++11 уже встроены несколько генераторов случайных чисел и разных вспомогательных функций. То что у вас — это линейный конгруэнтный генератор. Там есть готовый 64-разрядный вихрь мерсенна. (так что ваша жалоба на отсутствие 64-разрядного устарела)
Линейный конгруэнтный же вроде как не проходит Diehard полностью. Хотя сравнить с «дефолтным» в ЯП было бы неплохо даже через Diehard. Алсо поддерживаю вас по поводу вихря мерсенна.
Тоже как то понадобился свой генератор (но не в java, а в perl). Тоже взял LCG с параметрами 1103515245 и 12345 (выходные биты 30..0).

Первые грабли на которые наступил — переполнение на 32 машине.

Вторые — в какой-то задаче где случайные числа использовались для выбора порядка завершения задач в симуляции очереди заданий, в случае если количество параллельных процессов равно степени двойки, приоритезация в очереди заданий совершенно случайно начинала работать как round robin. Учитывая что я как раз писал тест, нужный чтобы убедиться что никакого round robin у меня нет (и в последствии тест должен начать проходить, когда я его реализую), был очень удивлён такой корреляции. Такие вот случайные числа.
SecureRandom random = new SecureRandom();
byte bytes[] = new byte[16];
random.nextBytes(bytes);
return new BigInteger(bytes)
Тоже не понял сути статьи. Даже в случае чего, можно просто «слепить» несколько случайных чисел побитовым сдвигом.
Не самая хорошая идея, имхо. Возможно потеряем качество случайных чисел. Линейный конгруентный метод «знаменит» распределением чисел по гиперплоскостям:
en.wikipedia.org/wiki/Linear_congruential_generator#Advantages_and_disadvantages_of_LCGs
Что не лучшим образом сказывается в использовании его в 3д графики. А если мы скомбинируем так сдвигом — рискуем получить очень хреновое качество распределения.
А что писать, всё уже реализовано — boost нашо всё (если не увлекаться). Если посмотреть исходники, то во многих есть ссылки на математические обоснования и доказательства для дотошных.
www.boost.org/doc/libs/1_55_0/doc/html/boost_random/reference.html#boost_random.reference.generators
Спасибо за подсказку.
Мне кажется прирост 25 процентов очень условный.
UFO just landed and posted this here
UFO just landed and posted this here
при изучении генераторов в универе оказалось, что встроенный генератор в Java довольно неплох — проходит тесты на равновероятность, независимость и однородность
а на С++ для своей реализации сильный и быстроработающий генератор Гёффе / Джиффи
Каким образом получили монохромные картинки?
Каждая картинка рисуется построчно, цвет каждого пикселя – это значение, к примеру, 5-го двоичного разряда в каждом числе xi, последовательность которых получается по формуле линейного конгруэнтного генератора. Нулевой разряд самый младший. Для картинки 256x256 пикселей нужно рассчитать 65536 чисел и взять из каждого по одному биту с заданной позиции.
UFO just landed and posted this here
можешь свою длинную арифметику написать
мы генерировали 8М бит на питоне, и работало
UFO just landed and posted this here
А почему Вы решили не пользоваться быстрыми криптостойкими хеш-функциями (в режиме счетчика)?
UFO just landed and posted this here
Верно, скорость была важнее, а криптостойкость не требовалась.
UFO just landed and posted this here
Из контекста, конечно, совершенно понятно, что речь в статье идет именно о псевдослучайных числах.
Но в заголовке топика и куче мест по тексту они фигурируют как «случайные», что некорректно (и теоретически может сбить кого-то с толку).

По поводу необходимости тестов и применения различных батарей (нист, дайхард, хи-квадрат) тут выше обсуждали…
Топик кастер же явно дал понять, что эти всевдослучайности ему нужны для узкоспециализированной задачи, никак не связанной с секурностью, ИБ, криптой и прочими вещами. Так что какие-то четкие требования по качеству последовательности предъявлять (а тем более — проверять) в данном случае бессмысленно.

Автору спасибо за топик, всегда приятно встретить на хабре что-то подобной тематики.
Sign up to leave a comment.

Articles

Change theme settings