Chất lượng của các bộ tạo cộng tuyến tính cho các số ngẫu nhiên

Tôi đang thực hiện một số mô phỏng của phương trình Langevin, cho các lực bên ngoài khác nhau. Được biết rằng C rand()từ stdlib.hcó thể giới thiệu sự thiên vị trong kết quả của tôi, tôi đang sử dụng Mersenne Twister.

Tuy nhiên, tôi muốn biết (và xem) chính xác loại lỗi mà trình tạo cộng hưởng tuyến tính có thể gây ra trong mô phỏng của tôi. Đây là những điều mà tôi đã thử:

• Tạo các bộ dữ liệu 3D của randoms để thử xem hyperplanes. Tôi không thể nhìn thấy bất cứ điều gì.
• Làm FFT của một vectơ lớn các số ngẫu nhiên. Nó gần như giống nhau cho cả Mersenne Twister và rand().
• Kiểm tra nguyên lý trang bị cho một hạt trong chuyển động Brown. Cả hai nhà tích hợp đều đồng ý về giá trị mong đợi của với cùng một số chữ số có nghĩa.$\langle \text{KE}\rangle=\frac{1}{2}k_BT$
• Xem làm thế nào họ bin tốt trong một số thùng không phải là một sức mạnh hai. Cả hai đều cho kết quả định tính như nhau, không ai tốt hơn.
• Nhìn vào các đường dẫn Brown để thấy các phân kỳ rõ ràng từ . Một lần nữa, không có may mắn.$\langle x\rangle = 0$
• Phân phối các điểm trong một vòng tròn. Đầy, và chỉ trong chu vi. Giữa tất cả họ và giữa những người hàng xóm gần nhất (câu trả lời của Shor, bên dưới trong phần bình luận). Có sẵn trong ý chính này , chỉ cần chạy nó với Julia 0.5.0 sau khi cài đặt các thư viện cần thiết (xem ý chính để biết hướng dẫn).

Tôi muốn nhấn mạnh rằng tôi đang tìm kiếm sự thiên vị được giới thiệu trong bối cảnh mô phỏng vật lý. Ví dụ, tôi đã thấy rand()các bài kiểm tra cực đoan thất bại trong khi Mersenne Twister không thành công, nhưng hiện tại điều đó không có ý nghĩa quá lớn đối với tôi.

Bạn có bất kỳ ví dụ cụ thể, cụ thể nào về cách một trình tạo số ngẫu nhiên xấu phá hỏng mô phỏng Montecarlo không?

Lưu ý: Tôi đã thấy PRNG như thế nào RANDUcó thể khủng khiếp. Tôi quan tâm đến các ví dụ không rõ ràng, về các máy phát điện trông vô tội nhưng cuối cùng lại đưa ra sự thiên vị.

Một tài liệu tham khảo thú vị mô tả sự thất bại của mô phỏng hệ thống vật lý Monte Carlo do RNG không đủ (mặc dù họ không sử dụng LCG) là:

A. Ferrenberg và DP Landau. Mô phỏng Monte Carlo: Lỗi ẩn từ Trình tạo số ngẫu nhiên "Tốt". Thư đánh giá vật lý 63 (23): 3382-3384, 1992.

Các mô hình Ising mà Ferrenberg và Landua đã nghiên cứu là các thử nghiệm tốt về RNG vì bạn có thể so sánh với một giải pháp chính xác (đối với bài toán 2 chiều) và tìm ra các lỗi trong các chữ số. Các mô hình này sẽ hiển thị các lỗi trong một PMMLCG số học 32 bit lỗi thời mà không gặp quá nhiều khó khăn.

Một tài liệu tham khảo thú vị khác là:

H. Bauke và Stephan Mertens. Tiền giả ngẫu nhiên cho thấy nhiều người đứng đầu hơn đuôi. arXiv: cond-mat / 0307138 [cond-mat.stat-mech]

Bauke và Mertens tạo ra một trường hợp mạnh mẽ chống lại các bộ tạo số ngẫu nhiên theo kiểu thanh ghi phản hồi tuyến tính nhị phân. Bauke và Mertens có một số giấy tờ khác liên quan đến điều này.

Có thể khó tìm thấy các máy bay Marsaglia trong một âm mưu phân tán 3D. Bạn có thể cố gắng xoay cốt truyện để có cái nhìn rõ hơn và đôi khi chúng sẽ bật ra khỏi bạn. Bạn cũng có thể thực hiện các bài kiểm tra 3D về tính đồng nhất thống kê - đối với các LCG 32 bit cũ hơn, những điều này sẽ thất bại ở số lượng thùng khá nhỏ. ví dụ: kiểm tra tính đồng nhất với lưới thùng 20x20x20 ở 3 chiều là đủ để phát hiện sự thiếu đồng nhất đối với PMMLCG được sử dụng rộng rãi (và được xem xét trước đó) với m = 2 ^ 31-1, a = 7 ^ 5.

Có thể sử dụng bộ thử nghiệm PRNG của TestU01 để tìm ra thử nghiệm nào trong số những thử nghiệm đó randkhông thành công. (Xem TestU01: Thư viện AC để kiểm tra theo kinh nghiệm về các bộ tạo số ngẫu nhiên để biết tổng quan về bộ thử nghiệm.) Điều đó dễ dàng hơn so với việc mô phỏng Monte Carlo của chính mình. Theo một cách nào đó, đó cũng là một câu hỏi về khả năng kết hợp phần mềm (và tính chính xác của phần mềm): đưa ra một PRNG có vẻ hoạt động tốt trong các thử nghiệm nhỏ, đơn giản, làm thế nào để bạn biết các hành vi bệnh lý của nó sẽ không được kích hoạt bởi một chương trình lớn hơn?

Đây là mã:

#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;
}

Đối với bộ SmallCrush , có 3 thử nghiệm không thành công trong số 15 thử nghiệm (xem guidelongtestu01.pdf trong TestU01 để biết mô tả dài và tất cả các tham chiếu; đây là 15 thống kê từ 10 thử nghiệm).

• BirthdaySpacings : bin vectơ chiều vào thùng, tạo đếm bin, , sau đó số lượng các vụ va chạm giữa các sau khoảng một phân phối nổi tiếng.t d t d t tôi 1 , ... { Tôi j + 1 - Tôi j$n$ $t$$d^t$$d^t$$I_1,\ldots$$\{I_{j+1}-I_j\}$

• Va chạm : tạo chiều vectơ trong , thùng chúng vào bằng hypercubes, và đếm số lượng các va chạm.t [ 0 , 1 ) t d $n$ $t$$[0,1)^t$$d^t$

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

Giả sử đây là tất cả các mô phỏng Monte Carlo "điển hình" (mặc dù chúng có thể không giống như các vấn đề bạn gặp phải), kết luận là đã randthất bại một số tập hợp con chưa biết của chúng. Tuy nhiên, tôi không biết tại sao cụ thể là tập hợp con đó, vì vậy tôi không thể nói liệu nó có hoạt động với vấn đề của bạn hay không.

MaxOft có vẻ đặc biệt đáng ngờ, được đưa ra cách mô tả đơn giản.

Trong số các thử nghiệm trong bộ Crush , đã randthất bại 51 trên 140 (thống kê 140 trong 96 thử nghiệm). Một số thử nghiệm thất bại (như Fourier3 ) được thực hiện trên chuỗi bit, vì vậy có lẽ chúng không liên quan đến bạn. Một thử nghiệm tò mò khác không thành công là GCD , thử nghiệm phân phối GCD của hai số nguyên ngẫu nhiên. (Một lần nữa, tôi không biết tại sao thử nghiệm cụ thể này thất bại hoặc liệu mô phỏng của bạn sẽ bị điều này.)

PS : Tuy nhiên, một điều khác cần lưu ý là rand()thực sự chậm hơn một số PRNG đã vượt qua tất cả các bài kiểm tra SmallCrush , Crush , BigCrush , chẳng hạn như MRG32k3a (xem bài viết về Giấy phép & Simard ở trên).