問題タブ [non-deterministic]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
sql - RAND()を使用したSQLServerでの非決定論的関数の作成
ドキュメントを少し検索して読んだ後、本体内で使用されている組み込み関数に応じて決定論的または非決定論的としてマークされたユーザー定義関数をSQLServerで記述できることは明らかです。
RAND()は、非決定論的関数の下にリストされています(msdnの記事を参照)。では、なぜ関数で使用できないのですか?
c++ - 非決定論の原因
私のおそらく決定論的なプログラムは、実行ごとにわずかに異なる出力の1つを生成します。入力、コンパイラ、およびコンピューターは変更されません。常に合理的に見えるため、どの出力が正しいかわかりません。
rand() への無駄な呼び出し以外に、どうしてこれが可能になるのでしょうか?
sql - Sql Server 決定論的ユーザー定義関数
次のユーザー定義関数があります。
この関数を使用して計算列にインデックスを作成することはできません。決定論的ではないためです。なぜ決定論的ではないのか、最終的に決定論的にするために変更する方法を誰かが説明できますか? ありがとう
c++ - DIR* はどのように EBADF エラーを取得できますか?
私は継承したいくつかのコードを持っています。これは反復するためのクラスの一部であり、ディレクトリの内容にアクセスし、boost::filesystem::path を使用します。コードの一部は次のとおりです。
私が遭遇した問題は、handle_read_error() で errno == EBADF の再現不可能な ASSERT です。コードを調べると、コンストラクターで m_directory_stream が設定されており、他に何も触れていないように見えます。NULL ではないか、コンストラクターが handle_open_error() を呼び出し、このケースは発生しませんでした。したがって、構築時点では、m_directory_stream は有効であり、開いたときにエラーは発生しませんでした。ただし、しばらくして unsafe_increment() が呼び出され、おそらくコンストラクターの直後に呼び出され、この時点で DIR オブジェクトは EBADF になり、アサーションの失敗がスタックに記録されます。
障害が検出されたマシンに関する情報は次のとおりです (アプリケーションはシングル スレッドであることに注意してください)。
ファイル記述子を保持している間に、どのようにしてファイル記述子が不良になる可能性がありますか? これは、dirent.h インターフェイスの既知の問題ですか?
このコードを改善し、この再現不可能な問題を回避する方法を提案してください。
c++ - 浮動小数点比較 - 異なる実行間の結果
C++/C では、2 つの浮動小数点数または倍精度数を絶対的に等しいかどうか比較できないことを知っています。なんらかの理由で、絶対等価を使用する if 条件を記述した場合、if 条件が同じデータに対してプログラムの異なる実行で同じ結果を返すことが保証されますか? それとも純粋に非決定論的であり、結果は異なる可能性がありますか?
multithreading - マルチスレッドプログラムは決定論的になり得ますか?
通常、マルチスレッド プログラムは非決定論的であると言われています。つまり、クラッシュした場合、その状態を引き起こしたエラーを再現することはほぼ不可能です。次にどのスレッドが実行されるか、またいつ再プリエンプトされるかはまったくわかりません。
もちろん、これは OS のスレッド スケジューリング アルゴリズムと関係しており、次にどのスレッドが実行されるか、またそれが実際にどれくらい実行されるかがわからないという事実に関係しています。プログラムの実行順序も役割を果たします。
しかし、スレッドのスケジューリングに使用されるアルゴリズムがあり、どのスレッドがいつ実行されているかを知ることができれば、マルチスレッド プログラムは「決定論的」になり、クラッシュを再現できるようになるでしょうか?
linux-kernel - 書き込みバリアがない場合、ディスクコントローラーは同じセクターへの同時書き込みをどのように処理しますか?
O_DIRECT | O_ASYNCを使用してファイルを開き、fsyncまたはfdatasyncを間にせずに、同じディスクセクターに2つの同時書き込みを行うと、Linuxディスクサブシステムまたはハードウェアディスクコントローラーは、そのディスクセクターの最終データが2番目の書き込みになりますか?
O_DIRECTがOSバッファキャッシュをバイパスするのは事実ですが、データは最終的に低レベルIOキュー(ディスクスケジューラキュー、ディスクドライバのキュー、ハードウェアコントローラのキャッシュ/キューなど)に入れられます。IOスタックをエレベータアルゴリズムまで追跡しました。
たとえば、次の一連の要求が最終的にディスクスケジューラキューに入れられた場合
エレベータコードは、バッファ1、2からそれぞれセクター1、2を合体させるために「バックマージ」を実行します。次に、ディスクに2つのディスクIOを発行します。しかし、ディスクセクター1の最終データがバッファー1からのものかバッファー3からのものかはわかりません(ドライバー/コントローラーの書き込みの並べ替えのセマンティクスについてはわかりません)。
シナリオ2:
このシナリオはどのように処理されますか?より基本的な質問は、AIOを使用してO_DIRECTモードで書き込みを行う場合、明示的な書き込みバリアがない場合、この一連の要求がディスクスケジューラのキューに入れられる可能性があるかどうかです。
はいの場合、「同じセクターへの複数の書き込みにより、最後の書き込みが最後の書き込みになる」などの順序保証はありますか?
または、その順序付けは非決定論的です[シーク時間を最適化するためにバリア内で書き込みを並べ替えるディスクコントローラー/そのキャッシュに翻弄されます]
deterministic - 確定的なバグの例
誰かがプログラムの決定論的なバグの例を教えてもらえますか?
ありがとう。
list - Curryのstdlibの非決定論的選択関数が単純に定義されておらず、ヘルパー2引数関数を使用しているのはなぜですか?
「リストから1つの要素を非決定論的に選択する」という仕様のchoose
Curryプログラミング言語の関数について考えてみます。(choose xs)
xs
私はそれを2つの代替の非決定論的ルールを通して簡単に実装します:
しかし、Muenster CurryCompilerの/usr/lib/curry-0.9.11/Success.curryでは、ヘルパー関数で定義されています。
コンパイラが提供するモジュールからの定義の利点(もしあれば)は何でしょうか?2つの定義は完全に同等ですか(非決定論と未定義の値を持ついくつかのトリッキーな場合でも)?..場合によっては、そのうちの1つがより効率的ですか?
追加:より深い考察
cthom06(Thanks!)は、私の定義がはるかに多くの場合に未定義の値にヒットすることを正しく指摘しています(最初に「トップレベル」の呼び出しごとに1回、空のリスト引数を使用してこの関数を呼び出そうとするためです空でないリスト引数)。(うーん、なぜ私はこの考慮事項にすぐに気づかなかったのですか?..)それは効率が悪いです。
しかし、私は疑問に思います:意味上の違いはありますか?いくつかのトリッキーなコンテキストで違いが重要になる可能性がありますか?
2つの定義の違い(空でないリストの場合)は、基本的に、次の2つの潜在的な定義の違いに要約されますid
。
私の定義は次のように定義するようなid
ものです。
そしてそれらの定義はid
通常の方法で定義するようなものです:
(したがって、ここでは単純さが元に戻されます。)
どのような状況でそれが重要になる可能性がありますか?