numpy 🚀 - 新しいPRNGBitGeneratorのデフォルトを決定する

Intel Windowsコンパイラは128ビット整数に対して何をしますか？ Windows上のMT1993と比較して、PCG64はMSVCでコンパイルされるのがどれくらい遅いですか？ジャンプアヘッド機能が広く使われるのではないかと思うので、デフォルトで持っておくといいかもしれません。

charris 2019年05月27日

Intel Windowsコンパイラは128ビット整数に対して何をしますか？

完全にはわかりません。 ICCが制約を受けたいと思うABIの影響があるかどうかはわかりません。生成されたアセンブリについて使用できるアイデアを知りたいだけの場合は、これが便利なリソースです： https ：

ジャンプアヘッド機能が広く使われるのではないかと思うので、デフォルトで持っておくといいかもしれません。

むしろ、設定可能なストリームを意味しますか？それは良い点ですが、逆にカットできないのではないかと思います。デフォルトの選択が実際に非常に重要である場合、おそらくこれらのより完全な機能を備えたPRNGのいずれかを選択すると、人々はそれらの「高度な」機能が必要であることを文書化せずに、ライブラリコードでこれらの機能をより広範囲に使用します。「標準」でご利用いただけます。しかし、別のユーザーが速度やその他の理由で機能の少ないBitGeneratorでそのライブラリを使用しようとすると、レンガの壁にぶつかります。 No defaultまたはMT19937世界では、図書館は必要な高度な機能について考え、文書化する可能性が高くなります。

一方で、その不測の事態により、設定可能なストリームのないBitGeneratorあまり望ましくないように見えます。私は、その方向でベストプラクティスと見なされるものを進めるという概念が好きです（純粋に個人的に;私は感じません） NumPy-the-projectにその概念を共有させる義務）。コードの途中で.seed()を使用している人に見られる、いくつかの悪用を回避するのに役立つ可能性があります。しかし、繰り返しになりますが、デフォルトがあると人々の行動が大幅に変わるという考えに基づいているため、これらの懸念はすべてかなり軽減される可能性があります。

rkern 2019年05月27日

Windows上のMT1993と比較して、PCG64はMSVCでコンパイルされるのがどれくらい遅いですか？

@bashtageが＃13163に投稿したベンチマークでは、PCG64はMT19937のほぼ半分の速度であり、MSVCやその仲間のパフォーマンスにはかなり期待外れです。 Linuxでは23％高速です。

Intel Windowsコンパイラは128ビット整数に対して何をしますか？

Clang、GCC、Intelコンパイラなどの他のコンパイラは、32ビットシステムで64ビット整数を実装したのと同じ方法で64ビットシステムに128ビット整数を実装します。新しいアイデアを必要としないすべて同じテクニック。 MicrosoftはMSVCに対してそれをわざわざ行わなかったので、コンパイラによって直接サポートされる128ビット整数はありません。

その結果、MSVCの場合、＃13163のPCG64の既存の実装は、x86_64の_umul128などのMicrosoft組み込み関数を呼び出すことにより、128ビットの計算を手動で実装します（おそらく、代わりに_mulx_u64などの同等でよりポータブルなIntel組み込み関数を使用することもできます）。これにより、GCC、Clang、およびIntelコンパイラが単独で行うことをコーディングします。最大の問題は、Microsoftのコンパイラがこれらの組み込み関数を十分に最適化していない可能性があります（少なくともインライン化されていることを願っていますか？）。手作業でコーディングされたアセンブラの方が高速になる可能性はありますが、適切な修正は、コンパイラがそれほど悪魔的に貧弱ではないことです。

ジャンプアヘッド機能が広く使われるのではないかと思うので、デフォルトで持っておくといいかもしれません。

ジャンプしてよかったのですが、なぜ広く使われるのか気になります。（個人的には、2つのPRNGがどれだけ離れているかを示すdistance本当に好きです。これはPCGのC ++バージョンにありますが、Cバージョンにはありません。追加するのは簡単です。興味。）

imneme 2019年05月27日

ジャンプしてよかったのですが、なぜ広く使われるのか気になります。

おそらく現在の用語に慣れていない。つまり、シミュレーションを並行して実行するために使用できる、簡単に取得できる独立したストリームです。並列化できるシミュレーションの問題の数はわかりませんが、多くの問題があり、最近のチップに搭載されるコアの数を考えると、速度の不利を簡単に補うことができると思います。

MicrosoftはMSVCに対してそれをわざわざ行わなかったので、コンパイラによって直接サポートされる128ビット整数はありません。

そのため、私たちの車輪を傷つけるでしょう、OTOH、Windowsの多くの人々はAnacondaまたはEnthoughtからパッケージを入手します。どちらもIntelを使用し、パフォーマンスを本当に気にする人々はおそらくLinux、Mac、またはおそらくAIXです。

編集：そしておそらくマイクロソフトが懸念しているなら、彼らは問題を解決するための報奨金を提供することができます。

charris 2019年05月27日

FWIW、これが重要な関数のためにclangが生成するアセンブリです。これには、 uint128_tをuint64_tの構造体にアンパック/再パックするために必要なビットが含まれます。https：// godbolt.org/z/Gtp3os

rkern 2019年05月27日

👍1

とてもかっこいい、@ rkern。同じことをして、MSVCが手書きの128ビットコードで何をしているのかを確認できる可能性はありますか？

imneme 2019年05月27日

とてもかっこいい、@ rkern。同じことをして、MSVCが手書きの128ビットコードで何をしているのかを確認できる可能性はありますか？

それは、ええと、きれいではありません。〜https：//godbolt.org/z/a5L5Gz〜

おっと、 -O3を追加するのを忘れましたが、それでも醜いです： https ：

rkern 2019年05月27日

それほど悪くはありません。最適化がオンになっていないため、何もインライン化されませんでした。 /Oxを追加しました（もっと良いオプションがあるかもしれませんか？）。また、MSVCはC回転イディオムを見つけることができないため、組み込みの回転組み込み関数（ _rotr64 ）を使用するようにコードを修正しました。

それでも一種の列車事故です。しかし、少し注意を払えば、PCG64コードを微調整して、MSVCでコンパイルし、誰にとってもまったく恥ずかしくないものにすることができると言っても過言ではありません。

imneme 2019年05月27日

他のすべてをマージできるようにするために、今のところ「デフォルトなし」を選択してみませんか？これにより、互換性を損なうことなく、後で（1つ以上のリリースの後でも）デフォルトを自由に決定できます。

eric-wieser 2019年05月27日

👍1

ほとんどのユーザーは乱数の専門家ではないため、デフォルトを提供する必要があります。

「今、彼らはより多くのコードを入力する必要がある」という無作法を超えて、何かを変更するとどうなりますか？ BitGeneratorがハードコーディングされている場合（デフォルトを提供しなかったため）、洗練されていないすべてのユーザーはコードをリファクタリングする必要があり、うまくいけば彼らの選択のニュアンスを理解する必要があります（私たちは自分たちの間で何に同意することさえできないことに注意してください最高です）。ただし、デフォルトを提供すると、新しいデフォルトまたは新しいバージョンはビットストリームと互換性がないため、テストが中断される可能性があります。

ビットストリームが常に一定であるという仮定と、 NumPy開発者が何をしているのかを知っているという仮定と、デフォルト値が最高のブランドである必要があるという仮定との間で、たとえそれがあったとしても、私は2番目の仮定の側で誤りを犯します最初を壊します。

編集：どの開発者が彼らが何をしているかを知っておくべきかを明確にする

mattip 2019年05月27日

ほとんどのユーザーは乱数の専門家ではないため、デフォルトを提供する必要があります。

ええと、少なくとも、デフォルトがあるかどうかやデフォルトが何であるかに関係なく、推奨事項を文書化することは確かです。

「今、彼らはより多くのコードを入力する必要がある」という無作法を超えて、何かを変更するとどうなりますか？

どんな「何か」を考えていますか？私はあなたの議論に従うことができません。

rkern 2019年05月27日

「今、彼らはより多くのコードを入力する必要がある」という無作法を超えて、何かを変更するとどうなりますか？
どんな「何か」を考えていますか？私はあなたの議論に従うことができません。

@mattipは、デフォルトのビットジェネレータの変更を指します。

このwoudlは、それを採用したユーザーを怒らせ、coudlはコードの変更を必要とします。

たとえば、

g = Generator()
g.bit_generator.seed(1234)

基になるビットジェネレータが変更された場合、これは間違っています。

あなたがもっと正気なことをして使ったなら

Generator(BitGenerator(1234))

その後、あなたはそれを見ないでしょう。

IMO、デフォルトの選択を検討するときは、基礎となるビットジェネレーターに致命的な欠陥が見つかるか、IntelがそのチップにQUANTUM_NIを追加するまで修正されたと考える必要があります。これにより、ランダムなパフォーマンスがOOM改善されます。

bashtage 2019年05月27日

私はここでは少し部外者だと思いますが、どのPRNGがデフォルトの選択であるかが永久に修正され、変更されないことを期待するのは合理的ではないと思います。（たとえば、C ++では、 std::default_random_engineは実装の裁量であり、リリースごとに変更できます。）

むしろ、以前の結果を再現するメカニズムが必要です。したがって、特定の実装が存在すると、それを変更することは非常にクールではありません（たとえば、MT19937 _is_ MT19937、異なる出力を与えるように調整することはできません）。 [そして、すでに存在する実装を削除するのもクールではありません。]

デフォルトが変更された場合、古い結果を再現し続けたい人は、以前のデフォルトを名前で尋ねる必要があります。（以前のリリースに対応するデフォルトを選択するメカニズムを提供することで、これを行うことができます。）

とは言うものの、デフォルトのジェネレーターを別のものに交換することが許可されている場合でも、それは本当に厳密に改善する必要があります。デフォルトのジェネレーターに存在する機能はすべて、将来その機能をサポートするというコミットメントを表しています。デフォルトのジェネレーターに効率的なadvanceがある場合、後でそれを実際に取り除くことはできません。（この問題を回避するために、デフォルトのジェネレーターの高度な機能を無効にする可能性があります。）

要約すると、デフォルトが永久に変更されない契約に自分自身を固定しようとせずに、使用が再現可能な結果をもたらすことができることを確認する方法があります。それはまたあなたがする選択のための賭け金を減らすでしょう。

（FWIWは、これは私がPCGに何をしたかである。デフォルトのPCG 32ビットのPRNGが現在のようにアクセスXSH-RRの変種である[ pcg_setseq_64_xsh_rr_32_random_r Cライブラリとでpcg_engines::setseq_xsh_rr_64_32 Cでクラス++ライブラリ]ですが、原則として、将来を見据えた再現性が本当に必要な場合は、エイリアスであるpcg32_random_rまたはpcg32を使用するのではなく、XSH-RRを明示的に指定する必要があります。原則として他のものにアップグレードできます。。）

imneme 2019年05月27日

それは本当に永遠ではありません（このプロジェクト全体の90％は、約14年前に行われた本物の、本物の、そして名誉ある永遠の約束によって推進されています）が、あなたが言うように、切り替えには（a）変更する説得力のある理由と（b）減価償却サイクルを与えるために少なくとも数年かかります。

今日はそれをできるだけ正しくするために一生懸命努力する方がはるかに良いです。

もちろん、禁止されていないことの1つは、リリース後に同じ値を生成するlognとしてPRNGコードを改善することです。たとえば、uint128を使用するPRNGを使用した場合、MSにuint128サポートを追加させるか（ファットチャンス）、将来のバージョンでWin64のアセンブリを追加することができます。

bashtage 2019年05月27日

たとえば、
g = Generator()
g.bit_generator.seed(1234)
基になるビットジェネレータが変更された場合、これは間違っています。

そうです、@ eric-wieserを使用して、「デフォルトなし」オプションについて議論しているようです。これは、最初のステートメント「ほとんどのユーザーは乱数の専門家ではないので、デフォルトを提供する必要があります。。」

rkern 2019年05月27日

デフォルトなしとフレンドリーの間で、完全にデフォルトを想定して、私は常に後者を選択します：

今：

Generator() # OK
Generator(DefaultBitGenerator(seed)) # OK
Generator(seed) # error

_my_設定：

Generator(1234) == Generator(DefaultBitGenerator(1234)
Generator(*args**kwargs) == Generator(DefaultBitGenerator(*args, **kwargs))

今ではこれがうまくいくとは思いませんが、RandomStateの使用を延長する1つの方法は、ビットジェネレーターを選択するのに十分な専門家であると感じるユーザーのみがこれを利用できるようにすることだと思います。

bashtage 2019年05月27日

要約すると、デフォルトが永久に変更されない契約に自分自身を固定しようとせずに、使用が再現可能な結果をもたらすことができることを確認する方法があります。それはまたあなたがする選択のための賭け金を減らすでしょう。

はい、あります。ユーザーは名前でBitGeneratorを取得し（たとえば、 MT19937 、 PCG64など）、シードを使用してインスタンス化できます。 BitGeneratorオブジェクトは、均一な[0..1) float64と整数（およびそれらが持つ楽しいジャンプアヘッド/ストリーム機能）を描画するための限られたメソッドセットを使用して、コアの均一PRNGアルゴリズムを実装します。。私たちが話しているGeneratorクラスは、提供されたBitGeneratorオブジェクトを受け取り、それをラップして、すべての不均一分布、ガウス分布、ガンマ、二項式などを提供します。 BitGeneratorの厳密なストリーム互換性保証。私たちは（リリースするために）何も取り除くことはなく、それらを変更することもありません。

デフォルトに関する中心的な質問は、「引数のないコードg = Generator()は何をするのか？」です。現在、PRでは、任意の状態でXoshiro256 BitGeneratorを作成します（つまり、 /dev/urandomような優れたエントロピーソースから抽出されます）。「デフォルトなし」オプションは、それをエラーにすることです。ユーザーは、必要なBitGeneratorに明示的に名前を付ける必要があります。 @ eric-wieserのポイントは、「デフォルトなし」は、最初のリリースではカテゴリ別に_safe_オプションであるということです。デフォルトを提供する新しいリリースでは、既存のデフォルトを変更するのと同じように問題が発生することはありません。

rkern 2019年05月27日

@rkern 、シードが利用可能なエントロピーから自動生成される引数なしの場合のみを気に

対照的に、 @ bashtageは、シードが提供されているデフォルトのジェネレーターを気にしているようです。

imneme 2019年05月27日

@rkern 、シードが利用可能なエントロピーから自動生成される_引数なし_の場合のみを気にする場合は、基礎となるジェネレーターが何であるかは実際にはそれほど重要ではありません。結果は再現できないため、1時間ごとに変更される可能性があります（実行が異なれば、シードも異なります）。

作成後、 BitGeneratorを再シードできます。したがって、 Generator()機能する場合、シードされたPRNGが必要な人は、 @ bashtageの例のように、次の行にシードするだけであると私は完全に予想しています。

g = Generator()
g.bit_generator.seed(seed)

それはやや面倒です。そのため、タイピングに関してはほぼ同じくらい便利なので、とにかくほとんどの人が通常Generator(PCG64(<seed>))選ぶだろうと私が最初に提案した理由です。ただし、 @ bashtageは、追加の決定を行うことに直面したときに、ある程度の抵抗を正しく記録します。

ですから、私たちの前にはもっと広い質問があると思います。「ユーザーにこれらの1つをインスタンス化してほしいすべての方法は何ですか？また、それらの方法にデフォルト設定がある場合、それらのデフォルトはどうあるべきですか？」いくつかのオープンデザインスペースがあり、 @ bashtageによるGenerator(<seed>)またはGenerator(DefaultBitGenerator(<seed>))の提案はまだ可能です。

@bashtageドキュメントはどのくらい役立つと思いますか？つまり、一番上で「 PCG64が推奨されるデフォルトのBitGenerator 」であり、すべての例で一貫してGenerator(PCG64(seed))を使用した場合（他のアルゴリズムを具体的に示していない場合）？

Generator(<seed>)またはg=Generator();g.seed(<seed>)超えるGenerator(<seed>) default_generator(<seed>) _ function_があると確信しているかもしれません。次に、本当に変更する必要があり、何かを壊したくない場合は、新しい関数を追加して、古い関数に警告を追加するだけで済みます。最初のリリースではexperimentalとマークすることをお勧めします。これにより、確固たるコミットメントを行う前に、このインフラストラクチャを実際に監視する時間が与えられます。

rkern 2019年05月27日

内部状態の詳細を公開しないDefaultBitGeneratorオブジェクトを実際に作成するの

Generator引数として整数シードを直接サポートする方がはるかに使いやすいという@bashtageに同意します（例： np.random.Generator(1234) 。もちろん、これはDefaultBitGeneratorます。

Generatorドキュメントでは、NumPyの過去の各バージョンでのデフォルトのビットジェネレーターの完全な履歴を提供できます。これは基本的に@imnemeの提案であり、再現性の目的には十分だと思います。

shoyer 2019年05月27日

（以前のコメントに対するこの編集を見たばかりです）

おっと、 -O3を追加するのを忘れましたが、それでも醜いです： https ：

MSVCの場合、 -O3ではなく、 /O2または/Ox （ただし、 /O3はありません！）。

imneme 2019年05月27日

Generatorドキュメントでは、NumPyの過去の各バージョンでのデフォルトのビットジェネレーターの完全な履歴を提供できます。これは基本的に@imnemeの提案であり、再現性の目的には十分だと思います。

実際には、ピクルスのprotocol引数のような明示的なversion引数をGenerator / DefaultBitGeneratorに含める方がさらに良いでしょう。次に、 np.random.Generator(123, version=1)ようなものを記述して、「バージョン1」の乱数（それが何であれ）が必要であることを示し、 np.random.Generator(123, version=np.random.HIGHEST_VERSION) （デフォルトの動作）が最新/最大のビットジェネレーターが必要であることを示します。（それが何であれ）。

おそらくversion=0はNumPyがこれまで使用してきたMT19937であり、 version=1は私たちが選んだ新しいデフォルトである可能性があります。

shoyer 2019年05月27日

内部状態の詳細を公開しないDefaultBitGeneratorオブジェクトを実際に作成するのはどうですか？これは、他のビットジェネレータオブジェクトの1つのプロキシになりますが、原則として、生成された数値の特定のシーケンスを除いて、それらのいずれかをラップすることができます。これにより、ユーザーがデフォルトのBitGeneratorで何ができるかについてプログラムで推測することを思いとどまらせながら、改善されたアルゴリズムを使用できるようになることを願っています。

うーん。それは魅力的です。物事を複雑にしすぎて、このゴーディアンノットに別のループを追加しているように感じます（そして、もっとアレクサンダー風のストロークが利用できるはずです）が、それについて私が言わなければならない唯一の悪いことです。これにより、残りの決定が容易になります。統計的な品質とパフォーマンスに集中できます。

実際には、 Generator / DefaultBitGenerator 、 pickleような明示的なversion引数を含める方がよいでしょう。

私はこれのファンではありません。 pickle場合とは異なり、これらには使用できる意味のある名前があり、メカニズムはすでに実装されています。

rkern 2019年05月27日

私はこれのファンではありません。 pickle場合とは異なり、これらには使用できる意味のある名前があり、メカニズムはすでに実装されています。

典型的なNumPyユーザーの観点から次のことを考慮してください。

np.random.Generator(seed, version=0) vs np.random.Generator(seed, version=1)
np.random.Generator(MT19937(seed)) vs np.random.Generator(PCG64(seed))

ほとんどのユーザーは、RNGアルゴリズムの相対的なメリットについてほとんど知らないと考えるのが安全だと思います。ただし、ドキュメントを読まなくても、ほとんどの場合、 version=0 version=1 （新しいデフォルト）の方がversion=0よりも優れているはずだと安全に推測できます。ほとんどのユーザーにとって、それは本当に彼らが知る必要があるすべてです。

対照的に、 MT19937やPCG64ような名前は、実際には専門家、またはすでにドキュメントを読んだ人にとってのみ意味があります:)。

shoyer 2019年05月27日

あなたのユースケースでは、誰も彼らが_望んでいるversionを選択していません。既知のバージョンの結果を複製するために_必要な_ versionのみを選択します。彼らは常に、複製したい結果で使用された特定の値を探しています（暗黙的に許可したため、暗黙的に）。複数の値の間の関係について推論する必要はありません。

そして、いずれにせよ、そのレベルのクロスリリースの再現性は、 NEP19で私たちが放棄したものです。ディストリビューションのバージョン管理に反対する議論は、ここでも同様に当てはまります。

rkern 2019年05月27日

デフォルトに関するいくつかの考え：

99.9％のユーザーは、基礎となるアルゴリズムを気にしない、または知りたくない、ただ乱数が欲しいだけです。したがって、デフォルトの意見を選択するための+1は、ユーザーに選択させないでください。
dSFMTは、 MT19937よりも単純に高速なバージョンのようです（ドキュメントで「SSE2」をどれだけ高速に削除するかを説明するとよいでしょう）。とにかくビットストリームの再現性を保証するものではないので、内部状態の違いはあまり面白くなく、ここでの勝利の議論が「記事のレビュー中の生活を楽にする」であっても、 dSFTMはMT19937も優先されるべきです。
パフォーマンスは、ユーザーベースのかなりの部分にとって重要です。ジェネレータの統計的特性は、ごく一部のユーザーにのみ重要です。含まれているすべてのジェネレーターは、通常のユースケースでは問題ありません。したがって、デフォルトとして最速のものを選択するための+1。

rgommers 2019年05月27日

申し訳ありませんが、Windowsでは32ビットが引き続き重要です。https： //github.com/pypa/manylinux/issues/118#issuecomment-481404761を参照して

matthew-brett 2019年05月27日

データ分析でのリサンプリング手法の使用拡大に向けて大きな転換期を迎えているため、統計的特性には十分注意する必要があると思います。 Pythonがこの問題に関して少しずさんな評判を得た場合、たとえそれがデフォルトであったとしても、それはデータ分析のためにPythonを検討している人々による取り込みの障壁になる可能性があります。順列とシミュレーションを真剣に受け止めている人々にとってPythonが最適なパッケージであるとしたら、私は非常に嬉しく思います。

より高速な最先端ではないアルゴリズムを提供することは問題ないと思いますが、デフォルトではなく、それを回避して下位互換性を維持できる範囲で提供します。

matthew-brett 2019年05月27日

いくつかのフォレンジックとディスカッションについては、 https ：ください。

教科書には、重大なエラーを発生させることなく、PRNGを真のIIDU [0,1）変数に置き換えることができると暗黙的または明示的に想定する方法が記載されています[20、7、2、16、15]。ここでは、MATLAB、Pythonのランダムモジュール、R、SPSS、Stataなど、一般的に使用される多くの統計パッケージのアルゴリズムでは、この仮定が正しくないことを示します。

@ kellieotto 、 @ pbstark-順列とブートストラップの可能な限り最良の基礎を与えるために、ここでどのPRNGを選択すべきかについて意見がありますか？

matthew-brett 2019年05月27日

データ分析でのリサンプリング手法の使用拡大に向けて大きな転換期を迎えているため、統計的特性については多くの注意を払う必要があると思います。

同意しました。これらのプロパティが実際のユースケースに関連している限り、それは非常に重要です。通常提起される懸念は常に非常に学術的です。

いくつかのフォレンジックとディスカッションについては、 https ：ください。

非常に興味深い記事。 R、Python stdlib＆coとは異なり、NumPyはそれを正しく行う唯一のライブラリ（9ページの上部）であると結論付けています。

論文よりもさらに具体的な例を入手することは非常に有用です。現在のデフォルトジェネレーターもある時点で故障した場合、それはいつですか？ Rのsample関数のような例では、約17億のサンプルを描画するときに、40％の偶数と60％の奇数を生成します。ここでのブートストラップ/リサンプリングの同等物は何ですか？

rgommers 2019年05月27日

R（3.6）の最新リリースでは、切り捨てとランダムビットのアプローチが修正されています。
ランダムな整数を生成します。メルセンヌツイスターはデフォルトのままです
ただし、PRNG。

@Kellieオットブニ[email protected]と私はデフォルトのPRNGで思います
科学言語と統計パッケージは暗号化する必要があります
安全（CS-PRNG、例：カウンターモードのSHA256）、フォールするオプション付き
より速いが品質の低いものに戻る（例、メルセンヌツイスター）
速度が必要な場合。

Python用のCS-PRNGに取り組んできました：
https://github.com/statlab/cryptorandom

パフォーマンスは（まだ）素晴らしいものではありません。ボトルネックは型変換のようです
Python内で、バイナリ文字列（ハッシュ出力）を整数としてキャストします。私たちは
より多くの作業をCに移す実装に取り組んでいます。

乾杯、
フィリップ

2019年5月27日月曜日午前6時27分ラルフゴマーズ[email protected]
書きました：

私たちは統計的性質に多くの注意を払うべきだと思います。
リサンプリング手法のより多くの使用への大きなシフトの過程で
データ解析
同意しました。それらのプロパティが実際の使用に関連している限り
場合、それは非常に重要です。通常提起される懸念は
常に非常に学術的です。
いくつかのフォレンジックとディスカッションについては、以下を参照してください。
https://arxiv.org/pdf/1810.10985.pdf
非常に興味深い記事。 NumPyは約唯一のものであると結論付けています
R、Python stdlib＆coとは異なり、それを正しく行うライブラリ（9ページの上部）。
より具体的な例を取得することは非常に役立ちます
論文。現在のデフォルトジェネレーターもある時点で故障した場合、
それはいつですか？ Rのサンプル関数のような例は40％も生成します
約17億のサンプルを描画する場合、数値と60％の奇数。何ですか
ここで同等のブートストラップ/リサンプリング？
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWJEIA4CTLLHVGZVKBLPXPOUFA5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2Z
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AANFDWJW445QDPGZDGXMPA3PXPOUFANCNFSM4HPX3CHA
。

pbstark 2019年05月27日

パフォーマンスは、ユーザーベースのかなりの部分にとって重要です。ジェネレータの統計的特性は、ごく一部のユーザーにのみ重要です。含まれているすべてのジェネレーターは、通常のユースケースでは問題ありません。したがって、デフォルトとして最速のものを選択するための+1

まず、「最速」を選択する方法はありません。 @bashtageは、＃13163の現在のコードで

また、速度を気にするユーザーの「かなりの割合」がどれだけ大きいのだろうか。 Python自体は、平均してCよりも約50倍遅くなります。 NumPyユーザーベースのどの部分がPyPyで実行していますか（4倍の速度ブーストが得られます）？確かにいくつかありますが、それほど多くはないと思います。

そして、上記で概説したすべての変動性を考えると、速度を気にするその「重要な部分」について、デフォルトのPRNGがアプリケーションで最も速く実行されるというあなたの言葉を誰が受け入れるのでしょうか。賢明なこと（これも非常に楽しく、ほとんどのユーザーの手の届く範囲にあります）は、利用可能なさまざまなPRNGのベンチマークを行い、どれが最も速いかを確認することです。

対照的に、彼らはドキュメントに手がかりを見つけるかもしれませんが、あなたが指摘するように、特定のPRNGの統計的品質を理解することは、ほとんどのユーザーのレーダーではありません（そして専門家にとってさえ挑戦的です）。ほとんどの人は、いつ/気にかけるべきかどうかさえ知りません。ここは父性主義の場であると私は主張します。ほとんどのユーザーが何かを気にしないという事実は、メンテナがそれを気にしないという意味ではありません。

含まれているすべてのPRNGがほとんどのユースケースで問題ないことは事実ですが、それはかなり低い基準です。 Unixシステムには、統計的にひどいCライブラリPRNGが多数付属していますが、世界がその軸から外れることなく、何年にもわたって広く使用されてきました。

統計的プロパティ以外にも、ユーザーが自分で欲しいとは思わないかもしれないが、私が欲しいと思うかもしれないプロパティがあります。個人的には、PRNGのプロバイダーとして、些細な予測可能性を避けたいと思っています。誰かがPRNGからのいくつかの出力を見て、将来のすべての出力がどうなるかを言うことができるようにしたくありません。 NumPyが使用されるほとんどのコンテキストでは、予測可能性は問題ではありません。シーケンスを簡単に予測できることで恩恵を受ける敵は存在しません。しかし、誰かがNumPyのPRNGを使用するのは、統計を行うためにNumPyが必要なためではなく、以前にPRNGを見つけた場所だからです。そのコードは、PRNGを予測できることで恩恵を受ける実際の敵に直面する可能性があります。この異常値の状況に対してしっかりと保険をかけるために多額の支払い（たとえば、速度の大幅な低下）をすることは価値がありませんが、適度な保険はそれだけの価値があるかもしれません。

imneme 2019年05月27日

👍1

いくつかのフォレンジックとディスカッションについては、 https ：ください。
教科書には、重大なエラーを発生させることなく、PRNGを真のIIDU [0,1）変数に置き換えることができると暗黙的または明示的に想定する方法が記載されています[20、7、2、16、15]。ここでは、MATLAB、Pythonのランダムモジュール、R、SPSS、Stataなど、一般的に使用される多くの統計パッケージのアルゴリズムでは、この仮定が正しくないことを示します。

FWIW、バイアスのない範囲の数値を効率的に生成することについての@lemireによる素晴らしい論文があります。私はそれを、自分の記事でもいくつかのベンチマークを調査して実行するための出発点として使用しました。（64ビットを生成する場合、Lemireの方法では128ビットの乗算を使用して、64ビットの遅い除算を回避します。MSVCユーザーに発生する可能性のあるよく知られた問題はすべてあります。）

imneme 2019年05月27日

👍1

@pbstark @kellieotto arXivに掲載されたとき、興味を持ってあなたの論文を読みました。私はBIDSの何人かの友人を訪ねていました、そして彼らはあなたの仕事について言及しました。ディスカッションセクションでは、MT19937の「これまでのところ、O（10 ^ 5）レプリケーションで検出されるのに十分な大きさの一貫したバイアスを持つ統計は見つかりませんでした」と述べています。もう見つけましたか？ PCG64のような128ビット状態のPRNGの具体的な例を見つけましたか？これは、少なくとも汎用のデフォルトを選択する目的で、この考慮事項が他の考慮事項（IMO）を上回り始める可能性がある、実用的な関連性の妥当なしきい値であるように思われます。

新しいPRNGフレームワーク＃13163の優れた機能は、プラグインするだけで誰でも独自のBitGeneratorを提供できることです。Numpyで使用するためにNumpyである必要はありません。コード。 cryptorandomをCでBitGeneratorとして実装することを検討することをお勧めします。そうすれば、他のオプションと直接比較できます。

rkern 2019年05月27日

👍1

個人的には、スピードを本当に気にする人は、必要に応じてさらに一歩前進することを期待しています（ここではそれほど多くはありません）。 安全なデフォルトを提供する必要があります。現在の私の推測では、これは暗号化を除くすべての目的で安全なデフォルトを意味します（おそらくドキュメントに警告があるはずです）。多くのユーザーは速度を気にかけていますが、率直に言って、私が速度を高くしすぎることを躊躇しているのはそのためです。
Numpyがうまくいったその記事は面白そうですが（おそらくそれを正しくするためにRobertに賛辞を送ります！）、実際にはビットジェネレータではなくサンプラーです。

@pbstark numpy / randomgenと互換性のあるBitGeneratorとしてこれを実装したいと思うかもしれませんか？それはおそらく、両方のそれをスピードアップし、より多くの有用な形態で幅広い視聴者が利用できるようにする最も簡単な方法があります。あなたとケリー・オットボニはバークレーにいるようですので、それを実現するためにしばらく会うことができますか？（ただの申し出ですが、最初に自分でコードを詳しく調べる必要があります）。

seberg 2019年05月27日

その_RandomSampling：Practice Makes Imperfect_紙に関しては、良い読み物ですが、1兆個のコアが1ナノ秒あたり1つの数値を100年間生成した場合、生成される数値は2 ^ 102未満になることを覚えておく価値があります。

簡単に予測できるPRNG（メルセンヌツイスターのような大きな状態空間を持つものでも）の場合、特定の出力シーケンスを生成できるかどうかを実際に知ることができます（存在する場合はそれを生成するシードを見つけ、存在しない場合は物欲しそうに感じます））が、他の自明ではない予測可能なPRNGの場合、どの出力シーケンスが生成されないか、どの出力シーケンスが存在するかを（簡単に）知ることはできませんが、十分にまれであるため、検索の期間中にそれらを見つけることはほとんどありません。（ご存知かもしれませんが、2 ^ 80の出力内に_TwelthNight_を含むzipファイルを吐き出すことがわかっているPRNGがありますが、幸運を祈ります。）

imneme 2019年05月27日

本当にcryptoprngが必要な場合は、最新のハードウェアでの唯一の選択肢は
専用の命令があるため、AES。 @lemireには実装があります
ここhttps://github.com/lemire/testingRNG/blob/master/source/aesctr.hその
noncryptoジェネレーターと同じくらい高速です。行くことができるChaCha20もあります
SIMDで高速。ただし、どちらも古いハードウェアでは非常に遅くなります。 ThreeFryと
Philoxはすでに含まれており、cryptoliteカウンターprngです。

IMO暗号は、費用便益の点で過大評価されています。私は何も知らない
山のPRNG問題による重要な撤回
10e6の出版された論文の順序で使用されます。私が見た唯一のアプリケーション
PRNGが本当に問題だったのは、期間がそうだった場合でした
発電機が全サイクルを完了したことは小さい。ここでも唯一
効果は、主なものを複製した研究のサンプルサイズを減らすことでした
結果は、より長い期間のシステムで再実行されます。

月、2019年5月27日には、午後07時50分ロバート・カーンの[email protected]は書きました：

@pbstark https://github.com/pbstark @kellieotto
https://github.com/kellieotto興味を持ってあなたの論文を読みました
arXivに現れました。私はBIDSで何人かの友人を訪ねていました、そして彼らは持っていました
あなたの仕事に言及しました。ディスカッションセクションでは、「これまでのところ、
で検出されるのに十分な大きさの一貫したバイアスを持つ統計を見つけました
MT19937のO（10 ^ 5）複製」。もう1つ見つけましたか？
PCG64のような128ビット状態のPRNGの具体例は？それは私には思えます
この考慮事項が実用的な関連性の合理的なしきい値である
少なくとも選択する目的で、他の人（IMO）を上回り始める可能性があります
汎用のデフォルト。
新しいPRNGフレームワーク＃13163の優れた機能
https://github.com/numpy/numpy/pull/13163は、誰でもできるということです
プラグインするだけの独自のBitGeneratorを提供します。
人々がnumpyコードでそれを使用するには、numpyである必要があります。私は...するだろう
CでのBitGeneratorとしてのcryptorandomの実装を検討することをお勧めします
そのため、他のオプションと直接比較することができます。
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=ABKTSRO5PKW4MRFSBGUFUNTPXQUOLA5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2Z
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABKTSRMRIHC4OYDR52HLTHDPXQUOLANCNFSM4HPX3CHA
。

bashtage 2019年05月27日

また、速度を気にするユーザーの「かなりの割合」がどれだけ大きいのだろうか。 Python自体の平均はCよりも約50倍遅いです。NumPyユーザーベースのどの部分がPyPyでPythonを実行していますか（4倍の速度向上が得られます）？確かにいくつかありますが、それほど多くはないと思います。

あなたは通常のユーザーではないと思います：）NumPyはほとんどCであり、Cで自分のことをするのと同じくらい高速です（まあ、ほとんどの場合高速です）。また、PyPyは科学的なアプリケーションに対応した製品ではなく、いずれの場合も低速です（NumPyが使用するCPython APIの使用に制限されているため、JITのメリットを享受できません）。

いずれにせよ、これはトピックから外れています。その速度の問題を主張することは物議を醸すものではありません。

rgommers 2019年05月27日

@imneme有界整数にはlemiresメソッドを使用しています。これ以来
レガシーや減価償却のない新たなスタート
良いアルゴリズム。

月、2019年5月27日には、19時46 imneme [email protected]は書きました：

いくつかのフォレンジックとディスカッションについては、以下を参照してください。
https://arxiv.org/pdf/1810.10985.pdf
教科書は、PRNGができることを暗黙的または明示的に想定する方法を提供します
材料を導入せずに真のIIDU [0,1）変数の代わりに使用する
エラー[20、7、2、16、15]。ここでは、この仮定が
MATLABを含む多くの一般的に使用される統計パッケージのアルゴリズム
Pythonのランダムモジュール、R、SPSS、およびStata。
FWIW、@ lemireによる素敵な論文https://arxiv.org/abs/1805.10941があります
範囲内の数値を効率的に生成するためのhttps://github.com/lemire
バイアスなし。私はそれをいくつかを探索して実行するための出発点として使用しました
私自身の記事のベンチマークも
http://www.pcg-random.org/posts/bounded-rands.html 。（生成する場合
64ビット、Lemireの方法では、低速を回避するために128ビットの乗算を使用します
64ビット除算、MSVCで発生する可能性のあるすべてのよく知られた問題
ユーザー。）
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=ABKTSRKNAQAK4WIXG5SVLO3PXQUA3A5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2Z
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABKTSRKV3KYKRLNMBKNU4JLPXQUA3ANCNFSM4HPX3CHA
。

bashtage 2019年05月27日

👍1

_safe_デフォルトを提供する必要があります。現在の私の推測では、これは暗号化を除くすべての目的で安全なデフォルトを意味するということです。

それについて議論するのは難しいです。私の質問は-何が安全ですか？さまざまなプロパティを持つさまざまな程度の準ランダム性があります。これまでのところ、具体的な例を挙げている人は誰もいません。ここでは、他の問題、PR、スレッドのいずれでもありません。抽象的な統計的特性について話すだけでは役に立ちません。

rgommers 2019年05月27日

私の感覚では、PCG64が適切なデフォルトになるでしょう。 Windowsでの速度の不利な点は、Anacondaet。を使用している人々には明らかではありません。 al。、およびある時点で修正される可能性があります。並列実行はPythonの新しい機能であるため、設定可能なストリームを持つことも望ましいプロパティだと思います。

charris 2019年05月27日

👍1

Visual StudioでのPCG64の速度ペナルティは、一掃できないものであることに非常に懐疑的です。

これはどこかで注意深く評価されましたか？

lemire 2019年05月27日

その速度の問題を主張することは物議を醸すものではありません。

私の質問は-何が安全ですか？

ロジックを一貫して適用します：「何が速いか」？どのnumpyプログラムが実際にBitGeneratorのパフォーマンスを重大なボトルネックとして持っているのか、私にはよくわかりません。 2倍の速度のBitGeneratorを使用した場合、完全な計算で5％の速度向上が得られますか？おそらくそれでもないでしょう。 Python-not-being-as-fast-as-Cは問題ではありません。実際に役立つPRNGを多用するプログラムでさえ、 BitGenerator膨大な時間を費やさないというだけです。おそらく、利用可能な選択肢のいずれかで十分です。

rkern 2019年05月27日

Visual StudioでのPCG64の速度ペナルティは、一掃できないものであることに非常に懐疑的です。

アップスレッドclang PCG64をアセンブリにコンパイルして64ビットMSVCを盗むことができる方法を示します。したがって、64ビットWindows上のMSVCが克服できない問題であるとは思いません。

トリッキーなのは、32ビットシステム上のPCG64ですが、32ビットWindowsだけがまだ実際に重要である可能性があります。その場合、それは32ビットISAに制限することよりもMSVCについてではありません。

rkern 2019年05月27日

@Kellie Ottoboni [email protected]と私が指摘するのは、
適度なサイズの問題の場合でも、MTの状態空間は小さすぎて近似できません
均一な順列（n <2100）または均一なランダムサンプル（n = 4e8、k = 1000）。

これは、ブートストラップから順列テスト、MCMCまですべてに影響します。
意図した分布と実際の分布の違い
分布は任意に大きくすることができます（総変動距離が近づいています
2）。それは大きくて深刻です。

の「統計」関数でMTを破る努力はしていません。
数年。私はそれを破る体系的な方法があるとかなり確信しています
（分布距離が非常に大きいため）。

乾杯、
フィリップ

12時26分PMロバート・カーンの月、2019年5月27日には[email protected]
書きました：

その速度の問題を主張することは物議を醸すものではありません。
私の質問は-何が安全ですか？
ロジックを一貫して適用します：「何が速いか」？いい考えがない
どのnumpyプログラムが実際にBitGeneratorのパフォーマンスを持っているか
重大なボトルネック。 2倍の速度のBitGeneratorを使用すると、
完全な計算で5％のスピードアップが得られますか？おそらくそれでもないでしょう。
Python-not-being-as-fast-as-Cは問題ではありません。それだけです
実際に役立つPRNGを多用するプログラムは、大量の費用をかけません。
BitGeneratorでの時間。おそらく利用可能な選択肢のいずれかが
十分。
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWKSMPAG3GFUCUFRXCDPXQYVRA5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOOR
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AANFDWIDCPAJJ6DJ3RO332LPXQYVRANCNFSM4HPX3CHA
。

pbstark 2019年05月27日

@pbstark私が見たいのは、MTまたは128ビットPRNGが失敗し、 cryptorandomが機能する問題の具体的な実装です（人為的である可能性がありますが、あまり工夫されていません）。リサンプリング方法が128ビットPRNGで誤った推論を行い、 cryptorandom正しい推論を行うデータセットを指摘できますか？

rkern 2019年05月27日

PCG64に移行すると、問題のサイズの下限が悪化します。
その状態空間はMTのそれよりもさらに小さいからです。もちろん、それは可能です
それでも、のサブグループをサンプリングする可能性があるという点で、「より良い」ランダム性を生成します。
MTよりも均等に置換群。しかし、それは前に故障しなければなりません
500は10を選択し、21より前に！。

乾杯、
フィリップ

12:30ロバート・カーンの月、2019年5月27日には[email protected]
書きました：

VisualStudioでのPCG64の速度ペナルティに非常に懐疑的です
拭き取れないもの。
アップスレッドclangがPCG64をアセンブリにコンパイルして盗むことができる方法を示します
64ビットMSVCの場合、64ビットWindowsのMSVCは
乗り越えられない問題。
トリッキーかもしれないのは、32ビットシステム上のPCG64で、そのうち32ビットのみです。
Windowsはまだ私たちにとって実際的に重要かもしれません。その場合は少ないです
32ビットISAに制限するよりもMSVCについてです。
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWJFCINQCYGFCI7ULI3PXQZGLA5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AANFDWK6QTB65Z4TJU76XKTPXQZGLANCNFSM4HPX3CHA
。

pbstark 2019年05月27日

いずれにせよ、PRNGについて十分に理解していないので、最初に統計的特性に焦点を当てたいと思います（答えがすべて非常に優れている場合は、問題ありません）。私が今疑問に思うことの1つは、k次元の同程度分布です。現在、MTと比較してここでうまく機能するPCGなどのバリアントを使用していますか？（非線形ダイナミクスから来るので、少し緊張しますが、PRNGの概要が十分になく、次の2日で理解できません...

seberg 2019年05月27日

最先端のパフォーマンスを気にするWindows32ビットユーザーがたくさんいるとは思えません。 64ビットに切り替えるのにそれほど労力はかかりません。

matthew-brett 2019年05月27日

私も見たいです。

私たちは、数学に基づいて、多くの大きな問題があるに違いないことを知っています、
しかし、まだ例を示すことはできません。

予防原則は、私たちが知っているので、
問題があり、それらを防ぐ方法（CS-PRNG）を知っている場合は、
これはデフォルトであり、ユーザーがそうすることを選択した場合は、ユーザーが慎重にならないようにします。

12:39ロバート・カーンの月、2019年5月27日には[email protected]
書きました：

@pbstarkhttps ：//github.com/pbstark私が見たいのは具体的なものです
問題の実装（人為的である可能性がありますが、あまり工夫されていません）
どのMTまたは128ビットPRNGが失敗し、cryptorandomが機能するか。あなたはできる
リサンプリング方法が間違っているデータセットを指摘する
128ビットPRNGによる推論とcryptorandomによる正しい推論？
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWODTUIPNMVOJB6QP3DPXQ2FPA5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AANFDWITAGQFZDQSIFNEHETPXQ2FPANCNFSM4HPX3CHA
。

pbstark 2019年05月27日

k-同程度分布定理は、全体にわたるPRNG出力のアンサンブルプロパティです。
PRNGの期間。それは良いことですが、他のことについては何も言いません
出力のシリアル相関など、ランダム性の失敗の種類。
それは比較的低いバーです。

12:48セバスチャン・ベルクで月、2019年5月27日には[email protected]
書きました：

私はPRNGについて十分に知らないので、いずれにせよ実際に重量を量ることができます。
最初に統計的特性に焦点を当てる（答えがそれである場合）
それらはすべて非常に良いです、素晴らしいです）。私が今疑問に思うことの1つは
k次元の同程度分布。現在、PCGなどのバリアントを使用していますか
MTと比較してここではうまくいきますか？（非線形ダイナミクスから来て、それ
少し緊張しますが、PRNGの概要が十分ではなく、
次の2日でそれを取得しません...
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWPOBTPYHC3XBINQYA3PXQ3HZA5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2Z
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AANFDWOEB7KR2YJZWHRRAHLPXQ3HZANCNFSM4HPX3CHA
。

pbstark 2019年05月27日

@pbstark MTは、PCG（および他のジェネレーター）が合格するいくつかの統計的検定に失敗します。

lemire 2019年05月27日

@rkern

MSVCでror命令を生成したい場合は、「_ rotr64」組み込み関数を使用する必要があると思います。

また、最適化のために「/ O2」フラグを好むかもしれません。

それを見ると、PCG64を使用したい場合は、アセンブリで作成するのが実際に最善かもしれません。

lemire 2019年05月27日

@pbstarkの場合、未知のシードで初期化されたPCG-64からの出力を次に示します（実際、ストリームについても説明します。 0x559107ab8002ccda3b8daf9dbe4ed480 ）。

  64bit: 0x21fdab3336e3627d 0x593e5ada8c20b97e 0x4c6dce7b21370ffc
     0xe78feafb1a3e4536 0x35a7d7bed633b42f 0x70147a46c2a396a0
  Coins: TTTHHTTTHHTHTTTTHTHHTTTTTHTTHHTTHHTHHTHHHHHHHHTTHHTTHHTHHHHHTHTHH
  Rolls: 5 3 5 2 5 3 1 6 6 5 4 4 5 5 5 6 2 3 5 3 2 3 2 5 6 2 4 6 2 3 4 6 3
  Cards: 5h 3h 3c 8d 9h 7s Kh Ah 5d Kc Tc 6h 7h 8s Ac 5c Ad Td 8c Qd 2h As
     8h 2d 3s 5s 4d 6d 2s Jd 3d 4h Ks 6s Qc Js Th 9d 9c Ts Jh 4c 2c 9s
     6c 4s 7c 7d Jc Qs Kd Qh

ここで、ランダムに選択されたシードを使用して別のpcgジェネレーターを初期化するとします。議論のために、 0xb124fedbf31ce435ff0151f8a07496d3選びましょう。この既知の出力を検出する前に、いくつの出力を生成する必要がありますか？上で使用したシードを知っているので、（PCGの距離関数を介して）約2.5×10 ^ 38（または約2 ^ 127.5）の出力に答えることができます。参考までに、10 ^ 38ナノ秒は宇宙の年齢の2300億倍です。

したがって、PCG-64には実際にそこにあるシーケンスがありますが、実際には、どこを見ればよいかを教えない限り、実際にはそれを見つけることはできません。（そして、ストリームを変更すると、さらに多くの可能性があります。）

通常のPCGでは、シェイクスピアプレイを出力する可能性は実際にはゼロです。 PCG拡張生成スキームは、実際にはシェイクスピアプレイを出力できますが、考案されていないシナリオで出力される可能性は非常に小さいため、本質的にゼロです。私の目には、実際的な影響がまったくないプロパティにはほとんど価値がありません。

（また、暗号的に安全なPRNGは、k次元的に等分配されることが保証されておらず、すべての可能なシーケンスを生成できるPRNGが必要な人にとっては特効薬でもありません。PRNGから必要なビット数よりも多くのビットが必要な瞬間シードしてその状態として格納する場合、生成できないビットシーケンスが必然的にいくつかあります（証明：鳩の穴の原理による）。また、シードと同じ出力量に制限すると、何ができるのでしょうか。本当に探しているのはハッシュ関数、またはシード入力がPRNGではなく本当にランダムである場合はID関数だけです。）

imneme 2019年05月27日

好奇心から、 aesctr.hを使用してAESカウンタービットジェネレーターをラップしました。時間はランダム値あたりのns単位です。

+---------------------+--------------+----------+--------------+
|                     |   Xoshiro256 |    PCG64 |   AESCounter |
|---------------------+--------------+----------+--------------+
| 32-bit Unsigned Int |      3.40804 |  3.59984 |      5.2432  |
| Uniform             |      3.71296 |  4.372   |      4.93744 |
| 64-bit Unsigned Int |      3.97516 |  4.55628 |      5.76628 |
| Exponential         |      4.60288 |  5.63736 |      6.72288 |
| Normal              |      8.10372 | 10.1101  |     12.1082  |
+---------------------+--------------+----------+--------------+

bashtage 2019年05月28日

よくできました、@ bashtage。

覚えておくべきいくつかのことは、特定のAES命令はアーキテクチャによって異なり、アクティブに使用されるすべてのCPUに存在するわけではないため、（遅い）フォールバックパスが必要であるということです。

また、それは少しリンゴとオレンジの比較です。特殊な命令を使用することに加えて、AESコードはループ展開からその速度のチャンクを取得しています—実際にはブロックで数値を生成してからそれらを読み取ります。展開すると、PRNGが高速化される可能性があります。 FWIW、 @ lemireには、実際にはAVX命令を使用して複数の出力を一度に生成

imneme 2019年05月28日

少なくとも1つのコンセンサスポイントを要約できるかどうかを見てみましょう。どのBitGeneratorアルゴリズムを使用するかについて、numpyが意見を述べ、1つのBitGeneratorを他のアルゴリズムよりも宣伝する必要があることに同意します。

そのコンセンサスに一致し、他のオプションのいくつかが持つ可能性のある問題のいくつかを回避する「デフォルトなし」オプションをスケッチすることをもう1つ突き刺してください。牽引力がない場合は、黙ります。

「デフォルトなし」オプションが本当に意味したのは、「匿名のデフォルトなし」でした。シードされたGeneratorを取得する最も便利な方法が、指定するPRNGに名前を付ける方法になるように、APIを設計する方法はまだあります。たとえば、 BitGeneratorアルゴリズムの全範囲を_含まない_としましょう。 numpyをかなり最小限に抑え、完成度をscipyやその他のサードパーティライブラリに任せるようにしています。ここでそうすることをお勧めします。現在のアーキテクチャの優れている点は、これらのBitGeneratorを他のライブラリに移動できることです。つまり、従来のRandomStateと、人々が使用することを好む1つのBitGeneratorをサポートするためにMT19937のみを提供するとします。議論のために、それがXoshiro256だとしましょう。 Generator.__init__()コンストラクターにBitGenerator必要になるようにしましょう。しかし、また、の関数を定義してみましょうnp.random.xoshiro256_gen(seed)戻っていることをGenerator(Xoshiro256(seed))カバーの下に。シードされたGeneratorを取得する方法として、その便利な機能を文書化します。

ここで、いくつかのリリースを早送りします。 PCG64 、 ThreeFryなどをrandom-tngまたはscipyまたはその他のパッケージにプッシュし、そのうちの1つが人気になったとします。追加機能または新しい統計上の欠陥はXoshiro256ます。どのBitGenerator人々が使用すべきかについてのnumpyの意見をPCG64に更新することにしました。次に、 PCG64 BitGeneratorクラスを追加し、 np.random.pcg64_gen(seed)関数を追加します。 np.random.xoshiro256_gen(seed)に非推奨の警告を追加して、推奨されるアルゴリズムではなくなったことを示します。新しいコードではnp.random.pcg64_gen(seed)を使用することをお勧めしますが、 Xoshiro256アルゴリズムを使用せずに引き続き使用することをお勧めします。警告、明示的にGenerator(Xoshiro256(seed))使用する必要があります。

これにより、「匿名」APIで発生する問題の一部（つまり、 Generator(seed) 、 Generator(DefaultBitGenerator(seed)) 、 np.random.default_gen(seed) ）を回避できると思います。もはや優先されなくなったアルゴリズムを永続的にサポートできます。意見を変更するときに、意見のある「優先」コンストラクターに別のことをさせる必要はありません。バージョン番号ではなく本名を使用して区別するため、コードを更新して古い結果を再現する方法を常に知っています（何らかの理由で無害な警告に耐えられない場合）。出所のないコードや記録されたnumpyのリリース番号を取得して、その更新を行うこともできます。同時に、アルゴリズムの数を最小限に抑え、ライブラリを操作するための最も簡単な方法をベストプラクティスにすることで、numpyの意見を効果的に表現することができます。

それはどのように聞こえますか？最初のリリースでは、そのBitGeneratorを確実に選択するためにまだ多くの努力を払う必要があります。それはまだ重要です。

rkern 2019年05月28日

最先端のパフォーマンスを気にするWindows32ビットユーザーがたくさんいるとは思えません。 64ビットに切り替えるのにそれほど労力はかかりません。

同意する。 Win32でのPCG64の問題は単にパフォーマンス（そしておそらくある程度の努力で改善できる問題）であるため、それがブロッカーではないことに同意しますか？

rkern 2019年05月28日

MSVCでror命令を生成したい場合は、「_ rotr64」組み込み関数を使用する必要があると思います。
また、最適化のために「/ O2」フラグを好むかもしれません。

ありがとう！ @imnemeは私のためにこれらすべての失敗を指摘しました。 :-)

rkern 2019年05月28日

@seberg警戒心につながった、あなたの分野からの引用はありますか？たとえば、MT19937のk = 623の同程度分布定理が、より小さなPRNGが引き起こす非線形ダイナミクスシミュレーションの問題を修正したことを示した論文ですか？それを参考にして、より具体的な保証を提供できるかもしれません。 _一般_では、同程度分布定理に関する私の見解は、一般に、PRNGの同程度分布をPRNGの状態サイズで許可されている最大値に近づけたいというものです。 _practice_で、PRNGが他の点で目的に十分な大きさである場合（PractRandを通過する、描画する予定のサンプル数の2乗よりも周期が大きいなど）、心配する理由はあまりありません。正確なk 。他の人は異なる意見を持っているかもしれません、そして多分あなたの分野で私が知らない特定の問題があるかもしれません。その場合は、利用可能な特定のソリューションがあります！

rkern 2019年05月28日

好奇心から、 aesctr.hを使用してAESカウンタービットジェネレーターをラップしました

私は間違っている可能性がありますが、これが@pbstarkの懸念に役立つとは思いません。 AES-CTRはCS-RNGですが、すべてのCS-RNGに、かなりのkすべての可能なk!順列に（理論的に）到達できるようにするために必要な長い期間があるわけではありません。カウンターはまだ128ビットの数値であり、ロールオーバーすると、期間の終わりに到達します。 @pbstarkは、非常に大規模な

rkern 2019年05月28日

一般に、同程度分布定理に関する私の見解は、PRNGの同程度分布を、PRNGの状態サイズで許可されている最大値に近づけたいというものです。

最大の同程度分布が望ましい特性であると考える人もいますが、それは欠陥と見なすこともできます（そして、多くのことを述べている論文がそこにあります）。 _k_-bit PRNGがあり、すべての_k_-bitシーケンスが1回だけ発生する場合、誕生日の問題に違反することになります。これは、約2 ^（k / 2）の出力後に出力が繰り返されると予想されることを示しています。（私はこれらのアイデアに基づいて誕生日の問題の統計的検定を作成しました。64ビット出力の64ビット状態のPRNGであるSplitMixと32ビット出力の64ビットのXoroshiro64 +で、統計的に妥当でない繰り返しがないことを正しく検出し

興味深いことに、64ビットの繰り返しがない（または繰り返しが多すぎる-ポアソン分布が予想される）ためにPRNGに失敗する統計的検定を作成することは非常に実用的ですが、逆に、省略されている値がわからない場合は、すべての64ビット値の36.8％の省略を検出します。

明らかに、_k_が大きくなるにつれて、期待されない繰り返しの欠陥をテストすることは実用的ではなくなりますが、状態のサイズ（および期間）が大きくなるにつれて、サイズが追加されることは、それを示すことの両方が実用的でないことを意味します。最大に等分配されたPRNGは、繰り返しに失敗したために欠陥があり、同様に非実用的であり、非最大に等分配されたPRNGは、いくつかの_k_ビットシーケンスを繰り返し（統計的にもっともらしい方法で）、他のシーケンスを完全に省略したために欠陥があります。どちらの場合も、PRNGは大きすぎて、2つを区別できません。

imneme 2019年05月28日

私も見たいです。私たちは、数学に基づいて、多くの大きな問題があるに違いないことを知っていますが、まだ例を示すことはできません。予防原則は、大きな問題があることを知っており、それらを防ぐ方法（CS-PRNG）を知っているので、デフォルトでそれを実行し、ユーザーが選択した場合に注意を払わないようにすることもできます。

私はこの議論と証拠に納得していないと言わざるを得ません。そのため、Numpyユーザーの前に立つのは気が進まないので、この理由で切り替える必要があると伝えます。私はこの声明を擁護する準備ができていないので、これらの例を求めています。それらは説得力があり、あなたが私たちに勧めているこの立場を擁護する準備をしてくれるでしょう。

有限のPRNGが真のRNGに達しない特性はたくさんあります。そして、理論的には、真のRNGのプロパティに依存して実行したい計算がたくさんあります（または、少なくとも、それらをどれだけ緩和できるかを厳密に証明していません）。しかし、これらの欠点の多くは、実行する実際の計算の結果に、ごくわずかで、実際には目立たない影響しか与えません。これらの違反は、否定的なものではなく、オールオアナッシング、ゴー/ノーゴーのようなものです。それらには効果量があり、私たちは多かれ少なかれ効果を許容することができます。

もちろん、説得力のあることに、特定のサイズのPRNGは、一部のkに対してすべてのk!順列を均等に生成できないことを示しています。私が見逃しているステップは、これらの順列をすべて生成できないことが、実行したい具体的な計算にどのように影響するかということです。 PractRandまたはTestU01に追加して、問題を人々に示すことをお勧めするテストがありません。

@imnemeのPCGペーパーから非常に有益であることがわかった分析ラインの1つは、各PRNGの複数のより小さな状態のバージョンを導き出し、それらがTestU01に失敗し始めた場所を正確に確認することでした。これにより、「X PRNGが合格」または「失敗」と言うだけでなく、PRNGアーキテクチャを通常比較する方法が得られます。また、使用中の状態サイズ（多数のGiBのサンプルでTestU01に合格）でのヘッドルームの量を見積もることができます。 8ビットPRNGの問題を実証するために実行できる具体的な計算はありますか？ 16ビットPRNG？次に、この新しいテストで、TestU01 / PractRandが現在行うよりも早くPRNGに関する情報が得られるかどうかを確認できます。そして、それは非常に役に立ちます。

一方、PractRandの現在の一連のテストの小さなPRNGの障害点よりも、これらの順列に基づいて障害を示すためにPRNGから引き出されたデータが必要な場合、この問題は実用的ではないと結論付けます。懸念事項であり、順列の問題が私の計算に実際的な影響を与えるかどうかの適切なプロキシとして「passesPractRand」を使用できます。

しかし、実行して問題を人々に示すことができるプログラムが手元にあるまで、これに基づいてCS-PRNGを推進することに抵抗があります。私はその選択を説得力を持って説明することはできません。

rkern 2019年05月28日

32アイテムをシャッフルするときにそれを要求する人のために、すべて32！シャッフル（つまり、それらのすべての263130836933693530167218012160000000）は、それらの32からのランダムサンプルのみを提供するPRNGではなく、生成可能である必要があります。シャッフル、私は実際にあなたが膨大な数を要求しようとしているなら、あなたはただ十分に大きく考えていないだけだと言うでしょう。

したがって、私は（顔を合わせて）それらのシャッフルが出てくる順序も事前に決定されるべきではないと主張します！明らかに、32個すべてを出力するように要求する必要があります。可能なすべての順序でシャッフルします—（32！）！必要なものです！もちろん、これには状態に3.8×10 ^ 18エクサバイトが必要であり、初期化するには同様の量のエントロピーが必要ですが、すべてがそこにあることを知っておく価値は確かにあります。

imneme 2019年05月28日

... np.random.xoshiro256_gen(seed)に非推奨の警告を追加して、推奨されるアルゴリズムではなくなったことを示します。新しいコードではnp.random.pcg64_gen(seed)を使用することをお勧めしますが、警告なしでXoshiro256アルゴリズムを引き続き使用することをお勧めします。明示的にGenerator(Xoshiro256(seed))使用する必要があります

それでも、非推奨と、本当に知りたくない奇妙な名前の両方でユーザーを悩ませています。

NEPは次のように述べています。

デフォルトを更新する十分な理由がある場合は、それを実行して、アルゴリズムを明示的に指定しなかったユーザーのビットごとの再現性を壊すことが、より良いオプションです（そしてあなたが以前に主張していたもの）。

「デフォルトなし」オプションが本当に意味したのは、「匿名のデフォルトなし」でした。

では、ユーザーが使用しているPRNGの名前を知りたいというのはあなたのポイントですか？

これをユーザーの観点から見てください。それらをnp.random.rand ＆coからnp.random.RandomState()から、メソッドを使用するのは十分に困難です。今度はより良いシステムを紹介します。彼らが目にするのはnp.random.xoshiro256_gen()ですか？これは、使いやすさの点で大きな回帰になります。

rgommers 2019年05月28日

では、ユーザーが使用しているPRNGの名前を知りたいというのはあなたのポイントですか？

いいえ、それは人々が回避していたdefault_generator(seed)ような「指定された移動ターゲット」APIを持つ問題を軽減することです（たとえば、 @ shoyerのversion引数）。

ストリームの互換性を維持すること（NEP 19はこれを否認します）は、APIの破損の二次的なものです。異なるBitGeneratorは、機能セットに応じて異なる有効なAPIを持ちます（主に、設定可能なストリーム、ジャンプアヘッドですが、PRNGのパラメーター化の程度に応じて、他のAPIもあります）。したがって、デフォルトのPRNG選択を変更すると、出力される値を変更するだけでなく、実際にコードが破損します（つまり、実行されなくなったり、正しく実行されなくなったりします）。

たとえば、最初にPCG64ます。 128ビットの状態、2 ^ 127の設定可能なストリームがあり、ジャンプアヘッドを実装します。素晴らしく、フル機能。したがって、人々はdefault_generator(seed, stream=whatever)書き始めます。さて、将来の作業で、他の何かに切り替えたくなるような大きな統計上の欠陥が見つかったとしましょう。デフォルトとしてプロモートする次のPRNGは、128ビット以上の状態（簡単です。汎用のデフォルトとしてこれよりも小さいものはお勧めしません）、ジャンプアヘッド（ハード！）、> = 2 ^ 127の設定可能なストリーム（whoo、少年！）、コードにすでに存在するdefault_generator()の使用を壊さないために。今、私たちはそのラチェットと一緒に暮らすことができるかもしれません。

@shoyerは、デフォルトのBitGenerator常に意図的に最小公分母の機能に限定することができるかもしれないと提案しました。それはうまくいくでしょう！しかし、 @ charrisが

今度はより良いシステムを紹介します。彼らが目にするのはnp.random.xoshiro256_gen()ですか？これは、使いやすさの点で大きな回帰になります。

奇妙な名前が問題である場合は、ポリシーが同じである限り、よりわかりやすい一般的な名前を使用できます（新しい関数を追加し、古い関数について警告を開始します）。私はそれと同等だと思います。これを頻繁に行うべきではありません。

ラチェットを使用してversionメカニズムを回避することにした場合も、問題ありません。

rkern 2019年05月28日

「デフォルト」についての私の見解は、 Generator()が常に機能するように、実装の詳細として残すことができるというものです。常に再現可能な結果（ジェネレーターの変更まで）を取得する唯一の方法は、構文Generator(BitGenerator(kwarg1=1,kwargs2=b,...))を使用することであることに注意して、これを理解します。

状態へのアクセスにはピクルスが必要であるため、実装の詳細を実際に非表示にすることは実用的ではありません。

別の方法は、他の関数と同じように扱い、一般にランダム生成を行い、変更が必要な場合は標準の非推奨サイクルを実行することです。これは、物事を正しく行うユーザーに影響を与えることはありません。ドキュメントに十分な警告があれば、少なくとも大規模なプロジェクトでは、これに対して適切なヒット率を得ることができる可能性があります。ここで私が提案しているのは、新しいAPIについて考えるときに、ストリームの互換性の保証が行われたことを忘れることができるということです。

bashtage 2019年05月28日

＃13650で@bashtageは、私がアクセス禁止Generator().bit_generatorまだへの直接アクセスがないと酸洗ことができますようにstate 。わずかに書き直されたtest_pickleを、Python Thread全体で使用できるように渡します。

mattip 2019年05月28日

私の質問は-何が安全ですか？さまざまなプロパティを持つさまざまな程度の準ランダム性があります。これまでのところ、具体的な例を挙げている人は誰もいません。ここでは、他の問題、PR、スレッドのいずれでもありません。

一部の_N_（ 512、1024）の「

アルゴリズムの序数ランキングを可能にする統計品質のより洗練されたビューが必要な場合は、 @ imnemeのPCGペーパーのセクション3をお勧めします。このペーパーでは、アルゴリズムの縮小状態バリアントのプロファイルを使用して、その方法を理解しています。各完全なアルゴリズムには多くの「ヘッドルーム」があります。これは、暗号技術者がさまざまな暗号アルゴリズムを分析する方法と非常によく似ています。検討中の実行可能なオプションは、「壊れていない」というベースライン基準に合格する必要がありますが、これは候補者のランク付けには役立ちません。代わりに、彼らは競合アルゴリズムの縮小バージョンを構築し、それを破る前にあなたがどれだけ削減しなければならないかを確認します。 Nラウンドの完全アルゴリズムがN-1で破られた場合、ヘッドルームはほとんどなく、暗号学者はおそらくそれを回避するでしょう。同様に、128ビットのBitGeneratorがPractRandを通過したが、その120ビットバージョンが失敗した場合、おそらくかなり危険です。

rkern 2019年05月28日

@mattipそれは合理的なようです。どこかで誰かが

import gc
state = [o for o in gc.get_objects() if 'Xoshiro256' in str(o)][0].state

bashtage 2019年05月28日

彼らがそれを深く掘り下げたいのなら、それは問題ありません。専門家以外のユーザーを支援したいだけです

mattip 2019年05月28日

わずかに書き直されたtest_pickleを、Python Thread全体で使用できるように渡します。

これは未解決の問題（＃9650）であることに注意してください。理想的には、 Generator()が子スレッドに再シードされます。 IIRCこれはPython> = 3.7でのみ実用的です

bashtage 2019年05月28日

「デフォルト」についての私の見解は、 Generator()が常に機能するように、実装の詳細として残すことができるというものです。常に再現可能な結果（ジェネレーターの変更まで）を取得する唯一の方法は、構文Generator(BitGenerator(kwarg1=1,kwargs2=b,...))を使用することであることに注意して、これを理解します。

区別する必要のある再現性には2種類あります。 1つは、同じシードを使用してプログラムを2回実行し、同じ結果が得られることです。それが私たちがサポートする必要があるものです。もう1つは、少なくとも厳密な意味で、私たちが否認したnumpyのバージョン間での再現性です。

引数のないGenerator() 、つまり「numpyが推奨する任意にシードされたPRNGを教えてください」は主な使用例ではありません。多くのサポートは必要ありません。「numpyが_this_seedで推奨するPRNGを教えてください」は、オプションについて説明しているものです。シードされたPRNGを取得する方法について、numpyが意見を表明する方法が必要です。その方法は、ユーザーにとって簡単で便利である必要があります（そうでない場合、ユーザーは使用しません）。私はアルゴリズムに名前を付けるのが好きですが（より便利な関数を使用しますが）、 @ rgommersはそれが一歩遠すぎると考えており、私はそれに同情しています。

rkern 2019年05月28日

引数のないGenerator（）、つまり「numpyが推奨する任意にシードされたPRNGを教えてください」は主なユースケースではありません。多くのサポートは必要ありません。「numpyがこのシードで推奨するPRNGを教えてください」は、オプションについて話し合っているものです。シードされたPRNGを取得する方法について、numpyが意見を表明する方法が必要です。その方法は、ユーザーにとって簡単で便利である必要があります（そうでない場合、ユーザーは使用しません）。私はアルゴリズムに名前を付けるのが好きですが（より便利な関数を使用しますが）、 @ rgommersはそれが一歩遠すぎると考えており、私はそれに同情しています。

私は、ユーザーが実際に良いシードを提供するための設備が整っていないと主張します。たとえば、メルセンヌツイスターをシードする正しい方法を知っているユーザーは何人いますか？思ったほど簡単ではありません。624個のランダムな32ビット整数（19937ビットの状態を提供するため）を供給していない場合は、間違っています。

したがって、実際には、ユーザーが再現可能な結果を得る正しい方法は、PRNGを作成し（シードを提供せずに、自動的に適切にシードされるようにする）、それをピクルスにすることです。

imneme 2019年05月28日

議論が正しい方法についてのみである場合、私は
Generator(BitGenerator(**kwargs))これはによってのみ使用されるため
複製を気にする半意識のユーザー。

Generator()使用されるデフォルト
考慮された選択と同じくらい多く解釈されるので、それを
シードされたフォームを使用する場合の推奨事項。

もう1つ捨てるだけで、クラスメソッドGenerator.seeded(seed[, bit_generator]) where bit generator is a string. This would allow the pattern of switching from one value to None to warn if the default was going to change, like lstsq. I would also only support a limited pallatte of but generators initially (i.e. 1). Doesn't make it easy to expose advanced features I suppose. In a perfect world it would use kwarg only to allow any keyword argument to be used which avoids most depreciation problems. Of course, this doesn't really need to be a class function, just seed`。

火、2019年5月28日には、午後4時38分ロバート・カーンの[email protected]は書きました：

「デフォルト」についての私の見解は、それを実装として残すことができるということです
詳細、Generator（）が常に機能するようにします。私はこれを
常に再現可能な結果を得る唯一の方法であることに注意してください。
（ジェネレーターの変更まで）構文を使用することです
Generator（BitGenerator（kwarg1 = 1、kwargs2 = b、...））
区別する必要のある再現性には2種類あります。 1つは
同じシードでプログラムを2回実行すると、同じ結果が得られます。
それが私たちがサポートする必要があるものです。もう1つは、全体の再現性です。
少なくとも厳密な意味で、私たちが否認したnumpyのバージョン。
引数のないGenerator（）、つまり「任意にシードされたPRNGを
numpyが推奨する」は主なユースケースではありません。それほど多くは必要ありません。
サポート。「numpyがこのシードで推奨するPRNGを教えてください」は、
そして、それが私たちがオプションについて議論しているものです。 numpyがする方法が必要です
シードされたPRNGを取得する方法について意見を表明し、その方法は
ユーザーにとって簡単で便利です（そうでなければ、ユーザーはそれを使用しません）。私は好きです
アルゴリズムに名前を付けます（より便利な関数を使用しますが）が、
@rgommers https://github.com/rgommersは、それは一歩遠すぎると考えており、
私はそれに同情しています。
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=ABKTSRKA4SSNW6XZEVFUMCDPXVGW5A5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2Z
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABKTSROCMLHG6E6BLWI6TWDPXVGW5ANCNFSM4HPX3CHA
。

火、2019年5月28日には、午後4時38分ロバート・カーンの[email protected]は書きました：

「デフォルト」についての私の見解は、それを実装として残すことができるということです
詳細、Generator（）が常に機能するようにします。私はこれを
常に再現可能な結果を得る唯一の方法であることに注意してください。
（ジェネレーターの変更まで）構文を使用することです
Generator（BitGenerator（kwarg1 = 1、kwargs2 = b、...））
区別する必要のある再現性には2種類あります。 1つは
同じシードでプログラムを2回実行すると、同じ結果が得られます。
それが私たちがサポートする必要があるものです。もう1つは、全体の再現性です。
少なくとも厳密な意味で、私たちが否認したnumpyのバージョン。
引数のないGenerator（）、つまり「任意にシードされたPRNGを
numpyが推奨する」は主なユースケースではありません。それほど多くは必要ありません。
サポート。「numpyがこのシードで推奨するPRNGを教えてください」は、
そして、それが私たちがオプションについて議論しているものです。 numpyがする方法が必要です
シードされたPRNGを取得する方法について意見を表明し、その方法は
ユーザーにとって簡単で便利です（そうでなければ、ユーザーはそれを使用しません）。私は好きです
アルゴリズムに名前を付けます（より便利な関数を使用しますが）が、
@rgommers https://github.com/rgommersは、それは一歩遠すぎると考えており、
私はそれに同情しています。
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=ABKTSRKA4SSNW6XZEVFUMCDPXVGW5A5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2Z
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABKTSROCMLHG6E6BLWI6TWDPXVGW5ANCNFSM4HPX3CHA
。

bashtage 2019年05月28日

使いやすさの観点から、私たちは本当にGenerator(seed)をサポートする必要があると思います。そうでなければ、彼らがする準備ができていない選択をすることに直面して、ユーザーはただRandomStateに固執するでしょう。

Generatorでデフォルトのビットジェネレーターをバージョン管理するには、 version=1代わりにbit_version=1使用できますが、 versionアイデアを削除しても問題ありません。ユーザーがビットジェネレータを明示的に設定する必要はあまりないと思います。

特定のジェネレーター機能を必要とする特定のユースケースを解決するための私の好みは、実装の詳細を隠す新しい汎用BitGeneratorAPIを設計することです。これらは、 DefaultBitGenerator追加するか、使用にトレードオフが含まれる場合は新しいクラスに入れることができます（例： ParallelBitGenerator 。

デフォルトのビットジェネレーターの変更によるRNGストリームの将来の変更に関する警告は絶対に避けたいと思います。これらの警告は、そのような詳細に依存しないが、乱数が自発的に変化するのを防ぐためだけにジェネレーターにseedを設定する大多数のユーザーにとっては単なるノイズです。

shoyer 2019年05月28日

ユーザーはRandomStateに固執するだけです。

それは問題ありません、彼らはアーリーアダプターではありません。 APIはいつでも拡大できますが、縮小するのははるかに難しいため、実行可能な最小限のAPIを強く求めています（多分難しすぎますか？）。 Generator(Philox()) 、 Generator(seed(3)) 、 Generator(bit_version=1)間のニュアンスは、これがエンドユーザーに伝わるまで少しわかりにくいです。

Generator(seed)ない最初のバージョンを入手して、フィードバックを受け取りましょう。

mattip 2019年05月28日

👍2

Generator(seed)ない最初のバージョンを入手して、フィードバックを受け取りましょう。

OK、ここでは深刻な異議はありません。その場合、今のところ完全なBitGeneratorを指定する必要があるかもしれません。

shoyer 2019年05月28日

したがって、実際には、ユーザーが再現可能な結果を得る正しい方法は、PRNGを作成し（シードを提供せずに、自動的に適切にシードされるようにする）、それをピクルスにすることです。

私は同じことを言いますが、私はそれでほとんど牽引力を得ません。あなたが言うように、「まあ、何かが悪い考えだからといって、人々がそれをやりたくないという意味ではありません！」

問題の一部は、MTの巨大な状態によって悪化します。これは、実際にはファイルへのシリアル化を必要とします。そのファイルベースのダンスを、ユーザーが使いたくなるような最も簡単なAPIにするのは難しいです。状態がはるかに小さいデフォルトのPRNGを使用すると、状況は改善されます。 128ビットはUUIDのサイズであり、16進数で印刷してコピーアンドペーストするのに十分小さいサイズです。したがって、適切なパターンは、デフォルトで適切なエントロピーシードになるようにプログラムを記述し、次にプログラムを実行するときにコピーして貼り付けることができるようにその状態を出力することです。

❯ python secret_prng.py
Seed: 0x977918d0c7da45e5168f72005586500c
...
Result = 0.7223650399276123

❯ python secret_prng.py
Seed: 0xe8962534e5fb585483b86119fcb852ce
...
Result = 0.10640984721018876

❯ python secret_prng.py --seed 0xe8962534e5fb585483b86119fcb852ce
Seed: 0xe8962534e5fb585483b86119fcb852ce
...
Result = 0.10640984721018876

rkern 2019年05月28日

このようなパターンが単純さと将来の証拠の両方を提供するかどうかはわかりません。

NumPy 1.next

class Generator:
    def __init__(bitgen_or_seed=None, *, bit_generator='pcg64', inc=0):

NumPy 1.20.x

`` `python
クラスジェネレータ：
def __init __（bitgen_or_seed = None、*、bit_generator = None、inc = None）：
bit_generatorがNoneでない場合、またはincがNoneでない場合：
warn（ 'デフォルトはPCG64からAESCtrに変更されています。incキーワード'
「議論は非推奨であり、将来的に提起されるでしょう」、FutureWarning）
「」

NumPy 1.22

`` `python
クラスジェネレータ：
def __init __（bitgen_or_seed = None、*、bit_generator = 'aesctr'、inc = None、counter = 0）：
bit_generator == 'pcg64'またはincがNoneでない場合：
例外を発生させます（ 'PCGはサポートされなくなり、incは削除されました'）
「」

bashtage 2019年05月28日

このようなパターンが単純さと将来の証拠の両方を提供するかどうかはわかりません。

上記のhttps://github.com/numpy/numpy/issues/13635#issuecomment-496589421で述べたように、これはほとんどのユーザーにとって驚くべきことであり、苛立たしいことだと思います。ユーザーがすべてのオプションの引数を設定していない場合に警告の発行を開始する計画よりも、明示的なBitGeneratorオブジェクトを提供する必要があります。 APIが予期しない方法で壊れていることがわかった場合、これは本当に最後の手段になるはずです。

shoyer 2019年05月28日

問題は移行期間です。デフォルトを使用しているすべての人が突然警告を受け取り、移行期間中に切り替えるための優れた方法がありません。あるいは、少なくとも、あなたはの「低エネルギー状態」からそれらを移動Generator(seed)の少ない便利な「高エネルギー状態」にGenerator(seed, bit_generator='aesctr') 。このAPIの目的は便利な「低エネルギー状態」を提供することであったため、この移行中に目的を達成できませんでした。ヒストグラム関数の1つであるIIRCを使用してこれを一度実行しましたが、これは悪夢でした。

これは、引数の意味をインプレースで変更しようとするすべての非推奨に共通です。ある機能から別の機能に移動するという非推奨は、管理がはるかに簡単であり、それが私が提唱していたことです。

rkern 2019年05月28日

Generator(seed)ない最初のバージョンを入手して、フィードバックを受け取りましょう。

「最初のバージョン」とは、完全なnumpyリリースを意味しますか？それとも、PRをマージするだけですか（それ以降に発生しました）？

完全なnumpyリリースの場合、含めるBitGeneratorの数など、まだ決定すべきことがいくつかあります。現在の完全な補数を含める場合は、いくつかのオプションを開示しています。

rkern 2019年05月28日

ある機能から別の機能に移動するという非推奨は、管理がはるかに簡単であり、それが私が提唱していたことです。

+1同意

いいえ、それは、人々が回避していたdefault_generator（seed）のような「指定された移動ターゲット」APIを持つ問題を軽減することです（たとえば、 @ shoyerのバージョン引数）。
ストリームの互換性を維持すること（NEP 19はこれを否認します）は、APIの破損の二次的なものです。異なるBitGeneratorは異なる効果的なAPIを持っています

ああ、今ではもっと理にかなっています。

奇妙な名前が問題である場合は、ポリシーが同じである限り、よりわかりやすい一般的な名前を使用できます（新しい関数を追加し、古い関数について警告を開始します）。私はそれと同等だと思います。これを頻繁に行うべきではありません。

これは、これまでのところ最善の解決策のように思えます。ここで正しい名前を選択できるはずです。そして、他の正気の名前の大きなスペースがあります-私たちがおそらく決して必要としないでしょう。

np.random.generatorやnp.random.default_generator 。

rgommers 2019年05月28日

含めるBitGeneratorの数

現在含まれているもの（MT19937、DSFMT、PCG32、PCG64、Philox、ThreeFry、Xoshiro256、Xoshiro512）から削除する必要があると思われるものを削除する提案で別の問題を開くことができますか？

ここではまだ問題を解決していません。どのBitGeneratorをデフォルトにする必要がありますか（現在はXoshiro256 ）

mattip 2019年05月28日

さて、この問題は、「どれを区別されたBitGeneratorとして宣伝する必要があるか」に関するものであり、デフォルトの選択に影響しますが、どの問題を含めるか削除する必要もあります。デフォルトを提供するメカニズム（デフォルトを提供する場合）はいくつかの制約を追加するため、これらはすべて、多かれ少なかれ一緒に決定する必要があるものです。それは大きな厄介な問題であり、このPRをシェパーディングするために行ったすべての作業の後、誰もコードを提供していない別のメガスレッドを見るのに疲れていると確信しているので、お見舞い申し上げます。 :-)

アルゴリズム自体に関する限り、私はすでに推奨事項を示しています。 RandomStateと比較のためにMT19937を保持する必要があり、推奨目的のためにPCG64好きです。

rkern 2019年05月28日

👍1

私はCompilerExplorerを少しいじりましたが、組み込み関数を使用して64ビットMSVC用のPCG64を実装し、コンパイラーにclangのuint128_t数学に近いアセンブリを生成させるようにしたと思います：https：// godbolt .org / z / ZnPd7Z

現在、Windows開発環境がセットアップされていないので、実際に_正しい_かどうかはわかりません... @ bashtageこれを試してみませんか？

rkern 2019年05月29日

🎉1

パッチなし：

Uniforms per second
************************************************************
PCG64            62.77 million

パッチ付き：

Uniforms per second
************************************************************
PCG64           154.50 million

bashtage 2019年05月29日

🎉1

パッチは、2つの異なるシードに対して1000uint64値の同じセットを生成することを含むテストに合格します。

bashtage 2019年05月29日

GCCネイティブおよび比較モードでの比較の場合：

Time to produce 1,000,000 Uniforms
************************************************************
Linux-64, GCC 7.4                      PCG64            4.18 ms
Linux-64, GCC 7.4, Forced Emulation    PCG64            5.19 ms
Win64                                  PCG64            6.63 ms
Win32                                  PCG64           45.55 ms

bashtage 2019年05月29日

うわー、それは本当に悪いようです。おそらく、比較ページの情報を拡張して、同じマシンでのmsvc2017-on-win {64、32}とgcc7.4-on-linux {64、32}のパフォーマンスを示す必要があります（msvc2017を使用していると仮定します。おそらくどこかにその情報を含める必要があります）。

mattip 2019年05月29日

Win32はここでは絶望的です。 Linux 32ビットもかなりひどいものになると思いますが、簡単にテストできる32ビットLinuxシステムがありません。

bashtage 2019年05月29日

32ビットマシン（企業のITポリシーのためにWindowsである可能性が高い）に固執している人々に推奨を行う場合は間違いなくわかります。このreccoは明らかです：32ビット用のDSFMT（またはMT19937も良いです）。ただし、ベンチマークは良いでしょう。

bashtage 2019年05月29日

それが価値があることについては、私は、複数の独立したランダムストリームの頻繁に繰り返されるPCGの主張にかなり懐疑的です。誰かが独立の主張を裏付けるために深刻な統計分析をしましたか？（実際、オニールの論文は「別個の」ストリームのみに言及しており、独立性を主張していないと思います。）

懐疑的であるのには十分な理由があると思います。特定のLCG乗数に対して、これらの個別のストリームはすべて、スケーリング[*]を介して単純に関連付けられます。したがって、同じ乗数を持つ2つのLCGストリームが与えられた場合、開始点は異なりますが、一方は単に他方の定数倍（モジュロ2**64または2**32 ）になります。 PCGの順列部分はこれを少し隠すのに役立ちますが、統計的に検出可能な相関関係があったとしても、実際には驚くことではありません。

確かに、別個のストリームですが、いくつかの深刻なテストがなければ、独立したストリームを額面どおりに主張することはできません。

[*]例： x[0], x[1], x[2], ...がx[i+1] := (m*x[i] + a) % 2**64標準64ビットLCGストリームであるとします。すべてのi y[i] := 3*x[i] % 2**64を設定します。その場合、 y[i]はy[i+1] := (m*y[i] + 3*a) % 2**64 LCGストリームであるため、元のストリームをスケーリングするだけで、同じ乗数で異なる加法定数を持つこれらの異なるLCGストリームの1つを生成できます。 3代わりに他の奇数乗数を使用し、全期間のLCGのみに関心があると仮定すると（したがって、 aは奇数です）、可能なすべての完全な-を取得します。その乗数を持つ期間LCG。

編集：共役類の数に関する誤った記述を修正しました。

mdickinson 2019年05月29日

PCGストリームの最も徹底的な公開分析はここにあると思います： http ：

@imneme最終的なアドバイスを拡張できますか？「DavidBlackmanとの通信は、一定のシードや1,2,3,4のストリームなど、相関のある初期化を使用して「近くの」ストリームを作成する方が思ったよりも簡単かもしれないことを示しています。で複数のストリームを使用する場合同時に、今のところ、ストリームIDとシードを区別し、相互に明確な相関関係を持たないようにすることをお勧めします。つまり、両方を1,2,3,4にしないでください。」

これは、単一の適切なシード（たとえば、エントロピーソースから派生）を取得してからID 1、2、3、4をストリームしても問題ないと考えることを意味しますか？または、シードIDとストリームIDの両方を、適切なエントロピーソースからランダムに選択する必要がありますか？

rkern 2019年05月29日

一部のLinux-32（Ubuntu 18.04 / GCC 7.4）番号

Time to produce 1,000,000 Uniforms
***************************************************************
Linux-64, GCC 7.4                      PCG64            4.18 ms
Linux-64, GCC 7.4, Forced Emulation    PCG64            5.19 ms
Win64                                  PCG64            6.63 ms
Win32                                  PCG64           45.55 ms
Linux-32, GCC 7.4                      PCG64           25.45 ms

したがって、Win-32の2倍の速度ですが、低速です。 4つのタイミングはすべて同じマシンで行われました

Other Linux-32/GCC 7.4 Timing Results
-----------------------------------------------------------------
DSFMT            6.99 ms
MT19937         13.09 ms
Xoshiro256      17.28 ms
numpy           15.89 ms

NumPyはNumPy1.16.4です。 DSFMTは、32ビット（x86）で優れたパフォーマンスを発揮する唯一のジェネレーターです。これは、32ビットユーザーに対して明確に文書化する必要があります。 MT19937は、32ビットユーザーにとっても比較的良い選択です。

bashtage 2019年05月29日

したがって、レガシー目的のためにMT19937が必要です。どのPRNGを含めるか（つまり、 MT19937と単一の汎用推奨）を最小限に抑えたい場合は、32ビットパフォーマンスを使用して単一の汎用推奨を制限する必要はありません。 3番目の「32ビットに推奨」PRNGを追加せざるを得ないと感じています。 MT19937は常に利用可能であり、現在の状態よりも悪くはありません。そして、サードパーティのパッケージは、よりニッチな用途に利用できるようになります。

もちろん、他の理由でより完全なPRNGのセットを含めたい場合は、ドキュメントにあらゆる種類の特定の推奨事項を含めることができます。

rkern 2019年05月29日

PCGの「P」部分が相関ストリームからの潜在的な問題をどの程度軽減したのか興味がありました。

したがって、これが（おそらく）LCGの最悪のケースです。一方のLCGストリームの加法定数は、もう一方の加法定数の正確な否定です。次に、適切にひどいシードの選択を行うと、LCGストリームの1つが他のストリームの正確な否定になることになります。

しかし、両方のストリームを使用して一連のfloatを生成している場合、PCGの順列部分とfloat64への変換の両方が少し役立つはずです。

これは、順列がどれだけ役立つかを示すプロットです。

streams

これは、そのような1つのストリームからの10000フロートの散布図であり、否定されたツインからの10000に対してです。ひどいわけではありませんが、素晴らしいものでもありません。明らかな遺物があります。

これから何を結論付けるかわからない：それは絶対に不自然な例であり、偶然に遭遇する可能性は低い（私は願っています）。一方、相関のない複数のストリームが本当に必要な場合は、ある程度の考慮と注意が必要であることを示しています。

記録のために、ここにソースがあります：

import matplotlib.pyplot as plt
import numpy as np

from pcgrandom import PCG64

gen1, gen2 = PCG64(), PCG64()
multiplier, increment, state = gen1._get_core_state()
new_increment, new_state = -increment % 2**128, -state % 2**128
gen2._set_core_state((multiplier, new_increment, new_state))

xs = np.array([gen1.random() for _ in range(10**4)])
ys = np.array([gen2.random() for _ in range(10**4)])
plt.scatter(xs, ys, s=0.1)
plt.show()

PCG64は、O'NeillがPCG-XSL-RR（PCGペーパーのセクション6.3.3）と呼ぶジェネレーターです。 pcgrandomパッケージはこちらから

mdickinson 2019年05月29日

独立したストリームを取得する標準的な方法は、jumpahead（）を使用することだと思いました。
「独立した」ストリームを取得するために再シードすることは、一般的に危険です。

カウンター/ハッシュジェネレーターには簡単なjumpahead（）があります。 PCGはありますか？

また、ユーザーからの嘆願：少なくとも1つのビットストリームを提供してください
無制限の状態空間を持つ暗号品質。

乾杯、
フィリップ

（sebergによる編集：電子メールの見積もりを削除）

pbstark 2019年05月29日

@pbstark ：これは再シードだけではありません。2つの基礎となるLCGジェネレーターは実際には異なります。異なる増分aとbの

しかし、LCGの単純さは、その加算定数を変更すると、元のジェネレーターで未知の量だけジャンプアヘッドになり、単純な線形変換（定数による乗算、または場合によっては定数の加算）と組み合わされることを意味します。

PCGを使用しない理由ではなく、NumPyの新しいメインPRNGには適していないことを私は今のところ主張していません。「独立した」ランダムストリームの約束に人々が巻き込まれてほしくないだけです。せいぜい、PCGの設定可能なストリームのアイデアは、クイックジャンプアヘッドに加えて、追加の乗法変換または加法変換のボーナスと同等のことを行うための便利な方法を提供します。

mdickinson 2019年05月29日

コミュニティコールで暗号化について少し話し合いました。少し慎重だったと思います。良いアイデアのように思えますが、暗号化された健全なRNGを含める場合、ユーザーが実際の暗号化の目的でそれらを使用するかどうかわからないため、発生するセキュリティの問題にも対応する必要があります。

含める数について：コンセンサスは、ビットジェネレーターをさらにいくつか配置することで問題がない傾向がありました（もちろん、いくつかの小さなドキュメントが適しています）。メンテナンスの負担はそれほど大きくないようです。結局、私の推測では、ケビンとロバートが提案するものは何でも一緒に行くでしょう。

名前について：私は個人的にRNG名を使用して、ユーザーにそれらを使用させることを気にしません。唯一の欠点は、コーディング中に名前を検索しなければならない可能性があることです。非推奨の警告はできるだけ少なくするようにしてください。シードなしのデフォルトRNGの最小限の公開APIが好きです。

seberg 2019年05月29日

@mdickinson 、私はあなたのグラフを自分で再現しようとしましたが失敗しました。私はこのプログラムで正規のC ++バージョンのコードを使用しまし

#include "pcg_random.hpp"
#include <iostream>
#include <random>

int main() {
    std::random_device rdev;
    pcg_detail::pcg128_t seed = 0;
    pcg_detail::pcg128_t stream = 0;
    for (int i = 0; i < 4; ++i) {
        seed   <<= 32;           
        seed   |= rdev();
        stream <<= 32;           
        stream |= rdev();
    }
    pcg64 rng1(seed,stream);
    pcg64 rng2(-seed,-stream);
    std::cerr << "RNG1: " << rng1 << "\n";
    std::cerr << "RNG2: " << rng2 << "\n";
    std::cout.precision(17);
    for (int i = 0; i < 10000; ++i) {
        std::cout << rng1()/18446744073709551616.0 << "\t";
        std::cout << rng2()/18446744073709551616.0 << "\n";
    }
}

これを実行すると、次のように出力されます（再現性を確保するため）。

RNG1: 47026247687942121848144207491837523525 203756742601991611962280963671468648533 41579532896305845786243518008404876432
RNG2: 47026247687942121848144207491837523525 136525624318946851501093643760299562925 52472962479578397910044896975270170620

次のグラフをプロットできるデータポイント：

corr1

私が違ったやり方で何をしているのか理解できれば、それは役に立ちます。

（相関が可能であるという考えに反論するためにこれを言っているのではなく、トピックについて別のコメントを書きますが、そのコメントを書いているときに、使用して結果を再現できないことに気づきました私のいつものツール。）

imneme 2019年05月29日

@mdickinsonは計算された状態でパンチし、内部に直接インクリメントし、2つのステップある通常の初期化ルーチンをバイパスします。

さまざまな方法で構築された複数のPCG32ストリームをインターリーブして、PractRandにフィードする簡単な小さなドライバースクリプトをmasterのnumpyを使用します。敵対的な内部状態/増分を直接パンチすると、PractRandはすぐに失敗します。敵対的な状態を達成するために、敵対的な_seeds_（実際には初期化ルーチンを通過する）を見つける合理的な方法を見つけることができるかどうかは私にはわかりません。

rkern 2019年05月29日

前述の私のブログ投稿で述べたように、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シーケンスで混合することです。）

imneme 2019年05月29日

私は専門家ではありませんが、暗号化の面では、次の場所では利用できない提案があります。
https://cryptography.io/en/latest/ Python Cryptographic Authorityから？

乱数生成に関する彼らのページにも言及されています：

Python 3.6以降、標準ライブラリには、暗号的に安全な乱数を生成するために使用できるシークレットモジュールと、テキストベースの形式用の特定のヘルパーが含まれています。

多分、世代に配列を追加していると思います。クリポグラフィックの堅牢性に関連する潜在的なメンテナンスの負担は、NumPyで本当に価値があり、適切であるかどうか疑問に思う必要があります。ナサニエルは以前に同様の懸念について言及したと思います。

実際、潜在的なdtypeリファクタリング/拡張機能のようなものも、多種多様な特殊な新しいアプリケーションを維持する負担を必ずしも負うことなく、APIインフラストラクチャを提供するように設計されているように思われます。

tylerjereddy 2019年05月30日

ところで、 VignaのPCG批評[特にこのセクション]への私の応答では説明しています。そこで観察したのは、PCGは距離関数を持っているので、実際に距離関数で確認して、不自然な種子を検出できるということです。距離関数のないPRNGでも、選択が不適切なシードペアを考案できますが（特に、シード用のパブリックAPIをバイパスしている場合）、最も露骨な工夫でさえ検出できるメカニズムは提供されていません。

一方では、お気に入りの（または最も嫌いな）PRNGを取得して、面白いことやひどいこと（たとえば、この病理学）を実行できるようにするためのシードを考案することが可能かどうかを考えるのは楽しいです...

しかし、全体像を見ると、実際にユーザーが直面している問題を見るのは理にかなっていると思います。ほとんどのユーザーは、_すべてのPRNG（過去および将来）_について、32ビットシードが絶対にひどい考えであり、どのPRNGが使用されていても、バイアスを簡単に検出できることを認識していません。確かに、私たちはそれを一掃し、代わりに誰かがメルセンヌツイスターをほぼゼロの状態（またはLFSRがまったく機能しないすべてゼロの状態！）に初期化できたかどうか、または誰かがそうするかもしれないかどうかを心配することに時間を費やすことができますXoshiroを11個の出力のスペースで同じ出力を7回繰り返すポイントの近くに初期化するか、2つの同様のPCGストリームを考案するなどですが、これらのすべての工夫は、ジェネレーターが発生した場合、基本的に微小（実際にはゼロ）の可能性がありますランダムデータがシードされています。これらの転換は知的に魅力的で学術的に興味深いものですが、ローマが燃えている間、ユーザーがシードに関して何をしているのかほとんどわからないという事実をほとんど無視しながら、それらについて考えます。

imneme 2019年05月30日

inc=1,2,3,4が悪い考えである場合、それは非常に明確に文書化する必要があることを示唆しているのではないでしょうか、それともわずかに異なるAPIを使用する必要があるのでしょうか。たぶんnew_generator = (Bit)Generator().independent()でさえ、（基礎となる）ビットジェネレーターがそれを達成するための優れた方法を提供しない場合は、警告を出すことができます。

また、32ビットシードの悪さにもよりますが。シードを作成して保存し、フリーズするための優れたAPIを考えられますか？私は知らない。たぶん、「凍結されたシードキャッシュファイルが存在しない場合は作成する」ことさえあります。

seberg 2019年05月30日

PCGの場合、シード-> uint64_t [2]-> splitmix64（seed_by_array）-> uint128を実行するだけで、低く連続したシードが確実に分散されます。

bashtage 2019年05月30日

PCGの場合、シード-> uint64_t [2]-> splitmix64（seed_by_array）-> uint128を実行するだけで、低く連続したシードが確実に分散されます。

または、適切な整数ハッシュを使用します。（それは全単射でなければなりません。）安くて短いものがたくさんあります。 Multiply–XorShiftを数回実行しても問題ありません。

imneme 2019年05月30日

@mdickinsonの指摘に不自然な/敵対的な設定の小さなセットに制限されていることを少し説得したいと思っています。その場合は、適切な方法で解決して、そのようなインスタンスを防ぐことができます。私たちが持っている現在のコードでは、ユーザーが現在のAPIで簡単に陥る可能性のあるいくつかの悪い状態があります。 seed=1とinc=0,1,2,...両方を設定すると、相関関係が作成されるというDavidBlackmanの発見を確認できます。インターリーブされたPCG32ストリーム用の最新のPractRandドライバーを使用して、これを実証できます。

❯ ./pcg_streams.py --seed 1 --inc 0 |time ./RNG_test stdin32
[
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 12728272447693586011,
            "inc": 1
        }
    },
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 7009800821677620407,
            "inc": 3
        }
    }
]
RNG_test using PractRand version 0.93
RNG = RNG_stdin32, seed = 0x470537d5
test set = normal, folding = standard (32 bit)

rng=RNG_stdin32, seed=0x470537d5
length= 128 megabytes (2^27 bytes), time= 4.0 seconds
  Test Name                         Raw       Processed     Evaluation
  BCFN(2+0,13-3,T)                  R=  +9.6  p =  2.3e-4   mildly suspicious
  ...and 116 test result(s) without anomalies

rng=RNG_stdin32, seed=0x470537d5
length= 256 megabytes (2^28 bytes), time= 8.7 seconds
  Test Name                         Raw       Processed     Evaluation
  BCFN(2+0,13-2,T)                  R= +26.1  p =  6.3e-13    FAIL           
  ...and 123 test result(s) without anomalies

./RNG_test stdin32  8.86s user 0.11s system 93% cpu 9.621 total

私はまだランダムシードで失敗に遭遇していませんが、同じ近い増分です。明日チェックインします。

コンストラクターで何も指定されていない場合、推奨されるデフォルトの増分を使用していないことに気付きました。おそらくそれを修正する必要があります。たぶんそれは、 2*inc + 1ではなく、指定されたストリームIDから実際の増分を導出するための適切なベース番号になります。

人々がデフォルトのエントロピーシードを使用してそれらを保存するのを支援するためのツールを構築することを試みることができます。私が持っている1つの質問は、複数のストリームの増分を簡単に生成できるのか、それともエントロピーサンプリングして保存する必要があるのかということです。シミュレーションの「初期状態」を、不透明なファイルではなく、同僚の電子メールからコピーして貼り付けることができる単一の数値としてエンコードできると非常に便利です。状態が128ビットまたは256ビットしかないこれらの小さなPRNGを使用すると、それを16進数でログファイルに簡単に出力し、複製したいときにコマンドラインにコピーアンドペーストするだけです。 32ビット整数よりも大きいですが、管理しやすいです。すべてのストリームIDもエントロピーサンプリングする必要がある場合は、それを忘れて、すべてを状態ファイルのどこかに記録する必要があります。これにより、新しいストリームを動的に生成する場合に説明したいくつかのユースケースが排除される可能性があります。カウンターをインクリメントして適切なストリームIDを取得できる場合（カウンターのハッシュなどから取得できる場合）、ストリームIDではなく、初期シードのみを記録する必要があります。

rkern 2019年05月30日

👍1

IIRC、シークレットモジュールはOSのエントロピーソースを呼び出します。
一部のシステムでは不良であり、複製/再現可能ではありません。

15:19タイラー・レディの水曜日、2019年5月29日には[email protected]
書きました：

私は専門家ではありませんが、暗号化の面では、提案されているのは
で利用できません：
https://cryptography.io/en/latest/ Python CryptographicAuthorityから
https://github.com/pyca ？
乱数生成に関する彼らのページ
https://cryptography.io/en/latest/random-numbers/も言及しています：
Python 3.6以降、標準ライブラリには秘密が含まれています
https://docs.python.org/3/library/secrets.htmlモジュール。
暗号的に安全な乱数を生成するために使用されます。
テキストベースのフォーマットのヘルパー。
多分、世代に配列を追加していると思います。私は疑問に思う必要があります
クリポグラフィックに関連する潜在的なメンテナンスの負担
堅牢性は本当に価値があり、NumPyと言うのに適切です
pycaと通信し、おそらくサードパーティについて考えます
そのためのジェネレータ/プラグイン。ナサニエルも同様の懸念について言及したと思います
以前。
確かに、潜在的なdtypeリファクタリングのようなもの/
拡張機能は、APIインフラストラクチャを提供するようにも設計されています。
必然的に多種多様なものを維持する負担を負う
特殊な新しいアプリケーション。
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWKXSSTX6QI7HJ65GYTPX36O3A5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AANFDWKGZMUB67VPCMFZYGTPX36O3ANCNFSM4HPX3CHA
。

pbstark 2019年05月30日

@tylerjereddyこれらは、攻撃者（およびあなた！）が予測できない物理エントロピーソースから少量のランダムビットを取得するためのものです。これらは、初期化ベクトル、ナンス、キーなど、すべて短い暗号化で使用されます。これらの要点は、それらを再現する方法がないということです。これは、 np.randomの数値シミュレーションの目的とは相容れません。このページでは、暗号的に安全なPRNGについては説明していません。これも存在し、 cryptographyパッケージで利用可能なプリミティブから構築できます。ただし、_practice_では、効率的なCコードですでに利用可能なアルゴリズムのより良い実装があります。少なくとも、シミュレーションの目的で定式化およびテストされたものです。 @bashtageは、このフレームワークに

また、 @ pbstarkが提案しているのは、暗号ベースのPRNGだけではないことをnumpyチームに明確にしたいと思います。むしろ、彼は_unbounded state_を備えたものを望んでいます。これは、彼が探している数学的特性を提供します。

一般的にシミュレーションするために考慮されている暗号ベースのPRNGの大半は、_not_は@pbstarkが望んでいることを無制限状態を持っています。これらは通常、有限カウンターの暗号化に基づいています。そのカウンターが回転すると、有限の期間に達します。技術的には、彼のcryptorandomは、固定サイズの256ビットダイジェスト状態と固定サイズの64ビット長カウンターにより、 2**(256+64)固有の初期条件にも制限されます。これはおそらく、長さカウンターを任意のサイズにすることで、真に無制限のPRNGを実装する方法を示していますが、そのようなアルゴリズムが公開またはテストされたのを見たことがありません。

一方、任意のサイズの状態を持つPRNGアルゴリズムが必要な場合は、最初に必要なものよりも上に固定されたものだけで、 PCGの拡張ジェネレーターがそのタスクに適しています。これらは明らかにCS-PRNGではありませんが、実際には、オンデマンドで巨大な状態空間を持ちたいという@pbstarkの要望を満たします。それでも、それらをnumpyに含めることはお勧めしません。

標準の有界CS-PRNGには他にも必要なプロパティがありますが、それらは簡単なデフォルトのIMOではありません。

rkern 2019年05月30日

Cryptorandomの状態空間は256ビットハッシュではありません。無制限です。ザ・
シード状態は任意の長さの文字列であり、更新のたびにゼロが追加されます
現在の状態に。無制限の整数カウンターをインクリメントすると、
同じことを成し遂げる。最初はそれを実装しましたが、
より効率的な更新が可能になるため、増分ではなく追加
各状態を最初からハッシュするよりもダイジェスト（顕著なスピードアップ）。

19:26ロバート・カーンの水曜日、2019年5月29日には[email protected]
書きました：

@tylerjereddyhttps ：//github.com/tylerjereddyこれらは取得するためのものです
物理エントロピーソースからの少量のランダムビット
攻撃者（そしてあなた！）には予測できません。それらは暗号化で使用されます
初期化ベクトル、ナンス、キーなど、すべて短いものです。ザ・
これらの要点は、それらを再現する方法がないということです。
np.randomの数値シミュレーションの目的とのオッズ。そのページは
再現性のある暗号的に安全なPRNGについては話していません。
存在し、プリミティブから構築できるものでもあります
暗号化パッケージで利用できます。しかし実際には、
ですでに利用可能なこれらのアルゴリズムのより良い実装
効率的なCコード、少なくとも定式化およびテストされたもの
シミュレーションの目的で。 @bashtagehttps ：//github.com/bashtageが実装されました
いくつかのhttps://github.com/numpy/numpy/issues/13635#issuecomment-496287650
このフレームワークのために。
また、@ pbstarkが何であるかをnumpyチームに明確にしたいと思います
https://github.com/pbstarkが提案しているのは、暗号ベースだけではありません
PRNG。むしろ、彼は無制限の状態を
彼が探している数学的特性。
シミュレーションで一般的に考慮されている暗号ベースのPRNGのほとんど
@pbstarkという無制限の状態はありません
https://github.com/pbstarkが望んでいます。それらは通常、
有限カウンターの暗号化。そのカウンターが転がると、あなたは
有限期間。技術的には、彼のクリプトランダム
https://statlab.github.io/cryptorandom/も2 **（256 + 64）に制限されてい
固定サイズの256ビットダイジェスト状態による固有の初期条件と
固定サイズの64ビット長カウンター。それはおそらくへの道を示しています
長さカウンターを作成することにより、真に無制限のPRNGを実装する
任意のサイズですが、そのようなアルゴリズムが公開されているのを見たことがありません。
テスト済み。
一方、次のようなPRNGアルゴリズムが必要な場合
任意のサイズの状態、最初に修正された状態
あなたが必要とするものの上に何か、そしてPCGの拡張ジェネレーター
http://www.pcg-random.org/party-tricks.htmlはそのためにうまくいくでしょう
仕事。これらは明らかにCS-PRNGではありませんが、実際には満足します
@pbstarkhttps ：//github.com/pbstarkの巨大な状態空間を持ちたいという願望
オンデマンド。それでも、それらをnumpyに含めることはお勧めしません。
標準の有界CS-PRNGが持つ他のプロパティがあります
必要な場合もありますが、これらは簡単なデフォルトではありません、IMO。
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWLGAF6YVIWXYZ2LTT3PX43ONA5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AANFDWLIJD3UCVY3NXCLPKDPX43ONANCNFSM4HPX3CHA
。

pbstark 2019年05月30日

それがSHA-256のオンラインアップデートの仕組みではないのではないかと思います。維持する状態は、更新を計算するときに追加する256ビットダイジェストと固定サイズの64ビット長カウンターのみです。全文を保持しているわけではありません。ハッシュは圧縮されます。これが、各バイトで効率的な更新を実行できる方法です。基本的に、有限である同じ内部SHA-256状態にマップする多くの初期化/過去の履歴があります。サイクルは確かに長く、おそらく2**(256+64)よりも長くなりますが、確かに存在します。いずれの場合も、可能な初期条件は2**(256+64)未満です（テキストの長さが0から2**64-1場合、最大で2**256内部ハッシュ状態を使用できます。テキストの長さが32バイトを超えているため、ピジョンホールで衝突が発生する必要があります）。データ構造にはこれ以上ビットがありません。

rkern 2019年05月30日

どうもありがとう; 理解した。私はそれを別の方法で表現します：状態
スペースには制限がありませんが、（鳩の穴によって）多くの異なる初期状態が必要です
区別できない出力シーケンスを生成します。

20:21ロバート・カーンの水曜日、2019年5月29日には[email protected]
書きました：

それがSHA-256のオンラインアップデートの仕組みではないのではないかと思います。状態
維持しているのは、256ビットダイジェストと固定サイズ64ビットのみです。
更新を計算するときに追加する長さカウンター。それは保持されません
全文。ハッシュは圧縮されます。それが効率的に行うことができる方法です
各バイトで更新します。基本的に、多くの初期化/過去があります
有限である同じ内部SHA-256状態にマップする履歴。
サイクルは確かに長く、おそらく2 （256 + 64）より長くなりますが
そして、いずれにせよ、あなたは2未満（256 + 64）
考えられる初期条件（テキストの長さ0〜2 64-1ごとに
持ちます。テキストの長さが32を超えたら
バイト、ラピジョンホールでの衝突が必要です）。何もありません
データ構造のより多くのビット。
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWO6HRJZHTVBF2TLK3LPX5B3TA5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AANFDWM56HCQRZXDO3BAQHDPX5B3TANCNFSM4HPX3CHA
。

pbstark 2019年05月30日

また、通過できる可能性のある状態が2**(256+64)しかない場合もあります。更新は毎回同じ形式で行われるため、最終的には以前に見た状態になり、（私には）未知の、しかし有限の期間のループに入ります。初期状態の数が有限であろうと期間が有限であろうと、 cryptorandomは両方があり、 MT19937よりも小さいと思います。

それ自体がcryptorandom問題だとは思いません。無制限の初期状態または無制限の期間を持つことが、実際に必要なものであると私は確信していません。

rkern 2019年05月30日

私はまだランダムシードで失敗に遭遇していませんが、同じ近い増分です。明日チェックインします。

512GiBで引き続き好調：

❯ ./pcg_streams.py -i 0 |time ./RNG_test stdin32
[
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 10843219355420032665,
            "inc": 1
        }
    },
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 5124747729404067061,
            "inc": 3
        }
    }
]
RNG_test using PractRand version 0.93
RNG = RNG_stdin32, seed = 0xb83f7253
test set = normal, folding = standard (32 bit)

rng=RNG_stdin32, seed=0xb83f7253
length= 128 megabytes (2^27 bytes), time= 4.0 seconds
  no anomalies in 117 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 256 megabytes (2^28 bytes), time= 8.6 seconds
  no anomalies in 124 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 512 megabytes (2^29 bytes), time= 16.9 seconds
  Test Name                         Raw       Processed     Evaluation
  BCFN(2+2,13-2,T)                  R=  -8.0  p =1-2.1e-4   mildly suspicious
  ...and 131 test result(s) without anomalies

rng=RNG_stdin32, seed=0xb83f7253
length= 1 gigabyte (2^30 bytes), time= 33.8 seconds
  no anomalies in 141 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 2 gigabytes (2^31 bytes), time= 65.7 seconds
  Test Name                         Raw       Processed     Evaluation
  BCFN(2+2,13-1,T)                  R=  -7.8  p =1-3.8e-4   unusual          
  ...and 147 test result(s) without anomalies

rng=RNG_stdin32, seed=0xb83f7253
length= 4 gigabytes (2^32 bytes), time= 136 seconds
  no anomalies in 156 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 8 gigabytes (2^33 bytes), time= 270 seconds
  no anomalies in 165 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 16 gigabytes (2^34 bytes), time= 516 seconds
  no anomalies in 172 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 32 gigabytes (2^35 bytes), time= 1000 seconds
  no anomalies in 180 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 64 gigabytes (2^36 bytes), time= 2036 seconds
  no anomalies in 189 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 128 gigabytes (2^37 bytes), time= 4064 seconds
  no anomalies in 196 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 256 gigabytes (2^38 bytes), time= 8561 seconds
  no anomalies in 204 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 512 gigabytes (2^39 bytes), time= 19249 seconds
  no anomalies in 213 test result(s)

rkern 2019年05月30日

ああ、シーケンシャルインクリメントで3つ以上のストリームを実行すると、すぐに失敗が発生します。ある種の全単射を使用してユーザー入力から実際の増分を導き出し、それを空間全体に広げることを検討する必要があります。

❯ ./pcg_streams.py -n 3  | time ./build/RNG_test stdin32
[
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 18394490676042343370,
            "inc": 2891336453
        }
    },
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 12676019050026377766,
            "inc": 2891336455
        }
    },
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 6957547424010412162,
            "inc": 2891336457
        }
    }
]
RNG_test using PractRand version 0.93
RNG = RNG_stdin32, seed = 0x4a9d21d1
test set = normal, folding = standard (32 bit)

rng=RNG_stdin32, seed=0x4a9d21d1
length= 128 megabytes (2^27 bytes), time= 3.2 seconds
  Test Name                         Raw       Processed     Evaluation
  DC6-9x1Bytes-1                    R= +19.4  p =  1.6e-11    FAIL           
  [Low8/32]DC6-9x1Bytes-1           R= +13.2  p =  4.6e-8    VERY SUSPICIOUS 
  ...and 115 test result(s) without anomalies

rkern 2019年05月30日

@imneme

私が違ったやり方で何をしているのか理解できれば、それは役に立ちます。

increment = 2 * stream + 1変換を可能にするには、コード内の行pcg64 rng2(-seed,-stream);をpcg64 rng2(-seed,-1-stream);に置き換える必要があると思います。増分の否定は、ストリームインデックスのビット単位の否定に対応します。その変更を加えてコードを実行すると、以前のプロットと非常によく似たものが表示されます。（そして、私がその変更をしなければ、すべてが視覚的に良く見えることを確認します。）

mdickinson 2019年05月30日

👍1

@imneme

ストリームを考える正しい方法は、シードする必要があるよりランダムな状態です。

同意しました。これにより、LCGの全体像が非常にきれいになると思います。適切に選択された乗数aが固定された64ビットLCGの場合、サイズ2^127状態空間があり、すべてのペア(x, c)整数のcは奇数の増分です。状態更新関数はnext : (x, c) ↦ (ax+c, c)であり、状態空間をそれぞれ長さ2^64互いに素なサイクル2^63に分割します。シードには、この状態空間で開始点を選択するだけです。

次に、分析を容易にし、異なるストリーム間の関係を明確にする明らかな群作用があります。 Z / 2^64Zの可逆1次元アフィン変換のグループは、正確に2^127順序であり、一時的に動作します。状態空間で（そして忠実に）：アフィン変換y ↦ ey + fは、ペア(x, c)を(ex + f, ec + (1-a)f)マップします。そのグループアクション通勤をnext変換ワンポイントことユニーク族元素ので関数、 (x, c)別に状態空間において、 (x2, c2) 、またによって生成されたシーケンスマッピング(x, c) (x2, c2)によって生成されたシーケンスに(x, c) (x2, c2) 。

tl; dr：固定乗数の場合、同じ乗数を持つ任意の2つのLCGシーケンス（先読みの場合のように同じ増分を使用するか、異なる増分を使用するかに関係なく）は、アフィン変換によって関連付けられます。避けたい不幸なケースでは、そのアフィン変換は、 2追加したり、 -1乗算したりするなど、非常に単純なものです。一般的なケースでは、アフィン変換が十分に複雑で、標準の統計的検定では2つのストリーム間の関係を検出できないことが望まれます。

mdickinson 2019年05月30日

👍1

@mdickinsonは状況をうまくカバーしています。 PCGの順列は、LCGの場合とは少し異なりますが、それほど多くはありません。 PCG順列の要点は、実行するスクランブルの量を選択できることです。切り捨てられた128ビットLCGはすでにBigCrushを通過しているため、 pcg64順列を選択したときに、そのサイズのLCG（XSL RR）に対して適度な量のスクランブルを選択しました。対照的に、64ビットLCGはいくつかの統計的検定にすぐに失敗するため、 pcg32はもう少しスクランブルを使用しますが、それでもPCGペーパーからの最強の順列ではありません。スレッドのプルリクエストスレッドで述べたように、 pcg32ユースケースでは、より強力なPCG順列（RXS M）に傾倒し始めました。これはまだデフォルトではありません。明示的にそのバージョンを要求する必要がありますが、PCGのメジャーバージョンバンプを実行するときにデフォルトを切り替える可能性があります。（RXSMはRXSM XSの上位半分であり、VignaはこのサイズとDavid Blackmanが好む順列で広範囲にテストしました）。

ニアストリームテストプログラムの更新バージョンがpcg32の両方のスキームを使用する場合の違いを視覚化できます（XSHRRとRCSM [および基になる生のLCGも]）。

#include "pcg_random.hpp"
#include <iostream>
#include <random>

// Create a "PCG" variant with a trivial output function, just truncation

template <typename xtype, typename itype>
struct truncate_only_mixin {
    static xtype output(itype internal)
    {
        constexpr size_t bits = sizeof(itype) * 8;
        return internal >> (bits/32);
    }
};

using lcg32 = pcg_detail::setseq_base<uint32_t, uint64_t, truncate_only_mixin>;

int main() {
    std::random_device rdev;
    uint64_t seed = 0;
    uint64_t stream = 0;
    for (int i = 0; i < 2; ++i) {
        seed   <<= 32;           
        seed   |= rdev();
        stream <<= 32;           
        stream |= rdev();
    }
    lcg32 rng1(seed,stream);
    lcg32 rng2(-seed,-1-stream);
    // pcg32 rng1(seed,stream);
    // pcg32 rng2(-seed,-1-stream);
    // pcg_engines::setseq_rxs_m_64_32 rng1(seed,stream);
    // pcg_engines::setseq_rxs_m_64_32 rng2(-seed,-1-stream);
    std::cerr << "RNG1: " << rng1 << "\n";
    std::cerr << "RNG2: " << rng2 << "\n";
    std::cout.precision(17);
    for (int i = 0; i < 10000; ++i) {
        std::cout << rng1()/4294967296.0 << "\t";
        std::cout << rng2()/4294967296.0 << "\n";
    }
}

始める前に、 @ mdickinsonが描いたグラフを見てみましょう。ただし、順列のないLCGの場合は、切り捨てだけです。

corr-truncated-lcg

これは、相関する状態を持つ病理学的LCG用であることに注意してください。代わりに、ランダムに選択された加法定数（ただし開始値は同じ）を持つ2つのLCGを選択した場合、次のようになります。

corr-truncated-lcg-good

PCGの出力関数に移ると、病理学的なケースでXSH RRを使用すると、次のようになります。上のグラフでは大幅に改善されていますが、恐ろしさを完全に覆い隠しているわけではありません。

corr-pcg32-current

これは、同じ基礎となる（相関が悪い）LCGペアを持つRXSMです。

corr-pcg32-future

しかし、これは私がpcg32ために検討しているものにすぎません。パフォーマンスの低下はごくわずかで、 pcg32は十分に小さいので、ヘビーユーザーが大量のランダムシードのpcg32ジェネレーターを作成し、それらから大量の数値を要求することを心配していることが想像できます。相関の可能性が非常に小さいわけではありません。率直に言って、私はそれについて2つの考えを持っています。なぜなら、この神話上のパワーユーザーはそもそもpcg32しているからです。

pcg64のストリームをより独立させることにあまり関心がない理由のひとつは、他のすべての状態を同じに保ち、ストリームをに切り替えることが賢明なユースケースが見当たらないことです。別のもの（たとえば、ランダムな値、ましてや近くの値）。ほとんどすべてのPRNGで、2番目のPRNGを作成する正しい方法は、新しいエントロピーで初期化することです。

結論として、NumPyの場合、PCG64が2つの256ビットの状態（ストリームの上位ビットが無視されるため、技術的には255）が必要であると考えて、それを完了と呼ぶのが最も理にかなっていると思います。これにより、APIに関連する問題も回避されます。これは、あるBitGeneratorでは機能が1つ少なくなり、別のBitGeneratorでは機能がなくなるためです。

（ただし、32ビットPCGバリアントをRXS Mバージョンに切り替えることをお勧めします。Cソースの場合、CコードでRXS Mを明示的に提供せず、C ++でのみ使用できるようにするため、最新バージョンが必要です。化身。）

[これがあなたが知りたいと思っていた以上のものである場合は申し訳ありません！まあ、申し訳ありません。 ;-)]

imneme 2019年05月30日

pcg64のストリームをより独立させることにあまり悩まされていない理由のひとつは、他のすべての状態を同じに保ち、ストリームを別のもの（たとえば、ランダムな値、ましてや近くの値）。ほとんどすべてのPRNGで、2番目のPRNGを作成する正しい方法は、新しいエントロピーで初期化することです。

ユースケースについては前に説明しました。単一の短い「シード」入力（つまり、電子メールからコマンドラインにコピーアンドペーストできるサイズ程度のもの）を受け入れ、プログラムの出力を決定論的にする確率的プログラムを作成するというUXの強力な理由があります。 @stevenjkernは、オフラインの会話で、彼のソフトウェアを検証する必要のある規制当局と協力するためには、そのようなやり取りが不可欠であると述べました。プログラムの実行のファイル_output_を使用して結果を複製する必要がある場合、そのような状況では少し疑わしいように見えます。規制当局は、ファイル内の情報が本当にコーシャであることを確認するために、コード（実際には利用できない可能性があります）を深く掘り下げる必要があります。

これで、Pythonに、N個の並列プロセスを動的にスピンアップして作業の一部を実行し、結果を収集してメインプロセスに進むための

Nストリームを再現可能に導出する必要性は十分に強いため、現在のMTアルゴリズムでそれを取得するために人々は奇妙なことをします。私はたくさんの危険な計画を撃墜しなければならなかった、そして私はPCGのストリームが私たちがそこに着くのを助けることを望んでいた。

2**63 / 2**127優れた全単射ハッシュを使用して、状態を同じに保ちながら、カウンターシーケンス0,1,2,3、...から増分を導出することについてどう思いますか？あなたはそれに関する問題を予見しますか？ハッシュされた増分とそれに続く大きなジャンプアヘッドを組み合わせて、状態を新しいサイクルの遠い部分に移動することについてどう思いますか？たぶん、このサブディスカッションを電子メールまたは別の問題に移動して、報告することができます。

rkern 2019年05月30日

@ rkern 、PRNGに非常に短いシードを与えることができることに

全員が同じPRNG（たとえば、メルセンヌツイスター）を使用し、同じ小さなセット（たとえば、10000未満の数）からシードを選択する場合、問題はさらに複雑になります。これは、プログラムごとの任意の特定のバイアスではなく、 _これを行うすべての人のために_バイアス。たとえば、4桁のシードを選択し、メルセンヌツイスターから妥当な数の数字（たとえば、100万未満）を取得するとします。そのような状況では、不運な数13は100億の出力のいずれかとして表示されることはなく（実際には32ビット整数の約10％が存在しない）、数123580738は次の係数で過大評価されていることを保証できます。 16.これは、100億個の32ビット整数のランダムサンプルに期待するものとまったく同じですが、_全員が同じサンプルを使用している場合_は実際の問題です。全員が9桁のシードを選択し、10000の数字しか描画しない場合、まったく同様の問題が発生します。

多くの人が何かをしたいという事実はそれを良い考えにしません。（それは、単に人々にそれを間違っている、または間違ったことを望んでいると言ってもいいという意味ではありません。彼らが実際に何を必要としているのかを理解する必要があります（たとえば、短いコマンドライン引数からの再現可能な結果-おそらく正しいことは、 UUIDと小さな整数からのシードを許可することです。シードデータを作成するためにこれらをうまくスクランブルする方法に関するいくつかのアイデアは、このブログ投稿にあり、 randutilsに組み込まれています。）

（かなり短いので、これが試してみるコードです...）

// mtbias.cpp -- warning, uses 4GB of RAM, runs for a few minutes
// note: this is *not* showing a problem with the Mersenne Twister per se, it is
// showing a problem with simplistic seeding

#include <vector>
#include <iostream>
#include <random>
#include <cstdint>

int main() {
    std::vector<uint8_t> counts(size_t(std::mt19937::max()) + 1);
    for (size_t seed=0; seed < 10000; ++seed) {
        std::mt19937 rng(seed);
        for (uint i = 0; i < 1000000; ++i) {
            ++counts[rng()];
        }
    }
    size_t shown = 0;
    std::cout << "Never occurring: ";
    for (size_t i = 0; i <= std::mt19937::max(); ++i) {
        if (counts[i] == 0) {
            std::cout << i << ", ";
            if (++shown >= 20) {
                std::cout << "...";
                break;
            }
        }
    }
    std::cout << "\nMost overrepresented: ";
    size_t highrep_count = 0;
    size_t highrep_n = 0;
    for (size_t i = 0; i <= std::mt19937::max(); ++i) {
        if (counts[i] > highrep_count) {
            highrep_n = i;
            highrep_count = counts[i];
        }
    }
    std::cout << highrep_n << " -- repeated " << highrep_count << " times\n";
}

imneme 2019年05月30日

前にも言ったように、128ビットシードはその目的には十分短いと思います。そして、人々が正しいことをするプログラムを書くのを助けるツールを構築することができます。つまり、デフォルトでエントロピーサンプリングを行い、印刷するかログに記録して、後で渡すことができるようにします。プログラムごとにUUIDを生成し、実行ごとにユーザーが提供するシードをさらに小さくすることをお勧めします。

PCG64の状態部分に、何らかの方法で適切な128ビットシードを使用してもらうことができると仮定しましょう。同じ州からストリームを派生させることについて何かコメントはありますか？全体として、単一のPCG64ストリームよりも多くの数値を描画することは考えていません。抽選ごとに調整することなく、さまざまなプロセスでこれらの数字を描くことができるようにしたいと思います。アドホックな63ビットのmultiply-xorshiftハッシュを使用すると、インターリーブされた8192ストリームに対して、これまでのところかなりうまく機能しているようです（現在、32 GiBです）。

rkern 2019年05月30日

@imneme

私たちが何を意味するのかを簡単に定義すると役立つかもしれません。

@rkernは、「電子メールからコマンドラインにコピー

lemire 2019年05月30日

抽選ごとに調整することなく、さまざまなプロセスでこれらの数字を描くことができるようにしたいと思います。アドホックな63ビットのmultiply-xorshiftハッシュを使用すると、インターリーブされた8192ストリームに対して、これまでのところかなりうまく機能しているようです（現在、32 GiBです）。

状態を十分な数（たとえば、 PCG64.jumped使用される2 ** 64）進めることにより、単一の品質シードを使用してnストリームをインターリーブしようとしましたか？これは、 PCG64(seed).jumped(node_id)ようなものを使用して、クラスター全体で大きなnストリームを大まかに調整する最も簡単な方法のようです。

ここで、 node_idは0,1,2、..です。

インデックスのようなものを使用して単純な独立したストリームを生成するのに本当に優れているPRNGはありますか？ MLFGができると信じていますが、63ビットジェネレーターだったので気に入らなかったです。

bashtage 2019年05月30日

@bashtage 、それは本当にそれをする正しい方法ではありません。正しい方法は、シードを取得することです。小さな整数を追加する場合は、ハッシュ関数を使用してハッシュします。前述のように、私は以前に（PCGとは関係なく）深刻なミキシング関数を作成しました[編集：リンクの修正正しい投稿に]大小さまざまな種類のエントロピーを混合します。あなたは私のものを使う必要はありませんが、私はあなたがそれらの線に沿って何かをすることをお勧めします。

理想的には、PCGに固有ではないメカニズムが必要です。 PCGはデフォルトの選択ではないかもしれません、そしてたとえそうであったとしても、あなたは人々にすべてのジェネレーターで同様のことをしてもらいたいです。ストリームまたはジャンプアヘッドに依存するいくつかの独立したPRNGを作成するためのスキームは必要ないと思います。

imneme 2019年05月30日

（おっと、間違ったブログ投稿にリンクしました。前のメッセージを編集しましたが、メールで読んでいる場合は、このブログ投稿にリンクするつもりでした）

imneme 2019年05月31日

@imneme現在、私たちが持っているすべてのジェネレーターはジャンプをサポートしています（そのうちのいくつかは実際にはアドバンスタイプの呼び出しです）。注意深くシードするのが良い考えであることは間違いありません。多くのユーザーがPRNG.jumped()呼び出しを使用したくなるのではないかと思います。これは思いとどまるべきものですか？

シードに関しては、MTジェネレーターはすべて作成者のinitルーチンを使用し、PCGはあなたのルーチンを使用し、残りは次のようになります。

seed = np.array(required_size, dtype=np.uint64)
last = 0
for i in range(len(user_seed))
    if i < len(user_seed)
        last = seed[i] = splitmix64(last ^ user_seed[i])
    else:
        last = seed[i] = splitmix64(last)

これは改善できると思います。

bashtage 2019年05月31日

これは思いとどまるべきものですか？

jumped見たことがありません

0x96704a6bb5d2c4fb3aa645df0540268d乗数Mがあるとします。 M ^（2 ^ 64）を計算すると、ひどいLCG乗数である0x6147671fb92252440000000000000001が得られます。したがって、128ビットLCGから2 ^ 64番目ごとのアイテムを取得した場合、それはひどいものになります（下位ビットは単なるカウンターです）。 PCGの標準順列関数は、カウンターをスクランブルするのではなく、LCGの通常の出力をスクランブルするように設計されています。

PCG64は現在、Practrandで最大0.5ペタバイトまでテストされており、さらに分析すると、2の累乗に関連する問題なしに多くのペタバイトを読み取ることができることが示されています。残念ながら、先に進んで2の巨大な正確な累乗をスキップすると、PCGの通常の（やや控えめな）順列では、このような基礎となるLCGの巨大な距離をスキップすることによる病理学的シーケンスを十分に補償できません。これを修正するために順列強度を上げることができます。実際、IとVignaはどちらも、PCGの標準順列を既成の整数ハッシュ関数と個別に比較しました（結局のところ、これらはSplitMixの基盤であり_is_ただのカウンター）。 2014年にFastHashで調べたところ、速度はそれほど速くはありませんでしたが、最近Vignaがmurmurhashで調べたとき、パフォーマンスは標準のPCGを上回っていると主張しました（！）。

本当に2 ^ 64のジャンプアヘッドが必要な場合は、より強力な出力関数の順列に切り替える必要があると思います（これまで見てきたように、低コストで実行できる可能性があります）。しかし、それがもはや実際には「標準」のPCGではないと感じ、通常の出力順列を維持したい場合jumped() 、おそらく

imneme 2019年05月31日

（ところで、病理学的ジャンプアヘッドは他のPRNGにも適用されます。SplitMixにはいくつかの悪い増分があることが知られており、0xbd24b73a95fb84d9の通常の増分（別名「ガンマ」）は問題ありませんが、2 ^進んでいると考えるのが妥当です。 32は0x95fb84d900000000の増分を与えますが、これはあまり良くありません。LFSRの場合、悪いジャンプアヘッドはおそらく2の累乗ではありませんが、基礎となる行列が病理学的に終わるジャンプがあると確信しています。まばらです。）

imneme 2019年05月31日

少なくともPCG32では、 .jumped()を使用した4つのインターリーブストリームが非常に迅速に失敗することを確認できます。

❯ ./pcg_streams.py --jumped -n 4 | time ./RNG_test stdin32
[
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 10149010587776656704,
            "inc": 2891336453
        }
    },
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 1158608670957446464,
            "inc": 2891336453
        }
    },
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 10614950827847787840,
            "inc": 2891336453
        }
    },
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 1624548911028577600,
            "inc": 2891336453
        }
    }
]
RNG_test using PractRand version 0.93
RNG = RNG_stdin32, seed = 0xeedd49a8
test set = normal, folding = standard (32 bit)

rng=RNG_stdin32, seed=0xeedd49a8
length= 128 megabytes (2^27 bytes), time= 2.1 seconds
  Test Name                         Raw       Processed     Evaluation
  BCFN(2+0,13-3,T)                  R= +58.7  p =  1.3e-27    FAIL !!!       
  BCFN(2+1,13-3,T)                  R= +48.0  p =  1.5e-22    FAIL !!        
  BCFN(2+2,13-3,T)                  R= +16.0  p =  2.3e-7   very suspicious  
  DC6-9x1Bytes-1                    R= +53.5  p =  1.8e-32    FAIL !!!       
  [Low8/32]DC6-9x1Bytes-1           R= +27.4  p =  1.1e-17    FAIL !         
  ...and 112 test result(s) without anomalies

rkern 2019年05月31日

理想的には、PCGに固有ではないメカニズムが必要です。 PCGはデフォルトの選択ではないかもしれません、そしてたとえそうであったとしても、あなたは人々にすべてのジェネレーターで同様のことをしてもらいたいです。

さて、それが私たちがここで決定しようとしていることです。 :-)各アルゴリズムによって公開されたプロパティが十分に研究されていることを前提として、各PRNGが提供する機能を公開するだけでかなり満足しました。また、「これが推奨されるデフォルトのPRNGです。便利な機能がたくさんありますが、他の人にはないかもしれません」と言ってもかなり満足しています。

どのアルゴリズムでも、ハッシュを使用して特定の状態とストリームIDから新しい状態を導出するという概念は興味深いものです。それがどれほどよく研究されているか知っていますか？それがすべてのアルゴリズムでうまく機能することを確認することは、研究上の問題のように聞こえます。「すべてのPRNGの独立したストリームを導出するための一般的な手順は次のとおりです」と主張することを躊躇します。「独立したストリームを導出するための一般的なAPIがあります。各PRNGは、アルゴリズムに適した方法で実装し、アルゴリズムが適切にサポートしていない場合は実装しない可能性があります」に満足しています。

一方、PractRandのN GiBに送信される各BitGeneratorインターリーブストリームをテストするのに十分なCPUサイクルを割り当てるだけの場合は、それほど面倒ではありません。

rkern 2019年05月31日

どのアルゴリズムでも、ハッシュを使用して特定の状態とストリームIDから新しい状態を導出するという概念は興味深いものです。それがどれほどよく研究されているか知っていますか？それがすべてのアルゴリズムでうまく機能することを確認することは、研究上の問題のように聞こえます。「すべてのPRNGの独立したストリームを導出するための一般的な手順は次のとおりです」と主張することを躊躇します。「独立したストリームを導出するための一般的なAPIがあります。各PRNGは、アルゴリズムに適した方法で実装し、アルゴリズムが適切にサポートしていない場合は実装しない可能性があります」に満足しています。

それを「リサーチクエスチョン」（したがって「十分に研究された」）と正確に呼ぶことができるかどうかはわかりませんが、C ++ 11（主に試行錯誤された真の老舗技術の使用に関するもの）は_SeedSequence_コンセプト（および特定のstd::seed_seq実装）。その仕事は、完全に任意のPRNGにシードデータを提供することです。

一般に、ほとんどすべてのPRNGは、ランダムビットで初期化/シードされることを期待しています。（たとえば） random.orgから出てくるランダムビットと、よりアルゴリズム的なもの（CS PRNG、ハッシュ関数など）から出てくるランダムビットについては、特に魔法のようなものはありません。

同じスキームからのPRNGのコレクションについて、すべて独自のランダムビットがシードされていると考えるのはかなり簡単です。私たちが行っていることは、線（たとえば、 2 ^ 255ポイントの線）。 _n_間隔を要求した場合に、ある間隔が別の間隔と重なる確率を計算できます。それはかなり基本的な確率です—（私が理解しているように）初等数学を含む論文に誰も興奮していないので、それについて論文を発表できるかどうかはわかりません。（ @lemireは同意しないかもしれません！）

[私は、あなたが一般的にすべきではないことは、ランダムなビットがそれ自体から出てくるPRNGをシードすることであると主張します。それは私にはあまりにも近親相姦だと感じます。]

imneme 2019年05月31日

確かに、適切に設計された_SeedSequence_のようなものを使用すると、任意の初期シードを取得し、アルゴリズムのサイクルで重複してはならない複数の開始点を描画する方法になることは明らかです。そして、それが独立したストリームを取得する唯一の現実的な方法である場合は、そうです。それを便利にするのはAPI設計の問題です。

私があまりはっきりしていないのは、初期化されたPRNGの現在の状態を取得し、ストリームIDでハッシュミックスして、サイクル内の新しい状態にジャンプすることがどれほど安全かということです。これは、あなたが提案していると思っていたものです（後で私はそれについて間違っていたかもしれないと思いました）。 jumped()の失敗が示すように、サイクル内で十分に分離されていることだけが要因ではありません。 jumped()は、重複しないシーケンスの遠い部分に送信されることも保証します。ジャンプが適切に選択されていない場合、最初の部分と非常に強く相関する可能性がある部分にすぎません。良いジャンプとは何かを知るには、各アルゴリズムの内部に関する知識が必要になる場合があります。 PCGの場合は明らかにしませんでした。

基本的に、PRNGを遷移関数および出力関数と考えると、このnew_state = seed_seq(old_state||streamID)は、1つのステップでドロップするもう1つの遷移関数にすぎません。そのseed_seq関連する操作が、各PRNGアルゴリズム（またはその逆関数）の遷移関数と十分に異なることを確認する必要があり、おそらく他のことを確認する必要があります。私は、言う、から構築されたものを使用したいとは思わないでしょうwyhash初期化するためにwyrand 。あなたが言うように、あなたはそれ自身のためにビットを提供するためにPRNG自体を使用したくありません。そのため、すべてのPRNGについてそれを保証するためにいくつかの調査が必要だと思います（自分で行う必要がないことを望んでいた調査）。

一方、 new_state = seed_seq(old_state||streamID)は、この点で、複数のストリームに対する_SeedSequence_の使用目的よりも悪くない可能性があります。2つの状態を順番に引き出します。もしそうなら、私はC ++の経験に頼って、おそらくあなたの実装で、そして私たちのすべてのアルゴリズムについてPractRandでいくつかの経験的テストを行って、それらがシングルストリームの対応物より悪くないことを示しても大丈夫でしょう。

ハッシュジャンプを機能させると、PRNGを調整なしで生成するためのいくつかのユースケースが開かれるため、非常に便利です。ストリームIDを使用するには、通信または事前割り当てが必要です。 daskは過去にこのようなものを求めてきました。

正しいことを行うのに便利な、適切なシードのみに依存する適切な代替手段がある場合は、デフォルトの選択基準として設定可能なストリームを削除する必要があります。十分に大きな状態空間を持つデフォルトのアルゴリズムが必要です。

とはいえ、 63ビットのハッシュを使用してシーケンシャルストリームID（ range(N) ）からPCG32増分を導出することは機能しているように見えます。 8192のインターリーブされたストリームは、PractRandを2TiBに渡します。 PCGジェネレーターのストリームIDを公開する場合は、他の手段を使用して独立したストリームを再現可能に取得することを提案したとしても、この手法を使用して増分を導出することをお勧めします。

rkern 2019年05月31日

私があまりはっきりしていないのは、初期化されたPRNGの現在の状態を取得し、ストリームIDでハッシュミックスして、サイクル内の新しい状態にジャンプすることがどれほど安全かということです。これは、あなたが提案していると思っていたものです（後で私はそれについて間違っていたかもしれないと思いました）。

私はおそらく曖昧に自分自身を表現しましたが、いいえ、PRNGの現在の状態を自己再シードに使用することを提案するつもりはありませんでした。

しかし、FWIW、SplitMixはこれを行います。これは、 split()操作が行うことです。そして、私はそれがそれをするのが好きではありません。

これは情報が多すぎるかもしれませんが、SplitMixのsplit()関数によって私が恐怖を感じた（おそらく私が本来よりも恐怖を感じた）理由について少しお話しします。歴史的なメモとして、SplitMixとPCGはほぼ同時に独立して設計されました（SplitMixは2014年10月20日に公開されましたが、 pcg-random.orgは2014年8月に公開され、2014年9月5日にPCGペーパーにリンクされました）。 PCGとSplitMix（およびVignaのxor shift *やxorshift +を含む他のさまざまなPRNG— 2014年に世界にリリースされたもの）の間にはいくつかの類似点があります。すべてに、スクランブリング出力関数によって修正された、かなり単純な、十分ではない状態遷移関数があります。私がPCGの論文を書いているとき、一部の人々が望んでいることを知っていたのはsplit()関数でしたが、それを行うための良い方法を見つけることができませんでした。代わりに、各ステップで左または右に移動できる_k_ビットPRNGがある場合、_k_ステップ内で、以前の状態に到達できる必要があるという簡単な証明を作成しました。これにより、コンセプト全体が証明されます。思いがけなかった。その観察はそれを論文に入れませんでした。しかし、その証明の前に私の考えを熟考した結果、論文の最終ドラフトに近い脚注で、PCGの出力はその状態のハッシュ/スクランブル/順列であったため、少し気まぐれに提案しました。いたずらを感じたら、ジェネレーターを独自の出力で再シードして、それを回避することができます。 PRNGを独自の状態で再シードすることは、PRNGの誤用の一種であると広く考えられていたため、このような気まぐれはレビュー担当者にとって赤旗には大きすぎると考えたため、最終バージョンから削除しました。それらを使用した経験のない人々から私たちが見るものの。

SplitMixの論文を読んで、好きなものがたくさん見つかりましたが、 split()を見て、とてもびっくりしました。それは私が基本的に冗談だと思っていた何かをして、それをビッグイベントにしました。数年後、私はあなたがこの種の操作をしているときに何が起こるかについてより技術的な深さで書くことに取り掛かりました。

全体的なポイントは、状態空間が十分に大きい場合（そして、SplitMixはほとんど十分ではない場合）、ハッシュ関数を介した自己再シードで回避できる可能性があるということです。これは良い考えではないと今でも感じています。ランダムマッピング（この状況で扱っているもの）には、「漸近確率がゼロではないため、関数グラフの最も高いツリーが最も長いサイクルに根ざしていない」などのプロパティがあるため、完全な信頼を得るのは難しいと思います。設計者がそのような病状が設計に存在しないことを示すために必要な作業に行っていない限り。

楽しみのために、SplitMixの小さなバージョンの状態空間のダンプを次に示します。 next()とsplit()を組み合わせる3つの異なる（そして厳密に固定された）方法を探っています。

Testing: SplitMix16: void advance() { rng = rng.split();}

Finding cycles...
- state 00000000 -> new cycle 1, size 4, at 000043b0 after 516 steps
- state 00000050 -> new cycle 2, size 41, at 00002103 after 2 steps
- state 000000cd -> new cycle 3, size 4, at 0000681a after 6 steps
- state 00000141 -> new cycle 4, size 23, at 00004001 after 11 steps
- state 00000dee -> new cycle 5, size 7, at 00007436 after 4 steps
- state 00008000 -> new cycle 6, size 90278, at 5e5ce38c after 46472 steps
- state 00030000 -> new cycle 7, size 6572, at 12c65374 after 10187 steps
- state 00030016 -> new cycle 8, size 3286, at 65d0fc0c after 402 steps
- state 00058000 -> new cycle 9, size 17097, at 2a2951fb after 31983 steps
- state 08040000 -> new cycle 10, size 36, at 08040000 after 0 steps
- state 08040001 -> new cycle 11, size 218, at 08040740 after 360 steps
- state 08040004 -> new cycle 12, size 10, at 38c01b3d after 107 steps
- state 08040006 -> new cycle 13, size 62, at 38c013a0 after 39 steps
- state 08040009 -> new cycle 14, size 124, at 08045259 after 24 steps
- state 08040019 -> new cycle 15, size 32, at 38c06c63 after 151 steps
- state 08040059 -> new cycle 16, size 34, at 38c00217 after 17 steps
- state 08040243 -> new cycle 17, size 16, at 38c06e36 after 13 steps
- state 123c8000 -> new cycle 18, size 684, at 77d9595f after 194 steps
- state 123c8002 -> new cycle 19, size 336, at 5de8164d after 141 steps
- state 123c9535 -> new cycle 20, size 12, at 123c9535 after 0 steps
- state 139f0000 -> new cycle 21, size 545, at 743e3a31 after 474 steps
- state 139f0b35 -> new cycle 22, size 5, at 139f0b35 after 0 steps
- state 139f1b35 -> new cycle 23, size 5, at 68d3c943 after 8 steps

Cycle Summary:
- Cycle 1, Period 4, Feeders 32095
- Cycle 2, Period 41, Feeders 188
- Cycle 3, Period 4, Feeders 214
- Cycle 4, Period 23, Feeders 180
- Cycle 5, Period 7, Feeders 12
- Cycle 6, Period 90278, Feeders 1479024474
- Cycle 7, Period 6572, Feeders 102385385
- Cycle 8, Period 3286, Feeders 5280405
- Cycle 9, Period 17097, Feeders 560217399
- Cycle 10, Period 36, Feeders 413
- Cycle 11, Period 218, Feeders 51390
- Cycle 12, Period 10, Feeders 1080
- Cycle 13, Period 62, Feeders 4113
- Cycle 14, Period 124, Feeders 4809
- Cycle 15, Period 32, Feeders 2567
- Cycle 16, Period 34, Feeders 545
- Cycle 17, Period 16, Feeders 87
- Cycle 18, Period 684, Feeders 95306
- Cycle 19, Period 336, Feeders 100263
- Cycle 20, Period 12, Feeders 7
- Cycle 21, Period 545, Feeders 163239
- Cycle 22, Period 5, Feeders 12
- Cycle 23, Period 5, Feeders 34

- Histogram of indegrees of all 2147483648 nodes:
      0  529334272
      1 1089077248
      2  528875520
      3     131072
      4      65536

Testing: SplitMix16: void advance() { rng.next(); rng = rng.split();}

Finding cycles...
- state 00000000 -> new cycle 1, size 36174, at 6b34fe8b after 21045 steps
- state 00000002 -> new cycle 2, size 4300, at 042a7c6b after 51287 steps
- state 0000000f -> new cycle 3, size 11050, at 0b471eb5 after 4832 steps
- state 0000001d -> new cycle 4, size 38804, at 2879c05c after 16280 steps
- state 00000020 -> new cycle 5, size 4606, at 46e0bdf6 after 7379 steps
- state 00046307 -> new cycle 6, size 137, at 0a180f87 after 89 steps
- state 00081c25 -> new cycle 7, size 16, at 177ed4d8 after 27 steps
- state 0044c604 -> new cycle 8, size 140, at 5e1f125b after 44 steps
- state 006e329f -> new cycle 9, size 18, at 006e329f after 0 steps
- state 13ebcefc -> new cycle 10, size 10, at 13ebcefc after 0 steps

Cycle Summary:
- Cycle 1, Period 36174, Feeders 975695553
- Cycle 2, Period 4300, Feeders 766130785
- Cycle 3, Period 11050, Feeders 110698235
- Cycle 4, Period 38804, Feeders 251133911
- Cycle 5, Period 4606, Feeders 43723200
- Cycle 6, Period 137, Feeders 4101
- Cycle 7, Period 16, Feeders 172
- Cycle 8, Period 140, Feeders 2310
- Cycle 9, Period 18, Feeders 124
- Cycle 10, Period 10, Feeders 2

- Histogram of indegrees of all 2147483648 nodes:
      0  529334272
      1 1089077248
      2  528875520
      3     131072
      4      65536

Testing: SplitMix16: void advance() { rng.next(); rng = rng.split(); rng = rng.split();}

Finding cycles...
- state 00000000 -> new cycle 1, size 40959, at 0069b555 after 49520 steps
- state 00000031 -> new cycle 2, size 1436, at 5f619520 after 2229 steps
- state 000003a4 -> new cycle 3, size 878, at 18d1cb99 after 1620 steps
- state 0000046c -> new cycle 4, size 2596, at 46ba79c0 after 1591 steps
- state 0000c6e2 -> new cycle 5, size 24, at 0212f11b after 179 steps
- state 000af7c9 -> new cycle 6, size 61, at 40684560 after 14 steps
- state 00154c16 -> new cycle 7, size 110, at 29e067ce after 12 steps
- state 0986e055 -> new cycle 8, size 4, at 2b701c82 after 7 steps
- state 09e73c93 -> new cycle 9, size 3, at 352aab83 after 1 steps
- state 19dda2c0 -> new cycle 10, size 1, at 78825f1b after 2 steps

Cycle Summary:
- Cycle 1, Period 40959, Feeders 2129209855
- Cycle 2, Period 1436, Feeders 5125630
- Cycle 3, Period 878, Feeders 7077139
- Cycle 4, Period 2596, Feeders 5997555
- Cycle 5, Period 24, Feeders 24221
- Cycle 6, Period 61, Feeders 1774
- Cycle 7, Period 110, Feeders 1372
- Cycle 8, Period 4, Feeders 23
- Cycle 9, Period 3, Feeders 4
- Cycle 10, Period 1, Feeders 3

- Histogram of indegrees of all 2147483648 nodes:
      0  829903716
      1  684575196
      2  468475086
      3  132259769
      4   32192209
      5      58402
      6      17026
      7       1982
      8        261
      9          1

Testing: SplitMix16: void advance() { rng.next(); rng.next(); rng = rng.split();}

Finding cycles...
- state 00000000 -> new cycle 1, size 55038, at 3e57af06 after 30005 steps
- state 00000005 -> new cycle 2, size 376, at 4979e8b5 after 6135 steps
- state 0000001e -> new cycle 3, size 10261, at 0cd55c94 after 1837 steps
- state 0000002d -> new cycle 4, size 3778, at 7f5f6afe after 3781 steps
- state 00000064 -> new cycle 5, size 2596, at 3bc5404b after 5124 steps
- state 0000012b -> new cycle 6, size 4210, at 525cc9f3 after 397 steps
- state 00000277 -> new cycle 7, size 1580, at 410010c8 after 1113 steps
- state 00001394 -> new cycle 8, size 916, at 7b20dfb0 after 193 steps
- state 00063c2d -> new cycle 9, size 51, at 6e92350b after 121 steps
- state 058426a6 -> new cycle 10, size 8, at 058426a6 after 0 steps
- state 0e5d412d -> new cycle 11, size 1, at 0e5d412d after 0 steps
- state 4c2556c2 -> new cycle 12, size 1, at 4c2556c2 after 0 steps

Cycle Summary:
- Cycle 1, Period 55038, Feeders 2027042770
- Cycle 2, Period 376, Feeders 28715945
- Cycle 3, Period 10261, Feeders 49621538
- Cycle 4, Period 3778, Feeders 13709744
- Cycle 5, Period 2596, Feeders 15367156
- Cycle 6, Period 4210, Feeders 10418779
- Cycle 7, Period 1580, Feeders 1782252
- Cycle 8, Period 916, Feeders 744273
- Cycle 9, Period 51, Feeders 2351
- Cycle 10, Period 8, Feeders 24
- Cycle 11, Period 1, Feeders 0
- Cycle 12, Period 1, Feeders 0

- Histogram of indegrees of all 2147483648 nodes:
      0  529334272
      1 1089077248
      2  528875520
      3     131072
      4      65536

等

imneme 2019年06月01日

ああ、すごい。私は数年前に自分でそれらの線に沿っていくつかの提案を打ち落としたので、私たちは何か良いものを逃したのではないかと心配しました。 :-)

PCGストリームの増分を導出するためのハッシュアプローチに関する最終的な考えはありますか？それが独立したストリームを取得するための主なメカニズムであるかどうかはさておき。その機能へのアクセスを完全に削除することを除けば、それは、誤用されやすいシーケンシャルストリームIDを防ぐために私たちがやりたいことのように思えます。

rkern 2019年06月01日

好奇心から、PCG64で2つの状態がどれだけ離れているかを知る（簡単な）方法はありますか？

charris 2019年06月01日

はい、公開していませんが： http ：

rkern 2019年06月01日

好奇心から、PCG64で2つの状態がどれだけ離れているかを知る（簡単な）方法はありますか？

はい、公開していませんが： http ：

C ++ソースでは、distance関数はストリーム間の距離も示し、最も近いアプローチのポイントを示します（ストリーム間の唯一の違いは追加された定数です）。

imneme 2019年06月01日

ちなみに、基礎となるLCGの場合、距離を使用して、位置との相関関係を計算できます。短い距離は明らかに悪いです（そしてPRNGにはまったく悪いです）が、1ビットを設定しただけの距離も良くありません。そのため2 ^ 64（ 0x10000000000000000 ）にジャンプします。 .jumpedは悪い考えです。私のPCGのやることリストには、2つの状態間の距離を調べ、距離がどれほどランダムに見えるかを示す「 independence_score 」関数を記述しています（ハミング重みなどを使用します。理想的には、約半分が必要です。ビットは0と半分になり、それらは自由に分散されます）。

PCG64でjumpedを_keep_する1つの方法は、 n * 0x10000000000000000ジャンプするのでn * 0x9e3779b97f4a7c150000000000000000なく、 .jumped(3).jumped(5) == .jumped(8) ）が得られます。

（「 0x10000000000000000進んではいけない」というのは「まあ、そのように反応しないでください」ということも承知してindependence_scoreが存在する可能性があるのは

imneme 2019年06月01日

PCGストリームの増分を導出するためのハッシュアプローチに関する最終的な考えはありますか？それが独立したストリームを取得するための主なメカニズムであるかどうかはさておき。その機能へのアクセスを完全に削除することを除けば、それは、誤用されやすいシーケンシャルストリームIDを防ぐために私たちがやりたいことのように思えます。

Murmur3ミキサーに通すことをお勧めします。意図的な努力なしに、誤って同様のストリームを作成する可能性はありません。（編集：128ビットバージョンが必要だと思いますが、上半分と下半分を混在させることもできます。定数も追加します。誰もが0x9e3779b97f4a7c15f39cc0605cedc835 （ϕの小数部分）を愛していますが、 0xb7e151628aed2a6abf7158809cf4f3c7 （eの小数部分）も問題ありません。または、ランダムに見える数です。）

imneme 2019年06月01日

wyhash（https://github.com/wangyi-fudan/wyhash）は、BigCrushとPractRandを通過した最速で最も単純なものなので、お勧めします。 cコードは次のように単純です

inline  uint64_t    wyrand(uint64_t *seed){    
    *seed+=0xa0761d6478bd642full;    
    __uint128_t t=(__uint128_t)(*seed^0xe7037ed1a0b428dbull)*(*seed);    
    return  (t>>64)^t;    
}

wangyi-fudan 2019年06月01日

👎2

@ wangyi-fudan、これが全単射だと自分に納得させることはできません。

imneme 2019年06月01日

私の限られた知識で申し訳ありません：なぜPRNGに全単射が必要/好まれるのですか？
いくつかの説明に感謝します：-） @ imneme

wangyi-fudan 2019年06月02日

@ wangyi-fudan、64ビットintから64ビットintへのハッシュ関数が全単射でない場合（つまり、1対1の関数）、一部の結果は複数回生成され、一部はまったく生成されません。それは一種のバイアスです。

imneme 2019年06月02日

何が言いたいのか理解した。ただし、64ビットの乱数ジェネレーターRの場合、1.2 * 2 ^ 32の乱数（http://mathworld.wolfram.com/BirthdayAttack.html）の後に1回の衝突が予想されます。 2 ^ 64の乱数では、多くの衝突が発生するのは自然なことです。衝突は自然ですが、全単射は自然にランダムではありません。ギャンブルテーブル（たとえば、3ビットPRNG）が8トレイル内で0の値であると判断された場合、5つの非ゼロを観察した後、あえてゼロに大きな賭けをします。

wangyi-fudan 2019年06月02日

@ wangyi-fudan、このコンテキストでは、ストリームIDを並べ替えて、1,2,3のようなストリームがよりランダムに見えるようにする方法について話していました（別名、より正常）。このプロセスでの衝突には美徳はありません。

一般的なPRNGの場合、ランダムマッピングに基づくPRNGとランダム可逆マッピング（1対1関数）に基づくPRNGの違いを確認する必要があります。私はそれについて書きましたが、他の人もそうです。サイズが小さいため、ランダムマッピングに基づくPRNGはバイアスを示し、他の手法に基づくPRNGよりも早く失敗します。サイズが大きいと、あらゆる種類の欠陥を検出するのが難しくなる可能性があります。

imneme 2019年06月02日

_n_間隔を要求した場合に、ある間隔が別の間隔と重なる確率を計算できます。それはかなり基本的な確率です—（私が理解しているように）初等数学を含む論文に誰も興奮していないので、それについて論文を発表できるかどうかはわかりません。

私はあなたがピエール・レクイヤーでなければならないと思います。 ;-) 15ページ

rkern 2019年06月23日

はい、彼が基本を説明するとき、それは大丈夫だと考えられます！

imneme 2019年06月23日

@rkern @imnemeシンプルさは、ソフトウェアと数学の両方の機能です。単純な作業に感銘を受けない人もいるということは、矛盾した証拠と見なされるべきではありません。

lemire 2019年06月23日

@lemire ： _コンピューター科学者を批判する方法_と呼ばれる、私が好きなユーモアの作品がたくさんあります。この作品の背後にある根本的な考え方は、理論家は洗練を好み、実験家は単純さを好むというものです。したがって、聴衆が実験家の1人である場合、彼らは単純さに喜ぶでしょうが、聴衆が理論家の1人である場合、それほど多くはありません。

imneme 2019年06月25日

👍1

デフォルトのBitGeneratorはPCG64です。思いやりのある貢献をありがとうございました。そしてスタミナ！

rkern 2019年06月26日

👍1

このスレッドに非常に触発されて、私は報告するいくつかのニュースがあります…

バックグラウンド

多くの点で、 pcg64はかなり良いです。たとえば、統計的品質の通常の測定では、クリーンな健康状態が得られます。さまざまな方法でテストされています。最近では、PractRandを使用して半ペタバイトまで実行しました。通常のユースケースでうまく機能します。

しかし、このスレッドで発生した病状は私にはよく合いませんでした。確かに、「まあ、そのように保持しないでください」

それで、約25日前に、PCGファミリーの新しいメンバーを設計することを考え始めました…

ゴール

私の目標は、現在のpcg64バリアントの代わりになる可能性のある新しいPCGファミリーメンバーを設計すること

出力関数は、XSL RRよりも多くのビットをスクランブルする必要があります（そうすることで、このスレッドで発生した問題を回避できるため）。
パフォーマンスは、現在のpcg64とほぼ同じくらい速い（または速い）はずです。
設計はPCG風である必要があります（つまり、簡単に予測できないため、出力関数の作業を簡単に元に戻すことはできません）。

いつものように、できるだけ早く最高の品質を得ようとするため、トレードオフがあります。速度をまったく気にしない場合は、出力関数にさらに多くのステップを追加して、より高度にスクランブルされた出力を生成できますが、PCGのポイントは、基盤となるLCGが「ほぼ十分」であるため、必要ありませんでした。 1ずつ増加するカウンターのようなもので行うのと同じくらい多くの努力をします。

ネタバレ

成功を報告できることをうれしく思います。私が最初にこれについて考えていた約25日前、私は実際に休暇中でした。約10日前に戻ったとき、自分が持っていたアイデアを試してみたところ、うまく機能していることがわかりました。その後の時間は、主にさまざまな種類のテストに費やされました。昨日は十分満足していたので、コードをC ++バージョンのPCGに

詳細

FWIW、新しい出力関数は次のとおりです（64ビット出力の場合）：

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

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

この出力関数は、広く使用されているxorshift-multiplyに触発されています。乗数の選択は、（a）マジック定数の数を抑えること、および（b）順列が元に戻されないようにすること（下位ビットにアクセスできない場合）であり、「ランダム化された- PCG出力関数が通常持つ「それ自体」の品質。

その他の変更

0xda942042e4dd58b5がこのPRNG（およびすべてのcm_プレフィックス付き128ビット状態PCGジェネレーター）のLCG乗数である場合もあります。比較すると0x2360ed051fc65da44385df649fccf645で使用されるpcg64 、この定数は、分光試験性の点ではまだ実際にはかなり良いですが、128ビット×64ビットよりも簡単であるため、乗算によると安いです128ビット×128ビット。私はこのLCG定数を数年間問題なく使用してきました。安価な乗数バリアントを使用する場合、命令レベルの並列性を高めるために、出力関数を反復後の状態ではなく反復前の状態で実行します。

テスト

私はそれを徹底的にテストし（PractRandとTestU01）、満足しています。テストには、このスレッドで概説されているシナリオが含まれていました（たとえば、ギャングジェネレーターをシーケンシャルスチームで使用するか、2 ^ 64だけ進めて、出力をインターリーブします—4つのギャングと8192のギャングを8TBまで問題なくテストしました。ストリームとその反対側の土地の対応物として）。

速度

速度テストとベンチマークについて詳しく説明することができました。特定のベンチマークで、あるPRNGが別のPRNGよりも速く実行されるかどうかに影響を与えるさまざまな要因がありますが、全体として、このバリアントは、多くの場合、少し速く、時にははるかに速く、時には少し遅くなるようです。コンパイラやアプリケーションなどの要因は、ベンチマークの変動性にはるかに大きな影響を及ぼします。

可用性

C ++ヘッダーのユーザーは、この新しいファミリメンバーに_now_としてpcg_engines::cm_setseq_dxsm_128_64としてアクセスできます。将来のある時点で、 pcg64をpcg_engines::setseq_xsl_rr_128_64からこの新しいスキームに切り替えます。私の現在の計画は、PCG2.0バージョンのバンプの一部として今年の夏にそうすることです。

正式な発表

全体として、私はこの新しい家族にとても満足しています。夏の後半のある時点で、このスレッドを参照している可能性が高い、より詳細なブログ投稿があります。

あなたの選択...

もちろん、これをどうするかを考えなければなりません。あなたがそれを使うかどうかに関係なく、私は実際にあなたの速度ベンチマークでそれが良くなるか悪くなるかを見るためにかなり興味があります。

imneme 2019年06月27日

👍3

@imneme高速のフル64ビット乗算器が必要になるのを回避できますか？（これはx64では超高速ですが、一部の弱いアーキテクチャでは少し遅くなります。）

lemire 2019年06月27日

@lemire ：128ビット×64ビットの乗算。これは、x86で2つの乗算命令を使用して内部的に実行されます（下位ビットで64ビット×64ビット→128ビットの結果、および64ビット×64 -上位ビットのビット。両方の乗算を並行して実行できるため、2つの結果を加算する必要があります。）

それでも、128ビット×128ビットよりも優れている可能性があります。どれだけ良くなるかは、その時点で命令スケジューリングがどれだけうまくいくかに依存しますが。

ARMでは、64ビット×64ビット→128ビットの結果は実際には2つの命令です。

（もちろん、2つの64ビットLCGを組み合わせて、それらを混合することは完全に可能です。存在する可能性があり、うまく機能するすべてのPRNGのスペースはかなり巨大です。）

imneme 2019年06月27日

私たちのフレームワークでの迅速で汚い実装は、少なくとも64ビットLinuxでは、パフォーマンスがわずかに向上することを示唆しています。

Time to produce 1,000,000 64-bit unsigned integers
************************************************************
MT19937      5.42 ms
PCG64        2.59 ms
PCG64DXSM    2.41 ms
Philox       4.37 ms
SFC64        2.07 ms
numpy        5.41 ms
dtype: object

64-bit unsigned integers per second
************************************************************
MT19937      184.39 million
PCG64        386.01 million
PCG64DXSM    415.02 million
Philox       228.88 million
SFC64        483.94 million
numpy        184.79 million
dtype: object

少なくともこのコンテキストでは、バンプを与える事前反復状態から出力していると思います。最初はそれを省略し、基本的にPCG64 1.0と同じパフォーマンスを得ました。本当の勝利は128ビットエミュレーションの下であると私は思うが、それを書き留めることができず、重要なプラットフォームでそれをテストする良い方法がない。

@imnemeさんにとっての本当の質問は、1.0アルゴリズムを実装するnumpy.random.PCG64という名前でどれほどイライラするかということだと思います。リリースは間近で、すでに遅れているので、現時点ではアルゴリズムを変更するつもりはありません。 32ビットプラットフォームでのパフォーマンスが特に優れている場合は、次のリリースでPCG64DXSMを追加し、数リリース後にデフォルトを再検討する可能性があると思います。

rkern 2019年06月28日

それはあなたの選択です！

PCG64の1.0バージョンの発送に問題はありません。他の多くの人々がその変種を使用しています。

DXSMバリアントには、このスレッドで発生したエッジケース使用の問題を回避できるという利点があると思いますが（結局のところ、それが存在する理由はほとんどあります）、一方で、遅れるという欠点があります。パーティー。 1か月未満のPRNGをユーザーに出荷するのは非常に無謀に思えるかもしれません（これは、より実績のあるPCGバリアントと同じアイデアに基づいていますが）。

（とはいえ、無謀さの可能性があるとの非難にもかかわらず、それが_my_の選択だった場合は、おそらく新しいものを出荷します。Numpyで起動して実行するまでの遅延はごくわずかだと思います。リスクは非常に低く、すでにBigCrushで徹底的にテストされ、PractRandで16 TBまでテストされ（サイズの4分の1であるcm_mcg_dxsm_64_32を含む[ストリームなし、32ビット出力]）、1週間以内に32TBに

[パフォーマンスが少し良くなったのはうれしい。 5年前、事前反復状態の使用は、128ビット乗数を使用した128ビットサイズの悲観論でした。しかし、それは、私がテストしていたマシンで、私が使用していたベンチマークでした。]

imneme 2019年06月28日

2.0バリアントを参照するためにその名前を使用する場合は、1.0バリアントにPCG64という名前を使用することについて詳しく説明しました。

rkern 2019年06月28日

@rkernそれが単なる命名の問題である場合、PCG64DXSMとPCG64はそれらをうまく区別しますね。

lemire 2019年06月29日

しつこい人にとっては、確かに。 @imnemeが、C ++バージョンでその名前で2.0バリアントをプロモートするときに、1.0実装にPCG64という名前を付けないことを好むかどうか疑問に思っています。私は、名前が緩いということは、一部の人々がnumpyのPCG64をテストし、それを2.0バージョンについてpcg-random.orgで行われる主張と比較する可能性があるという事実に敏感です。ボブ・ジェンキンのPRNGについてのほぼすべての会話を参照してください。

rkern 2019年06月29日

PCGペーパーのセクション6.3には、次のように書かれています。

ジェネレーターには、実行する順列に基づいたニーモニック名が表示されますが、PCGライブラリのユーザーがこれらのニーモニックによってファミリーメンバーを選択することはめったにないことにも注意してください。ライブラリは、基盤となる実装ではなく、プロパティに基づいて名前付きジェネレーターを提供します（たとえば、一意のストリームを持つ汎用32ビットジェネレーターの場合はpcg32_unique）。そうすれば、パフォーマンスがさらに向上する将来の家族が発見されて追加されたときに（できれば他の人の発見のために）、ユーザーはシームレスにそれらに切り替えることができます。

そして、CおよびC ++ライブラリはそのように構成されています。ライブラリは提供します

順列の名前、動作するビットサイズ、および基になるLCGの特性を介して、特定のファミリメンバーを選択できる低レベルのインターフェイス
事前に選択された低レベルのファミリメンバーに接続するpcg64ような便利なエイリアスを提供する高レベルのインターフェイス。

このようにして、エイリアスを更新して新しい家族を指すようにすることができますが、古い結果を正確に再現したいユーザーは、低レベルのインターフェイスを使用して、以前は便利な高さで到達できた家族を選択することができます。 -レベルのエイリアス。

PCG64というPRNGを出荷する場合は、ドキュメントで、どの特定のPCGバリアントであるか、つまり、どのファミリメンバーに対応するかを低位で示すだけで十分だと思います。 -レベルCまたはC ++ライブラリインターフェイス。

imneme 2019年06月29日

👍1

デフォルトのジェネレーターは、 https：//github.com/numpy/numpy/pull/13840でnp.random.default_gen()として実装されています。（将来の参照のために@ rkern 、PRを明示的に呼び出すことはおそらく良いことです-バックリンクを提供するだけの場合、通知がないため、GitHubでそれらを見逃しがちです。）

1つのマイナーな問題：代わりにこれをnp.random.default_generator()と呼ぶのはどうですか？ genは、私には短すぎる/自明ではないと感じています。他の人の考えが気になります。

shoyer 2019年06月30日

代わりにこのnp.random.default_generator（）を呼び出すのはどうですか？

同じ考えnp.random.default_generator()が、 default_rng遊んでみました。

charris 2019年06月30日

👍私のようなdefault_rngより良いdefault_genあまりにも、。私はまだdefault_generator傾いていますが、これらのいずれかに満足しています。

shoyer 2019年06月30日

：+1： default_rng() 。

rkern 2019年06月30日

Numpy: 新しいPRNGBitGeneratorのデフォルトを決定する

デフォルトなし

`MT19937`

`PCG64`

`Xoshiro256`

最も参考になるコメント

バックグラウンド

ゴール

ネタバレ

詳細

その他の変更

テスト

速度

可用性

正式な発表

あなたの選択...

全てのコメント166件

NumPy 1.next

NumPy 1.20.x

NumPy 1.22

バックグラウンド

ゴール

ネタバレ

詳細

その他の変更

テスト

速度

可用性

正式な発表

あなたの選択...

関連する問題