Rasgele sayılar için lineer kongruratif jeneratörlerin kalitesi

Çeşitli dış kuvvetler için Langevin denkleminin bazı simülasyonlarını yapıyorum. C olduğunu söylenmişti rand()dan stdlib.hbenim sonuçlarında önyargılara neden olabilir, bir Mersenne Twister kullanıyorum.

Bununla birlikte, doğrusal bir uyumlu jeneratörün simülasyonumda tam olarak ne tür hataları ortaya çıkarabileceğini bilmek (ve görmek) istiyorum. Bunlar denediğim şeyler:

• Hiperplanları görmeye çalışmak için 3 boyutlu rastgele tuples üretmek. Hiçbir şey göremiyorum.
• Rastgele sayılardan oluşan büyük bir vektörün FFT yapması. Hem Mersenne Twister hem de neredeyse aynı rand().
• Eşit bölme prensibinin Brownian hareketinde bir parçacık için kontrol edilmesi. Her iki entegratörleri beklenen değer hemfikir ile aynı sayıda anlamlı basamak.$\langle \text{KE}\rangle=\frac{1}{2}k_BT$
• Bir ikilik olmayan bir kutuya ne kadar iyi oturduklarını görmek. Her ikisi de aynı kalitatif sonuçları veriyor, hiç kimse daha iyi değil.
• Brown yolları baktığımızda açıkça farklılıkları görmek için . Yine şans yok.$\langle x\rangle = 0$
• Bir daire içindeki noktaların dağılımı. Dolu ve sadece çevre. Hepsi arasında ve en yakın komşular arasında (Shor'un cevabı, aşağıdaki yorumlarda). Bu özette mevcut , gerekli kütüphaneleri kurduktan sonra Julia 0.5.0 ile çalıştırın (talimatlar için özete bakın).

Fiziksel simülasyonlar bağlamında tanıtılan önyargı aradığımı vurgulamak isterim. Örneğin rand(), Mersenne Twister'ın yapmadığı zamanlarda dieharder testlerinin ne kadar sefil bir şekilde başarısız olduğunu gördüm , ancak şu an benim için çok fazla bir şey ifade etmiyor.

Kötü bir rasgele sayı üretecinin Montecarlo simülasyonunu nasıl bozduğuna dair fiziksel, somut, örnekleriniz var mı?

Not: PRNG'nin nasıl RANDUkorkunç olabileceğini gördüm . Masum görünen ama sonuçta önyargı yaratan jeneratörlerin bariz örnekleri ile ilgilenmiyorum.

Yetersiz RNG nedeniyle (LCG kullanmasalar da) bir fiziksel sistemin Monte Carlo simülasyonunun başarısızlığını açıklayan ilginç bir referans:

A. Ferrenberg ve DP Landau. Monte Carlo Simülasyonları: "İyi" Rastgele Sayı Üreticilerinden Gizli Hatalar. Fiziksel İnceleme Mektupları 63 (23): 3382-3384, 1992.

Ferrenberg ve Landua'nın incelediği Ising modelleri, RNG'lerin iyi testleridir, çünkü kesin bir çözümle (2-B problemi için) karşılaştırabilir ve rakamlarda çıkış yollarını bulabilirsiniz. Bu modeller, çok fazla zorluk çekmeden eski moda 32 bit aritmetik PMMLCG'deki hataları göstermelidir.

Bir başka ilginç referans:

H. Bauke ve Stephan Mertens. Sözde Rastgele Paralar Kuyruklardan Daha Fazla Kafa Gösterir. arXiv: koşul-mat / 0307138 [koşul-mat.stat-mekanik]

Bauke ve Mertens ikili doğrusal geri besleme kaydırma yazmacı rasgele sayı üreteçlerine karşı güçlü bir dava oluşturur. Bauke ve Mertens'in bununla ilgili başka makaleleri var.

3D dağılım planında Marsaglia uçaklarını bulmak zor olabilir. Daha iyi bir görünüm elde etmek için çizimi döndürmeyi deneyebilirsiniz ve bazen sadece size açılırlar. Ayrıca istatistiksel tekdüzeliklerin 3D testlerini de yapabilirsiniz - daha eski 32 bit LCG'ler için, bunlar oldukça az sayıda kutuda başarısız olacaktır. örneğin, m = 2 ^ 31-1, a = 7 ^ 5 ile yaygın olarak kullanılan (ve daha önce iyi bilinen) PMMLCG için muntazamlık eksikliğini tespit etmek için 3 boyutta 20x20x20 ızgaralı bir teneke testi ile tekdüzelik testi yeterlidir.

Kullanmak mümkündür TestU01 paketi öğrenmek için PRNG testlerin hangi bu testlerin randbaşarısız olur. ( Test ürününe genel bakış için TestU01: Rastgele Sayı Üreticilerinin Ampirik Testi için AC Kütüphanesi'ne bakın .) Bu, Monte Carlo'nun kendi simülasyonlarına sahip olmaktan daha kolaydır. Bir bakıma, bu, yazılımın birleştirilebilirliği (ve yazılımın doğruluğu) sorunudur: küçük, basit testlerde iyi görünen bir PRNG göz önüne alındığında, patolojik davranışlarının daha büyük bir program tarafından tetiklenmeyeceğini nasıl anlarsınız?

İşte kod:

#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 paketi için 15'ten 3 başarısız olan 3 test vardır ( uzun açıklamalar ve tüm referanslar için TestU01'deki guidelongtestu01.pdf dosyasına bakın ; bunlar 10 testten 15 istatistiktir).

• $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}$

Bunların hepsinin "tipik" Monte Carlo simülasyonları olduğu varsayılarak (aklınızdaki problemler gibi olmasa da), sonuç, randbilinmeyen bazı alt kümelerin başarısız olmasıdır. Neden bu alt kümenin neden olduğunu bilmiyorum, bu yüzden kendi probleminizde çalışıp çalışmayacağını söylemek benim için imkansız.

MaxOft , açıklamanın ne kadar basit olduğu göz önüne alındığında, özellikle şüpheli görünüyor.

Crush takımındaki testler arasında rand140'tan 51'i başarısız oldu (96 testte 140 istatistik). Başarısız testlerden bazıları ( Fourier3 gibi ) bit dizeleri üzerinde yapılır, bu yüzden belki sizin için uygun olmayabilirler. Başarısız başka ilginç bir testtir GCD'yı iki rasgele sayının GCD'nın dağılımı test eder. (Yine, bu testin neden başarısız olduğunu veya simülasyonunuzun bundan muzdarip olup olmayacağını bilmiyorum.)

Not : Dikkat edilmesi gereken başka bir şey , MRG32k3a gibi rand()tüm SmallCrush , Crush , BigCrush testlerini başarıyla geçen bazı PRNG'lerden daha yavaş olmasıdır (yukarıdaki L'Ecuyer ve Simard belgesine bakın).