アカウント名:
パスワード:
リアルタイム信号処理のプログラム書きますが、立ち上がってすぐは入力データが用意されていないでクリアしたバッファの初期値で演算(たとえばパイプラインADCとか使っていて入力に遅延がある)なんてことは普通にあり得るので、アルゴリズム中に割り算があるとき(正規化とかAGCとか)では 0割が発生しないように 除数がゼロかどうかあらかじめチェックします。そして、結果を後段アルゴリズムの制約上問題ない値とします。例外なんて起こさない方がいいし、誰か書いていましたがそんな機構は無い場合もあるしで予測される例外は基本的に排除(生起しないように手を打つ)すべきです。データが用意されるまで待てばいいんだけどね。演算側の水際でも処置しておかないと安心できないつーか、後段の用途によって0割の結果値を吟味するのって普通だと思いますが(0で駄目なら非0の微小値とかそもそものアルゴリズムをスキップするとか)そういうこと考えないでプログラム書いてるんですかね。
業務計算のプログラムとか除算の嵐です。しかも本来そこに、データエラーでない限り、0はありえないという場合も多い。ありえないので処理しない、テストもしないというわけ。
で、データエラーというのは頻繁に起こるわけです(爆笑)笑ってる場合ではないですが。
入力値のダイナミックレンジが大きすぎて、入力を制限できない場合はありますよ。レジスタ幅で表現できるダイナミックレンジぎりぎりとか、時にはそれをを上回る計算をさせるようなときに、(当然精度は落ちる)逆数を求めると値が小さすぎて0になってしまって、それで除算するとエラーとか。
式の項数が少ないうちは入力を制限できますけど、計算式の項が10項を超える方程式とかを解かせる様な場合に、入力から出力が0になる事を予想する事が困難、または入力をチェックするよりも実際に計算させてみる方が速いな事もありえます。
その例だと桁落ちを放っておくのがまずいだけでは?
桁落ちに対応する為に、レジスタ幅を超える演算をメモリと対話しながら行うと、計算速度が低下してしまうのが問題で、それは許容できない場合です。
計算速度的にチェックルーチンの追加が許容できないとき、#2835055でいうところの事前チェックでゼロ除算エラーが発生したらどうするの?
その際の動作は、プログラムに要求されている仕様によるんじゃないでしょうか。仕様が定義されていなければ、案件として上にあげて、仕様を決めてもらったらいいと思います。
仕様を決めても計算量が増えたら間に合わないらしいから速いCPUを持ってくるしかないんじゃないかな。
さもなければ誤差だらけかもしれない演算結果を受入れ、本番でゼロ除算が起こったら素直に諦める。
前提条件で対応が変わるものに、前提条件を定めないまま、結論を出してもしょーがないと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生unstable -- あるハッカー
割り算させない (スコア:5, 参考になる)
リアルタイム信号処理のプログラム書きますが、
立ち上がってすぐは入力データが用意されていないでクリアしたバッファの初期値で演算
(たとえばパイプラインADCとか使っていて入力に遅延がある)
なんてことは普通にあり得るので、アルゴリズム中に割り算があるとき
(正規化とかAGCとか)では 0割が発生しないように 除数がゼロかどうか
あらかじめチェックします。そして、結果を後段アルゴリズムの制約上問題ない値とします。
例外なんて起こさない方がいいし、誰か書いていましたがそんな機構は無い場合もあるしで
予測される例外は基本的に排除(生起しないように手を打つ)すべきです。
データが用意されるまで待てばいいんだけどね。
演算側の水際でも処置しておかないと安心できない
つーか、後段の用途によって0割の結果値を吟味するのって普通だと思いますが
(0で駄目なら非0の微小値とかそもそものアルゴリズムをスキップするとか)
そういうこと考えないでプログラム書いてるんですかね。
Re: (スコア:1)
業務計算のプログラムとか除算の嵐です。
しかも本来そこに、データエラーでない限り、0はありえないという場合も多い。
ありえないので処理しない、テストもしないというわけ。
で、データエラーというのは頻繁に起こるわけです(爆笑)
笑ってる場合ではないですが。
Re: (スコア:1)
0がデータエラーでない限りありえないということであれば、データチェックのバグと考えるのが普通で、そのバグの回避を下流の処理で行わせなければならないようなシステムの方こそ品質に問題があります。
上流処理にデータチェック処理が存在しないということであれば、それはまた別の意味で問題ですが…。
Re: (スコア:0)
入力値のダイナミックレンジが大きすぎて、入力を制限できない場合はありますよ。
レジスタ幅で表現できるダイナミックレンジぎりぎりとか、
時にはそれをを上回る計算をさせるようなときに、(当然精度は落ちる)
逆数を求めると値が小さすぎて0になってしまって、それで除算するとエラーとか。
式の項数が少ないうちは入力を制限できますけど、
計算式の項が10項を超える方程式とかを解かせる様な場合に、
入力から出力が0になる事を予想する事が困難、
または入力をチェックするよりも実際に計算させてみる方が速いな事もありえます。
Re: (スコア:0)
その例だと桁落ちを放っておくのがまずいだけでは?
Re: (スコア:0)
桁落ちに対応する為に、レジスタ幅を超える演算をメモリと対話しながら行うと、
計算速度が低下してしまうのが問題で、それは許容できない場合です。
Re: (スコア:0)
計算速度的にチェックルーチンの追加が許容できないとき、
#2835055でいうところの事前チェックでゼロ除算エラーが
発生したらどうするの?
Re: (スコア:0)
その際の動作は、プログラムに要求されている仕様によるんじゃないでしょうか。
仕様が定義されていなければ、案件として上にあげて、仕様を決めてもらったらいいと思います。
Re:割り算させない (スコア:0)
仕様を決めても計算量が増えたら間に合わないらしいから
速いCPUを持ってくるしかないんじゃないかな。
さもなければ誤差だらけかもしれない演算結果を受入れ、
本番でゼロ除算が起こったら素直に諦める。
Re: (スコア:0)
前提条件で対応が変わるものに、
前提条件を定めないまま、結論を出してもしょーがないと思います。