Numpy: Numpy가 제공하는 PCG 구현에는 중요하고 위험한 자기 상관 관계가 있습니다.

@imneme, @bashtage, @rkern 여기 당국 될 것이다, 그러나 나는 우리가이 이상 갈 생각하고 우리가 선호하는 이유는 SeedSequence.spawn 오버 인터페이스 jumped 를. 예를 들어 API에 대해 논의 할 https://numpy.org/devdocs/reference/random/parallel.html 여기에서 조언을 확인하고 필요에 따라 개선 사항을 제안하십시오.

@mattip 이것은 점프와 관련이 없습니다.

개선 된 문서화는 항상 좋은 생각이지만 실제로는 전체적으로 변경하기가 어렵다고 생각합니다.

AES-NI를 사용하는 사람에게는 AESCounter 을, 고도의 병렬 설정이없는 사람에게는 SPECK128 를 권장합니다.

가산 상수를 변경하여 LCG에 의해 생성 된 시퀀스는 부호 변경과 가산 상수 모듈로 모두 동일하기 때문에 다른 "스트림"에서도 동일한 일이 발생할 수 있습니다.

이것을 정량화 할 수 있습니까? 동일한 증분을 사용하여 실패를 복제 할 수 있지만 증분과 상태를 시드하고 두 개의 다른 임의 증분으로 실패를 아직 관찰하지 않았습니다. 증분도 신중하게 구성해야하는 경우 실제 생일 충돌 빈도에 영향을줍니다.

https://gist.github.com/rkern/f46552e030e59b5f1ebbd3b3ec045759

❯ ./pcg64_correlations.py --same-increment | stdbuf -oL ./RNG_test stdin64 -tf 2 -te 1 -tlmaxonly -multithreaded
0x56b35656ede2b560587e4251568a8fed
0x93526034ed105e9e587e4251568a8fed
[
    {
        "bit_generator": "PCG64",
        "state": {
            "state": 115244779949650410574112983538102603757,
            "inc": 137507567477557873606783385380908979143
        },
        "has_uint32": 0,
        "uinteger": 0
    },
    {
        "bit_generator": "PCG64",
        "state": {
            "state": 195824235027336627448689568147458133997,
            "inc": 137507567477557873606783385380908979143
        },
        "has_uint32": 0,
        "uinteger": 0
    }
]
RNG_test using PractRand version 0.93
RNG = RNG_stdin64, seed = 0x4bf19f7b
test set = expanded, folding = extra

rng=RNG_stdin64, seed=0x4bf19f7b
length= 128 megabytes (2^27 bytes), time= 3.0 seconds
  Test Name                         Raw       Processed     Evaluation
  BCFN_FF(2+0,13-3,T)               R= +59.9  p =  3.8e-28    FAIL !!!       
  BCFN_FF(2+1):freq                 R= +89.0  p~=   6e-18     FAIL !         
  BCFN_FF(2+2):freq                 R= +39.6  p~=   6e-18     FAIL !         
  BCFN_FF(2+3):freq                 R= +14.6  p~=   6e-18     FAIL !         
  BCFN_FF(2+4):freq                 R= +10.3  p~=   5e-11   very suspicious  
  DC6-9x1Bytes-1                    R=  +7.1  p =  5.6e-4   unusual          
  DC6-6x2Bytes-1                    R= +18.9  p =  1.0e-10   VERY SUSPICIOUS 
  DC6-5x4Bytes-1                    R= +11.2  p =  1.4e-6   suspicious       
  [Low4/16]BCFN_FF(2+0):freq        R= +19.5  p~=   6e-18     FAIL !         
  [Low4/16]FPF-14+6/16:all          R=  +5.6  p =  1.0e-4   unusual          
  [Low4/16]FPF-14+6/4:all           R=  +5.9  p =  4.6e-5   unusual          
  [Low4/32]BCFN_FF(2+0):freq        R=  +6.5  p~=   2e-5    unusual          
  [Low8/32]BCFN_FF(2+0):freq        R= +15.1  p~=   6e-18     FAIL !         
  [Low8/32]FPF-14+6/32:all          R=  +8.4  p =  2.5e-7   very suspicious  
  [Low8/32]FPF-14+6/32:all2         R=  +9.0  p =  7.8e-5   unusual          
  [Low8/32]FPF-14+6/16:(0,14-0)     R= +12.4  p =  4.5e-11   VERY SUSPICIOUS 
  [Low8/32]FPF-14+6/16:all          R= +15.5  p =  5.2e-14    FAIL           
  [Low8/32]FPF-14+6/16:all2         R= +41.4  p =  2.6e-16    FAIL !         
  [Low8/32]FPF-14+6/4:(0,14-0)      R=  +6.9  p =  5.9e-6   unusual          
  [Low8/32]FPF-14+6/4:all           R=  +7.9  p =  6.6e-7   suspicious       
  ...and 871 test result(s) without anomalies

알겠습니다. 다시 시도하겠습니다.

2의 거듭 제곱 모듈러스를 가진 LCG에는 다중 스트림이 없습니다. 많은 사람들이 초기에 그것을 믿었고 그 "흐름"으로 흥미로운 일을한다고 주장하는 긴 오래된 논문도 있지만, 상수를 변경하여 얻은 궤도는 _ 모두 동일한 모듈로 첨가제라는 것이 수십 년 동안 알려져 왔습니다. 상수 및 아마도 부호 change_. 내가 추적 할 수있는 가장 먼 것은

Mark J. Durst, 병렬 난수 생성을 위해 선형 합동 생성기 사용,
1989 Winter Simulation Conference Proceedings, IEEE Press, 1989, pp. 462–466.

그래서 다른 프로그램 http://prng.di.unimi.it/corrpcgnumpy.c를 작성 하여 설정할 수 있습니다.

• PRNG의 초기 상태입니다.
• 다른 PRNG의 초기 상태입니다.
• 첫 번째 PRNG에 대한 임의의 "스트림 상수"입니다.
• 두 번째 PRNG에 대한 임의의 "스트림 상수"(둘 다 짝수 또는 둘 다 홀수 여야합니다.이 제한은 약간의 추가 조작으로 제거 할 수 있음).
• 기본적으로 첫 번째 PRNG의 동일한 비트로 시작하는 방식으로 두 번째 PRNG에 적대적으로 설정할 고정 된 하위 비트 수입니다. 나머지 비트는 제공 한 두 번째 PRNG의 초기 상태에서 가져옵니다.

그래서 이것은 _ 정확하게 _ 첫 번째 프로그램의 설정이지만, 상수를 선택할 수도 있습니다.

./corrpcgnumpy 0x596d84dfefec2fc7 0x6b79f81ab9f3e37b 0xac9c8abfcb89f65f 0xe42e8dff1c46de8b 0x8d7deae9efec2fc7 0x6b79f81ab9f3e37b 0x06e13e5e8c92c843 0xf92e8346feee7a21 56 | stdbuf -oL ~/svn/c/xorshift/practrand/RNG_test stdin -tf 2 -te 1 -tlmaxonly -multithreaded

rng=RNG_stdin, seed=unknown
length= 4 gigabytes (2^32 bytes), time= 113 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low1/8]BCFN(0+0,13-1,T)          R= +27.2  p =  4.0e-14    FAIL
  [Low1/8]DC6-6x2Bytes-1            R= +10.9  p =  4.4e-6   suspicious
  [Low1/64]DC6-5x4Bytes-1           R=  -6.4  p =1-1.4e-4   unusual
  [Low8/64]FPF-14+6/64:(0,14-0)     R=  +8.4  p =  2.2e-7   mildly suspicious
  [Low8/64]FPF-14+6/64:all          R=  +8.7  p =  1.2e-7   suspicious
  [Low8/64]FPF-14+6/32:(0,14-0)     R= +10.2  p =  5.1e-9   suspicious
  [Low8/64]FPF-14+6/32:all          R=  +9.4  p =  2.7e-8   very suspicious
  [Low8/64]FPF-14+6/16:all          R=  +5.8  p =  6.4e-5   unusual
  ...and 1439 test result(s) without anomalies

따라서 _ 최소 _ 2 ^ 72 개의 상관 된 하위 시퀀스가 ​​있습니다. "스트림 상수"를 선택하는 방법에 상관없이 동일한 상수의 경우와 똑같습니다.

그리고 우리는 제너레이터에 엄청나게 느슨해졌습니다. 정확한 시작점 대신에 당신이 조금 전후의 상태를 사용한다고 계산하더라도 상관 관계는 어쨌든 나타날 것입니다. 이를 위해 추가 매개 변수를 사용하여 프로그램을 쉽게 수정할 수 있습니다.

다시 한 번 반복합니다. 과학 문헌에 나온 기존의 현대 발전기에는 이러한 잘못된 동작이 없습니다 (물론 2의 거듭 제곱 LCG에는이 동작이 있지만, 제발 현대식 발전기는 _ 아닙니다).

PCG에 대한 Sabastiano의 비판은 2018 년 이 블로그 게시물 에서 다룹니다.

짧은 버전은 특정 시드를 구성 할 수있는 경우 거의 모든 PRNG에서 "나쁜 모양"동작을 보여줄 수 있다는 것입니다. PCG가 어떻게 든 독특하다는 그의 주장에도 불구하고, 실제로 PCG는 꽤 전통적입니다. PCG의 스트림은 널리 사용되는 또 다른 PRNG 인 SplitMix보다 나쁘지 않습니다.

그것은 완전히 거짓입니다. 내가 틀렸다는 것을 증명하기 위해 MRG32k3a 또는 xoshiro256 ++에서 두 개의 상관 관계가없는 중첩 시퀀스를 보여줍니다.

나는 겹치지 않는다고 말한 적이 없다. xoshiro256 ++에 대해 현재 사용 가능한 테스트를 보여주세요. 두 씨앗이 겹치지 않도록합니다.

대조적으로, 나는 당신이 보여준 "상관 관계"가 본질적으로 겹침의 한 형태임을 보여주는 PCG에 대한 테스트를 가지고 있습니다.

"본질적으로"및 "양식"처럼 FUD와 싸울 수는 없지만 처음에는 각 PRNG를 100 억 번 반복하고 오류와 함께 종료되도록 http://prng.di.unimi.it/intpcgnumpy.c를 수정했습니다. 생성 된 시퀀스가 ​​다른 PRNG의 초기 상태를 순회하는 경우 메시지. 이렇게하면 Practrand로 들어오는 처음 160GB의 데이터가 겹치지 않는 시퀀스에서 나옵니다.

./intpcgnumpy 0x596d84dfefec2fc7 0x0579f81ab9f3e37b 0x8d7deae980a64ab0 0x6c79f81ab9f3e37b | stdbuf -oL ~/svn/c/xorshift/practrand/RNG_test stdin -tf 2 -te 1 -tlmaxonly -multithreaded
[...]
rng=RNG_stdin, seed=unknown
length= 64 gigabytes (2^36 bytes), time= 926 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low1/8]FPF-14+6/64:(0,14-0)      R=  +8.8  p =  8.7e-8   mildly suspicious
  [Low1/8]FPF-14+6/64:all           R=  +6.3  p =  2.1e-5   unusual          
  [Low1/16]FPF-14+6/64:(0,14-0)     R=  +7.6  p =  1.1e-6   unusual          
  [Low1/16]FPF-14+6/64:(1,14-0)     R=  +8.3  p =  2.9e-7   mildly suspicious
  [Low1/16]FPF-14+6/64:all          R=  +8.0  p =  5.8e-7   suspicious       
  [Low1/16]FPF-14+6/32:all          R=  +7.1  p =  3.9e-6   mildly suspicious
  [Low1/64]FPF-14+6/32:cross        R=  +7.1  p =  2.6e-6   mildly suspicious
  [Low4/32]FPF-14+6/64:(0,14-0)     R= +13.5  p =  4.3e-12   VERY SUSPICIOUS 
  [Low4/32]FPF-14+6/64:all          R=  +9.0  p =  5.9e-8   very suspicious  
  [Low4/64]FPF-14+6/64:(0,14-0)     R= +11.4  p =  3.8e-10  very suspicious  
  [Low4/64]FPF-14+6/64:all          R=  +8.0  p =  5.3e-7   suspicious       
  [Low4/64]FPF-14+6/32:(0,14-0)     R= +10.3  p =  3.6e-9   suspicious       
  [Low4/64]FPF-14+6/32:all          R=  +6.1  p =  3.2e-5   unusual          
  [Low8/64]FPF-14+6/64:(0,14-0)     R= +18.6  p =  8.4e-17    FAIL           
  [Low8/64]FPF-14+6/64:(1,14-0)     R= +11.4  p =  3.9e-10  very suspicious  
  [Low8/64]FPF-14+6/64:(2,14-0)     R=  +8.3  p =  2.8e-7   mildly suspicious
  [Low8/64]FPF-14+6/64:all          R= +15.3  p =  6.9e-14    FAIL           
  [Low8/64]FPF-14+6/32:(0,14-0)     R=  +7.8  p =  7.1e-7   unusual          
  [Low8/64]FPF-14+6/32:(1,14-0)     R=  +7.2  p =  2.7e-6   unusual          
  [Low8/64]FPF-14+6/32:all          R=  +5.8  p =  6.9e-5   unusual          
  ...and 1786 test result(s) without anomalies

이 특정 초기화 데이터에는 56 개의 하위 고정 비트가 있으므로 상위 비트를 뒤집어 2 ^ 72 개의 상관 시퀀스를 생성 할 수 있습니다. 통계적 오류는 64GB의 데이터 후에 발생하며 중복이 상관 관계에 대한 책임이 없음을 보여줍니다. 물론 64GB 이전에 다른 특정 대상 선택 항목과 중복이 발생할 수 있습니다. 이것은 특정 예입니다. 그러나 이제는 겹침이 문제가 아니라는 것을 쉽게 확인할 수 있습니다. 생성기에 바람직하지 않은 내부 상관 관계가 많이 있습니다.

행동 강령을 존중하십시오. 귀하의 의견은 "공감, 환영, 친절, 인내"및 "우리가 선택한 단어에주의하십시오. 우리는 의사 소통에주의하고 존중합니다"라는 지침에 따라 어조로 유지하십시오.

나는 겹치지 않는다고 말한 적이 없다. xoshiro256 ++에 대해 현재 사용 가능한 테스트를 보여주세요. 두 씨앗이 겹치지 않도록합니다.

음, 그것은 사소한 일입니다. 스트림의 길이를 결정하고, 반복하고, 두 스트림이 초기 상태를 넘지 않는지 확인합니다. http://prng.di.unimi.it/intpcgnumpy.c 프로그램에서 상호 관련된 PCG 스트림을 표시하는 데 사용한 것과 동일한 코드가 겹치지 않습니다.

PCG가 어떻게 든 독특하다는 그의 주장에도 불구하고, 실제로 PCG는 꽤 전통적입니다. PCG의 스트림은 널리 사용되는 또 다른 PRNG 인 SplitMix보다 나쁘지 않습니다.

IMHO, PCG 내의 자기 상관 관계는 훨씬 더 나쁩니다. LCG에 대한 Durst의 극적인 1989 결과와 유사한 SplitMix 인스턴스의 기반이되는 첨가제 생성기에 대한 결과는 없습니다.

그러나 SplitMix의 매우 가벼운 문제가 알려져 있으며 JEP 356 은 이러한 문제를 해결하기 위해 새로운 종류의 분할 가능 생성기 LXM을 제공 할 것입니다. PCG도 결함이 덜한 것으로 이동하여 교체해야 할 때입니다.

근본적인 문제는 두 생성기 모두에 대해 알려져 있으며 상태 혼합이 부족하기 때문입니다. 이러한 생성기 중 하나의 상태에서 비트 _k_를 변경하면 변경 사항이 비트 _k_ 아래로 전파되지 않습니다. 이것은 프라임 모듈러스를 가진 LCG, F₂- 선형 생성기, CMWC 생성기 등에서 발생하지 않습니다. 다른 모든 생성기는 가능한 한 빨리 상태를 혼합하려고합니다.

PCG와 SplitMix의 문제를 동일시하는 것은 붉은 청어입니다. SplitMix는 매우 간단한 기본 생성기를 가지고 있으며 단지 추가 기능이지만 그 위에 매우 강력한 스크램블링 기능이 있습니다.이 기능은 Appleby의 MurmurHash3 해시 함수에 대한 64 비트 종료 자입니다. Stafford (http://zimbry.blogspot.com/2011/09/better-bit-mixing-improving-on.html)에 의해 개선되었습니다. 함수의 상수는 구체적이고 측정 가능한 눈사태 속성을 갖도록 훈련되었습니다. 적은 수의 비트 변경조차도 모든 출력에 퍼지는 경향이 있습니다. 즉, SplitMix는 거인의 어깨 위에 서 있습니다.

반대로 LCG 기반 PCG 생성기는 동일한 혼합 부족 문제를 가지고 있지만 스크램블링 기능은 이론적 또는 통계적 보장없이 저자가 조립 한 간단한 산술 및 논리 연산 시퀀스 일뿐입니다. 기본 LCG의 모든 시퀀스가 ​​동일한 모듈로 덧셈 상수 및 부호 변경이라는 사실을 고려하여 고안 되었다면 문제를 해결할 수 있었을 것입니다.

그러나 저자는 시퀀스가 ​​서로 쉽게 파생 될 수 있다는 것을 전혀 몰랐습니다. 이는 PCG 기술 보고서 ​​(https://www.pcg-random.org/pdf/hmc-cs-2014-0905.pdf)의 섹션 4.2.3에있는 다음 성명에서 쉽게 확인할 수 있습니다.

"_c_를 선택할 때마다 다른 시퀀스와 공통된 연속 출력 쌍이없는 다른 숫자 시퀀스가 ​​생성됩니다."

이것은 시퀀스가 ​​다르다는 증거, 즉 기본 LCG가 여러 스트림을 제공한다는 증거로 간주됩니다. 이 주제에 대한 Durst의 1989 부정적인 결과는 논문 어디에도 나타나지 않습니다. 앞서 언급했듯이 이러한 결과에 따르면 이러한 모든 시퀀스는 동일하고 모듈로 가산 상수 및 부호 변경 일 수 있습니다 (PCG에서 발생하는 최대 효능의 2 승 모듈러스를 가진 LCG의 경우).

Durst의 결과를 인용하는 것은 _ 진짜 _ 실수라고 확신합니다.하지만 문제는 사용중인 기본 LCG가 어떤 의미에서 "다른" "스트림"을 제공한다고 확신하면 그렇지 않은 경우 결국 PCG와 같은 생성기를 사용하면 "스트림"을 변경하더라도 각 하위 시퀀스에 대해 2 ^ 72 개의 겹치지 않는 상관 하위 시퀀스가 ​​있습니다.

귀하의 의견에 감사드립니다. 현재로서는 "PCG가 좋다 / 나쁘다"와 같은 이진 판단에 관심이 없습니다. 이러한 토론에는 자신의 포럼을 사용하십시오. 여기서 주제는 numpy가 할 일이며 최종 판단은 numpy 개발자에게 있습니다. 우리는 여러분 모두가이 토론에 제공 한 전문 지식에 감사하지만 최종 판단보다는 근본적인 사실에 초점을 맞추고 싶습니다. 특히 우리가 가지고있는 여유 공간에 대한 아이디어를 제공하는 정량적 진술에 감사드립니다. 이전 판단이 틀렸다면 너무 빨리 판단에 뛰어들었기 때문에 다시 피할 수 있도록 도와 주시면 감사하겠습니다. 감사합니다.

두 개의 생성기가 두 개의 상관 된 시드 (무작위로 선택됨)에서 시작될 확률을 50 % 더 얻으려면 무작위로 시작하는 약 50 만 개의 생성기가 필요합니다 (생일 패러독스).

@vigna 이 계산 방법을 2**(n/2) 항목에서 n -비트 충돌의 50 % 확률을 제공합니다 (2의 인수를 주거나 받음). 50 만 달러는 2**19 이므로 위험한 상관 관계가 하위 비트의 약 40 비트 충돌에서 시작한다고 주장하는 것처럼 보이지만 실제로 관찰 할 수 있다는 증거를 보지 못했습니다. 하위 40 비트를 공유하는 쌍을 테스트하고 테스트를 취소하기 전에 PractRand에서 16TiB에 도달했습니다. 40 비트 충돌로 인한 오류를 관찰 한 경우이를 확인하기 위해 몇 TiB를 테스트해야 했습니까?

증분을 변경해도 충돌 가능성에 영향을 미치지 않는다고 확신합니다. "PCG 스트림"의 장점에 대한 추가 논의는 주제를 벗어납니다. 이 토론을 "저자"에 대해 반복적으로 망치는 핑계로 사용하는 것은 특히 반갑지 않으며 우리 의 행동 강령을 위반 합니다. 지속한다는 것은 귀하의 입력없이 진행해야 함을 의미합니다. 감사합니다.

@imneme 이것은 2의 큰 거듭 제곱의 배수로 점프하는 문제와 관련된 것 같습니다. 동일한 증분으로 한 쌍의 PCG64 인스턴스를 구성하고 낮은 n 공유 할 때 비트, 내가 계산하는 거리는 1 << n 의 배수입니다. 더 강력한 DXSM 출력 함수 도이 현상을 해결하는 것으로 보입니다. 증분과 하위 64 비트 상태를 문제없이 2TiB까지 공유하는 한 쌍의 PCG64DXSM 인스턴스를 테스트했습니다.

좋아요, 이것은 당황 스럽습니다. 그것은 5 백만 달러가 아니라 5 억 달러였습니다. 한 글자가 큰 차이를 만들 수 있습니다. 전표에 대해 사과드립니다.

그러나 앞서 말했듯이 이것은 정확히 동일한 시작 상태에 도달 할 확률이지 상관 된 하위 시퀀스가 ​​상당히 겹칠 확률이 아닙니다. 개인적으로 저는 PRNG를 상관 관계가없는 하위 시퀀스없이 사용하는 것을 선호합니다. 그 이유는 그 수가 많기 때문입니다. 그러나 귀하가 올바르게 말했듯이 결정은 귀하의 것입니다.

더 나은 믹싱 속성을 갖도록 스크램블링 기능을 수정하는 것은 완벽하게 합리적인 해결책처럼 들립니다.

내 게시물은 PCG와 SplitMix의 구조적 차이점을 설명하기위한 것일뿐입니다. 이전 게시물에서 비슷한 문제가 있다고 주장했기 때문에 이것이 올바른 진술이라고 생각하지 않습니다. SplitMix에 대해 http://prng.di.unimi.it/corrpcgnumpy.c 와 같은 프로그램을 작성할 수 없습니다.

@rkern , 당신은 물었습니다 :

@imneme 이것은 2의 큰 힘의 배수로 점프하는 문제와 관련된 것 같습니다. 동일한 증분으로 한 쌍의 PCG64 인스턴스를 구성하고 낮은 n 공유 할 때 비트, 둘 사이의 거리는 1 << n 의 배수입니다. 더 강력한 DXSM 출력 함수 도이 현상을 해결하는 것으로 보입니다. 증분과 하위 64 비트 상태를 문제없이 2TiB까지 공유하는 한 쌍의 PCG64DXSM 인스턴스를 테스트했습니다.

작년의 토론 스레드를 찾아 다시 연결해 주셔서 감사합니다. 예, Sebastiano가 답변에서 언급했듯이

더 나은 믹싱 속성을 갖도록 스크램블링 기능을 수정하는 것은 완벽하게 합리적인 해결책처럼 들립니다.

XSL-RR은 더 약한 것입니다. 반대로 PCG 논문의 원래 RXS-M 출력 기능과 새로운 DXSM 출력 기능은 모두 스크램블링 방식으로 더 많은 작업을 수행하므로 이러한 종류의 문제를 표시하지 않습니다. DXSM (작년 에이 커밋 에서 PCG 소스에 추가됨)은 XSL-RR보다 더 강력하지만 유사한 시간 성능을 갖도록 특별히 설계되었습니다 (참조 : RXS-M, 더 느림). 작년에 DXSM을 상당히 열심히 테스트했지만 67 일 동안 서버를 중단하고 (UPS 배터리가 소모 됨) 테스트 실행을 종료하는 연장 된 정전이 있었지만 그 시점에서 두 가지 모두에서 꽤 잘 입증되었습니다. 테스트 (128TB의 출력 테스트) 및 2 ^ 48의 점프 (64TB의 출력 테스트는 느리게 실행되기 때문에).

DXSM을 설계하지 않았더라도 RXS-M이 문제를 해결했다면, 한 가지 질문은 왜 제가 약한 XSL-RR 순열을 대신 사용했는지입니다. 출력 함수에서 항상 매우 강력한 비트 스크램블링을 사용하지 않는 이유는 무엇입니까? 대답은 기본적으로 주기로 귀결된다는 것입니다. 속도는 사람들에게 중요하므로 필요한 것보다 훨씬 더 많은 스크램블링을 피하려고합니다.

이것은 그의 접근 방식과 나의 공통점이 많기 때문에 Sebastiano가 친숙한 문제입니다. 우리는 각각 현대 통계 테스트 (제 경우에는 LCG, 그의 경우에는 Marsaglia의 XorShift LFSR)에 실패하고이를 사용하기 위해 스크램블링 출력 기능을 추가하는 오랜 확립 된 접근 방식을 취합니다. 우리는 둘 다 그 출력 함수를 저렴하게 만들기 위해 노력하고 있지만, 그럼에도 불구하고 우리가 출력 함수로 마스킹하려는 기본 생성기의 결함이 드러나는 부분을 조금 발견했습니다. 그의 경우,의 를 통해 보여 주었다 선형성 문제 .

그러나 저를 많이 기쁘게하는 최근의 작업에서 그는 얼마나 많은 LFSR 기반 디자인이 출력 기능에 의해 부적절하게 가려지는 해밍 가중치 문제 (내 자신의 오랜 관심사를 반영 함)가 있는지도 보여주었습니다. 그의 발전기는 그의 테스트를 통과했습니다. 그래서 그것은 무언가입니다.하지만 2018 년 에 그의 새로운 xoshiro PRNG를보고 있었을 때 저에게 있어서는 언더 링 생성기의 해밍 가중치 문제가 그의 출력 함수를 통해 만든 것 같았습니다. 그는 이후 새로운 출력 기능으로 xoshiro를 수정했으며, 이것이 트릭을 수행하기를 바랍니다 (그는 다른 변경도 수행 했으므로이 테스트 프로그램 에서 강조한 반복 문제도 수정 했습니까?).

그의 상관 프로그램에 관해서는 2018 년에 그가 다양한 이슈 (예 : 인위적인 시드 등)로 작성한 프로그램을 포함하는 그의 웹 사이트에 PCG에 대한 비판을 올렸을 때 비슷한 프로그램이 많이 포함 된 답변 을 썼습니다 corrsplitmix2.c 를 포함하여 오랫동안 확립 된 PRNG의 경우. 세바스찬이 할 수 없다고 말했을 때 무슨 뜻인지 잘 모르겠지만, 그의 새로운 테스트 프로그램이 그의 테스트 프로그램과 실질적으로 다른지 확인하기 위해 그의 테스트 프로그램을 면밀히 살펴볼 기회가 없었습니다. 몇 년 전에 썼습니다.

저의 이해 부족을 용서해주십시오.하지만이 단계에서 누군가에게 요약 결론을 요청할 수 있습니까? 기본 PCG가 안전하지 않은 현실적 상황이 있습니까? 기본값을 전환하기위한 인수는 무엇입니까?

쉬운 경로는 고차원 (초고도) 응용 프로그램과 상관 시퀀스의 확률에 대한 문서를 추가하는 것입니다.

더 어려운 경로는 스트림을 중단시킬 출력 함수를 교체하는 것입니다. default_rng 약속이 얼마나 강력한 지 잘 모르겠습니다. 문서는 이것이 변경 될 수 있다고 경고하지 않는 것 같으므로 변경하려면 지원 중단주기가 필요할 수 있습니다. 이를 위해서는 새로운 출력 기능을 독립형 비트 생성기로 추가하고 (또는 PCG64에서 구성 할 수 있으며, 이는 더 합리적인) XXXX / 릴리스 Y.ZZ 이후에 변경 될 것이라고 사용자에게 경고해야합니다.

가장 어려운 경로는 새로운 기본 rng를 찾는 것입니다. 처음에는 쉽지 않았고 지난 18 개월 동안 바늘을 특정 방향으로 움직이기 위해 변경된 것이 없다고 생각합니다.

default_rng() 수정에 대해 gh-16493을 열었습니다.이 문제와 관련이 없다고 생각합니다. 논의해야 할지도 모르겠습니다. 아마도 이미 오래 전에 규칙을 정해 놓았을 것입니다. 기억하지 마십시오.

나는이 논의를 완전히 이해한다고 주장하지 않지만, 알아 내야 할 두 가지가있는 것 같습니다.

1. 우리가 충분한 진로를 가지고 있다는 것을 확신하고, 나는 이것에 대해 로버트를 신뢰해야하고 지금 당장 우리가 아는 한 그것이 괜찮을 것 같습니까? (즉, 실제 충돌 가능성은 NumPy가 사용될 수있는 어떤 것보다 큰 환경에서도 부끄럽게 낮을 것입니다. 미래에 기본값을 변경해야할지 여부는 다른 문제입니다.)

2. 우리는 다음과 같이 진술합니다.

   및 지원 [...] 및 : math : 2^{127} 스트림

   숫자의 출처를 정확히 알지 못하는 경우 우리 측에서 약간 과장된 것처럼 들리며 완벽하게 정확하도록 약간 조정 한 것으로 간주 할 수 있습니까? 또는 추가 세부 정보를 제공하는 외부 리소스에 대한 링크?

지금 가장 쉬운 방법은 "저렴한 승수"와 더 강력한 DXSM 출력 기능을 가진 PCG64의 변형 인 PCG64DXSM BitGenerator 를 추가하는 것입니다. 모든 사람들이 이것이 현재 PCG64 구현에있는 XSL-RR 출력 함수에서 한 단계 올라간 것으로, 런타임 성능에 손상을주지 않고 통계적으로 더 나은 성능을 발휘한다는 데 동의한다고 생각합니다. 우리가 제공하는 BitGenerator 대해 PCG64 제공하는 틈새 시장에서의 간단한 업그레이드입니다. PCG64 와 함께 추가해야한다고 생각합니다.

덧붙여서, PCG64 생성자에 대한 옵션보다는 BitGenerator 라는 별도의 이름을 선호합니다. 이러한 옵션은 randomgen 에서 훌륭합니다. 그 목적은 다양한 알고리즘과 변형을 제공하는 것이지만 numpy 의 경우 선택 항목이 다음과 같이 "그랩 앤 고"가되기를 원합니다. 우리가 할 수있는 한 많이.

나는 우리가 default_rng() 제공하는 것을 변경하기위한 정책을 실제로 정하지 않았다고 생각합니다. 내가 그것을 제안했을 때, 나는 그 기능을 Generator() 생성자에 넣는 것보다 선호하는 이유 중 하나가 필요하다면 더 이상 사용하지 않고 다른 이름의 함수로 이동할 수 있다는 생각을 떠올 렸습니다. 그러나 그 당시 우리는 default_rng() 기본 BitGenerator 대한 많은 세부 정보를 노출해야 할 수 있다고 생각하고 있었지만 나중에 피했습니다. 때문에 PCG64DXSM 같은 API (노출 .jumped() 로 특히) PCG64 , 우리가 할 수있는 유일한 고려 사항은 새 기본값으로 사용하는 비트 스트림을 변경 것입니다. NEP 19 당 Generator 메서드 (즉, X.Y.0 기능 릴리스)에서 오는 스트림에 대한 다른 수정과 동일한 타임 라인을 따르는 것이 합리적이라고 생각합니다. 원하는 경우 조금 더 신중하게 선택할 수 있습니다. 먼저 1.20.0 및 문서에서 PCG64DXSM 를 사용 가능한 BitGenerator 로 노출합니다 ( warn() , 너무 시끄러워서 효과가 없음) default_rng() 는 1.21.0 에서 사용하도록 변경됩니다.

새 BG를 추가하는 과정에서 지침 역할을 시작하고 최신 변형을 선호하는 근거를 제공하기 위해 노트를 PCG64로 업데이트하는 것이 좋습니다.

1. 우리가 충분한 진로를 가지고 있다는 것을 확신하고, 나는 이것에 대해 로버트를 신뢰해야하고 지금 당장 우리가 아는 한 그것이 괜찮을 것 같습니까? (즉, 실제 충돌 가능성은 NumPy가 사용될 수있는 어떤 것보다 큰 환경에서도 부끄럽게 낮을 것입니다. 미래에 기본값을 변경해야할지 여부는 다른 문제입니다.)

그것은 아마도 너무 어리석은 것 같습니다. 스트림 수, 각 스트림에서 가져 오는 데이터의 양, 생일 충돌에 대한 위험 허용 범위에 따라 다릅니다. 아직 따라하기 쉬운 권장 사항을 만들기 위해 그 수학을 이해하기 쉬운 단락으로 처리하지 못했기 때문에 한동안이 Github 문제를 다시 검토하지 않았습니다. 그래도 _ 지금 당장 고쳐야 할 문제가 아니라고 생각합니다.

나중에 더 오래 쓸 것이지만,이 스레드에서 볼 때 우리는 작년에 다룬 땅을 다시 읽었습니다. Sebastiano가 NumPy가 PCG를 출시했다는 사실을 발견 한 것 외에는 아무것도 변하지 않았습니다. 작년 NumPy 팀의 분석은 더 심층적이었고 더 그럴듯한 시나리오를 고려했습니다.

내가 선호하는 것은 혼란을 줄이기 위해 가능한 한 빨리 기본값을 업그레이드하는 것입니다. 내 말은, 감가 상각주기를 기다리지 말라는 것입니다.

@imneme- 대단히 감사합니다-더 긴 것이 매우 유용하다는 것을 알게 될 것입니다.

아마도 그것에 대한 과거 게시물 폭발 은 이것입니다. 확실히 읽을만한 가치가 있다고 생각합니다. 여기에서 스레드에서 위로 스크롤하여 이러한 문제에 대해 이야기하는 것을 볼 수 있습니다. PCG 32 정도였습니다.

내가하고 싶은 말이 머릿속에 있었지만 1 년 전의 게시물을 보면 이미 여기와 다른 곳에서 모두 말한 적이 있습니다 ( 내 블로그 (2017), 레딧 , 내 블로그 다시 (2018)) , NumPy 토론 등)

스트림과 그 자체 유사성 ( @rkern 이 스트림 의존성 테스터 를 썼음 )에 대해 작년에 썼습니다.

앞서 언급 한 내 블로그 게시물 에서 언급했듯이 PCG의 스트림은 SplitMix와 많은 공통점이 있습니다.

@mdickinson 의 그래프 와 관련하여 카운터 기반 암호화를 포함하여 전체 상태를 시드 할 수있는 _every_ PRNG의 경우 출력이 어떤 방식 으로든 상관 관계가있는 PRNG가있는 시드를 만들 수 있습니다 (가장 쉬운 방법). 가까운 거리에있는 PRNG 상태를 만드는 것입니다.하지만 종종 작동 방식에 대한 이해를 바탕으로 다른 작업을 수행 할 수 있습니다.) 전체 상태 시드를 허용하지 않는 PRNG는이 문제를 피할 수 있지만, 그렇게하면 가능한 상태의 극히 일부에 대한 실질적인 액세스 만 제공하는 새로운 문제가 도입됩니다.

스트림을 생각하는 올바른 방법은 시드해야하는 더 임의의 상태입니다. 1,2,3과 같은 작은 값을 사용하는 것은 일반적으로 _any_ PRNG에 대한 시드 목적에 대해 나쁜 생각입니다 (모든 사람이 이러한 시드를 선호하면 해당 초기 시퀀스가 ​​과도하게 표현되기 때문입니다).

우리는 그것을 스트림이라고 부르지 않고 단지 상태라고 부를 수 있습니다. 이것이 Marsaglia가 XorWow 에서 한 counter 는 나머지 상태와 전혀 상호 작용하지 않으며 LCG와 마찬가지로 초기 값의 변형은 실제로 추가 된 상수에 해당합니다.

SplitMix, PCG 및 XorWow의 스트림은 "멍청한"스트림이라고 할 수 있습니다. 그들은 생성기의 사소한 재 매개 변수화를 구성합니다. 그러나 여기에는 가치가 있습니다. 스트림이 없으면 PRNG가 42의 흥미로운 근접 반복을 갖는다 고 가정합니다. 여기서 42는 빠르게 연속적으로 여러 번 자르고 42에 대해서만이 작업을 수행하고 다른 수는 없습니다. 어리석은 "단지 증분"또는 "단지 xor"스트림을 사용하면 실제로 이상한 반복을 42로 고정하는 것을 피할 수 있습니다. 모든 숫자는 그들이 이상하게 반복되는 스트림을 가지고 있습니다. (이러한 이유로 Xoshiro 256에서 반복되는 문제 를 복구

(I는 더 깊이 들어갔다 이 댓글 과에서 이것 .)

중요한 점은 거의 모든 PRNG의 경우 약간의 시간과 에너지로 병적 씨앗을 만들 수 있다는 것입니다. PCG는 손으로 만든 병리학 (예 : Sebastiano)이있는 PCG에 대해 그럴듯하게 보이는 시드 작업을 즐기는 사람이 있다는 다소 특이한 위치에 있습니다. 그 작업의 결과로 저는 그의 PRNG와 다른 오랜 기간 동안의 PRNG에 대해 똑같은 일을했습니다.

일반적으로 "무작위"로 보이는 것으로 PRNG 상태를 초기화하려고합니다. 사람들이 다른 방법을 원하더라도 그것은 매우 보편적입니다. 예를 들어 모든 LFSR PRNG (XorShift 스타일, Mersenne Twister 등)의 경우에는 그대로 유지되므로 모두 0 상태로 초기화해서는 안됩니다. 그러나 대부분이 0 인 상태조차도 LFSR (제로 랜드로 알려진 현상과 C ++ 사람들이 seed_seq 만든 이유)에 문제가되는 경우가 많습니다. "인위적인 시딩을 해보자"게임을하고 싶다면 100 개의 LFSR에 대한 초기화 컬렉션을 만들고 모두 제로 랜드를 치는 것으로부터 1K 떨어져 있도록하는 것이 어렵지 않습니다. 인위적인 초기화는 모두 순진 해 보이지만 동시에 해밍 가중치가 이상하게 떨어질 것입니다.

합리적인 엔트로피로 초기화 된 PCG 생성기를 사용하는 경우 괜찮습니다. 1, 2, 3과 같은 정크로 초기화하려면 실제로 PRNG에 문제가 있습니다. 그리고 PCG를 사용하면 99.9 %의 시간 동안 약간의 쓰레기를 사용하는 것도 괜찮습니다. LFSR이 가진 종류의 문제와 같은 것은 없습니다.

그러나 DXSM은 확실히 더 강력합니다. 나는 그것이 더 낫거나 만들지 않았을 것이라고 생각하지만, 약간의 관점을 가지고 실제로 사용자가 고전적인 PCG64 구현에서 문제에 부딪히지 않을 것이라는 것을 깨닫는 것은 가치가 있습니다.

나는 현재 논의에서 PCG64의 스트림 (LCG 증가를 통해)에 대한 비판 / 방어를 분리하고 싶습니다. LCG의 수학으로 인해 특정 이중성이 포함되어 있지만 원래 여기에서 제기 된 핵심 문제는 아닙니다. 또한 Sebastiano의 원래 비평 , 귀하의 답변 또는 오래된 메가 스레드보다 더 많은 세부 사항을 고려할 수 있습니다. 아마도 수학에 더 많은 시간을 투자 한 전문가들에게는 연관성이 더 분명 할 수 있지만, 적어도 실질적인 결과는 이제 나에게 더 분명해졌습니다.

중요한 점은 거의 모든 PRNG의 경우 약간의 시간과 에너지로 병적 씨앗을 만들 수 있다는 것입니다.

당연하지만, 내 앞에서 결정을 내릴 수있는 것은 바이너리가 아닙니다. 유한 PRNG에서 너무 많은 숫자를 그리면 결국 PractRand가이를 제거합니다. 이진 사실은 PRNG 알고리즘을 무효화하지 않습니다. 바이너리에서 벗어나 헤드 룸의 개념을 설정하는 것은 원래 PCG 논문에 대해 정말 감사하게 생각하는 것 중 하나였습니다. 적대적으로 생성 된 병리를 감안할 때, 그 병리가 좋은 엔트로피 시드에서 무작위로 발생하는 빈도를 볼 수 있습니다. 이를 수량화하여 사용자를위한 실용적인 조언으로 바꾸고 싶습니다.

하위 58 비트와 동일한 증분을 공유하는 두 개의 상태 (그 안에 핀을 넣을 것임)를 감안할 때 이러한 상태에서 PCG64 XSL-RR 인스턴스를 인터리빙하면 PractRand에서 약 32GiB에서 실제로 관찰 가능한 오류를 보여줍니다. 나는 그것을 피하고 싶은 것이 합리적이라고 생각합니다. 이제이를 벤치 마크로 삼아 좋은 엔트로피 시드로 얼마나 자주 발생하는지 살펴 보겠습니다. 다행스럽게도이 적대적인 계획은 확률 적 분석이 가능합니다 (모두가 그렇게 친근한 것은 아닙니다). n 인스턴스의 경우 동일한 하위 58 비트를 공유하는 2 개의 확률은 n**2 / 2**58 이며 이중 계산에 대해 2의 인수를 주거나받습니다. 따라서 5 억 개의 인스턴스에서 인터리브 될 경우 PractRand에 실패하는 페어링이 하나있을 가능성이 높습니다. 5 억은 많습니다! 제 판단으로는 PCG64 인스턴스를 많이 생성하려고 시도하는 numpy 프로그램을 결코 볼 수 없을 것입니다. numpy 는 잘못된 도구 일 수 있습니다.

또한 후속 그리기가 다른 초기 상태의 58 비트 하위 충돌 상태를 _cross_하는 초기 상태를 피하는 것이 합리적이라고 생각합니다. 나는 여전히 그것에 대한 논리를 생각하려고 노력하고 있지만 길이는 확률에 2 차적이 아닌 선형 적으로 영향을 미친다고 생각합니다. 내가 맞고 각 인스턴스 ( 2**28 드로우)에서 16GiB를 그리고 싶은 경우 ( 2**15 로만 작업 할 수 있습니다. numpy 프로그램은 XSL-RR 출력 함수와 함께 PCG64 를 사용하는 데 문제가있을 가능성이 없다고 생각합니다. 그러나 일부 애플리케이션은 가까워지기 시작할 수 있습니다 (예 : 대규모 분산 강화 학습 실행).

증분 핀을 꺼내어 해결해 봅시다. XSL-RR 출력 함수를 사용하면 상태에 추가로 증가분을 엔트로피 시드해도이 특정 분석이 변경되지 않는다고 말하는 것이 타당하다고 생각합니다. 주어진 엔트로피 시드 증분 쌍에 대해 실질적으로 충돌하는 상태의 수가 동일한 것 같습니다. 이러한 상태를 의도적으로 구성하는 구체적인 절차는 동일한 하위 58 비트에서 bashing하는 것보다 더 복잡해 보이지만 충돌 상태의 수가 동일한 것처럼 보이므로 확률 계산은 동일하게 유지됩니다. 이것은 일반적으로 PCG 체계에 내재 된 것이 아닙니다. DXSM 출력 기능은 (단순한 +2 만으로도) 증분을 변경하는 것만으로도 기본 LCG에 대한 최악의 상태 (거리 메트릭이 0 제공하는 경우)에도 저항 할 수있을만큼 충분히 강력 해 보입니다.

나는 우리 모두가 완전히 동의하는 것처럼 보이는 것을 반복하면서 끝내고 싶습니다. PCG64DXSM 은 좋은 생각입니다. 다른 것이 없다면, 그것의 개선 된 통계적 속성은 내가 문서화해야한다고 느끼는 정신적 모델을 단순화하고, 문서를 적게 작성해야한다는 것을 의미하는 것은 내 책에서 좋다.

동일한 스트림에 생성기가있는 경우에만 문제가 나타나기 때문에 스트림은 여전히 ​​다소 관련이 있습니다.

그러나 어떤 상황에서 동일한 하위 58 비트를 갖고 동일한 스트림에 있을까요? 이것이 일어날 수있는 사용 사례가 있습니까?

제가 아는 다소 현실적인 경우는 작년에 ( jumped 대해 이야기했을 때) 이야기 한 것이고, 제가 앞서 링크 한이 게시물 에서 이야기 한 것입니다.

동일한 스트림에 생성기가있는 경우에만 문제가 나타나기 때문에 스트림은 여전히 ​​다소 관련이 있습니다.

불행히도 XSL-RR의 경우는 그렇지 않습니다. 두 개의 PCG64 XSL-RR 인스턴스를 고려해 보겠습니다. 증분을 임의로 엔트로피 시드하고 상태 중 하나를 엔트로피 시드합니다. 동일한 하위 58 비트 상태 동일 증분 실패와 동일한 방식으로 PractRand에 실패하는 다른 PCG64 인스턴스에 대해 2**70 잘못된 상태를 구성 할 수 있습니다. 같은 증분의 경우보다 수행하는 것이 더 복잡합니다. 하위 58 비트를 다른 증분을 가진 첫 번째 상태로 공유하는 대신 첫 번째 인스턴스에서 0 거리 (LCG 거리 측정에 따라) 인 상태의 하위 58 비트를 공유하여 증분을 설명합니다. 건설적인 증거 (Python 코드)가 있지만 지금 자고 내일 청소해야합니다.

@rkern , 좋은 지적입니다. 나는 인정할 것이다, 나는 그것이 어떻게 작동하는지보기 위해 그 시나리오를 시험하지 않았다.

중요한 점은 거의 모든 PRNG의 경우 약간의 시간과 에너지로 병적 씨앗을 만들 수 있다는 것입니다. PCG는 손으로 만든 병리학 (예 : Sebastiano)이있는 PCG에 대해 그럴듯하게 보이는 시드 작업을 즐기는 사람이 있다는 다소 특이한 위치에 있습니다. 그 작업의 결과로 저는 그의 PRNG와 다른 오랜 기간 동안의 PRNG에 대해 똑같은 일을했습니다.

이미 언급했듯이 이것은 거짓입니다. PCG 내에서 쉽게 찾을 수있는 xoshiro256 ++와 같은 상관 관계가없는 한 쌍의 겹치지 않는 시퀀스의 예를 알지 못합니다.

전체 상태를 빠르게 혼합하는 PRNG에는이 문제가 없습니다. xoshiro256 ++에서 두 개의 비 중첩 시퀀스를 생성하는 프로그램을 제공 할 수 있다면 여기에 게시 한 예제와 같이 상관 관계가 있습니다.

그의 상관 프로그램에 관해서는 2018 년에 그가 다양한 이슈 (예 : 인위적 시드 등)로 작성한 프로그램을 포함하는 그의 웹 사이트에 PCG에 대한 비평을 올렸을 때 비슷한 프로그램이 많이 포함 된 답변 을 썼습니다 corrsplitmix2.c 를 포함하여 오랫동안 확립 된 다른 PRNG의 경우. 세바스찬이 할 수 없다고 말했을 때 무슨 뜻인지 잘 모르겠지만, 그의 새로운 테스트 프로그램이 그의 테스트 프로그램과 실질적으로 다른지 확인하기 위해 그의 테스트 프로그램을 면밀히 살펴볼 기회가 없었습니다. 몇 년 전에 썼습니다.

위에 인용 된 프로그램은 _ 스트림을 선택합니다 _. 쓰기는 분명히 쉽습니다.

그러나 그것은 PCG의 문제와는 아무런 관련이 없습니다. 내가 제공 한 프로그램은 _user_가 스트림을 선택하도록 한 다음 상관 관계를 보여줍니다.

다시 한 번 @inmeme 에게 http : / 와 같은 다른 생성기에서 상관 시퀀스를 찾습니다

사용자가 스트림을 임의로 선택하게하면 훨씬 더 강력한 상관 관계가 나타납니다.

이미 언급했듯이 이것은 거짓입니다. PCG 내에서 쉽게 찾을 수있는 xoshiro256 ++와 같은 상관 관계가없는 한 쌍의 겹치지 않는 시퀀스의 예를 알지 못합니다.

우리가 여기서 서로 과거 이야기하고있는 것 같습니다. 나는 어떤 PRNG에 대해서도 상관 관계가없고 겹치지 않는 서열을 생각 해낼 수 있다고 말하지 않았고, 내가 이전에 작성한 다양한 상관 관계 프로그램에서 보여준 것처럼 일반적으로 병리학 적 시드를 생각 해낼 수 있다고 말했고 Xoshiro **에 대한 나쁜 반복 데모 프로그램으로 .

또한 전체 상태를 혼합하지 않은 PRNG는 XorWow, 수치 레시피의 생성기 등을 포함하여 오랜 역사를 가지고 있습니다. Sebastiano의 주장은 관점을 나타내지 만 Marsaglia가 Weyl을 추가하여 XorWow에서 XorShift를 _worse_ 만들었습니다. 수 많은 유사한 생성기를 생성하기 때문입니다.

우리가 여기서 서로 과거 이야기하고있는 것 같습니다. 나는 어떤 PRNG에 대해서도 상관 관계가없고 겹치지 않는 서열을 생각 해낼 수 있다고 말하지 않았고, 내가 이전에 작성한 다양한 상관 관계 프로그램에서 보여준 것처럼 일반적으로 병리학 적 시드를 생각 해낼 수 있다고 말했고 Xoshiro **에 대한 나쁜 반복 데모 프로그램으로 .

기술적 인 수준에서 토론을 유지하십시오. "병리학 적"은 수학적 의미가 없습니다.

자기 상관을 확인하는 기술적으로 올바른 방법은 두 개의 겹치지 않는 시퀀스 (테스트 기간 동안 겹치지 않음-충분히 멀리 가면 불가피하게 겹칠 수 있음)를 생성하는 두 개의 시드를 찾아서 인터리브하고 배터리에 전달하는 것입니다. 테스트

겹치는 두 개의 시퀀스를 고려하면 시퀀스가 ​​겹친 후 동일한 출력이 두 번 발생하고 합리적인 테스트가이를 선택하기 때문에 모든 생성기, 심지어 암호화 된 생성기에 대해 상관 관계가 있습니다.

중첩 시퀀스를 사용하는 "병리 적 시딩"은 모든 생성자에게 사소한 작업입니다 ( "병리 적"이 의미하는 것이 무엇이든간에).

다시 한 번, 다른 생성기에서 PCG (시퀀스가 겹치지 않는 경우)와 유사한 상관 관계를 발견했다고 주장하므로 xoshiro256 ++ 또는 SFC64와 같은 상관 관계가없는 한 쌍의 겹치지 않는 시퀀스를 제공 할 수 있습니다. ?

자기 상관을 확인하는 기술적으로 올바른 방법은 두 개의 겹치지 않는 시퀀스 (테스트 기간 동안 겹치지 않음-충분히 멀리 가면 불가피하게 겹칠 수 있음)를 생성하는 두 개의 시드를 찾아서 인터리브하고 배터리에 전달하는 것입니다. 테스트

이 상관 관계 정의에 대한 문헌을 지적하여 내가 그것에 대해 "기술적으로 올바른"상태를 유지하도록 할 수 있습니까?

Sebastiano, 당신은 내가 당신의 조건에 설정된 도전에 대답하기를 계속 원합니다. 당신이 지적하는 것은 자기 유사성이있는 LCG의 본질적인 속성과 관련이 있습니다. 혼란스러운 PRNG 또는 LFSR 기반의 경우 동일한 문제를 찾을 수 없습니다.

그러나 다른 PRNG에는 다른 약점이 있습니다.

LFSR에는 제로 랜드, 불량 상태, 해밍 가중치 문제, 선형성이 있으며 xoshiro에 대한 시도에서 배웠 듯이 반복되는 이상한 문제와 같은 다른 기이함도 있습니다.

혼돈의 PRNG는 짧은주기 (카운터가있는 경우-Weyl 시퀀스 FTW!)와 고유 한 편향의 위험이 있습니다.

내가 쓴 것처럼 시퀀스가 ​​겹치면 테스트는 _ 항상 _ 실패합니다. _ 항상 실패하는 테스트가 테스트가 아님을 이해하기 위해 문헌이 필요하지 않습니다.

다시 한 번, 다른 생성기에서 PCG (시퀀스가 겹치지 않는 경우)와 유사한 상관 관계를 발견했다고 주장하므로 xoshiro256 ++ 또는 SFC64와 같은 상관 관계가없는 한 쌍의 겹치지 않는 시퀀스를 제공 할 수 있습니다. ?

당신은 정말로 질문을 피하는 것 같습니다. 귀하의 주장에 따라 그러한 증거를 제공하는 것은 매우 쉬울 것입니다.

지금 가장 쉬운 방법은 "저렴한 승수"와 더 강력한 DXSM 출력 기능을 가진 PCG64의 변형 인 PCG64DXSM BitGenerator 를 추가하는 것입니다. 모든 사람들이 이것이 현재 PCG64 구현에있는 XSL-RR 출력 함수에서 한 단계 올라간 것으로, 런타임 성능에 손상을주지 않고 통계적으로 더 나은 성능을 발휘한다는 데 동의한다고 생각합니다. 우리가 제공하는 BitGenerator 대해 PCG64 제공하는 틈새 시장에서의 간단한 업그레이드입니다. PCG64 와 함께 추가해야한다고 생각합니다.

64 비트 "저렴한 승수"에는 입증 가능한 결함이 있습니다. 이것은 오랫동안 알려져 있습니다.

W. Hörmann 및 G. Derflinger, 휴대용 난수 생성기
거부 방법, ACM Trans. 수학. Softw. 19 (1993), no. 4, 489–495.

일반적으로 계수의 제곱근보다 작은 승수는 스펙트럼 점수 f₂에 대한 고유 한 한계를 갖습니다.

이 한계는 65 비트 승수를 사용하여 쉽게 극복 할 수 있습니다. 컴파일러는 추가 "추가"작업으로 만 변환 할 수 있으며 생성기 속도를 변경하지 않을 수도 있습니다.

Guy Steele과 저는이 문제에 대해 약간 작업하고 다양한 크기의 저렴한 승수에 대한 스펙트럼 점수 표를 게시했습니다 : https://arxiv.org/pdf/2001.05304.pdf . 클수록 더 좋지만 64 비트에서 65 비트 (상태가 128 비트 인 LCG의 경우)에서 입증 가능한 간격이 있습니다.

예를 들어, 논문의 표 7에서 f₂ 점수가 0.9919 인 0x1d605bbb58c8abbfd를 얻습니다. 64 비트 승수는 0.9306 (논문의 정리 4.1)을 초과 할 수 없습니다.

혼합과 모든 작업 후에 f₂ 점수의 개선은 통계적 관점에서 전혀 눈에 띄지 않을 수 있습니다. 그러나 추가 작업만으로 가장 관련성이 높은 차원에 대해 얻을 수있는 큰 개선을 고려할 때 노력할 가치가 있다고 생각합니다 (글쎄, 우리가 생각하거나 문서를 작성하지 않았을 것입니다).

Sebastiano, 당신은 내가 당신의 조건에 설정된 도전에 대답하기를 계속 원합니다. 당신이 지적하는 것은 자기 유사성이있는 LCG의 본질적인 속성과 관련이 있습니다. 혼란스러운 PRNG 또는 LFSR 기반의 경우 동일한 문제를 찾을 수 없습니다.

와, 거기에 도착하는 데 시간이 걸렸습니다!

LFSR에는 제로 랜드, 불량 상태, 해밍 가중치 문제, 선형성이 있으며 xoshiro에 대한 시도에서 배웠 듯이 반복되는 이상한 문제와 같은 다른 기이함도 있습니다.

나는 전적으로 동의합니다. 그것이 당신이 그들을 뒤섞어 야하는 이유입니다. LFSR과 F₂- 선형 생성기는 서로 다릅니다. 관련이 있지만 다릅니다.

"반복이있는 이상한 문제"는 평소와 같이 내가 언급 할 수없는 비 기술적 인 용어입니다.

혼돈의 PRNG는 짧은주기 (카운터가있는 경우-Weyl 시퀀스 FTW!)와 고유 한 편향의 위험이 있습니다.

[업데이트 : 괄호 안의 카운터 관찰을 놓쳐서 코멘트를 업데이트하고 있습니다.]

예, SFC64에는 이러한 문제가 없으므로 (카운터 사용) 전체 범주로 일반화하지 않습니다. 입증 가능하고 가장 짧은주기 길이를 가진 신중하게 설계된 혼돈 발생기가 있습니다.

"반복이있는 이상한 문제"는 평소와 같이 내가 언급 할 수없는 비 기술적 인 용어입니다.

내가 올바른 전문 용어를 사용하지 않았기 때문에 댓글을 달 수없는 것이 이상해 보입니다. 이 프로그램을 실행 한 다음 적절한 전문 용어로 문제를 설명하는 가장 좋은 방법을 알려주고 적절한 해설을 제공하십시오. 나는 당신과 David Blackman이 그 문제에 대해 그와 통신했기 때문에 처음 밝혀 졌을 때 그 문제에 대해 논의했을 것이라고 상상했을 것입니다.

numpy 없는 PRNG에 대한 토론은 주제에서 벗어납니다. 토론을 계속하려면 자신의 포럼을 사용하십시오. 감사합니다.

@rkern- 기준으로 약간 엄격한 것 같습니다. 다른 구현에서 공유하지 않는 Numpy 표현에 결함이있는 경우 논의하는 것이 합리적입니다.

제가 언급하는 거래소가이 문제에서 우리 앞에 놓인 결정을 내리는 데 도움이되지 않음을 확인할 수 있습니다. 진행될 때까지 집중할 수있는 대화가 필요합니다.

더 넓은 맥락을 이해하는 것이 도움이된다고 생각합니다. Sebastiano는 PCG에 대해 약간의 관심을 가지고 있으며 수년 동안 이에 대해 난관을 제기 해 왔습니다. 요즘 어떤 사람들은 우리 둘 다보고 눈을 굴리며 "너희 둘 다 서로 나쁘다"라고 말할지도 모른다고 생각한다. 나도 그의 PRNG에 대해 비판을했기 때문이다. 나는 그의 물건에 대해 말하지 않고 무언가를 숨기려고했다 (실제로 나는 시간 / 성향이 없었을 때 – 사실, 나는 그들이 괜찮다고 생각했을 뿐이었다).

그의 비평은 유용하고, 그의 인생의 많은 부분을 내 작품에 대해 생각하는 데 보내도록 선택되어 기쁩니다.하지만 그의 테스트가 본질적으로 적대적이라는 것을 깨닫는 것이 중요합니다. 그는 PCG의 구조에 대한 지식을 사용하여 RNG 테스터 및 실패 테스트에 제공 할 수있는 배열을 구성합니다.

그것이 얼마나 무섭게 보일 수 있는지를 감안할 때, 유사한 적대적 접근 방식이 수많은 다른 생성자들을 넘어 뜨릴 것이며 그가 PCG에 대해 제기하는 많은 우려가 생성 계획에 대해 관찰 한 것처럼 다른 세대 계획에도 적용될 것임을 보여주는 것이 합리적으로 보입니다. XorWow와 같고, 아래에서 설명하는 것처럼 SplitMix를 예제로 자주 사용합니다. (우리 중 누구도 특히 SplitMix에 어떤 식 으로든 투자하지 않습니다.)

예를 들어 우리는 SplitMix에 대해 매우 무서워 할 수 있으며 기본 스트림 상수를 사용하여 35185 번째 출력을 볼 때마다 PRNG 테스트 스위트에서 실패 함을 보여줍니다. 이런! 이는 내부적으로 카운터 (Weyl 시퀀스!)를 0x9e3779b97f4a7c15 (φ, 황금 비율 기준)만큼 증가 시키지만 35185 * 0x9e3779b97f4a7c15 = 0x86a100000c480245 . 14 비트 세트와 중간에 아무것도없는 큰 스와 스. 또는 모든 360998717 번째 출력을 살펴보면 0x48620000800401 의 내부 상태에 추가하는 것과 동일합니다. 이는 8 비트 만 추가되고 출력 함수가 완전히 마스킹하기 어려운 것입니다. .

우리는 계속해서 SplitMix에 대해 겁쟁이를 일으킬 수 있습니다. 하나는 가산 상수 0x9e3779b97f4a7c15 있고 다른 하나는 0xdaa66d2c7ddf743f 가있는 스트림이 두 개 있으면 어떨까요? PRNG 테스트 스위트 !!! 그러나 그것은 두 번째 것이 다른 것의 3 배에 불과하도록 고안 되었기 때문입니다.

그리고 마지막으로, 누군가가 "내가 두 스트림을 모두 제공 할 것입니다. 무서운 일을하세요!"라고 말하면 π ( 0x243f6a8885a308d3 ) 및 _e_ ( 0xb7e151628aed2a6b )를 기반으로한다고 가정 해 보겠습니다. ), 우리는 확실히 더 겁쟁이를 일으키고 Pi 스트림에서 모든 6561221343 번째 항목을 가져와 E 스트림과 로우 앤 벨 홀드의 모든 6663276199 번째 항목과 혼합하여 두 개의 동일한 항목을 생성한다고 말할 수 있습니다. 시퀀스. 그리고 _worse_, 나는 계속해서 스트림 a의 모든 점프에 대해 동일한 출력을 제공하기 위해 스트림 b에 일치하는 점프가 있음을 보여줍니다. 따라서 실제로 상관 관계가있는 2 ^ 64 방식이 있습니다 !!! (그리고 우리는 두 개의 스트림에 대해 이것을 할 수 있습니다. π와 _e_에는 특별한 것이 없었습니다.)

PCG로 돌아가서 Sebastiano의 테스트는 두 개의 PCG64 XSH RR 생성기가 정확하게 정렬되어 일치하는 출력이 인터리브되도록하는 데 의존합니다. PRNG 중 하나를 조금만 전진시켜 완벽한 정렬을 조금만 깨 뜨리면 의심스러운 것을 감지하기가 훨씬 더 어려워집니다.

다른 방향에서 비슷한 적대적 테스트 (Sebastiano에게 부담을 줌)는 상관 관계가 있다는 그의 주장을 충족시키는 PCG64 XSH RR의 출력을 제공하는 것이지만 우리는 정확히 어떻게 정렬되어 있는지 알려주지 않습니다 (그냥 오른쪽 일반 이웃). 그의 임무는 서로 연관되어 있음을 보여주기 위해 정렬을 찾는 것입니다.

전반적으로 긴급한 화재를 진압하는 것이 실제로 문제라고 생각하지 않지만, 반면에 DXSM 버전은 작년에 이러한 종류의 문제를 정확하게 완화하기 위해 작성 되었기 때문에 더 낫습니다. 전환 해 주셔서 기쁩니다.

추신 :이 코드를 사용하여 좋아하는 실수로 매직 Weyl 가산 상수를 만들 수 있습니다.

WeylConst[r_,bits_] = BitOr[Floor[(r-Floor[r])*2^bits],1]

그것이 Mathematica입니다. 저는 연습으로 Python 버전을 남겨 두겠습니다.

다른 증분에 대해 낮은 비트 충돌을 구성하는 방법은 다음과 같습니다.

❯ ./pcg64_correlations.py -m 58 | stdbuf -oL ./RNG_test stdin64 -tf 2 -te 1 -tlmaxonly -multithreaded
s0 = 0b01110010100110011101000110010010101111111001100011001011001011111001001110101010011101111101001101011000011100001111111111100001
s1 = 0b10110001011001100111100010000110101110011010101010011011010100011001011111001100010001101001001011010010110101001011101111111100
dist = 0x2eb6ec432b0ea0f4fc00000000000000
[
    {
        "bit_generator": "PCG64",
        "state": {
            "state": 152330663589051481538402839025803132897,
            "inc": 228410650821285501905570422998802152525
        },
        "has_uint32": 0,
        "uinteger": 0
    },
    {
        "bit_generator": "PCG64",
        "state": {
            "state": 235805414096687854712168706130903874556,
            "inc": 70910205337619270663569052684874994465
        },
        "has_uint32": 0,
        "uinteger": 0
    }
]
RNG_test using PractRand version 0.93
RNG = RNG_stdin64, seed = 0x12d551b8
test set = expanded, folding = extra

rng=RNG_stdin64, seed=0x12d551b8
length= 128 megabytes (2^27 bytes), time= 2.8 seconds
  no anomalies in 891 test result(s)

rng=RNG_stdin64, seed=0x12d551b8
length= 256 megabytes (2^28 bytes), time= 9.4 seconds
  no anomalies in 938 test result(s)

rng=RNG_stdin64, seed=0x12d551b8
length= 512 megabytes (2^29 bytes), time= 18.1 seconds
  no anomalies in 985 test result(s)

rng=RNG_stdin64, seed=0x12d551b8
length= 1 gigabyte (2^30 bytes), time= 31.2 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low1/8]FPF-14+6/16:cross         R=  +4.9  p =  1.7e-4   unusual          
  [Low4/16]FPF-14+6/16:all          R=  +8.4  p =  2.3e-7   very suspicious  
  [Low4/16]FPF-14+6/16:all2         R=  +8.3  p =  8.1e-5   unusual          
  [Low8/32]FPF-14+6/32:all          R=  +6.3  p =  2.1e-5   mildly suspicious
  [Low8/32]FPF-14+6/16:all          R=  +5.7  p =  8.0e-5   unusual          
  ...and 1034 test result(s) without anomalies

rng=RNG_stdin64, seed=0x12d551b8
length= 2 gigabytes (2^31 bytes), time= 52.7 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low4/16]FPF-14+6/32:all          R=  +7.4  p =  2.0e-6   suspicious       
  [Low4/16]FPF-14+6/16:(0,14-0)     R=  +7.7  p =  9.4e-7   unusual          
  [Low4/16]FPF-14+6/16:all          R=  +8.0  p =  5.9e-7   suspicious       
  [Low4/16]FPF-14+6/16:all2         R= +12.2  p =  2.1e-6   mildly suspicious
  [Low4/16]FPF-14+6/4:(0,14-0)      R=  +7.9  p =  6.3e-7   mildly suspicious
  [Low4/16]FPF-14+6/4:all           R=  +5.8  p =  6.7e-5   unusual          
  [Low4/16]FPF-14+6/4:all2          R= +11.5  p =  3.1e-6   mildly suspicious
  [Low8/32]FPF-14+6/32:(0,14-0)     R=  +7.8  p =  8.4e-7   unusual          
  [Low8/32]FPF-14+6/32:all          R=  +7.3  p =  2.3e-6   suspicious       
  [Low8/32]FPF-14+6/32:all2         R= +14.3  p =  3.8e-7   suspicious       
  [Low8/32]FPF-14+6/16:(0,14-0)     R=  +7.7  p =  8.8e-7   unusual          
  [Low8/32]FPF-14+6/16:(1,14-0)     R=  +7.7  p =  9.3e-7   unusual          
  [Low8/32]FPF-14+6/16:all          R=  +6.9  p =  5.3e-6   mildly suspicious
  [Low8/32]FPF-14+6/16:all2         R= +18.3  p =  8.0e-9   very suspicious  
  ...and 1078 test result(s) without anomalies

rng=RNG_stdin64, seed=0x12d551b8
length= 4 gigabytes (2^32 bytes), time= 90.2 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low1/8]BCFN_FF(2+0):freq         R= +14.8  p~=   6e-18     FAIL !         
  [Low1/8]BCFN_FF(2+1):freq         R=  +7.4  p~=   1e-6    mildly suspicious
  [Low1/8]FPF-14+6/16:cross         R=  +8.4  p =  2.1e-7   very suspicious  
  [Low4/16]FPF-14+6/32:(0,14-0)     R=  +8.9  p =  8.1e-8   mildly suspicious
  [Low4/16]FPF-14+6/32:(1,14-0)     R=  +8.5  p =  1.9e-7   mildly suspicious
  [Low4/16]FPF-14+6/32:all          R=  +9.4  p =  2.4e-8   very suspicious  
  [Low4/16]FPF-14+6/32:all2         R= +23.9  p =  5.2e-11   VERY SUSPICIOUS 
  [Low4/16]FPF-14+6/16:(0,14-0)     R= +13.8  p =  2.2e-12   VERY SUSPICIOUS 
  [Low4/16]FPF-14+6/16:(1,14-0)     R= +10.0  p =  7.3e-9   suspicious       
  [Low4/16]FPF-14+6/16:all          R= +12.1  p =  8.0e-11   VERY SUSPICIOUS 
  [Low4/16]FPF-14+6/16:all2         R= +52.5  p =  1.3e-22    FAIL !!        
  [Low4/16]FPF-14+6/4:(0,14-0)      R= +12.2  p =  7.0e-11   VERY SUSPICIOUS 
  [Low4/16]FPF-14+6/4:all           R=  +7.1  p =  3.7e-6   mildly suspicious
  [Low4/16]FPF-14+6/4:all2          R= +29.8  p =  7.1e-14    FAIL           
  [Low4/16]FPF-14+6/4:cross         R=  +5.3  p =  7.8e-5   unusual          
  [Low4/32]FPF-14+6/32:(0,14-0)     R=  +7.6  p =  1.3e-6   unusual          
  [Low4/32]FPF-14+6/32:all          R=  +6.0  p =  4.4e-5   unusual          
  [Low4/32]FPF-14+6/32:all2         R=  +9.4  p =  2.9e-5   unusual          
  [Low4/32]FPF-14+6/16:(0,14-0)     R=  +7.3  p =  2.5e-6   unusual          
  [Low4/32]FPF-14+6/16:all          R=  +6.5  p =  1.4e-5   mildly suspicious
  [Low4/32]FPF-14+6/16:all2         R=  +8.2  p =  8.0e-5   unusual          
  [Low8/32]FPF-14+6/32:(0,14-0)     R= +17.2  p =  1.7e-15    FAIL           
  [Low8/32]FPF-14+6/32:(1,14-0)     R= +12.7  p =  2.3e-11   VERY SUSPICIOUS 
  [Low8/32]FPF-14+6/32:all          R= +15.3  p =  7.9e-14    FAIL           
  [Low8/32]FPF-14+6/32:all2         R= +86.1  p =  1.2e-35    FAIL !!!       
  [Low8/32]FPF-14+6/16:(0,14-0)     R= +16.8  p =  3.5e-15    FAIL           
  [Low8/32]FPF-14+6/16:(1,14-0)     R= +12.2  p =  6.6e-11   VERY SUSPICIOUS 
  [Low8/32]FPF-14+6/16:all          R= +13.1  p =  8.9e-12   VERY SUSPICIOUS 
  [Low8/32]FPF-14+6/16:all2         R= +82.1  p =  1.7e-34    FAIL !!!       
  [Low8/32]FPF-14+6/4:(0,14-0)      R= +12.8  p =  2.0e-11   VERY SUSPICIOUS 
  [Low8/32]FPF-14+6/4:(1,14-0)      R=  +9.4  p =  2.5e-8   suspicious       
  [Low8/32]FPF-14+6/4:all           R= +10.5  p =  2.2e-9    VERY SUSPICIOUS 
  [Low8/32]FPF-14+6/4:all2          R= +42.0  p =  5.8e-19    FAIL !         
  ...and 1118 test result(s) without anomalies

❯ ./pcg64_correlations.py -m 64 --dxsm | stdbuf -oL ./RNG_test stdin64 -tf 2 -te 1 -tlmaxonly -multithreaded
s0 = 0b10001000010110111101010101010101111100100011011111011111011111001011110101111100101101101100110101110001101101111111010101111111
s1 = 0b11000101110100011001011000001110100001001111001001100101010000101100011001010111011001100000010010011100101110001110101000011100
dist = 0x3a26b19c91e6da1d0000000000000000
[
    {
        "bit_generator": "PCG64DXSM",
        "state": {
            "state": 181251833403477538233003277050491434367,
            "inc": 46073632738916603716779705377640239269
        },
        "has_uint32": 0,
        "uinteger": 0
    },
    {
        "bit_generator": "PCG64DXSM",
        "state": {
            "state": 262946148724842088422233355148768897564,
            "inc": 125105549038853892415237434774494719583
        },
        "has_uint32": 0,
        "uinteger": 0
    }
]
RNG_test using PractRand version 0.93
RNG = RNG_stdin64, seed = 0x85cea9
test set = expanded, folding = extra

rng=RNG_stdin64, seed=0x85cea9
length= 128 megabytes (2^27 bytes), time= 2.6 seconds
  no anomalies in 891 test result(s)

rng=RNG_stdin64, seed=0x85cea9
length= 256 megabytes (2^28 bytes), time= 9.4 seconds
  no anomalies in 938 test result(s)

rng=RNG_stdin64, seed=0x85cea9
length= 512 megabytes (2^29 bytes), time= 18.5 seconds
  no anomalies in 985 test result(s)

rng=RNG_stdin64, seed=0x85cea9
length= 1 gigabyte (2^30 bytes), time= 32.3 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low4/32]BCFN_FF(2+3,13-3,T)      R=  -8.3  p =1-9.5e-5   unusual          
  ...and 1035 test result(s) without anomalies

rng=RNG_stdin64, seed=0x85cea9
length= 2 gigabytes (2^31 bytes), time= 55.8 seconds
  no anomalies in 1092 test result(s)

rng=RNG_stdin64, seed=0x85cea9
length= 4 gigabytes (2^32 bytes), time= 93.1 seconds
  no anomalies in 1154 test result(s)

rng=RNG_stdin64, seed=0x85cea9
length= 8 gigabytes (2^33 bytes), time= 175 seconds
  no anomalies in 1222 test result(s)

rng=RNG_stdin64, seed=0x85cea9
length= 16 gigabytes (2^34 bytes), time= 326 seconds
  no anomalies in 1302 test result(s)

rng=RNG_stdin64, seed=0x85cea9
length= 32 gigabytes (2^35 bytes), time= 594 seconds
  no anomalies in 1359 test result(s)

rng=RNG_stdin64, seed=0x85cea9
length= 64 gigabytes (2^36 bytes), time= 1194 seconds
  no anomalies in 1434 test result(s)

rng=RNG_stdin64, seed=0x85cea9
length= 128 gigabytes (2^37 bytes), time= 2334 seconds
  no anomalies in 1506 test result(s)
...

@rkern , 코드를 공유해 주셔서 감사합니다. 완벽하게 정렬되지 않은 테스터에 인터리브 출력을 공급하기 위해 스큐를 추가하는 옵션을 추가하는 것이 도움이 될 것입니다. 그것은 내가 조금 탐구 한 것입니다.

네, 최종 return 전에 다양한 N 대해 bg0.advance(N) 를 삽입하여 비공식적으로 수행했습니다. 나는 무언가를 볼 수 있도록 낮은 64 비트 충돌을 사용했습니다. 같은 작은 변화 16 많은 실패를 변경하지 않지만, 같은 심지어 겸손한 변화 128 32 지브에 실패를 연장.

PCG64 DXSM을 선택적 비트 생성기로 추가하고 결국 기본값으로 만들어야하는 것 같습니다. 우리에게 구현이 있습니까?

더 넓은 맥락을 이해하는 것이 도움이된다고 생각합니다. Sebastiano는 PCG에 대해 약간의 관심을 가지고 있으며 수년 동안 이에 대해 난관을 제기 해 왔습니다. 요즘 어떤 사람들은 우리 둘 다보고 눈을 굴리며 "너희 둘 다 서로 나쁘다"라고 말할지도 모른다고 생각한다. 나도 그의 PRNG에 대해 비판을했기 때문이다. 나는 그의 물건에 대해 말하지 않고 무언가를 숨기려고했다 (실제로 나는 시간 / 성향이 없었을 때 – 사실, 나는 그들이 괜찮다고 생각했을 뿐이었다).

이러한 고려 사항은 완전히 부적절하다고 생각합니다.

장점과 증거없이 다른 사람의 작업 (예 : SplitMix)을 공격한다고 주장하는 것은 PCG 또는 Numpy의 생성기를 더 좋게 만들지 않습니다. 대신 더 나은 승수 또는 더 잘 설계된 스크램블러가 도움이 될 수 있습니다.

사용자가 스트림을 선택할 수있을 때 SplitMix에서 상관 관계를 보여주는 테스트를 기다리고 있습니다. 명확하게 말하면 Numpy의 생성기에 대해 다음 형식의 진술을 증명했습니다.

∀c ∀d ∀x ∃y 상관 관계

여기서 c, d는 증분 ( "스트림")이고 x, y는 초기 상태입니다. 사실, 2 ^ 72 y가 있습니다. 즉, c, d, x를 어떻게 선택하든 상관 관계를 나타내는 2 ^ 72 y가 있습니다.

SplitMix에 대해 제공 한 해당 코드는

∃c ∃d ∃x ∃y 상관 관계

즉, 적대적으로 c, d, x 및 y를 선택하면 상관 관계를 나타낼 수 있습니다.

두 진술의 강점 차이는 상당히 놀랍습니다. 두 문장을 합치려고하는 것은 잘못된 것입니다.

@vigna 귀하는 @mattip 및 @rkern의 행동 강령에 대해 두 번 경고를 받았습니다. "다른 사람의 일을 찌르는 것"과 "두 진술을 합치려는 것은 순수한 FUD"와 같은 언어를 사용하는 것은 좋지 않습니다. 이것이 마지막 경고라고 생각하십시오. 어조를 바꾸지 않으면 _ 금지 _하겠습니다. 기술적 인 주장은 여전히 ​​환영합니다. 다른 것은이 시점에서 없습니다.

나는 그 표현을 중립적 인 표현으로 바꾸는 메시지를 수정했습니다. 나는 여전히 토론에 다른 참가자를 개인적으로 공격하는 것 ( "세바스티아노는 PCG에 대해 약간의 문제를 가지고 있으며 수년간 그것에 대해 난간을 해왔다")은 전적으로 부적절하다고 생각합니다. 나는 당신이 아니라는 것이 매우 놀랍습니다.

세 번째이자 마지막으로, 어느 방향 으로든 SplitMix에 대한 논의는 저에게 조금도 도움이되지 않습니다. 왜 필요한 맥락을 제공한다고 생각하는지 또는 상대방에게 응답해야한다고 생각하는지 이해할 수 있지만, 여기에서 결정을 내리는 데 도움이되는 정보를 제공하지 않는다는 사실을 말하고 있다는 사실을 믿으십시오. 둘 다 자신의 웹 사이트가 있습니다. 그것을 써.

나는 그 표현을 중립적 인 표현으로 바꾸는 메시지를 수정했습니다.

감사합니다.

나는 여전히 토론에 다른 참가자를 개인적으로 공격하는 것 ( "세바스티아노는 PCG에 대해 약간의 문제를 가지고 있으며 수년간 그것에 대해 난간을 해왔다")은 전적으로 부적절하다고 생각합니다. 나는 당신이 아니라는 것이 매우 놀랍습니다.

나는 그것을 실제로 보지 않기를 원합니다. 그러나 그 메시지의 어조는 그다지 나쁘지 않습니다.

둘 다 @vigna 와 @imneme의 건설적인 사실 진술을 고수 할 수 있다면 감사하겠습니다.

확인. 처음부터 시작해 보겠습니다. 편의성과 속도를 위해 2의 거듭 제곱 모듈러스를 사용하는 LCG를 기반으로하는 일종의 스트림이있는 생성기를 원합니다. 문헌에서는 LCG 가산 상수를 기반으로하는 스트림이 문제를 일으킬 수 있다고 제안하지만 (지금 발생하는 것처럼) 이것이 원하는 것이라고 가정 해 보겠습니다.

128 비트 상태와 좋은 승수 (최소 65 비트)가있는 LCG를 가져 와서 다른 응용 프로그램 (해싱, PRNG 등)에서 많이 테스트 된 SplitMix의 혼합 기능을 사용하여 상위 비트를 교란하지 않는 이유는 무엇입니까? 우수한 결과를 제공합니까?

나는 속도의 차이가 미미할 것이라고 확신합니다. 그리고 결과가 모든 비트에 따라 달라진다는 (통계적) 보장이 있는데, 이것이 여기서 문제입니다.

이것은 자기 상관 문제가있는 생성기에서 믹싱 함수를 직접 만드는 것보다 "거인의 어깨 위에서는"접근 방식에 가깝다고 생각합니다.

@imneme 내가 사용할 수있는 것은 에서이 발표 코멘트 보다 링크하기가 더 쉽습니다. 그 주석에있는 것 이상일 필요는 없지만 여기에서 언급 한 테스트의 현재 상태를 포함하는 것이 좋습니다. 그 발전을 이끈 메가 이슈에서 논의 된 내용을 요약하고 싶다면 확실히 유용 할 것이지만 전적으로 필요하지는 않습니다.

비냐

128 비트 상태와 좋은 승수 (최소 65 비트)가있는 LCG를 가져 와서 다른 응용 프로그램 (해싱, PRNG 등)에서 많이 테스트 된 SplitMix의 혼합 기능을 사용하여 상위 비트를 교란하지 않는 이유는 무엇입니까? 우수한 결과를 제공합니까?

비정상적으로 들리면 사과하지만 (확실히 지적 되겠지만) 성실합니다. 귀하의 웹 사이트 또는 arXiv에서 구현, 분석, 벤치 마크 및 PractRand 결과를보기를 기대합니다. 우리는 PRNG 연구원이 아닌 (합리적으로 정보를 갖춘) 실무자이며이 제안을 수행 할 수있는 장비가 특히 잘 갖추어져 있지 않습니다. 그 느낌을 볼 수는 있지만 개인적인 시간에 대한 다른 제약을 감안할 때 제안에서 구현 및 분석에 이르기까지 노력을 기울일 의향이 없습니다. 이 제안을 numpy에게 전달하려면 PRNG 연구원이 해당 작업을 수행해야합니다. 이 제안을 다른 사람에게 실제로 전달하는 경우 웹 사이트를 사용하십시오.

NumPy의 임의의 Generator -> BitGenerator -> SeedSequence 아키텍처는 플러그 가능합니다. BitGenerator에 대한 PR을 열 사람이 필요한 시점에 이르렀으므로 실제 속성을 현재 NumPy에있는 속성과 비교할 수 있습니다. 프로젝트의 일부가되면 계속 테스트 할 수 있으며 기본값으로 설정할 수 있습니다. 그 결정은

• 편견 부족 (및 기타 기준? 전문가에게 양도)
• 공연
• BitGenerator.spawn 및 SeedSequence 사용하여 우리가 권장하는 규범 적 인터페이스를 통해 다양한 유형의 스트림 충돌 가능성.

개인적으로이 토론은 spawn 인터페이스를 사용하는 코드를 통해 BitGenerators 의 장점을 논의하지 않았을 때 저를 잃었습니다. 우리가 그것을 모범 사례로 홍보하는 이유가 있으며, 향후 PR에 대한 논의가 NumPy 사용자를위한 모범 사례

아마도 여기서 결론 중 하나는 jumped 또는 advance 하면 모범 사례를 위반할 수 있으므로 spawn 메서드로 허용해야한다는 것입니다. 이에 초점을 맞춘 새로운 문제 또는 NEP 도 생산적 일 수 있습니다.

@mattip @vigna가 언급 한 하위 비트 생일 충돌은 SeedSequence.spawn() 인터페이스에도 영향을 미칩니다. 제가 참여한 논의의 모든 부분은 API의 적절한 사용과 관련이 있습니다.

그것은 단지 완전히 분리 된 발전기의 선호 된 접근을 @rkern 사용하는 몇 가지 #ifdef와 블록으로 pcg64.c 8에 대한 행을 추가해야합니다. 그렇지 않으면 pyx / pxd는 올바른 정의 (PCG_DXSM = 1) 및 업데이트 된 독 스트링으로 만 빌드되는 PCG64 클래스와 동일합니다.

특히이를 필요로하는 플랫폼을위한 에뮬레이트 된 128 비트 수학에 대해 더 명확하게 설명 할 것입니다.

https://github.com/rkern/numpy/compare/v1.17.4...rkern%3Awip/pcg64-dxsm

그것은 "저렴한"64 비트 승수를 사용하기 때문에 나에게 그것보다 쉬웠다. 새 출력 믹서 (즉, 불변)를 추가 한 다음 LCG의 출력을 가져와 믹서를 적용하는 랜덤 생성기의 최종 라인 주위에 ifdef를 추가 할 수 있습니다.

https://github.com/bashtage/randomgen/commit/63e50a63f386b5fd725025f2199ff89454321f4c#diff -879bd64ee1e2b88fec97b5315cf77be1R115

이 시점에서 Murmur Hash 3을 추가 할 수도 있습니다.

if 문이 컴파일되지 않습니까? 나는 우리가 핫 루프 안에 그것들의 배수를 원하지 않는다고 생각합니다.

다시 말하지만, 이것은 randomgen 와 numpy 목적 차이로 귀결됩니다. randomgen 에서는 매개 변수화 된 패밀리를 만드는 것이 합리적이지만 numpy 에서는 활성 기본값에서 레거시 BitGenerator 구현을 얽히는 것은 좋은 생각이 아니라고 생각합니다. BitGenerator 둘 중 하나의 성능을 위해 유지 관리 또는 리팩토링을 수행해야한다면 그 노력이 더 나아지기보다는 더 나빠질 것입니다.

여기에서 Robert와 동의합니다. 1.19.0 릴리스에 새 비트 생성기를 넣는 것에 대해 아무런 불만이 없으며 현재 동작을 변경하지 않습니다.

@bashtage 또한 pcg_cm_random_r() 는 사후 반복 상태가 아닌 #ifdef 또는 if 동일한 코드 경로를 유지하는 것이 간단하지 않을 것입니다.

if 문이 컴파일되지 않습니까? 나는 우리가 핫 루프 안에 그것들의 배수를 원하지 않는다고 생각합니다.

아니요, NumPy에서 if else 는 다음과 같아야합니다.

#if defined(PCG_DXSM)
    pcg_output_dxsm(state.high, state.low)
#else 
   <old way>
#endif

uint128을 높음과 낮음으로 수동으로 이동하려면 uint128 버전과 대체 버전에서 별도로 정의해야합니다.

@bashtage 또한 pcg_cm_random_r() 는 post-iterated state 보다는 pre-iterated state를 사용하여 출력 하므로 #ifdef 또는 if 동일한 코드 경로를 유지하는 것이 간단하지 않을 것입니다.

흠, @imneme 참조 구현에 대해 테스트 한 결과 2 개의 개별 시드를 사용하여 1000 개의 값에 대해 100 % 일치하는 결과를 얻었습니다.

https://github.com/bashtage/randomgen/blob/master/randomgen/src/pcg64/pcg_dxsm-test-data-gen.cpp

AFAICT (그리고 나는 틀릴 수 있습니다)

https://github.com/imneme/pcg-cpp/blob/master/include/pcg_random.hpp#L174

과

https://github.com/imneme/pcg-cpp/blob/master/include/pcg_random.hpp#L1045

uint_128 경로가 항상 저렴한 승수를 사용하고 있음을 의미합니다.

당신이 거기에서 무슨 말을 하려는지 잘 모르겠습니다.

정식 PCG64 DXSM이 무엇인지 명확하지 않습니다. 두 경우 모두 출력 함수는 64 비트 연산 만 사용합니다. 현재 가지고있는 버전은 다른 위치에서 64 비트 승수를 사용하여 훨씬 더 빠르며 post가 아닌 pre를 반환합니다. setseq_dxsm_128_64 는 기존 PCG64의 자연스러운 확장처럼 보이며 출력 기능 만 변경합니다.

아, 알겠습니다. 아니요, C에서 구현 한 것과 다른 C ++ 생성기를 사용했습니다. LCG 반복에서 "저렴한 승수"를 사용하는 cm_setseq_dxsm_128_64 와 동등한 것을 구현했습니다. setseq_dxsm_128_64 가 아닙니다. LCG 반복에서 큰 승수를 사용합니다. "저렴한 승수"는 DXSM 출력 기능 내에서 재사용되지만 이는 직교 설계 축입니다.

setseq_dxsm_128_64를 선호하지 않는 이유는 무엇입니까?

@imneme 는 결국 C ++ 버전의 공식 pcg64 을 cm_setseq_dxsm_128_64 가 아닌 setseq_dxsm_128_64 cm_setseq_dxsm_128_64 를 가리 키도록 변경할 것이라고 말했습니다 . 저렴한 승수는 XSL-RR에 비해 DXSM의 추가 비용 중 일부를 상쇄합니다. 그리고 나는 그녀가 몇 달 동안 테스트를 한 것이 변종이라고 생각합니다.

사전 반복 상태를 출력하는 것도 성능 향상의 일부입니다 .

다음은 몇 가지 타이밍입니다.

In [4]: %timeit p.random_raw(1000000)
3.24 ms ± 4.61 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [5]: p = rg.PCG64(mode="sequence",use_dxsm=False)

In [6]: %timeit p.random_raw(1000000)
3.04 ms ± 8.47 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [7]: import numpy as np

In [8]: p = np.random.PCG64()

In [9]: %timeit p.random_raw(1000000)
3.03 ms ± 2.54 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

모두 Ubuntu-20.04, 기본 컴파일러입니다.

6 % 느립니다. 나에게는 작은 차이처럼 보입니다. NumPy / randomgen의 모든 타이밍은 네이티브 코드의 실제 타이트 루프에서 얻을 수있는 것과는 상당히 다릅니다.

비교

In [10]: x = rg.Xoroshiro128(mode="sequence")

In [11]: %timeit x.random_raw(1000000)
2.59 ms ± 35.7 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

C 코드에서 게시 된 내용 (150 % 느림 ??).

물론 numpy 컨텍스트에서는 그다지 중요하지 않습니다. 이는 C ++ 컨텍스트에서 더 중요합니다. 이는 클러스터 월을 테스트에 할당하고 공식 C ++ 코드에서 향후 기본 pcg64 로 지명하도록 유도했습니다. 이것이 numpy , IMO에 대한 가장 가까운 동기입니다.

내 브랜치의 주식 PCG64 와 내 PCG64DXSM ( "저렴한 승수", DXSM 출력 함수, 사전 반복 상태 출력, 별도의 코드 경로) :

[practrand]
|1> s = np.random.SeedSequence()

[practrand]
|2> pcg64 = np.random.PCG64(s)

[practrand]
|3> pcg64dxsm = np.random.PCG64DXSM(s)

[practrand]
|4> %timeit pcg64.random_raw(1000000)
100 loops, best of 3: 3.46 ms per loop

[practrand]
|5> %timeit pcg64dxsm.random_raw(1000000)
100 loops, best of 3: 2.9 ms per loop

나는 MSVC에 대한 특수한 구현으로도 둘 사이에 #ifdefs 몇 개 (내가 가진 것보다 더 많음)에 불과하다고 말한다. Plus RSN MS 사용자는 clang # 13816 👍을 사용할 수 있습니다.

코드 중복에 대해 논쟁하고 있습니까? #ifdefs 난독 화 된 몇 줄의 코드에 대해 걱정하는 것보다 훨씬 더 분리 된 구현이 있습니다. :)

"PCG 2.0"(가급적이면 NumPy의 GitHub 문제가 아닌 곳)을 정의하는 절대적으로 명확한 진술의 필요성을 강조했지만 대부분은 농담이었습니다.

감사합니다, @rkern et al.

@imneme 내가 사용할 수있는 것은 에서이 발표 코멘트 보다 링크하기가 더 쉽습니다. 그 주석에있는 것 이상일 필요는 없지만 여기에서 언급 한 테스트의 현재 상태를 포함하는 것이 좋습니다. 그 발전을 이끈 메가 이슈에서 논의 된 내용을 요약하고 싶다면 확실히 유용 할 것이지만 전적으로 필요하지는 않습니다.

시간을 염두에두고 계십니까? 저는이 일을 한동안하고 다른 일로 밀어 붙이려 고했기 때문에 실제로 마감일을 제안하는 것이 저에게 유용한 동기가 될 것입니다. 일주일 정도? 두?

@rkern 은 또한 했습니다 .

128 비트 상태와 좋은 승수 (최소 65 비트)가있는 LCG를 가져 와서 다른 응용 프로그램 (해싱, PRNG 등)에서 많이 테스트 된 SplitMix의 혼합 기능을 사용하여 상위 비트를 교란하지 않는 이유는 무엇입니까? 우수한 결과를 제공합니까?

FWIW,이 접근 방식은 원래 PCG 논문에서 논의되었으며, _FastHash_를 기성품 해시 함수로 사용하여 매우 유사한 곱셈-엑소 시프트 해시 함수입니다. 내 테스트에서 다른 순열만큼 빠르지는 않았지만 고품질이었습니다. Sebastiano는 2018 년 PCG 비평에서도이 아이디어를 언급했으며, 이 비평에 대한 저의 응답 이에 대해 논의합니다.

PCG 비평의 원래 버전 에서 그는 자신의 PCG 변형을 작성하여 끝냅니다.

        #include <stdint.h>

        __uint128_t x;

        uint64_t inline next(void) {
            // Put in z the top bits of state
            uint64_t z = x >> 64;
            // Update state
            x = x * ((__uint128_t)0x2360ed051fc65da4 << 64 ^ 0x4385df649fccf645)
                  + ((__uint128_t)0x5851f42d4c957f2d << 64 ^ 0x14057b7ef767814f);
            // Compute mix
            z = (z ^ (z >> 30)) * 0xbf58476d1ce4e5b9;
            z = (z ^ (z >> 27)) * 0x94d049bb133111eb;
            return z ^ (z >> 31);
        }

그는 비판의 코드를 더 저렴한 승수를 사용하고 가산 상수를 64 비트로 줄이는 더 빠른 버전으로 업데이트했습니다.

        #include <stdint.h>

        __uint128_t x;

        uint64_t inline next(void) {
            // Put in z the top bits of state
            uint64_t z = x >> 64;
            // Update state (multiplier from https://arxiv.org/abs/2001.05304)
            x = x * ((__uint128_t)1 << 64 ^ 0xd605bbb58c8abbfd) + 0x14057b7ef767814f;
            // Compute mix
            z = (z ^ (z >> 30)) * 0xbf58476d1ce4e5b9;
            z = (z ^ (z >> 27)) * 0x94d049bb133111eb;
            return z ^ (z >> 31);
        }

이 두 가지 변형에 대한 내 문제는 잘린 상태 (상부 절반)가 순열 / 스크램블되기 때문에 순열이 반전 될 수 있다는 것입니다. 역순으로 실행하고 스크램블을 해제하여 모든 고유 결함이있는 단순한 잘린 LCG 만 남길 수 있습니다. 내가 선호하는 것은 전체 상태를 순회 / 스크램블 한 다음 그 잘림을 출력하는 것입니다. (물론 더 적은 비트를 순열 / 스크램블하는 것이 더 빠른 방법이 될 것입니다. 평상시처럼 트레이드 오프가 있습니다. 합리적인 사람들은 중요한 것에 동의하지 않을 수 있습니다.)

그러나 자신의 PCG 변형을 만드는 그의 작업은 제가 작년에 그것을 썼을 때 DXSM 순열에 매우 유용한 영감을 제공했습니다.

@charris PCG64DXSM 구현을 1.19.0에서 사용할 수 있도록 (아직 기본값은 아님) 원하는 것은 무엇입니까? 그 타임 라인은 무엇입니까? 나는 이미 1.19.0rc2가 출시 된 것으로 보는데, 이는 새로운 기능을 도입하기에 _ 훌륭하지 않습니다. 다시 말하지만, 저는이 문제에 대해 화제가되지 않습니다. default_rng() 변경 사항에 대한 정책을 문서화하고 1.20.0에 새로운 내용을 도입하는 것만으로 1.19.0을 릴리스 할 것입니다.

@rkern 최종 rc는 2 주 이상 출시되어야하므로 6 월 하반기에 출시 될 예정입니다. 나는 PCG64DXSM이 테스트를 용이하게한다면 선택 사항으로 선택하는 것을 선호합니다. 저는 그것을 새로운 기능으로 간주하지 않습니다. 그리고 때로는 실제 작업 코드를 가지고 작업을 진행하는 데 도움이됩니다. NumPy는 트렌드 세터입니다 :)

편집 : 물론 새 코드에 큰 문제가 없다고 가정하고 거기에있는 것처럼 보이지 않습니다. 나는 또한 PCG64의 문제에 대해 너무 걱정하지 않으며 권장 절차를 사용하는 데 문제가 없을 것 같습니다.

@imneme 일주일

다소 주제에서 벗어난 질문이 있습니다. 비트 생성기가 임의의 비트를 생성하기를 원하지만 AFAICT, 대부분의 테스트에는 정수가 포함됩니다. 비트를 실제로 테스트 할 때 기존 테스트가 얼마나 잘 수행합니까? 그 지역에 더 익숙한 사람이 그 질문에 답할 수 있다면 가장 감사 할 것입니다.

테스트되고있는 것은 비트의 흐름입니다. 우리는 테스트 소프트웨어에 우리가 출력하는 PRNG의 자연스러운 단어 크기를 알려 주지만 비트를 가장 효율적으로 폴딩하여 낮은 또는 높은 비트에서 발생하는 오류를 가장 효율적으로 유발할 수 있도록합니다. 나쁜 PRNG의 단어. 오늘날 우리 모두가 사용하는 소프트웨어는 PractRand이며 테스트는 여기에 간단히 문서화되어 있습니다 . 읽기에 가장 좋은 논문 은 아마도 이전의 골드 표준 테스트 스위트 인 TestU01 에 대한 설명서 에는 테스트에 대한 자세한 내용이 있습니다.

비정상적으로 들리면 사과하지만 (확실히 지적 되겠지만) 성실합니다. 귀하의 웹 사이트 또는 arXiv에서 구현, 분석, 벤치 마크 및 PractRand 결과를보기를 기대합니다. 우리는 PRNG 연구원이 아닌 (합리적으로 정보를 갖춘) 실무자이며이 제안을 수행 할 수있는 장비가 특히 잘 갖추어져 있지 않습니다. 그 느낌을 볼 수는 있지만 개인적인 시간에 대한 다른 제약을 감안할 때 제안에서 구현 및 분석에 이르기까지 노력을 기울일 의향이 없습니다. 이 제안을 numpy에게 전달하려면 PRNG 연구원이 해당 작업을 수행해야합니다. 이 제안을 다른 사람에게 실제로 전달하는 경우 웹 사이트를 사용하십시오.

나는 당신의 관점을 완벽하게 이해할 수 있습니다. 코드와 벤치 마크는 몇 년 동안 LCG128Mix라는 이름으로 PCG (http://prng.di.unimi.it/pcg.php)의 문제를 설명하는 페이지 하단에있었습니다. 내 하드웨어, Intel (R) Core (TM) i7-7700 CPU @ 3.60GHz, gcc 9.2.1 및 -fno-move-loop-invariants -fno-unroll-loops에서 2.16ns가 걸립니다.

코드는 매우 간단합니다. 표준 LCG와 표준 믹싱 기능을 결합합니다 (Stafford의 개선 된 MurmurHash3의 종료 자). 프로그래밍 가능한 상수를 갖도록 약간 수정했습니다.

    #include <stdint.h>
    __uint128_t x; // state
    __uint64_t c;  // stream constant (odd)

    uint64_t inline next(void) {
        // Put in z the top bits of state
        uint64_t z = x >> 64;
        // Update LCG state
        x = x * ((__uint128_t)1 << 64 ^ 0xd605bbb58c8abbfd) + c;
        // Compute mix
        z = (z ^ (z >> 30)) * 0xbf58476d1ce4e5b9;
        z = (z ^ (z >> 27)) * 0x94d049bb133111eb;
        return z ^ (z >> 31);
    }

앞서 설명했듯이 65 비트 상수는 모듈러스의 제곱근보다 작은 곱셈기의 이론적 문제 때문에 곱셈기로서 64 비트 상수보다 훨씬 낫습니다.

보다 원칙적인 디자인에 관심이 있다면 PractRand 테스트를 실행하겠습니다. 그러나이 믹싱 함수는 훨씬 더 약한 기본 생성기 (단지 가산 성)와 더 작은 상태 (64 비트)에서도 우수한 생성기 SplitMix를 생성했습니다. 따라서 32TB에서 PractRand를 통과하는 SplitMix보다 "더 나을"것입니다.

그리고 기본 생성기는 LCG이므로 60 년대의 모든 일반적인 종소리 (점프, 거리 등)가 있습니다. 또한 결과의 모든 비트가 상위 64 비트의 모든 비트에 의존한다는 통계적 보장도 있습니다. 상태.

다른 생성기에 대한 벤치 마크를 염두에 두거나 다른 컴파일러를 사용하는 경우 알려주십시오.

그러나 동일한 방식으로 진심으로 부탁드립니다. 표준 구성 요소 만 사용하는 "거인의 어깨 위에서는"디자인을 고려하는 데 정말로 관심이있는 경우에만 해당됩니다. 제 시간에도 개인적인 제약이 있고, 기여하게되어 기쁩니다.하지만 고려할 기회가없는 발전기에 시간을 보내는 것은 피하고 싶습니다.

BTW는 관련된 승수의 품질을 개선하는 방법에 대한보다 확실한 측정을 제공하기 위해 PCG DXS 및 일부 대안에서 사용하는 현재 64 비트 승수의 스펙트럼 점수를 f₂에서 f₈까지 계산했습니다.

스펙트럼 점수는 승수의 장점을 판단하는 표준 방법입니다. 0은 나쁘고 1은 우수합니다. 각 점수는 출력에서 ​​쌍, 트리플, 4- 튜플 등이 얼마나 잘 분포되어 있는지를 나타냅니다.

이 7 개의 숫자는 TAoCP에서 Knuth가 제안한대로 첫 번째 점수를 더 중요하게 만들기 위해 클래식 측정 값, 최소값 또는 가중치 측정 값 (첫 번째 점수와 두 번째 점수를 2로 나눈 값 등)으로 재개 할 수 있습니다. , 다음은 현재 승수에 대한 최소 및 가중치 측정 값입니다.

0xda942042e4dd58b  0.633  0.778

그보다 훨씬 더 나은 64 비트 상수가 있습니다.

0xff37f1f758180525  0.761  0.875

기본적으로 동일한 속도로 65 비트로 이동하면 (적어도 LCG128Mix가 동일한 속도 인 경우) 더 나은 가중치 측정을 얻을 수 있습니다.

0x1d605bbb58c8abbfd  0.761  0.899

그 이유는 64 비트 승수에는 f₂ 점수 (≤0.93)에 대한 본질적인 한계가 있으며, 이는 Knuth가 언급 한 바와 같이 가장 관련성이 높습니다.

0xda942042e4dd58b5  0.795
0xff37f1f758180525  0.928
0x1d605bbb58c8abbfd  0.992

따라서 첫 번째 승수는 평범한 f₂ 점수를 갖습니다. 두 번째 승수는 64 비트 승수에 대한 최적 값에 매우 가깝습니다. 65 비트 승수는 이러한 제한이 없으며 일반적으로 가능한 최고인 1에 매우 가까운 점수를가집니다.

완전성을 위해 모든 점수는 다음과 같습니다.

 0xda942042e4dd58b5  0.794572 0.809219 0.911528 0.730396 0.678620 0.632688 0.639625
 0xff37f1f758180525  0.927764 0.913983 0.828210 0.864840 0.775314 0.761406 0.763689 
0x1d605bbb58c8abbfd  0.991889 0.907938 0.830964 0.837980 0.780378 0.797464 0.761493

이 점수를 다시 계산하거나 Guy Steele과 내가 배포 한 코드 ( https://github.com/vigna/CPRNG) 를 사용하여 자신의 승수를 찾을 수 있습니다. 더 나은 승수는 관련 논문에서 가져옵니다.

PCG는 아마도 numpy에 대한 훌륭한 기본 프린팅이 될 것이지만, 더 유망하지만 테스트가 덜한 방법이 있기 때문에 시간의 테스트를 견디지 ​​못할 것이라고 생각합니다. 다음 중 하나를 제안합니다.

하프 카오스 SFC64는 합리적으로 큰 최소주기를 가진 통계적으로 가장 빠른 사운드 생성기 중 하나입니다. SFC64에는 점프 기능이 없지만 _ 속도 오버 헤드없이 2 ^ 63 보장 된 고유 스트림을 지원하도록 확장 할 수 있습니다 _. 카운터를 1 씩 증가시키는 대신 사용자가 선택한 추가 상수 k (홀수 여야 함)로 Weyl 시퀀스 를 추가하기 만하면됩니다. 각 홀수 k는 고유 한 전체 기간을 생성합니다. Weyl 상수를 유지하려면 추가 64 비트 상태가 필요합니다.

typedef struct {uint64_t a, b, c, w, k;} sfcw64_t; // k = stream

static inline uint64_t sfcw64_next(sfcw64_t* s) {
    enum {LROT = 24, RSHIFT = 11, LSHIFT = 3};
    const uint64_t out = s->a + s->b + (s->w += s->k);
    s->a = s->b ^ (s->b >> RSHIFT);
    s->b = s->c + (s->c << LSHIFT);
    s->c = ((s->c << LROT) | (s->c >> (64 - LROT))) + out;
    return out;
}

320 비트 상태는 때때로 바람직하지 않기 때문에 256 비트를 다시 사용하도록 압축하려고했습니다. 비트 믹싱에 Weyl 시퀀스를 더 잘 활용하는 변경된 출력 기능도 주목하십시오. 그것은 좋은 균형을 이루는 것처럼 보이는 128/128 비트 혼란 / 구조화 된 상태를 사용합니다.
/ 편집 : 출력 func + 정리에서 rotl64 () 제거, 8 월 6 일 :

typedef struct {uint64_t a, b, w, k;} tylo64_t;

static inline uint64_t tylo64_next(tylo64_t* s) {
    enum {LROT = 24, RSHIFT = 11, LSHIFT = 3};
    const uint64_t b = s->b, out = s->a ^ (s->w += s->k);
    s->a = (b + (b << LSHIFT)) ^ (b >> RSHIFT);
    s->b = ((b << LROT) | (b >> (64 - LROT))) + out;
    return out;
}

이것은 현재 PractRand 테스트에서 이상없이 4TB를 통과했으며 지금까지 문제없이 Vigna의 Hamming-weight 테스트를 잠시 실행했습니다. ).

참고 : 비트 세트의 약 50 %를 사용하여 (고유 한) 랜덤 Weyl 상수를 사용하는 것이 통계적으로 이점이있을 수 있지만 추가 테스트 또는 분석을 통해서만 이것이 얼마나 중요한지 알 수 있습니다.

/ 편집 : 정리.

@ tylo-work SFC64는 이미 NumPy에 있으며 Philox와 함께 기본 생성기에 관한 것입니다.

좋습니다. 정확히 어떤 것이 구현되었는지 몰랐습니다.이 중에서 전체적으로 가장 적합한 것을 선택하는 것뿐입니까? 충분히 공평하고 명확히 해주셔서 감사합니다.

제안한 생성기를 광범위하게 테스트하여 다른 생성기와 어떻게 쌓이는 지 살펴 보겠습니다. 지금까지는 속도, 출력 품질, 단순성 / 크기 / 휴대 성 및 대규모 병렬 사용에 대해 매우 좋아 보입니다. 하지만 다른 사람들도 시험해 본다면 기쁠 것입니다.

NumPy의 버전은 k=1 가있는 표준 변형입니다.

https://github.com/numpy/numpy/blob/ad30b31af0bb3fbfdc0f11486807edc76cec2680/numpy/random/src/sfc64/sfc64.h#L25 -L33

기본 PRNG에 대한 논의를 처음부터 다시 시작한다고 생각하지 않습니다. 현재 PRNG에 매우 구체적인 문제가 있으며 해당 특정 문제를 해결하는 사용 가능한 밀접하게 관련된 변형을 찾고 있습니다. 우리의 관심사 중 하나는 현재 기본 PRNG가 점프 가능성과 같은 PRNG의 특정 기능을 노출하고이를 대체하는 변형이 여전히 노출해야한다는 것입니다. SFC64 (저희 또는 귀하의)에는 해당 기능이 없습니다.

@bashtage 는 SFC64 의 Weyl 스트림 변형을 추가하기 위해

@ tylo-work 병렬 실행에 관심이 있다면 NumPy의 SeedSequence 구현을 살펴볼 수 있습니다.

기본 PRNG에 대한 논의를 처음부터 다시 시작한다고 생각하지 않습니다. 현재 PRNG에 매우 구체적인 문제가 있으며 해당 특정 문제를 해결하는 사용 가능한 밀접하게 관련된 변형을 찾고 있습니다.

PCG-DXS와 같은 것을 원한다고 가정하면 더 나은 상수 (그리고 매우 미미한 속도 저하)로 할 수있는 추가 개선 사항이 있습니다. 예를 들어, PCG-DXS는 동일한 하위 112 비트 상태를 가진 두 개의 인터리빙 된 상관 하위 시퀀스에서 두 가지 별개 유형의 테스트에 곧 실패합니다.

rng=PCGDXS_int112, seed=0x4d198651
length= 128 gigabytes (2^37 bytes), time= 5700 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low1/64]TMFn(0+2):wl             R= +57.3  p~=   2e-27     FAIL !!
  [Low8/64]FPF-14+6/64:(1,14-0)     R= +17.5  p =  8.0e-16    FAIL
  [other failures in the same tests]
  ...and 1893 test result(s) without anomalies

우리는 ≈65536 개의 상관 시퀀스에 대해 이야기하고 있다는 점에 유의하십시오. 두려워 할 필요가 없습니다.

그러나 0x1d605bbb58c8abbfd와 같은 더 나은 승수와 0x9e3779b97f4a7c15와 같은 더 나은 믹서를 선택하여 생성기를 개선 할 수 있습니다. 첫 번째 숫자는 훨씬 더 나은 스펙트럼 점수를 가진 65 비트 승수입니다. 두 번째 숫자는 64 비트 고정 점 표현의 황금 비율이며, 이는 좋은 혼합 속성을 갖는 것으로 알려져 있습니다 (곱셈 해싱에 대한 Knuth TAoCP 참조). 예를 들어 Eclipse Collections 라이브러리에서 해시 코드를 혼합하는 데 사용됩니다.

결과적으로 동일한 양의 데이터에 대해 FPF 만 실패합니다.

rng=PCG65-DXSϕ_int112, seed=0x4d198651
length= 128 gigabytes (2^37 bytes), time= 5014 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low8/64]FPF-14+6/64:(0,14-0)     R= +16.1  p =  1.5e-14    FAIL
  [other failures in the same test]
  ...and 1892 test result(s) without anomalies

사실, 2TB에서 더 나아가면 PCG-DXS가 동일한 인터리빙 된 상관 하위 시퀀스에 대해 _three_ 유형의 테스트에 실패합니다.

rng=PCGDXS_int112, seed=0x4d198651
length= 2 terabytes (2^41 bytes), time= 53962 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low1/32]TMFn(0+0):wl             R= +50.2  p~=   4e-23     FAIL !!
  [Low8/64]FPF-14+6/64:(1,14-0)     R=+291.1  p =  4.7e-269   FAIL !!!!!!
  [Low8/64]Gap-16:B                 R= +19.5  p =  1.4e-16    FAIL !
  [other failures in the same tests]
  ...and 2153 test result(s) without anomalies

PCG65-DXSϕ는 여전히 FPF 만 실패합니다.

rng=PCGDXS65ϕ_int112, seed=0x4d198651
length= 2 terabytes (2^41 bytes), time= 55280 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low8/64]FPF-14+6/64:(0,14-0)     R=+232.1  p =  2.0e-214   FAIL !!!!!!
  [other failures in the same test]
  ...and 2153 test result(s) without anomalies

물론 조만간 PCG65-DXSϕ도 Gap과 TMFn에 실패 할 것입니다. 그러나 PCG-DXS보다 훨씬 더 많은 출력을 볼 필요가 있습니다.

이것은 PCG65-DXSϕ에 대한 완전한 코드이며, 더 나은 상수를 가진 PCG-DXS입니다.

#include <stdint.h>

__uint128_t x; // State
uint64_t c; // Additive constant

static inline uint64_t output(__uint128_t internal) {
    uint64_t hi = internal >> 64;
    uint64_t lo = internal;

    lo |= 1;
    hi ^= hi >> 32;
    hi *= 0x9e3779b97f4a7c15;
    hi ^= hi >> 48;
    hi *= lo;
    return hi;
}

static uint64_t inline next(void) {
    __uint128_t old_x = x;
    x = x *  ((__uint128_t)1 << 64 ^ 0xd605bbb58c8abbfd) + c;
    return output(old_x);
}

한계 속도 저하는 추가 명령어 (65 비트 승수로 인해 발생)와로드 할 두 개의 64 비트 상수가 있기 때문입니다.

나는 일반적으로 이런 종류의 발전기를지지하지는 않지만 PCG65-DXSϕ는 상관 관계를 숨기는 데 PCG-DXS보다 훨씬 낫습니다.

@Vigna , FYI, 또한 인터리빙 테스트를 수행 한 결과 128 개 이상의 인터리브 스트림을 생성 할 때 xoshiro256 **이 다소 빠르게 실패하는 것을 발견했습니다. 256으로 빠르게 실패했습니다. 테스트의 요점은 각 스트림이 일부 선형 종속성으로 초기화되었을 때 PRNG가 얼마나 잘 작동하는지 확인하는 것입니다. 기본적으로 상태는 s[0]=s[1]=s[2]=s[3] = k1 + stream*k2 초기화됩니다. 그런 다음 12 개의 출력을 건너 뛰고 기본적으로 sfc64가 초기화됩니다.

나는 이것이 xoshiro에 권장되는 초기화가 아니라는 것을 알고 있지만, 인터리빙 스트림이 거의없는 xoshiro에 대해서는 테스트가 괜찮아 보였지만 많은 경우 실패했다는 것이 여전히 흥미롭고 약간 걱정됩니다.

seed: 1591888413
RNG_test using PractRand version 0.95
RNG = RNG_stdin64, seed = unknown
test set = core, folding = standard (64 bit)
...
rng=RNG_stdin64, seed=unknown
length= 2 gigabytes (2^31 bytes), time= 29.6 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low1/64]FPF-14+6/16:(1,14-1)     R=  +7.2  p =  3.7e-6   unusual
  [Low1/64]FPF-14+6/16:all          R=  +9.6  p =  1.8e-8   very suspicious
  ...and 261 test result(s) without anomalies

rng=RNG_stdin64, seed=unknown
length= 4 gigabytes (2^32 bytes), time= 55.5 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low1/64]FPF-14+6/16:(0,14-0)     R= +13.4  p =  4.7e-12   VERY SUSPICIOUS
  [Low1/64]FPF-14+6/16:(1,14-0)     R=  +9.4  p =  2.6e-8   suspicious
  [Low1/64]FPF-14+6/16:(2,14-1)     R=  +7.7  p =  1.3e-6   unusual
  [Low1/64]FPF-14+6/16:all          R= +17.4  p =  8.8e-16    FAIL !
  ...and 275 test result(s) without anomalies

또한 SFC64 및 TYLO64의 초기화를 약화시켜 2 개의 출력 만 건너 뛰려고했지만 여전히 괜찮아 보였습니다.
성능 : xoshiro256 **은 다른 두 컴퓨터보다 내 컴퓨터에서 33 % 느리게 실행됩니다. TYLO64는 196 비트의 상태 변수 만 업데이트합니다. 다음은 테스트 프로그램입니다.

int main()
{
    //FILE* f = freopen(NULL, "wb", stdout);  // Only necessary on Windows, but harmless.
    enum {THREADS = 256};
    uint64_t seed = 1591888413; // <- e.g. this fails. // (uint64_t) time(NULL); 
    fprintf(stderr, "seed: %lu\n", seed);

    static tylo64_t tyl[THREADS];
    static sfc64_t sfc[THREADS];
    static uint64_t xo[THREADS][4];

    for (size_t i = 0; i < THREADS; ++i) {
    tyl[i] = tylo64_seed(seed + (12839732 * i), 19287319823 * i);
    sfc[i] = sfc64_seed(seed + (12839732 * i));
    xo[i][0] = xo[i][1] = xo[i][2] = xo[i][3] = seed + (12839732 * i);
    for (int j=0; j<12; ++j) xoshiro256starstar_rand(xo[i]);
    }
    static uint64_t buffer[THREADS];
    size_t n = 1024 * 1024 * 256 / THREADS;

    while (1/*n--*/) {
        for (int i=0; i<THREADS; ++i) {
        //buffer[i] = tylo64_rand(&tyl[i]);
        //buffer[i] = sfc64_rand(&sfc[i]);
            buffer[i] = xoshiro256starstar_rand(xo[i]);
        }
        fwrite((void*) buffer, sizeof(buffer[0]), THREADS, stdout);
    }
    return 0;
}

관련 헤더 코드를 포함하겠습니다.

typedef struct {uint64_t a, b, w, k;} tylo64_t; // k = stream

static inline uint64_t tylo64_rand(tylo64_t* s) {
    enum {LROT = 24, RSHIFT = 11, LSHIFT = 3};
    const uint64_t b = s->b, w = s->w, out = (s->a + w) ^ (s->w += s->k);
    s->a = (b + (b << LSHIFT)) ^ (b >> RSHIFT);
    s->b = ((b << LROT) | (b >> (64 - LROT))) + out;
    return out;
}

/* stream in range [0, 2^63) */
static inline tylo64_t tylo64_seed(const uint64_t seed, const uint64_t stream) {
    tylo64_t state = {seed, seed, seed, (stream << 1) | 1};
    for (int i = 0; i < 12; ++i) tylo64_rand(&state);
    return state;
}

static inline uint64_t rotl(const uint64_t x, int k) {
    return (x << k) | (x >> (64 - k));
}
static inline uint64_t xoshiro256starstar_rand(uint64_t* s) {
    const uint64_t result = rotl(s[1] * 5, 7) * 9;
    const uint64_t t = s[1] << 17;
    s[2] ^= s[0];
    s[3] ^= s[1];
    s[1] ^= s[2];
    s[0] ^= s[3];
    s[2] ^= t;
    s[3] = rotl(s[3], 45);
    return result;
}

@ tylo-work 분석에 감사하지만 집중하기 위해이 문제가 정말로 필요합니다. 이 토론을 계속하고 싶다면 자신의 Github 저장소에 작업을 게시하고 여기에 사람들을 초대하는 게시물을 하나 더 작성하는 것이 좋습니다. 그 외 모두 거기에서 응답 해주십시오. 도움 주셔서 감사합니다.

@imneme @rkern Time은 1.19 릴리스에서 실행 중입니다.

@rkern PCG64DXSM이 1.19.0으로 진입하지 못할 것 같습니다. 이번 주말에 출시 할 예정입니다. 위에서 언급 한 변경 정책 / 예정된 변경 사항에 대한 메모를 작성해 주시면 감사하겠습니다.

죄송합니다. 다른 관련없는 문제를 처리하고 있습니다. 토론에 따르면 PCG64DXSM은 새로운 기본값이 아닌 대체 옵션으로 계획 되었기 때문에 작은 지연이 큰 문제라고 생각하지 않습니다 (적어도 현재로서는).

이제 1.20이 시작되었으므로 이것을 다시 방문하여 DXSM으로 이동할 때입니까?

분기하기 전에 이동을 수행 할 시간이 있지만 다음 주 정도 이내에 시작하는 것이 좋습니다. @bashtage 나는 당신이 PCG64DXSM 준비가 되었다고 생각하고 이것은 주로 기본 스트림에서 스위치를 뒤집는 결정이 필요합니까?

보시다시피 우리가 쉽게 구할 수 있다면 1.20을 위해 이것을해야하는 것처럼 들렸습니다.

IIRC, 우리는 링크 될 수있는 참조를 기다리고있었습니다. 그러나 난수 사람들이 변화에 만족한다면 우리는 그것을 사용해야합니다. Windows 용 특수 코드가 필요합니까?

그것은 단지 다른 상수이고 다른 스크램블링 기능입니다. @rkern Windows에서 원래 PCG64 구현에 쓴 것보다 더 많은 새로운 아무것도 없습니다. (성능을 위해) 일부 코드를 공유하기보다는 완전히 독립형 PCG64DXSM을 사용하기로 결정했다고 생각합니다.

rkern의 WIP 지점 에서 시작하는

@rkern이 원한다고 생각하는 블로그 게시물을 작성하겠다고 말했지만 다른 문제에 참석해 왔지만 아직 발생하지 않았습니다 (죄송합니다). 그 동안 DXSM 순열은 테스트 중이며 계속해서 원본보다 개선 된 것처럼 보입니다. 스레드의 초기 발언에서 @rkern 이 더 강력한 출력 순열을 좋아했을 수도 있다고 생각하지만 그렇게하면 속도가