0

16ビットおよび8ビットのバッファを使用するように配線された粒子検出器があります。時々、それを通過する粒子フラックスの特定の[予測された]ピークがあります。大丈夫。大丈夫ではないのは、これらのフラックスは通常、それらを保存するためのバッファーの容量を超える大きさに達するということです。したがって、オーバーフローが発生します。チャート上では、フラックスが突然低下し、再び成長し始めているように見えます。オーバーフローが発生しているデータのポイントを[ほぼ]正確に検出する方法を提案できますか？

PS検出器は物理的にアクセスできないため、バッファを交換して「正しい方法」で修正することはできません。

更新：要求に応じていくつかの説明。データ処理施設ではPythonを使用しています。検出器自体で使用されているテクノロジーはかなりあいまいです（完全に無関係なサードパーティによって開発されたものとして扱います）が、それは間違いなく洗練されていません。つまり、「実際の」OSを実行しておらず、記録するための低レベルのものだけです。検出器の読み取り値と、電源の入れ直しなどのリモートコマンドに応答します。現在、メモリの破損やその他の問題は問題ではありません。オーバーフローは、検出器の設計者が粒子フラックスのカウントに16ビットバッファーを使用したために発生し、フラックスが1秒あたり65535粒子を超える場合があります。

更新2：何人かの読者が指摘しているように、意図された解決策は、フラックスプロファイルを分析して、通常の変動からそれらを分離する試みで、急激な低下（たとえば1桁）を検出することと関係があります。別の問題が発生します：復元（元のフラックスがオーバーフローレベルを下回るポイント）は、元に戻された（x軸による）フラックスプロファイルに対して補正プログラムを実行するだけで検出できますか？

4

6 に答える 6

1 
int32[] unwrap(int16[] x)
{
   // this is pseudocode
   int32[] y = new int32[x.length];
   y[0] = x[0];
   for (i = 1:x.length-1)
   {
      y[i] = y[i-1] + sign_extend(x[i]-x[i-1]);
      // works fine as long as the "real" value of x[i] and x[i-1]
      // differ by less than 1/2 of the span of allowable values
      // of x's storage type (=32768 in the case of int16)
      // Otherwise there is ambiguity.
   }
   return y;
}

int32 sign_extend(int16 x)
{
   return (int32)x; // works properly in Java and in most C compilers
}

// exercise for the reader to write similar code to unwrap 8-bit arrays
// to a 16-bit or 32-bit array
于 2009-05-29T13:33:10.147 に答える
1

もちろん、理想的には、検出ソフトウェアを 65535 で最大に修正して、悲しみの原因となっている種類のラップアラウンドを防ぐ必要があります。これが常に可能であるとは限らないこと、または少なくとも常に迅速に実行できるとは限らないことを理解しています.

粒子フラックスが 65535 を超えると、急激に増加しますか、それともフラックスが徐々に増加してから徐々に減少しますか? これにより、これを検出するために使用するアルゴリズムが異なります。たとえば、フラックスが十分にゆっくりと上昇する場合:

true flux     measurement  
 5000           5000
10000          10000
30000          30000
50000          50000
70000           4465
90000          24465
60000          60000
30000          30000
10000          10000

その後、オーバーフローしたときに大きなマイナスのドロップが発生する傾向があります。他のどの時点よりもはるかに大きなマイナスの低下です。これは、オーバーフローしたというシグナルとして機能します。オーバーフロー期間の終わりを見つけるには、65535 からそれほど離れていない値への大きなジャンプを探すことができます。

これはすべて、可能な最大の真のフラックスと、フラックスの上昇と下降の速さに依存します。たとえば、1 回の測定期間で 128k を超えるカウントを取得することは可能ですか? ある測定値が 5000 で、次の測定値が 50000 になる可能性はありますか? データの動作が十分でない場合は、いつオーバーフローしたかについて統計的な判断しかできない場合があります。

于 2009-05-29T04:47:27.080 に答える
0

隠れた状態がオーバーフロー状態にあるかどうかであり、放出が観察された粒子フラックスであるHMMを使用するのはどうですか？

トリッキーな部分は、遷移（基本的にピークのタイムスケールをエンコードします）と放出（フラックスがどのように動作し、オーバーフローが測定にどのように影響するかを知っていれば構築できます）の確率モデルを考え出すことです。これらはドメイン固有の質問であるため、既成のソリューションはおそらく存在しません。

しかし、モデルを持っていると、他のすべて---データの適合、不確実性の定量化、シミュレーションなど---は日常的です。

于 2009-05-29T06:09:29.917 に答える
0

基になるバッファーを修正せずに修正できるとは本当に思いません。値のシーケンス (0, 1, 2, 1, 0) と (0, 1, 65538, 1, 0) の違いをどのように見分けるのですか? できません。

于 2009-05-29T04:43:39.670 に答える
0

質問には、実装に関する詳細情報を提供する必要があります。使用している言語/フレームワークは何ですか?

ソフトウェアのデータ オーバーフロー (これはあなたが話していることだと思います) は悪い習慣であり、避けるべきです。ご覧のとおり (奇妙なデータ出力) は、データ オーバーフローが発生したときに発生する可能性のある副作用の 1 つにすぎませんが、これは、目に見える問題の種類の氷山の一角にすぎません。

プログラムが大音量でクラッシュしたり、さらに悪いことに、あいまいにクラッシュしたりする可能性がある、メモリ破損などのより深刻な問題を簡単に経験する可能性があります。

そもそもオーバーフローが発生するのを防ぐためにできる検証はありますか?

于 2009-05-29T04:21:56.857 に答える
0

これを行うことができるのは、連続する値の間の実際のジャンプが 65536 よりもはるかに小さい場合のみです。それ以外の場合、オーバーフローによって引き起こされた谷のアーティファクトは実際の谷と見分けがつかず、推測することしかできません。右側と左側からの信号を同時に分析することにより、オーバーフローを対応する復元と一致させることができます (認識可能なベース ラインがあると仮定します)。

それ以外にできることは、元の粒子の流れを変えて実験を繰り返すことで実験を調整することだけです。これにより、実際の谷は動かず、アーティファクトの谷はオーバーフローのポイントに移動します。

于 2009-05-29T12:50:39.017 に答える