Якість лінійних конгрурентних генераторів для випадкових чисел

Я роблю деякі імітації рівняння Лангевіна для різних зовнішніх сил. Говорив , що C це rand()з stdlib.hможе ввести ухил в моїх результатах, я використовую Вихор Мерсенна.

Тим не менш, я хотів би знати (і бачити), які саме помилки може вводити лінійний конгрурентний генератор в моєму моделюванні. Це те, що я спробував:

• Створення 3D-кортежів рандов, щоб спробувати побачити гіперплани. Я нічого не бачу.
• Виконуємо на FFT великий вектор випадкових чисел. Це майже однаково і для Mersenne Twister, і для rand().
• Перевірка принципу обладнання для частинки в броунівському русі. Обидва інтегратори погоджуються в очікуваному значенні з однаковою кількістю значущих цифр.$\langle \text{KE}\rangle=\frac{1}{2}k_BT$
• Побачивши, наскільки добре вони біняють у кількох бункерах, що не є двома потужностями. Обидва дають однакові якісні результати, і ніхто не буде кращим.
• Дивлячись на броунівські контури, щоб побачити чіткі розбіжності від . Знову не пощастило.$\langle x\rangle = 0$
• Розподіл балів по колу. Заливається, і тільки по периметру. Між усіма ними і між найближчими сусідами (відповідь Шор, нижче в коментарях). Доступний у цьому суті , просто запустіть його з Julia 0.5.0 після встановлення необхідних бібліотек (інструкції див. У суті).

Я хотів би підкреслити, що я шукаю введені упередження в контексті фізичних симуляцій. Наприклад, я бачив, як rand()жалюгідно не спрацьовує випробування на дегердер, тоді як Мерсенн Твістер не робить, але на даний момент це не означає для мене занадто багато.

Чи є у вас якісь фізичні, конкретні приклади того, як поганий генератор випадкових чисел руйнує імітацію Монтекарло?

Примітка. Я бачив, як подібні PRNG RANDUможуть бути жахливими. Мене цікавлять не очевидні приклади генераторів, які виглядають невинні, але в кінцевому рахунку вносять упередженість.

Одне цікаве посилання, яке описує збій моделювання фізичної системи в Монте-Карло через неадекватну RNG (хоча вони не використовували LCG), це:

А. Ферренберг та Д. П. Ландау. Моделювання в Монте-Карло: приховані помилки від «хороших» генераторів випадкових чисел. Листи фізичного огляду 63 (23): 3382-3384, 1992.

Моделі Ізінга, які вивчали Ферренберг та Ландуа, є хорошими тестами RNG, тому що ви можете порівняти з точним рішенням (для 2-D проблеми) та знайти помилки у цифрах. Ці моделі повинні показувати несправності в старомодному 32-бітному арифметичному PMMLCG без особливих труднощів.

Ще одна цікава посилання:

Х. Бауке та Стефан Мертенс. Псевдо випадкові монети показують більше головок, ніж хвости. arXiv: cond-mat / 0307138 [cond-mat.stat-mech]

Бауке та Мертенс висловлюють вагомий випадок проти генераторів бінарних лінійних зворотних зв'язків зсуву регістра стилів генераторів випадкових чисел. У Бауке і Мертенса є деякі інші документи, пов'язані з цим.

Знайти площини Марсагліа в 3D-графіці розсіювання може бути важко. Ви можете спробувати повернути сюжет, щоб отримати кращий вигляд, а іноді вони просто вискакують на вас. Ви також можете зробити 3D-тести статистичної рівномірності - для старих 32-бітових LCG вони не зможуть отримати досить невелику кількість бункерів. наприклад, тест на рівномірність із сіткою 20-х20х20 бункерів у 3-х розмірах є достатнім, щоб виявити відсутність рівномірності широко використовуваного (і раніше добре розглянутого) PMMLCG з m = 2 ^ 31-1, a = 7 ^ 5.

Можна використати набір тестів PRNG TestU01 для того, щоб з’ясувати, який з цих тестів randне вдається. (Див. TestU01: Бібліотека змінного струму для емпіричного тестування генераторів випадкових чисел для огляду тестового набору.) Це простіше, ніж придумати власне моделювання в Монте-Карло. Певним чином, це також питання комбінованості програмного забезпечення (та коректності програмного забезпечення): якщо ПРНГ, який, здається, працює добре на невеликих, простих тестах, як ви знаєте, його патологічна поведінка не буде спровокована більшою програмою?

Ось код:

#include "TestU01.h"

int main() {
  // Same as rand() on my machine
  unif01_Gen* gen = ulcg_CreateLCG(2147483647, 16807, 0, 12345);

  bbattery_SmallCrush(gen);
  bbattery_Crush(gen);

  return 0;
}

Для пакету SmallCrush є 3 тести, які не виходять із 15 (див. Посібник longtestu01.pdf у TestU01 для довгих описів та всіх посилань; це 15 статистичних даних з 10 тестів).

• $n$ $t$$d^t$$d^t$$I_1,\ldots$$\{I_{j+1}-I_j\}$

• $n$ $t$$[0,1)^t$$d^t$

• $n$$t$$[0,1)$$X$$n$$\mathbb{P}(X<x) = x^t$$n=2\times 10^6$$t=6$$\chi^2$$<10^{-300}$

Якщо припустити, що це все "типові" імітації Монте-Карло (хоча вони можуть бути не схожими на проблеми, які ви мали на увазі), то висновок полягає в тому, що це randне вдається деякому невідомому їх набору. Я не знаю, чому саме це підмножина, тому мені неможливо сказати, чи буде вона працювати на вашу власну проблему чи ні.

MaxOft здається особливо підозрілим, враховуючи, наскільки прямолінійний опис.

Серед тестів у наборі Crushrand не виходить 51 із 140 (140 статистичних даних у 96 тестах). Деякі невдалі тести (наприклад, Fourier3 ) робляться на бітових рядках, тому, можливо, можливо, вони не були б стосуються вас. Ще один цікавий тест, який не вдається - це GCD , який перевіряє розподіл GCD двох випадкових цілих чисел. (Знову ж таки, я не знаю, чому саме цей тест виходить з ладу, чи буде від цього страждати ваше моделювання)

PS : Ще одна річ, яку слід зазначити, rand()це насправді повільніше, ніж деякі PRNG, які успішно проходять усі тести SmallCrush , Crush , BigCrush , такі як MRG32k3a (див. Папір L'Ecuyer & Simard вище).