アカウント名:
パスワード:
リアルタイム信号処理のプログラム書きますが、立ち上がってすぐは入力データが用意されていないでクリアしたバッファの初期値で演算(たとえばパイプラインADCとか使っていて入力に遅延がある)なんてことは普通にあり得るので、アルゴリズム中に割り算があるとき(正規化とかAGCとか)では 0割が発生しないように 除数がゼロかどうかあらかじめチェックします。そして、結果を後段アルゴリズムの制約上問題ない値とします。例外なんて起こさない方がいいし、誰か書いていましたがそんな機構は無い場合もあるしで予測される例外は基本的に排除(生起しないように手を打つ)すべきです。データが用意されるまで待てばいいんだけどね。演算側の水際でも処置しておかないと安心できないつーか、後段の用途によって0割の結果値を吟味するのって普通だと思いますが(0で駄目なら非0の微小値とかそもそものアルゴリズムをスキップするとか)そういうこと考えないでプログラム書いてるんですかね。
実時間処理でそんな面倒なことするなんて想像も出来ない我が社ではそのような場合、バッファは常に非ゼロの有限値(疑似乱数等)で初期化割り算は常に分母に微少な定数を加えてから計算時間がもったいないから、いちいち余分なチェックなんてしない
定数を加えるコストとゼロ条件分岐のコストが極端に違うならもったいないと言えるかもだがイミディエート値のロードと、レジスタ値の0チェック比較したら(たぶん除数は既にレジスタにロードされてる)定数加算の方がコスト掛かると思う比べてみた?
元ACじゃないけど、ふつう定数のロードはループの外にあるから、レジスタが十分にあるなら無視してもよいコストでは?
とすれば、0と比較する分無駄は多いと思うけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
割り算させない (スコア:5, 参考になる)
リアルタイム信号処理のプログラム書きますが、
立ち上がってすぐは入力データが用意されていないでクリアしたバッファの初期値で演算
(たとえばパイプラインADCとか使っていて入力に遅延がある)
なんてことは普通にあり得るので、アルゴリズム中に割り算があるとき
(正規化とかAGCとか)では 0割が発生しないように 除数がゼロかどうか
あらかじめチェックします。そして、結果を後段アルゴリズムの制約上問題ない値とします。
例外なんて起こさない方がいいし、誰か書いていましたがそんな機構は無い場合もあるしで
予測される例外は基本的に排除(生起しないように手を打つ)すべきです。
データが用意されるまで待てばいいんだけどね。
演算側の水際でも処置しておかないと安心できない
つーか、後段の用途によって0割の結果値を吟味するのって普通だと思いますが
(0で駄目なら非0の微小値とかそもそものアルゴリズムをスキップするとか)
そういうこと考えないでプログラム書いてるんですかね。
Re: (スコア:0)
実時間処理でそんな面倒なことするなんて想像も出来ない
我が社ではそのような場合、バッファは常に非ゼロの有限値(疑似乱数等)で初期化
割り算は常に分母に微少な定数を加えてから計算
時間がもったいないから、いちいち余分なチェックなんてしない
Re:割り算させない (スコア:0)
定数を加えるコストと
ゼロ条件分岐のコストが
極端に違うならもったいないと言えるかもだが
イミディエート値のロードと、レジスタ値の0チェック比較したら
(たぶん除数は既にレジスタにロードされてる)
定数加算の方がコスト掛かると思う
比べてみた?
Re: (スコア:0)
元ACじゃないけど、ふつう定数のロードはループの外にあるから、
レジスタが十分にあるなら無視してもよいコストでは?
とすれば、0と比較する分無駄は多いと思うけど。