Numpy: Numpyが提供するPCGの実装には、重大で危険な自己相関があります

@imneme、@bashtage、@rkernはここ当局だろうが、私たちは、この上で行っていると思うし、私たちが好適なぜそれがSeedSequence.spawn超えるインターフェースjumped一つ。 たとえば、APIについて話し合っていたときにhttps://numpy.org/devdocs/reference/random/parallel.htmlのアドバイスを確認し、必要に応じて改善を提案して

@mattipこれはジャンプとは何の関係もありません。

ドキュメントを改善することは常に良い考えですが、実際には大規模な変更を加えることは難しいと思います。

私はおそらく推薦AESCounter AES-NIまたはを持つ人のためのSPECK128 、高度に並列設定でなしに、誰のために。

加法定数を変更することによってLCGによって生成されるシーケンスは、符号の変更と加法定数を法としてすべて同じであるため、異なる「ストリーム」でも同じことが発生する可能性があります。

これを定量化できますか？ 同じ増分を使用して障害を複製できますが、増分と状態をシードし、2つの異なるランダムな増分で障害をまだ観察していません。 増分も注意深く作成する必要がある場合、それは実際の誕生日の衝突頻度に影響します。

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

OK、もう一度やり直します。

2乗の係数を持つLCGには複数のストリームはありません。 多くの人が初期の頃にそれを信じていました、そしてそれらの「ストリーム」で面白いことをすると主張する長い古い論文さえあります、しかし定数を変えることによってあなたが得る軌道は_すべて同じモジュロ加算であることが何十年もの間知られています定数で、場合によっては符号の変更_。 私がそれをたどることができる最も遠いのは

Mark J. Durst、並列乱数生成に線形合同法を使用、
1989 Winter Simulation Conference Proceedings、IEEE Press、1989年、462〜466ページ。

そこで、次のように設定できる別のプログラムhttp://prng.di.unimi.it/corrpcgnumpy.cを作成しました。

• PRNGの初期状態。
• 別のPRNGの初期状態。
• 最初のPRNGの任意の「ストリーム定数」。
• 2番目のPRNGの任意の「ストリーム定数」（両方とも偶数または両方とも奇数である必要があります。この制限は、追加の操作で削除できます）。
• 基本的に、最初のPRNGの同じビットで開始するように、2番目のPRNGで逆に設定する固定数の下位ビット。 残りのビットは、指定した2番目の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にはこの動作がありますが、神のために、それは最新の発電機ではありません）。

SabastianoのPCGに対する批判は、2018年のこのブログ投稿で取り上げられています。

短いバージョンでは、特定のシードを考案することが許可されている場合、ほとんどすべてのPRNGから「見栄えの悪い」動作を示すことができます。 PCGはどういうわけかユニークであるという彼の主張にもかかわらず、実際にはPCGはかなり従来型です。PCGのストリームは、たとえば、広く使用されている別のPRNGであるSplitMixのストリームよりも悪くはありません。

それは完全に誤りです。 私が間違っていることを証明するために、MRG32k3aまたはxoshiro256 ++からの2つの相関する重複しないシーケンスを示します。

重複しないと言ったことはありません。 xoshiro256 ++で現在利用可能なテストを見せてください。 2つのシードが重複を回避すること。

対照的に、私はあなたが示した「相関関係」が本質的に重複の形であることを示すPCGのテストを持っています。

「本質的に」や「フォーム」のようにFUDと戦うことはできませんが、 http：//prng.di.unimi.it/intpcgnumpy.cを変更して、最初に各PRNGを100億回繰り返し、エラーで終了するようにしました。生成されたシーケンスが他の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 ++で現在利用可能なテストを見せてください。 2つのシードが重複を回避すること。

ささいなことです。ストリームの長さを決定し、繰り返し、2つのストリームが初期状態と交差しないことを確認します。 これは、プログラムhttp://prng.di.unimi.it/intpcgnumpy.cで相関PCGストリームが重複しないことを示すために使用したのと同じコードです。

PCGはどういうわけかユニークであるという彼の主張にもかかわらず、実際にはPCGはかなり従来型です。PCGのストリームは、たとえば、広く使用されている別のPRNGであるSplitMixのストリームよりも悪くはありません。

私見、PCG内の自己相関ははるかに悪いです。 LCGに関するダーストの劇的な1989年の結果に類似した、SplitMixインスタンスの基礎となる加法ジェネレーターの結果はありません。

しかし、SplitMixの非常に軽度の問題は知られており、 JEP 356は、これらの問題に対処しようとする新しいクラスの分割可能ジェネレーターLXMを提供します。 PCGに移り、欠陥の少ないものに交換する時が来ました。

根本的な問題は両方のジェネレーターで知られており、状態の組み合わせが不足していることが原因です。 これらのジェネレーターの1つの状態のビット_k_を変更した場合、変更がビット_k_より下に伝播することはありません。 これは、プライムモジュラスを持つLCG、F2線形ジェネレーター、CMWCジェネレーターなどでは発生しません。他のすべてのジェネレーターは、可能な限り迅速かつ可能な限り状態を混合しようとします。

PCGとSplitMixの問題を同一視することは、真っ赤なニシンです。 SplitMixには、非常に単純な基礎となるジェネレーターがあり、追加機能がありますが、それに加えて、非常に強力なスクランブリング関数があります。これは、ApplebyのMurmurHash3ハッシュ関数の64ビットファイナライザーであり、スタッフォード（http://zimbry.blogspot.com/2011/09/better-bit-mixing-improving-on.html）によって改善されました。 関数の定数は、特定の測定可能ななだれ特性を持つようにトレーニングされています。 少数のビットの変更でさえ、すべての出力に広がる傾向があります。 言い換えれば、SplitMixは巨人の肩の上に立っています。

それどころか、PCGジェネレーターの基礎となるLCGにも同じ混合不足の問題がありますが、スクランブリング関数は、理論的または統計的な保証なしに、作成者が組み立てた算術演算と論理演算の単純なシーケンスです。 基礎となるLCGのすべてのシーケンスが、加法定数と場合によっては符号の変化を法として同じであるという事実に注意して考案されていれば、問題に対処することができたはずです。

しかし、作者は、シーケンスが互いに簡単に導出できることを知りませんでした。 これは、PCGテクニカルレポート（https://www.pcg-random.org/pdf/hmc-cs-2014-0905.pdf）のセクション4.2.3のこのステートメントから簡単に確認できます。

「_c_を選択するたびに、別のシーケンスと共通の連続する出力のペアがない、異なる番号のシーケンスが生成されます。」

これは、シーケンスが異なること、つまり、基になるLCGが複数のストリームを提供することの証拠と見なされます。 このトピックに関するダーストの1989年の否定的な結果は、論文のどこにも現れていません。 前に述べたように、これらの結果により、このようなシーケンスはすべて同じであり、加法定数を法として、場合によっては符号が変化します（PCGで発生するように、最大​​効力の2の累乗係数を持つLCGの場合）。

ダーストの結果を引用しないのは「誠実な」間違いだと確信していますが、問題は、使用している基になるLCGが、ある意味で「異なる」「ストリーム」を提供していると確信すると、そうでない場合は最終的になることです。 PCGのようなジェネレーターを使用すると、「ストリーム」を変更した場合でも、サブシーケンスごとに2 ^ 72の重複しない相関サブシーケンスが存在します。

ご意見ありがとうございました。 今のところ、「PCGは良い/悪い」のような二元的な判断には興味がありません。 そのような議論のためにあなた自身のフォーラムを使用してください。 ここで話題になっているのは、numpyが何をするかであり、その最終的な判断はnumpyの開発者にあります。 皆さんがこの議論にもたらした専門知識に感謝しますが、最終的な判断ではなく、根本的な事実に焦点を当てたいと思います。 私は特に、私たちが持っているヘッドルームの量のアイデアを私に与える定量的なステートメントに感謝します。 以前の判断が間違っていたのは、判断に飛びつくのが早すぎたからですので、また避けていただきたいと思います。 ありがとうございました。

2つのジェネレーターが2つの相関シード（ランダムに選択）から開始する確率を50％以上取得するには、ランダムに開始するジェネレーターが約50万個必要であることに注意してください（誕生日のパラドックス）。

@vignaこの計算について教えていただけますか？ 私が精通している誕生日の衝突計算では、 2**(n/2)アイテムでnビットの衝突が50％発生する可能性があります（2の因数を与えるか取る）。 50万ドルは2**19なので、危険な相関関係は下位ビットの40ビット前後の衝突から始まると主張しているようですが、これが実際に観察できるという証拠は見ていません。 テストをキャンセルする前に、下位40ビットを共有するペアをテストし、PractRandで16TiBに到達しました。 40ビットの衝突による障害を観察した場合、それを確認するためにいくつのTiBをテストする必要がありましたか？

増分を変更しても、衝突の確率には影響しないと確信しています。 「PCGストリーム」のメリットについてのこれ以上の議論はトピックから外れています。 その議論を「作者」を繰り返し槌で打つ言い訳として使用することは特に歓迎されておらず、私たちの行動規範を踏みにじっています。 持続するということは、あなたの意見なしに進めなければならないことを意味します。 ありがとうございました。

@imnemeこれは、2の大きな累乗の倍数でジャンプするているようです。同じ増分でPCG64インスタンスのペアを作成し、下位のnを共有するとビット、2つの間で計算する距離は1 << n倍数です。 より強力なDXSM出力関数も、この症状を解決しているように見えます。 インクリメントを共有するPCG64DXSMインスタンスのペアと、状態の下位64ビットを2TiBまで問題なくテストしました。

OK、これは恥ずかしいことです。それは50億ドルではなく、5億ドルでした。 1文字で大きな違いが生まれます。 すべりをお詫びします。

しかし、先に述べたように、これはまったく同じ開始状態に達する確率であり、相関するサブシーケンスの重なりが大きくなる確率ではありません。 個人的には、相関サブシーケンスのないPRNGを使用することを好みます。なぜなら、それらはたくさんあるからですが、あなたが正しく言うように、決定はあなただけです。

スクランブリング関数を修正してミキシング特性を向上させることは、完全に合理的な解決策のように思えます。

私の投稿は、PCGとSplitMixの構造の違いを明確にすることを目的としていました。以前の投稿では、同様の問題があると主張していたため、それは正しい記述ではないと思います。 SplitMix用にhttp://prng.di.unimi.it/corrpcgnumpy.cのようなプログラムを作成することはできません。

@rkern 、あなたは尋ねました：

@imnemeこれは、2の大きな累乗の倍数でジャンプするているようです。同じ増分でPCG64インスタンスのペアを作成し、下位のnを共有するとビット、2つの間で計算する距離は1 << n倍数です。 より強力なDXSM出力関数も、この症状を解決しているように見えます。 インクリメントを共有するPCG64DXSMインスタンスのペアと、状態の下位64ビットを2TiBまで問題なくテストしました。

昨年のディスカッションスレッドを見つけてリンクしていただきありがとうございます。 はい、Sebastianoが彼の応答で述べているように、

スクランブリング関数を修正してミキシング特性を向上させることは、完全に合理的な解決策のように思えます。

XSL-RRは物事の弱点にあります。 対照的に、PCGペーパーからの元のRXS-M出力機能と新しいDXSM出力機能はどちらもスクランブルの方法でより多くのことを行うので、この種の問題は示しません。 DXSM（昨年のこのコミットでPCGソースに追加された）は、XSL-RRよりも強力になるように特別に設計されましたが、同様の時間パフォーマンスを備えています（RXS-Mを参照、遅い）。 昨年、DXSMをかなりハードにテストしましたが、実行の67日後に長時間の停電が発生し、サーバーが停止し（UPSのバッテリーが消耗しました）、テストの実行が終了しましたが、その時点で、通常の両方でかなり良好に証明されました。テスト（128 TBの出力がテストされました）および2 ^ 48のジャンプ（64 TBの出力がテストされました。実行速度が遅いため）。

DXSMを設計しなくても、RXS-Mが問題を処理したとしたら、1つの質問は、代わりに弱いXSL-RR順列を使用した理由です。出力関数で常に非常に強力なビットスクランブリングを使用しないのはなぜですか。 答えは、基本的にはサイクルに帰着するということです。 スピードは人にとって重要なので、必要以上にスクランブルをかけないようにします。

彼のアプローチと私のアプローチには多くの共通点があるため、これはセバスティアーノがよく知っている問題です。 私たちはそれぞれ、最新の統計的検定（私の場合はLCG、彼の場合はMarsagliaのXorShift LFSR）に失敗する、長い間確立されたアプローチを採用し、スクランブル出力関数を追加してそれを利用します。 私たちは両方ともその出力関数を安価にするよう努めていますが、出力関数でマスクしようとしている基盤となるジェネレーターの欠陥が明らかになっているところを少し見つけました。 彼の場合、それは線形性の問題です。

しかし、私を大いに喜ばせた最近の研究で、彼はまた、出力関数によって十分にマスクされていないハミング重みの問題（私自身の長年の懸念を反映している）を持っているLFSRベースの設計の数を示しました。 彼自身のジェネレーターは彼のテストに合格しているので、それは何かですが、2018年に彼の新しいxoshiro PRNGを見ていたとき、下にあるジェネレーターからのハミング重みの問題が彼の出力関数を通過したように見えました。 それ以来、彼は新しい出力関数でxoshiroを改訂しましたが、それでうまくいくことを願っています（彼は他にもいくつか変更を加えたので、このテストプログラムで強調されている繰り返しの問題も修正されるのではないでしょうか？）。

彼の相関プログラムについては、2018年に彼がさまざまな問題（不自然なシードなど）で書いたプログラムを含むPCGの批評を彼のウェブサイトに掲載したときに、私は同様のプログラムの束を含むたSplitMixで相関ストリームを作成するcorrsplitmix2.cを含む、他の長く確立されたPRNGの場合。 セバスチャンがそれができないと言ったときに何を意味するのかはよくわかりませんが、彼の新しいプログラムが彼のものと実質的に異なるかどうかを確認するために彼のテストプログラムを詳しく調べる機会がなかったことを認めます数年前に書いた。

私の理解不足を許してください-しかし、この段階で誰かに要約の結論を求めることはできますか？ デフォルトのPCGが安全でない現実的な状況はありますか？ デフォルトを切り替えるための引数は何ですか？

簡単な方法は、高（超高？）次元のアプリケーションと相関シーケンスの確率に関するドキュメントを追加することです。

より難しいパスは、ストリームを中断する出力関数を置き換えることです。 default_rngがどれほど強力な約束をするのかわかりません。 ドキュメントはこれが変更される可能性があることを警告していないようであるため、変更するには非推奨サイクルが必要になる可能性があります。 これには、新しい出力関数をスタンドアロンビットジェネレーターとして追加し（またはPCG64から構成可能で、より賢明です）、XXXX年/リリースY.ZZ以降に変更されることをユーザーに警告する必要があります。

最も難しい方法は、新しいデフォルトのrngを見つけることです。 初めてのことは簡単ではなく、過去18か月間、針を特定の方向に動かすために何も変わっていないと思います。

default_rng()変更についてgh-16493を開きましたが、この問題に関連しているとは思いません。話し合う必要があるかどうかさえわかりません。おそらくずっと前にルールを設定していたので、私はしません。覚えておいてください。

私はこの議論を完全に理解しているとは主張していませんが、理解すべきことが2つあるようです。

1. 私たちには十分な前進があると確信しているので、これについてロバートを信頼する必要があります。今のところ、私たちの知る限りでは問題ないように思えますか？ （つまり、実際の衝突の確率は、NumPyが使用される可能性のあるものよりも大きい環境でも、おそらく恥ずかしいほど低いのでしょうか？将来デフォルトを変更する必要があるかどうかは別の問題です。）

2. 私たちは次のように述べています。

   [...]と：math： 2^{127}ストリームをサポートします

   数字がどこから来ているのか正確にはわからないので、私たちの側では少し誇張されているように聞こえますが、完全に正しいと少し調整したと見なすことができますか？ または、追加の詳細を提供する外部リソースにリンクしますか？

今すぐ行う最も簡単な方法は、 PCG64DXSM BitGeneratorを追加することです。これは、「安価な乗数」とより強力なDXSM出力関数を備えたPCG64のバリアントです。 これは、現在PCG64実装にあるXSL-RR出力関数からのステップアップであり、ランタイムパフォーマンスを損なうことなく統計的に優れたパフォーマンスを発揮することに誰もが同意していると思います。 PCG64が私たちが提供するBitGeneratorのは、ニッチでの簡単なアップグレードです。 PCG64と一緒に追加する必要があると思います。

ちなみに、 PCG64コンストラクターのオプションではなく、 BitGeneratorという名前の別のファイルにすることをお勧めします。 このようなオプションは、さまざまなアルゴリズムやバリアントを提供することを目的としたrandomgenで優れていますが、 numpy場合は、選択を「グラブアンドゴー」にする必要があると思います。できる限り。

default_rng()提供するものに変更を加えるためのポリシーを実際に解決したとは思いません。 私が提案したとき、その機能をGenerator()コンストラクターに入れるよりも、それを好んだ理由の1つは、必要に応じて非推奨にして別の名前の関数に移動できるという考えを持ち出しました。 ただし、当時、 default_rng()は、基になるBitGenerator多くの詳細を公開する必要があるかもしれないと考えていましたが、その後は回避しました。 PCG64DXSMはPCG64と同じAPI（特に.jumped() ）を公開するため、新しいデフォルトとして使用するとビットストリームが変更されるという唯一の考慮事項があります。 NEP 19のGeneratorメソッドからのストリームに対する他の変更と同じタイムラインに従うのが合理的だと思います（つまり、 X.Y.0機能リリース）。 必要に応じて、もう少し慎重になることを選択できます。最初に、 PCG64DXSMを1.20.0とドキュメントで利用可能なBitGeneratorとして公開します（ただし、 warn()は公開しません）。 、ノイズが多すぎて効果がない） default_rng()が1.21.0使用するように変更されます。

新しいBGを追加する一環として、PCG64のメモを更新してガイドとしての役割を開始し、新しいバリアントを優先する理由を提供するとよいでしょう。

1. 私たちには十分な前進があると確信しているので、これについてロバートを信頼する必要があります。今のところ、私たちの知る限りでは問題ないように思えますか？ （つまり、実際の衝突の確率は、NumPyが使用される可能性のあるものよりも大きい環境でも、おそらく恥ずかしいほど低いのでしょうか？将来デフォルトを変更する必要があるかどうかは別の問題です。）

それはおそらく少しグリブすぎます。 これは、ストリームの数、各ストリームから取得するデータの量、および誕生日の衝突に対するリスク許容度によって異なります。 私はまだその数学をわかりやすい段落にまとめて、わかりやすい推奨事項を作成することに慣れていません。そのため、このGithubの問題をしばらく再検討していません。 ただし、_今_修正する必要があるのはヘアオンファイアの問題ではないと思います。

後で何かを書きますが、このスレッドでそれを見ると、私たちは昨年行った地面を読み直しています。 SebastianoがNumPyがPCGを出荷したことを発見した以外は何も変わっていません。 昨年のNumPyチームの分析はより詳細であり、より妥当なシナリオを検討しました。

私の好みは、混乱を減らすために、できるだけ早くデフォルトをアップグレードすることです。 つまり、廃止サイクルを待たないでください。

@ imneme-ありがとう

おそらくそれについての過去の投稿爆発はこれです。 確かに読む価値があると思います。 そこからスレッドを上にスクロールして、これらの問題について話しているのを見ることができます。 それはPCG32についてでした。

私は言いたいことを頭の中に持っていましたが、1年前の投稿を見ると、ここと他の場所の両方ですでにすべてを言っています（私のブログ（2017）、 reddit 、私のブログ（2018） 、およびNumPyディスカッションなどで）

ストリームとその自己相似性（ @rkernがストリーム依存テスターを作成した）について、私は昨年次のように書いています。

前述の私のブログ投稿で述べたように、PCGのストリームにはSplitMixのストリームと多くの共通点があります。

@mdickinsonのグラフに関して、カウンターベースの暗号化のものを含む状態全体をシードできる_every_ PRNGの場合、出力が何らかの方法で相関しているPRNGがあるシードを考案できます（これを行う最も簡単な方法）短い距離にあるPRNG状態を作成することですが、多くの場合、それらがどのように機能するかを理解することに基づいて他のことを行うことができます）。 また、フルステートシードを許可しないPRNGはこの問題を回避できますが、そうすることで新しい問題が発生するだけで、可能な状態のごく一部にしか実際にアクセスできません。

ストリームを考える正しい方法は、シードする必要があるよりランダムな状態です。 1,2,3のような小さな値を使用することは、_any_ PRNGのシード目的では一般的に悪い考えです（誰もがこれらのシードを好む場合、対応する初期シーケンスが過大評価されるため）。

ストリームとはまったく呼ばず、状態と呼ぶこともできます。 それがマルサリーアがXorWowでしたことcounterは残りの状態とまったく相互作用せず、LCGと同様に、初期値の変動は実際には追加された定数になります。

SplitMix、PCG、およびXorWowのストリームは、「愚かな」ストリームと呼ばれるものです。 それらは、ジェネレータの些細な再パラメータ化を構成します。 ただし、これには価値があります。 ストリームがない場合、PRNGは42の興味深い密接な繰り返しを持ち、42はすばやく連続して数回出現し、42に対してのみこれを実行し、他の数は実行しないと仮定します。 愚かな「ただの増分」または「ただのxor」ストリームを使用すると、実際には、奇妙な繰り返しを42にハードワイヤリングすることを回避できます。 すべての数字には、奇妙な繰り返しであるストリームがあります。 （このため、 Xoshiro 256のクローズリピートの問題を修復するために適用する修正は、Weylシーケンスで混合することです。）

（私はその後で、より深みに入ったこのコメントとで、この1 。）

重要なポイントは、ほぼすべてのPRNGの場合、少しの時間とエネルギーで病理学的シードを考案できることです。 PCGはやや珍しい立場にあり、特に手作りの病状を持つPCGのもっともらしい見た目の種まきを楽しんでいる人がいます（つまり、Sebastiano）。 その作業の結果として、私は振り返り、彼のPRNGと他の長年のPRNGの両方に対して同じことを行いました。

一般に、PRNG状態を「ちょっとランダム」に見えるもので初期化する必要があります。 たとえ人々が他の方法でやりたいとしても、それはかなり普遍的seed_seq作成した理由）。 「不自然なシードを実行しよう」ゲームをプレイしたい場合は、100個のLFSRの初期化のコレクションを作成し、それらすべてをゼロランドに到達することから1K離すのは難しくありません。 不自然な初期化はすべて十分に無害に見えますが、同時にハミング重みのこの奇妙な低下にぶつかります。

妥当なエントロピーで初期化されたPCGジェネレーターを使用している場合は、問題ありません。 1、2、3のようなジャンクで初期化する場合、PRNGでは実際に

しかし、DXSMは確かに強力です。 私はそれがより良いか、私はそれを成し遂げなかっただろうと思いますが、実際にはユーザーが古典的なPCG64の実装で問題に遭遇することはないということを理解する価値があります。

PCG64のストリームに対する批判/防御を（LCG増分を介して）現在の議論から切り離したいと思います。 LCGの数学のために特定の二重性が関係していますが、それは最初にここで提起された中心的な問題ではありません。 また、Sebastianoの元の批評、あなたの応答、または古いメガスレッドに存在していたよりも、考慮すべき詳細がここにあります。 おそらく、数学にもっと時間を費やした専門家にとっては、そのつながりはより明白ですが、少なくとも実際の結果は今ではより明確になっています。

重要なポイントは、ほぼすべてのPRNGの場合、少しの時間とエネルギーで病理学的シードを考案できることです。

確かに、しかし、私の目の前で決定を下すのは、バイナリのできない/できないということではありません。 有限のPRNGからあまりにも多くの数値を引き出すと、最終的にPractRandがそれを検討します。 そのバイナリファクトは、そのPRNGアルゴリズムを無効にしません。 そのバイナリから離れてヘッドルームの概念を確立することは、元のPCGペーパーについて私が本当に感謝したことの1つでした。 敵対的に生成された病状を考えると、その病状が良好なエントロピーシードからランダムに発生する可能性がある頻度を調べることができます。 それを数値化して、ユーザーへの実践的なアドバイスにしたいと思います。

下位58ビットと同じ増分を共有する2つの状態（ピンをその中に配置します）を考えると、これらの状態からPCG64 XSL-RRインスタンスをインターリーブすると、約32GiBでPractRandで実際に観察可能な障害が発生します。 それを避けたいのは当然だと思います。 それでは、それをベンチマークとして、適切なエントロピーシードで発生する頻度を見てみましょう。 幸いなことに、この敵対的なスキームは確率論的分析に適しています（すべてがそれほど友好的であるとは限りません）。 nインスタンスの場合、任意の2が同じ下位58ビットを共有する確率はn**2 / 2**58 、二重カウントの場合は2の因数を与えます。 したがって、5億のインスタンスでは、インターリーブされた場合にPractRandが失敗するようなペアリングが1つある可能性が高くなります。 5億はたくさんあります！ 私の判断では、これほど多くのPCG64インスタンスを作成しようとするnumpyプログラムはおそらく見られないでしょう。 numpyは間違ったツールである可能性があります。

また、後続の描画が他の初期状態の下位58ビットの衝突状態のいずれかと「交差」する初期状態を回避することも合理的だと思います。 私はまだその論理を考えようとしていますが、長さは二次的ではなく線形的に確率に影響を与えると思います。 私が正しく、各インスタンスから16 GiBを描画したい場合（ 2**28描画）、これはPractRandの失敗を示した各ペアから描画した量です。約2**15しか作業できません。交差点を観測する可能性が非常に高くなる前のPCG64を使用すると、実際のnumpyプログラムで問題が発生する可能性は低いと思います。 ただし、一部のアプリケーションは近づき始める可能性があります（たとえば、大規模な分散強化学習の実行）。

そのインクリメントピンを取り出して対処しましょう。 XSL-RR出力関数では、状態に加えて増分をエントロピーシードしても、この特定の分析は変更されないと言っても過言ではありません。 エントロピーシードされた増分の任意のペアに対して、実際に衝突する状態の数は同じであるようです。 これらの状態を意図的に構築するための具体的な手順は、同じ下位58ビットでバッシングするよりも複雑に見えますが、衝突する状態の数は同じであるように見えるため、確率の計算は同じままです。 これは、一般的にPCGスキームに固有のものではありません。 DXSM出力関数は十分に強力であるため、増分を変更すると（単純な+2 ）、基になるLCGの最悪の状態（距離メトリックが0与える場合）にも抵抗するのに十分であるように見えます。

最後に、私たち全員が完全に一致しているように見えることを繰り返します。 PCG64DXSMは良い考えです。 他に何もないとしても、その改善された統計的特性は、私が文書化することを余儀なくされていると感じるメンタルモデルを単純化します。

同じストリームにジェネレーターがある場合にのみ問題が発生するため、ストリームは依然としてある程度関連性があります。

しかし、どのような状況下で、それらは同じ下位58ビットを持ち、同じストリーム上にあるでしょうか？ これが発生するユースケースはありますか？

私が知っているやや現実的なケースの1つは、昨年（ jumpedについて話したとき）に話し合ったケースです。以前にリンクしたこの投稿で話しました。

同じストリームにジェネレーターがある場合にのみ問題が発生するため、ストリームは依然としてある程度関連性があります。

残念ながら、XSL-RRの場合はそうではありません。 2つのPCG64 XSL-RRインスタンスについて考えてみましょう。 増分を任意にエントロピーシードし、状態の1つをエントロピーシードします。 同じ下位58ビット状態の同じインクリメントの失敗と同じ方法でPractRandに失敗する他のPCG64インスタンスの2**70不良状態を構築できます。 同じインクリメントの場合よりも実行が複雑になります。 異なる増分で最初の状態として下位58ビットを共有する代わりに、最初のインスタンスから0距離（LCG距離測定による）である状態の下位58ビットを共有し、増分を考慮します。 私は構成的証明（Pythonコード）を持っていますが、今寝て明日掃除しなければなりません。

@rkern 、良い点。 私は認めます、私はそれがどのように運ばれるかを見るためにそのシナリオをテストしていません。

重要なポイントは、ほぼすべてのPRNGの場合、少しの時間とエネルギーで病理学的シードを考案できることです。 PCGはやや珍しい立場にあり、特に手作りの病状を持つPCGのもっともらしい見た目の種まきを楽しんでいる人がいます（つまり、Sebastiano）。 その作業の結果として、私は振り返り、彼のPRNGと他の長年のPRNGの両方に対して同じことを行いました。

すでに述べたように、これは誤りです。 PCG内で簡単に見つけることができるように、たとえばxoshiro256 ++からの相関した重複しないシーケンスのペアの例を私は知りません。

状態全体をすばやく混合するPRNGには、この問題はありません。 ここに投稿した例のように、xoshiro256 ++から相互に関連する2つの重複しないシーケンスを生成するプログラムを提供できる場合は、そうしてください。

彼の相関プログラムについては、2018年に彼がさまざまな問題（不自然なシードなど）で書いたプログラムを含むPCGの批評を彼のウェブサイトに掲載したときに、私は同様のプログラムの束を含むたSplitMixで相関ストリームを作成するcorrsplitmix2.cを含む、他の長く確立されたPRNGの場合。 セバスチャンがそれができないと言ったときに何を意味するのかはよくわかりませんが、彼の新しいプログラムが彼のものと実質的に異なるかどうかを確認するために彼のテストプログラムを詳しく調べる機会がなかったことを認めます数年前に書いた。

上で引用したプログラムは_ストリームを選択します_。 明らかにそれを書くのは簡単です。

しかし、それはPCGの問題とは何の関係もありません。 私が提供したプログラムは、_user_にストリームを選択させてから、相関関係を示します。

繰り返しになりますが、 http：/のように他のジェネレーターで相関シーケンスを見つけそうします。

ユーザーにストリームを任意に選択させると、はるかに強力な相関関係が示されます。

すでに述べたように、これは誤りです。 PCG内で簡単に見つけることができるように、たとえばxoshiro256 ++からの相関した重複しないシーケンスのペアの例を私は知りません。

ここでお互いを超えて話しているようです。 以前に作成したさまざまな相関プログラムなどで示されているように、PRNGに対して相関のある、重複しないシーケンスを思い付くことができるとは言いませんでした。 Xoshiro **の

また、状態全体を混合しないPRNGには、XorWow、数値レシピのジェネレーターなど、長い歴史があります。Sebastianoの議論は視点を表していますが、彼の議論は、MarsagliaがWeylを追加することによってXorWowでXorShiftを_worse_にしたと言うでしょうシーケンスは、同様のジェネレーターを多数作成するためです。

ここでお互いを超えて話しているようです。 以前に作成したさまざまな相関プログラムなどで示されているように、PRNGに対して相関のある、重複しないシーケンスを思い付くことができるとは言いませんでした。 Xoshiro **の

技術的なレベルで議論を続けるようにしてください。 「病理学的」には数学的な意味はありません。

自己相関をチェックするための技術的に正しい方法は、2つのシードを見つけて2つの重なり合わないシーケンスを生成することです（テストの期間中は重なり合いません。十分に遠くまで行くと、重なり合うことは避けられません）、それらをインターリーブしてバッテリーに渡しますテストの。

オーバーラップする2つのシーケンスを検討する場合、シーケンスがオーバーラップした後に同じ出力が2回発生するため、暗号化されたものであっても、すべてのジェネレーターで相関があり、適切なテストでそれが検出されます。

重複するシーケンスを使用する「病理学的シード」は、すべてのジェネレーターにとって簡単な作業です（「病理学的」が意味するものは何でも）。

繰り返しになりますが、他のジェネレーターでPCG（テストが示すようにシーケンスがオーバーラップしていない）と同様の相関関係を見つけたと主張しているので、たとえばxoshiro256 ++またはSFC64からの相関関係のあるオーバーラップしないシーケンスのペアを提供できますか？ ？

自己相関をチェックするための技術的に正しい方法は、2つのシードを見つけて2つの重なり合わないシーケンスを生成することです（テストの期間中は重なり合いません。十分に遠くまで行くと、重なり合うことは避けられません）、それらをインターリーブしてバッテリーに渡しますテストの。

この相関関係の定義についての文献を指摘して、私もそれについて「技術的に正しい」ままでいることを確認できますか？

セバスティアーノ、あなたは私があなたの条件で設定された挑戦に答えることを望んでいます。 あなたが指摘しているのは、自己相似性があるLCGの固有の特性に関連しています。 混沌としたPRNGやLFSRベースの問題では同じ問題は見つかりません。

しかし、他のPRNGについては、他の弱点があります。

LFSRには、ゼロランド、悪い状態、ハミング重みの問題、線形性があり、xoshiroでの試みで学んだように、繰り返しの奇妙な問題のような他の奇妙なことがあります。

カオスPRNGには、短いサイクル（ただし、カウンターがあるものはそれを回避します— WeylシーケンスFTW！）とその固有のバイアスのリスクがあります。

私が書いたように、シーケンスが重複している場合、テストは_常に_失敗します。 _常に失敗する_テストはテストではないことを理解するために、文献は必要ありません。

繰り返しになりますが、他のジェネレーターでPCG（テストが示すようにシーケンスがオーバーラップしていない）と同様の相関関係を見つけたと主張しているので、たとえばxoshiro256 ++またはSFC64からの相関関係のあるオーバーラップしないシーケンスのペアを提供できますか？ ？

あなたは本当に質問を避けているようです。 あなたの主張に続いて、もしあれば、そのような証拠を提供することはあなたにとって非常に簡単でしょう。

今すぐ行う最も簡単な方法は、 PCG64DXSM BitGeneratorを追加することです。これは、「安価な乗数」とより強力なDXSM出力関数を備えたPCG64のバリアントです。 これは、現在PCG64実装にあるXSL-RR出力関数からのステップアップであり、ランタイムパフォーマンスを損なうことなく統計的に優れたパフォーマンスを発揮することに誰もが同意していると思います。 PCG64が私たちが提供するBitGeneratorのは、ニッチでの簡単なアップグレードです。 PCG64と一緒に追加する必要があると思います。

64ビットの「安価な乗数」には証明可能な欠陥があることに注意してください。 これは長い間知られています：

W.HörmannとG.Derflinger、に適したポータブル乱数ジェネレーター
棄却法、ACMTrans。 数学。 ソフトウェア。 19（1993）、no。 4、489–495。

一般に、モジュラスの平方根よりも小さい乗数には、スペクトルスコアf²に固有の制限があります。

この制限は、65ビットの乗算器を使用することで簡単に克服できます。この乗算器は、コンパイラが追加の「追加」操作で変換するだけで、おそらくジェネレータの速度を変更することさえありません。

Guy Steeleと私はこの問題に少し取り組み、さまざまなサイズの安価な乗数のスペクトルスコアの表を公開しました： https ：

たとえば、論文の表7から、f²スコア0.9919の0x1d605bbb58c8abbfdが得られます。 64ビット乗算器は0.9306を超えることはできません（論文の定理4.1）。

ミックスとすべての後、f₂スコアの改善は統計的な観点から完全に見過ごされる可能性があります。 しかし、追加操作を追加するだけで最も関連性の高いディメンションが大幅に改善されることを考えると、努力する価値があると思います（まあ、私たちは考えます、または私たちは論文を書いていなかったでしょう）。

セバスティアーノ、あなたは私があなたの条件で設定された挑戦に答えることを望んでいます。 あなたが指摘しているのは、自己相似性があるLCGの固有の特性に関連しています。 混沌としたPRNGやLFSRベースの問題では同じ問題は見つかりません。

うわー、そこに着くのに少し時間がかかりました！

LFSRには、ゼロランド、悪い状態、ハミング重みの問題、線形性があり、xoshiroでの試みで学んだように、繰り返しの奇妙な問題のような他の奇妙なことがあります。

私は完全に同意します—それがあなたがそれらをスクランブルしなければならない理由です。 LFSRとF²線形ジェネレーターは異なるものであることに注意してください。 関連していますが、異なります。

「リピートに関する奇妙な問題」は、いつものように、私がコメントできない非技術的な用語です。

カオスPRNGには、短いサイクル（ただし、カウンターがあるものはそれを回避します— WeylシーケンスFTW！）とその固有のバイアスのリスクがあります。

[更新：括弧で囲まれたカウンターの観察を見逃したので、コメントを更新しています。]

はい、SFC64にはそのような問題はありません（カウンターを使用します）ので、カテゴリー全体に一般化することはしません。 証明可能な、最も短いサイクル長を持つ慎重に設計されたカオスジェネレータがあります。

「リピートに関する奇妙な問題」は、いつものように、私がコメントできない非技術的な用語です。

適切な専門用語を使用しなかったためにコメントできないのは奇妙に思えます。このプログラムを実行してから、適切な専門用語で問題を説明する最善の方法を教えてください。その後、適切と思われるコメントを提供してください。 私はそれについて彼と連絡を取り合ったので、あなたとデビッド・ブラックマンが最初に明るみに出たときにこの問題について話し合ったであろうと想像したでしょうが、あなたがそれについてコメントするのを見たことがありません。

numpyないPRNGの議論はトピックから外れています。 その議論を続けるためにあなた自身のフォーラムを使ってください。 ありがとうございました。

@ rkern-それは基準として少し厳しいようです。 他の実装で共有されていないNumpyの実装に欠陥がある場合は、それについて議論するのが妥当と思われます。

私が言及している交換は、この問題で私たちの目の前にある決定を下すのに役立っていないことを確認できます。 それが進むまで、集中力を保つために会話が必要です。

より広い文脈を理解することは有益だと思います。 セバスティアーノはPCGについて少し気になっていて、何年もの間それに対して手すりをしてきました。 私も彼のPRNGを批判したので、最近は私たちの両方を見て目を転がして「あなたはお互いに同じくらい悪い」と言う人もいるかもしれませんが、実際には彼が主張した後にのみそうしました私は彼のことについて決して話さないことによって何かを隠そうとしていました（実際には、私には時間/傾斜がありませんでした-実際、私はそれらが大丈夫だと思っていました）。

彼の批評は役に立ちます。彼が私の仕事について考えることに人生の多くを費やすことを選んだことを嬉しく思いますが、彼のテストは本質的に敵対的であることを認識することが重要です。 彼は、PCGの構造に関する知識を使用して、RNGテスターに​​入力してテストに失敗する可能性のある配置を考案します。

それがどれほど恐ろしいように見えるかを考えると、同様の敵対的アプローチが他の多くのジェネレーターをトリップさせ、PCGに関して彼が提起する懸念の多くが他のジェネレーションスキームにも当てはまることを示すのは合理的です。 XorWowのように、以下で行うように、例としてSplitMixをよく使用します。 （私たちの誰も、SplitMixに何らかの形で特に投資しているわけではないと思います。）

たとえば、SplitMixについては非常に恐ろしいことがあります。デフォルトのストリーム定数では、35185番目ごとの出力を見ると、PRNGテストスイートで失敗することを示しています。 ああ、いや！ これは、内部的にはカウンター（Weylシーケンス！）を0x9e3779b97f4a7c15 （黄金比φに基づく）だけインクリメントしているためですが、35185 * 0x9e3779b97f4a7c15 = 0x86a100000c480245 、 14ビットが設定され、中央に何もない大きな帯があります。 または、360998717番目の出力ごとに見ると、 0x48620000800401の内部状態への追加と同等になります。これは、8ビットしか追加されておらず、出力関数が完全にマスクするのが難しいものです。 。

SplitMixについて怖がり続けて、見て言うことができます。1つは加法定数0x9e3779b97f4a7c15 、もう1つは0xdaa66d2c7ddf743f 、2つのストリームがある場合、これをにフィードすると欠陥が発生します。 PRNGテストスイート!!! しかし、それは2番目のものが他のもののちょうど3倍になるように考案されているためです。

そして最後に、誰かが「両方のストリームを提供するつもりです、それで何か怖いことをしてください！」と言った場合、それらがπ（ 0x243f6a8885a308d3 ）と_e _（ 0xb7e151628aed2a6b ）に基づいているとしましょう。 ）、確かに、もう少し怖がらせて、Piストリームから6561221343番目のアイテムごとに取得し、Eストリームからの6663276199番目のアイテムごとに混合して、2つの同一のものを生成します。シーケンス。 そして_さらに悪い_、次に、ストリームaのすべてのジャンプについて、同じ出力を与えるためにストリームbに一致するジャンプがあることを示します。したがって、実際には2 ^ 64の方法で相関します!!! （そして、これは任意の2つのストリームに対して実行できます。πと_e_について特別なことは何もありませんでした。）

PCGに戻ると、Sebastianoのテストは、一致する出力がインターリーブされるように正確に位置合わせされた2つのPCG64 XSHRRジェネレーターに依存しています。 PRNGの1つを少しだけ進めて、完全な位置合わせを少しだけ壊すと、疑わしいものを検出するのが非常に難しくなります。

他の方向での同様の敵対的テスト（Sebastianoに負担をかける）は、PCG64 XSH RRからの出力に、それらが相関しているという彼の主張を満たすものを提供することですが、それらがどのように調整されているかを正確に伝えていません（それらはただ右の一般的な近所）。 彼の仕事は、それらが相関していることを示すための配置を見つけることです。

全体として、緊急の火災を消火することは実際には問題ではないと思いますが、一方で、DXSMバージョンは、この種の問題を正確に軽減するために昨年作成されたものとして優れています。あなたがそれに切り替えてくれることを嬉しく思います。

PS次のコードを使用して、お気に入りの実数から魔法のワイル加法定数を作成できます。

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

それは数学です。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ようなわずかなシフトでも障害は32GiBに延長されます。

オプションのビットジェネレータとしてPCG64DXSMを追加し、最終的にはデフォルトにする必要があるようです。 実装がありますか？

より広い文脈を理解することは有益だと思います。 セバスティアーノはPCGについて少し気になっていて、何年もの間それに対して手すりをしてきました。 私も彼のPRNGを批判したので、最近は私たちの両方を見て目を転がして「あなたはお互いに同じくらい悪い」と言う人もいるかもしれませんが、実際には彼が主張した後にのみそうしました私は彼のことについて決して話さないことによって何かを隠そうとしていました（実際には、私には時間/傾斜がありませんでした-実際、私はそれらが大丈夫だと思っていました）。

これらの考慮事項は完全に不適切だと思います。

メリットも証拠もなく、他の人の作品（SplitMixなど）を攻撃することを主張しても、PCGの混乱やNumpyのジェネレーターが改善されることはありません。 代わりに、より優れた乗数、またはより適切に設計されたスクランブラーが役立つ場合があります。

ユーザーがストリームを選択できるときに、SplitMixで相関関係を示すテストをまだ待っています。 明確にするために、Numpyのジェネレーターについて、私はフォームのステートメントを証明しました

∀c∀d∀x∃y相関

ここで、c、dは増分（「ストリーム」）であり、x、yは初期状態です。 実際、2 ^ 72年あります。 つまり、c、d、およびxをどのように選択しても、2 ^ 72yの相関関係が示されます。

SplitMixに提供したとされる対応するコードは、

∃c∃d∃x∃y相関

つまり、敵対的にc、d、x、yを選択すると、相関関係を示すことができます。

2つのステートメントの強さの違いは非常に驚異的です。 2つのステートメントを混同しようとするのは正しくありません。

@vignaは、 @ mattipと@rkernから、行動規範について2回警告を受けています。 「他の人の仕事をスラッシングする」や「2つのステートメントを混同しようとするのは純粋なFUD」などの言葉を使用することはできません。 これを最後の警告と考えてください。 あなたの口調を変えてください、さもないと私たちはあなたを禁止します。 技術的な議論はまだ歓迎されています、他のものはこの時点ではありません。

これらの式をニュートラルな式に置き換えてメッセージを変更しました。 私はまだ、議論の別の参加者を個人的に攻撃すること（「セバスティアーノはPCGについて少し何かを持っていて、何年もの間それに対して手すりをしている」）は完全に不適切だと思います。 私はあなたのためではないことに非常に驚いています。

3回目で最後に、SplitMixについての議論は、どちらの方向でも、私を少しも助けてくれません。 なぜそれが必要なコンテキストを提供すると思うのか、または他の人に対応せざるを得ないと感じるのかは理解できますが、ここでの決定に役立つ情報を提供していないというのは真実です。 あなたは両方ともあなた自身のウェブサイトを持っています。 それらを使用してください。

これらの式をニュートラルな式に置き換えてメッセージを変更しました。

ありがとうございました。

私はまだ、議論の別の参加者を個人的に攻撃すること（「セバスティアーノはPCGについて少し何かを持っていて、何年もの間それに対して手すりをしている」）は完全に不適切だと思います。 私はあなたのためではないことに非常に驚いています。

確かにそれも見たくないです。 しかし、そのメッセージのトーンはそれほど悪くはありません。

@vignaと@imnemeの建設的な事実に固執していただければ幸いです。

OK。 ゼロから始めましょう。利便性と速度のために、2の累乗係数を持つLCGに基づくある種のストリームを備えたジェネレーターが必要です。 文献は、LCGの加法定数に基づいてストリームを作成すると、問題が発生する可能性があることを示唆していますが（現在のように）、それが必要であると仮定しましょう。

128ビットの状態と適切な乗数（少なくとも65ビット）を備えたLCGを取得し、さまざまなアプリケーション（ハッシュ、PRNGなど）で徹底的にテストされたSplitMixのmix関数を使用して上位ビットを混乱させてみませんか？優れた結果をもたらしますか？

速度の違いはごくわずかだと確信しています。 そして、結果がすべてのビットに依存するという（統計的な）保証があります。これがここでの問題です。

これは、自己相関の問題があるジェネレーターでミキシング関数を手作りするというよりも、「巨人の肩の上に立つ」アプローチのように思えます。

@imneme私が使用できるのは、DXSMに関するブログ投稿で、古いメガイシューのこの発表コメントよりもリンクが簡単です。 そのコメントの内容よりもはるかに多い必要はありませんが、ここで言及したテストの現在のステータスを含めるとよいでしょう。 その開発につながったメガイシューからの議論のいくつかを要約したいのであれば、それは確かに有用ですが、完全に必要というわけではありません。

@vigna

128ビットの状態と適切な乗数（少なくとも65ビット）を備えたLCGを取得し、さまざまなアプリケーション（ハッシュ、PRNGなど）で徹底的にテストされたSplitMixのmix関数を使用して上位ビットを混乱させてみませんか？優れた結果をもたらしますか？

これが卑劣に聞こえる場合はお詫びしますが（確かに指摘されますが）、それは誠実でもあります。実装、分析、ベンチマーク、およびPractRandの結果がWebサイトまたはarXivで表示されることを楽しみにしています。 私たちはここでは（合理的な情報に基づいた）実践者であり、PRNG研究者ではなく、この提案を実行するための十分な設備が整っていません。 その意味はわかりますが、個人的な時間に他の制約があることを考えると、提案から実装、分析に至るまで努力する傾向はありません。 この提案をnumpyに対処する場合は、PRNG研究者がその作業を行う必要があります。 あなたが本当に他の誰かにこの提案に取り組んでいるなら、あなたのウェブサイトを使ってください。

NumPyのランダムなGenerator -> BitGenerator -> SeedSequenceアーキテクチャは、プラグイン可能であることが意図されています。 議論の中で、BitGeneratorのPRを開くために誰かが必要になるところまで来ていると思います。そうすれば、その実用的な属性を現在NumPyにあるものと比較できます。 プロジェクトの一部になると、引き続きテストを行うことができ、デフォルトにすることを決定する場合があります。 その決定は、私が望むに、

• バイアスの欠如（および他の基準？私は専門家に譲ります）
• パフォーマンス
• BitGenerator.spawnとSeedSequenceを使用して、私たちが推進する規範的なインターフェースを介したさまざまなタイプのストリーム衝突の確率。

個人的には、 spawnインターフェイスを使用するコードを介してBitGeneratorsのメリットについて議論することを避けたとき、この議論は私を失いました。 ベストプラクティスとして宣伝するのには理由があり、今後のPRの議論がNumPyユーザーのベストプラクティスます。

おそらく、ここでの結論の1つは、 jumpedまたはadvanceを使用するとグッドプラクティスに反する可能性があるため、メソッドとしてspawnのみを許可する必要があるということかもしれません。 これに焦点を当てた新しい問題またはNEPも生産的である可能性があります。

注意@vignaが私たちに影響することを下位ビットの誕生日の衝突を@mattip SeedSequence.spawn()同様のインターフェイスを。 私が行った議論のどの部分も、APIの適切な使用に関連しているのでご安心ください。

@rkernが推奨する完全に独立したジェネレーターのアプローチを使用するには、いくつかの#ifdefブロックを使用してpcg64.cに約8行を追加するだけで済みます。 pyx / pxdは、それ以外の点では、正しい定義（PCG_DXSM = 1）と更新されたdocstringでのみ構築されている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

この時点でMurmurHash 3を追加することもできますが、その傾向が強かったのです。

ifステートメントはコンパイルされますか？ ホットループ内にそれらの倍数が必要だとは思いません。

繰り返しますが、これはrandomgenとnumpy目的の違いに帰着します。 パラメータ化されたファミリを作成することはrandomgen意味がありますが、 numpyでは、アクティブなデフォルトからレガシーBitGeneratorの実装を絡ませることは良い考えではないと思いますBitGenerator 。 どちらか一方のパフォーマンスのためにメンテナンスやリファクタリングを行う必要がある場合、その努力は改善されるのではなく悪化するだけです。

ここでロバートに同意します。 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()使用して出力にプリ反復状態ではなく、後の反復状態と同じコードパスを維持するために、簡単なようであることを行っていないので、 #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パスが常に安価な乗数を使用していることを意味します。

あなたがそこで何を言おうとしているのかわかりません。

正規のPCG64DXSMが何であるかは不明です。 いずれの場合も、出力関数は64ビット演算のみを使用します。 お使いのバージョンでは、別の場所で64ビット乗算器を使用してさらに高速化し、ポストではなくプレを返します。 setseq_dxsm_128_64は、既存のPCG64の自然な拡張のようで、出力関数のみを変更します。

ああなるほど。 いいえ、Cで実装したものとは異なるC ++ジェネレーターを使用しました。 setseq_dxsm_128_64ではなく、LCG反復で「安価な乗数」を使用するcm_setseq_dxsm_128_64と同等のものを実装しました。 LCG反復で大きな乗数を使用します。 「安価な乗数」はDXSM出力関数内で再利用されますが、これは直交設計軸です。

なぜsetseq_dxsm_128_64を好まないのですか？

@imnemeは、最終的にC ++バージョンの公式pcg64を、 setseq_dxsm_128_64ではなくcm_setseq_dxsm_128_64を指すように変更する

事前反復状態を出力することも、パフォーマンスバンプの一部です。

いくつかのタイミングは次のとおりです。

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としての指名を推進しました。 これらは、IMOのnumpyの最も近い動機です。

ブランチのストック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の特殊な実装を使用しても、2つの間の#ifdefsはほんのわずか（私が持っていたよりも多い）であると私はまだ言います。 さらに、RSN MSユーザーはclang＃13816👍を使用できるようになります。

コードの重複について議論していますか？ #ifdefs難読化された数行のコードについて心配するよりも、まとまりのない実装が必要です:)

「PCG2.0」（できればNumPyのGitHubの問題ではない場所）を定義する完全に明確なステートメントの必要性を強調していましたが、それはほとんど冗談でした。

ありがとう、 @ rkern etal。

@imneme私が使用できるのは、DXSMに関するブログ投稿で、古いメガイシューのこの発表コメントよりもリンクが簡単です。 そのコメントの内容よりもはるかに多い必要はありませんが、ここで言及したテストの現在のステータスを含めるとよいでしょう。 その開発につながったメガイシューからの議論のいくつかを要約したいのであれば、それは確かに有用ですが、完全に必要というわけではありません。

時間枠を考えていますか？ 私はしばらくの間これを行うつもりであり、他のことによってそれを押し出してもらうことを意味していたので、実際に提案された期限を持つことは私にとって有用な動機になるでしょう。 たぶん一週間？ 二？

@rkernは@vignaも引用しました。

128ビットの状態と適切な乗数（少なくとも65ビット）を備えたLCGを取得し、さまざまなアプリケーション（ハッシュ、PRNGなど）で徹底的にテストされたSplitMixのmix関数を使用して上位ビットを混乱させてみませんか？優れた結果をもたらしますか？

FWIW、このアプローチは元のPCGペーパーで説明されており、非常によく似た乗算xorshiftハッシュ関数である既製のハッシュ関数として_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の問題についてもあまり心配していません。推奨される手順を使用して、問題が発生する可能性はほとんどないようです。

@ imneme1週間は素晴らしいでしょう。 2週間で十分でしょう。 ありがとう！

私が自分自身に問いかけている質問がありますが、それはやや話題から外れています。 ビットジェネレーターでランダムビットを生成する必要がありますが、AFAICTでは、ほとんどのテストには整数が含まれます。 実際にビットをテストする際に、既存のテストはどの程度うまく機能しますか？ その地域に詳しい人がその質問に答えてくれたら、私は最も感謝しています。

テストされているのはビットストリームです。 テストソフトウェアに、出力するPRNGの自然なワードサイズを通知しますが、ビットの最適な折り畳みを実行して、ビットの下位ビットまたは上位ビットで発生する傾向のあるエラーを最も効率的に引き起こすことができるようにするためです。悪いPRNGの単語。 最近私たち全員が使用する傾向のあるソフトウェアはPractRandであり、そのテストはここに簡単に読むのにTestU01の論文です。 そのユーザーガイドには、テストの詳細が記載されています。

これが卑劣に聞こえる場合はお詫びしますが（確かに指摘されますが）、それは誠実でもあります。実装、分析、ベンチマーク、およびPractRandの結果がWebサイトまたはarXivで表示されることを楽しみにしています。 私たちはここでは（合理的な情報に基づいた）実践者であり、PRNG研究者ではなく、この提案を実行するための十分な設備が整っていません。 その意味はわかりますが、個人的な時間に他の制約があることを考えると、提案から実装、分析に至るまで努力する傾向はありません。 この提案をnumpyに対処する場合は、PRNG研究者がその作業を行う必要があります。 あなたが本当に他の誰かにこの提案に取り組んでいるなら、あなたのウェブサイトを使ってください。

私はあなたの視点を完全に理解することができます。 コードとベンチマークは、ページの下部にあり、LCG128Mixという名前で数年前からPCG（http://prng.di.unimi.it/pcg.php）の問題についてコメントしています。 私のハードウェア、Intel（R）Core（TM）i7-7700 CPU @ 3.60GHz、gcc9.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ビットのすべてのビットに依存するという統計的保証もあります。状態。

他のジェネレーターに対するベンチマーク、または他のコンパイラーの使用を念頭に置いている場合は、お知らせください。

ただし、同じように誠実にお願いします。標準コンポーネントのみを使用した「巨人の肩の上に立つ」設計を検討することに本当に関心がある場合に限ります。 私の時間にも個人的な制約があり、貢献できてうれしいですが、考慮される機会のない発電機に時間を費やすことは避けたいと思います。

ところで、関連する乗算器の品質を改善する方法のより具体的な尺度を与えるために、PCGDXSおよびいくつかの代替で使用されている現在の64ビット乗算器のf2からf1までのスペクトルスコアを計算しました。

スペクトルスコアは、乗数の良さを判断するための標準的な方法です。 0は悪い、1は優れています。 各スコアは、出力でペア、トリプル、4タプルなどがどの程度適切に分散されているかを示します。

TAoCPのKnuthが示唆しているように、これらの7つの数値は、古典的なメジャー、最小、または加重メジャー（最初のスコアに加えて、2番目を2で割ったものなど）で再開して、最初のスコアをより重要にすることができます。 、およびこれらは、現在の乗数の最小値と加重メジャーです。

0xda942042e4dd58b  0.633  0.778

それよりもはるかに優れた64ビット定数があります。

0xff37f1f758180525  0.761  0.875

基本的に同じ速度で（少なくともLCG128Mixの場合は同じ速度で）、65ビットに移行すると、より適切な加重メジャーが得られます。

0x1d605bbb58c8abbfd  0.761  0.899

その理由は、64ビット乗数にはf₂スコア（≤0.93）に固有の制限があるためです。これは、クヌースが最も関連性があると指摘しています。

0xda942042e4dd58b5  0.795
0xff37f1f758180525  0.928
0x1d605bbb58c8abbfd  0.992

したがって、最初の乗数のスコアは平凡です。 2番目の乗算器は、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の優れたデフォルトのprngですが、これを行うためのより有望でテストされていない方法があるため、時間の試練に耐えられるとは思いません。 以下のいずれかを提案します。

半分混沌としたSFC64は、統計的に健全なジェネレーターの中で最も高速で、最小期間がかなり長いものの1つです。 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ビットのカオス/構造化状態を使用しており、バランスが取れているようです。
/編集：出力関数から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テストで4 TBに合格しており、これまで問題なくVignaのハミング重みテストを簡単に実行しました（ただし、これらのテストに合格しても、ほぼ真のランダム出力が保証されるわけではなく、prngに欠陥があるかどうかのテストです。 ）。

注：ビットの約50％が設定された（一意の）ランダムWeyl定数を使用することは、統計的にはおそらく利点ですが、さらにテストまたは分析するだけで、これがどれほど重要であるかが明らかになります。

/編集：クリーンアップ。

@ tylo-work SFC64はPhiloxとともにすでにNumPyにあり、これはデフォルトのジェネレーターに関するものです。

さて、どれが実装されているのか正確にはわからなかったので、これはそれらの中から全体的に最も適したものを選択することだけですか？ 十分に公平であり、明確にしてくれてありがとう。

提案したジェネレーターを広範囲にテストして、他のジェネレーターとどのように連携するかを確認します。これまでのところ、速度、出力品質、シンプルさ/サイズ/移植性、および大規模な並列使用に関しては非常に見栄えがします。 しかし、他の人もそれをテストしてくれたら嬉しいです。

NumPyのバージョンは、 k=1を持つ標準のバリアントです。

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

デフォルトのPRNGについての議論を最初から再開するつもりはないと思います。 現在のPRNGには非常に具体的な問題があり、その特定の問題に対処する、利用可能な密接に関連するバリアントを検討しています。 私たちの懸念の1つは、現在のデフォルトのPRNGが、ジャンプ可能性などのPRNGの特定の機能を公開していることです。これは、それを置き換えるバリアントが引き続き公開する必要があります。 SFC64（私たちまたはあなたのもの）にはその機能がありません。

@bashtageは、 SFC64のWeyl-streamバリアントを追加するために

@ tylo-work並列実行に興味がある場合は、NumPyのSeedSequence実装を確認することをお勧めします。

デフォルトのPRNGについての議論を最初から再開するつもりはないと思います。 現在のPRNGには非常に具体的な問題があり、その特定の問題に対処する、利用可能な密接に関連するバリアントを検討しています。

PCG-DXSのようなものが必要な場合は、定数を改善するだけでさらに改善を行うことができます（そして非常にわずかな速度低下）。 たとえば、PCG-DXSは、同じ下位112ビットの状態を持つ2つのインターリーブされ、相関するサブシーケンスで、2つの異なるタイプのテストにすぐに失敗します。

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ビットの乗算器で、スペクトルスコアがはるかに優れています。 2番目の数値は、64ビットの固定小数点表現の黄金比であり、これには優れた混合特性があることが知られています（乗法ハッシュに関するKnuth TAoCPを参照）。 たとえば、ハッシュコードを混合するためにEclipseコレクションライブラリによって使用されます。

その結果、同じ量のデータに対して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は、同じインターリーブされた相関サブシーケンスの3つのタイプのテストに失敗します。

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ϕもギャップと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ビット乗算器によって引き起こされる）と、ロードする2つの64ビット定数があるためです。

私は一般的にこの種のジェネレーターを推奨していませんが、PCG65-DXSϕは相関を隠す点でPCG-DXSよりもかなり優れています。

@Vigna 、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 **は、私のマシンでは他の2つより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リポジトリに作品を投稿し、ここにもう1つ投稿して、ここにいる人々を招待することをお勧めします。 他の皆さん、そこで返信してください。 ご協力ありがとうございます。

@imneme @ rkern1.19リリースの時間が不足しています。

@rkern PCG64DXSMは1.19.0にならないようですが、今週末にリリースします。 上記の変更ポリシー/今後の変更についてのメモを書いていただければ幸いです。

申し訳ありませんが、私は他のいくつかの無関係な問題を扱ってきました。 私たちの議論に基づくと、PCG64DXSMは（少なくとも今のところ）新しいデフォルトではなく、代替オプションとして計画されていたため、小さな遅延は大きな問題ではないと思います。

1.20が起動しているので、これを再検討してDXSMに移行する時が来ましたか？

分岐する前に移動する時間はまだありますが、来週かそこら以内に開始するのが良いかもしれません。 @bashtage PCG64DXSM準備ができていると思いますが、これには主にデフォルトストリームのスイッチを切り替える決定が必要ですか？

見たところ、すぐに利用できるのであれば、1.20でこれを実行する必要があるように思えました。

IIRC、リンクできるリファレンスを待っていました。 しかし、乱数の人々が変更に満足している場合は、それを使用する必要があります。 Windows用の特別なコードが必要ですか？

これは、異なる定数と異なるスクランブリング関数です。 @rkernがWindowsでの元のPCG64実装のために書いたものほど斬新なものはありません。 コードを共有するのではなく、完全にスタンドアロンのPCG64DXSMを使用することにしたと思います（パフォーマンスのため）。

rkernのWIPブランチから始めるのはおそらく理にかなっています。

@rkernが望んでいたと思うブログ投稿を書くと言ったのですが、他の問題にも@ rkernはさらに強力な出力順列が好きだったと思いますが、