アカウント名:
パスワード:
リアルタイム信号処理のプログラム書きますが、立ち上がってすぐは入力データが用意されていないでクリアしたバッファの初期値で演算(たとえばパイプラインADCとか使っていて入力に遅延がある)なんてことは普通にあり得るので、アルゴリズム中に割り算があるとき(正規化とかAGCとか)では 0割が発生しないように 除数がゼロかどうかあらかじめチェックします。そして、結果を後段アルゴリズムの制約上問題ない値とします。例外なんて起こさない方がいいし、誰か書いていましたがそんな機構は無い場合もあるしで予測される例外は基本的に排除(生起しないように手を打つ)すべきです。データが用意されるまで待てばいいんだけどね。演算側の水際でも処置しておかないと安心できないつーか、後段の用途によって0割の結果値を吟味するのって普通だと思いますが(0で駄目なら非0の微小値とかそもそものアルゴリズムをスキップするとか)そういうこと考えないでプログラム書いてるんですかね。
業務計算のプログラムとか除算の嵐です。しかも本来そこに、データエラーでない限り、０はありえないという場合も多い。ありえないので処理しない、テストもしないというわけ。
で、データエラーというのは頻繁に起こるわけです（爆笑）笑ってる場合ではないですが。
>しかも本来そこに、データエラーでない限り、０はありえないという場合も多い。>ありえないので処理しない、テストもしないというわけ。
みずほ銀行の問題が未だに収拾ついていないらしいのって、こういう文化圏の人が仕切ってるからじゃないかという気がしてならないのですが(^_^;まぁ、そういう文化圏の会社の仕事やったことあったから書いてるのですが(；´Д｀)
入力値のダイナミックレンジが大きすぎて、入力を制限できない場合はありますよ。レジスタ幅で表現できるダイナミックレンジぎりぎりとか、時にはそれをを上回る計算をさせるようなときに、(当然精度は落ちる)逆数を求めると値が小さすぎて0になってしまって、それで除算するとエラーとか。
式の項数が少ないうちは入力を制限できますけど、計算式の項が10項を超える方程式とかを解かせる様な場合に、入力から出力が0になる事を予想する事が困難、または入力をチェックするよりも実際に計算させてみる方が速いな事もありえます。
その例だと桁落ちを放っておくのがまずいだけでは？
桁落ちに対応する為に、レジスタ幅を超える演算をメモリと対話しながら行うと、計算速度が低下してしまうのが問題で、それは許容できない場合です。
そりゃアルゴリズムの実装の問題だろう処理系の仕様を熟知していなければならないのは当然の話確認的動作させなきゃわからない、という状況なら処理系に実装されている例外処理を使うべきかもしれないすべからく実装コストと実行コストのバランスでプログラマが「判ってない」ってのは笑止、っていう話だがこのトピでもそういう状況なのを云っているのを散見する
計算速度的にチェックルーチンの追加が許容できないとき、#2835055でいうところの事前チェックでゼロ除算エラーが発生したらどうするの？
しょぼい一般論しか話せないお前のような「わかってない」半可通は黙れよ。
×すべからく
その際の動作は、プログラムに要求されている仕様によるんじゃないでしょうか。仕様が定義されていなければ、案件として上にあげて、仕様を決めてもらったらいいと思います。
仕様を決めても計算量が増えたら間に合わないらしいから速いCPUを持ってくるしかないんじゃないかな。
さもなければ誤差だらけかもしれない演算結果を受入れ、本番でゼロ除算が起こったら素直に諦める。
前提条件で対応が変わるものに、前提条件を定めないまま、結論を出してもしょーがないと思います。
大手SIerが人足かき集めて作った大規模基幹システムなんてザルなのが当たり前だと思ってました。変なデータがくるんだけどって問い合わせたら、今さら変えられないから受信側でチェックしろってところまでがテンプレでしょ？
それ根本的に間違ってるよ。おもしろ狙いじゃなくて本気で言ってるの?あり得ないことが起きるのが現場なんだよ。あり得ないことがあり得てないことをチェックしろよなんでそういうあり得ないからあり得ないのでチェックしないみたいな思考するかな
たぶん着目点・立ち位置のちがいだと思いますけど。
ただ、このスレッドの流れは>業務計算のプログラムとか除算の嵐です。からきてると考えると、チェックするのが妥当だと感じてます。
＃これってサニタイジングの一種ですよね。＃サニタイジング言うなってそりゃ荒れるわ。。
いやさ、「あり得ないもの」を「正常に処理しなきゃいけない」っていう動機が無いわけよ。「あり得ないもの」が「ある」時点で、どう取り繕おうが「終わってる」のには変わりないわけよ。
それを顕在化させるか、既に意味のないものだから無視するかというケースはそれぞれにあるわけで普遍的な正解があるわけではない。
業務系で言うなら、「割り勘処理に人数0人の例外処理をホントに仕様化する必要あるの？」って話だから。
チェックするのが正しいけど、チェックする事に何の意味もないし、チェックしなくて困る奴もいない。
>チェックするのが正しいけど、チェックする事に何の意味もないし、チェックしなくて困る奴もいない。
ただ、実際問題として全部一人で見切れるボリュームならよいけど、かき集められた元うどん職人とかが書いたコードとかからいきなり0とか投げつけられることもあるわけで。
よたよた進んで密かに計算間違うぐらいなら、盛大に「エラーです」と止まってくれた方がよいし、自分の責任では無いと表明できるのです。
これは仕様の綺麗さとか、ポリシーとかではなくて、単に保身・保険の問題です。
> で、データエラーというのは頻繁に起こるわけです（爆笑）
うーん。昔、新人君が、先輩ライブラリの中で落ちます。ライブラリバグってます！ていうんで、見てみたら引数に NULL を渡してただけだったってのを思い出しました。
まっとうなプログラムなら、どこでイレギュラーなデータを除去するかを規定するもんだと思うんですが。
で、それより後は、デバッグを簡単にするために ASSERT でチェックするだけ。
＃ でも日本人の性なのか、どこまでも半端なチェックでごまかされてだけってことは多いんだよなぁ
>チェックに疲れ果てたベテランプログラマー本来やりたいことからすれば、余計な処理と言えるわけで。。必要なのは分かってるが、堅牢にしようとすればチェック処理の方が多くなるのはもやっとしません？
>必要なのは分かってるが、堅牢にしようとすればチェック処理の方が多くなるのはもやっとしません？
堅牢なことは至上命題で大前提だと思いますよ。高速化とかエレガントなアルゴリズムとかは、その後についてくると思ってます。だから、殆どもやっとはしないです、個人的には。まぁ、この手のチェックや回避策の処理自体をミドルウェアや言語系でやってくれると助かるんですけどね。
同じく、もやっとしない。堅牢なのに高速化を阻害しないデータ構造とか、実装に関する設計がエンジニアの腕の見せ所だと思ってます。
至上命題ってどういう意味ですか？ぐぐっても分かりませんでした。
あれま…「至上」の「命題」って事です。要は、最優先事項とかそういう意味です。
命題に至上もなにもありませんよ。命題とは、真偽の判断に使う文章でしかありません。←これが命題ひょっとして至上命令ですか？
つまり至上命題は間違った日本語ですよってことが言いたいようです
http://www.sankei.com/life/news/150222/lif1502220004-n1.html [sankei.com]
社会人にとっては業界用語みたいなものだから、辞書に載っていないので間違いと言い切れるものでもないのでは。適切な用語がないから新語が生まれてくる。
実社会では何事も正/誤で割り切れないことも多いものなのです。
いや誤だろ自分の無知をひけらかすことになるんだから、今指摘されててよかったんじゃねーの
それは仕方がありません。
交通にしても料理にしても工場にしても建設現場にしても、安全を確保した上で仕事をしているわけで。もし安全のためのチェック処理のほうが多くなっても、それが必要なものであれば省略してはいけません。それが自分自身のためでもありますし、客のためでもありますし、職業倫理でもあります。法律の縛りがあるかないか、という差はありますが。
「それが必要なものであれば」の判断が難しいのだと思うよ。
判断が難しいので、安全に倒して冗長だろうがなんだろうが全てチェックし始めて、privateメソッドの引数や戻り値も疑ってチェックコードだらけになり、使用しているライブラリの結果も疑い、最終的にチェックコードを書くのを面倒になった結果、メソッド分割もせず、外部ライブラリどころか標準ライブラリすらほとんど使用しなくなり、スパゲッティ大盛りな超巨大メソッドになったものを、なんとかしてくれと依頼されるわけです。
# そこまでしてチェックコードを書くのに、ユニットテストはやらない不思議
実時間処理でそんな面倒なことするなんて想像も出来ない我が社ではそのような場合、バッファは常に非ゼロの有限値（疑似乱数等）で初期化割り算は常に分母に微少な定数を加えてから計算時間がもったいないから、いちいち余分なチェックなんてしない
定数を加えるコストとゼロ条件分岐のコストが極端に違うならもったいないと言えるかもだがイミディエート値のロードと、レジスタ値の0チェック比較したら(たぶん除数は既にレジスタにロードされてる)定数加算の方がコスト掛かると思う比べてみた?
元ACじゃないけど、ふつう定数のロードはループの外にあるから、レジスタが十分にあるなら無視してもよいコストでは？
とすれば、0と比較する分無駄は多いと思うけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
割り算させない (スコア:5, 参考になる)
リアルタイム信号処理のプログラム書きますが、
立ち上がってすぐは入力データが用意されていないでクリアしたバッファの初期値で演算
(たとえばパイプラインADCとか使っていて入力に遅延がある)
なんてことは普通にあり得るので、アルゴリズム中に割り算があるとき
(正規化とかAGCとか)では 0割が発生しないように 除数がゼロかどうか
あらかじめチェックします。そして、結果を後段アルゴリズムの制約上問題ない値とします。
例外なんて起こさない方がいいし、誰か書いていましたがそんな機構は無い場合もあるしで
予測される例外は基本的に排除(生起しないように手を打つ)すべきです。
データが用意されるまで待てばいいんだけどね。
演算側の水際でも処置しておかないと安心できない
つーか、後段の用途によって0割の結果値を吟味するのって普通だと思いますが
(0で駄目なら非0の微小値とかそもそものアルゴリズムをスキップするとか)
そういうこと考えないでプログラム書いてるんですかね。
Re:割り算させない (スコア:1)
業務計算のプログラムとか除算の嵐です。
しかも本来そこに、データエラーでない限り、０はありえないという場合も多い。
ありえないので処理しない、テストもしないというわけ。
で、データエラーというのは頻繁に起こるわけです（爆笑）
笑ってる場合ではないですが。
Re:割り算させない (スコア:1)
>しかも本来そこに、データエラーでない限り、０はありえないという場合も多い。
>ありえないので処理しない、テストもしないというわけ。
みずほ銀行の問題が未だに収拾ついていないらしいのって、こういう文化圏の人が仕切ってるからじゃないかという気がしてならないのですが(^_^;
まぁ、そういう文化圏の会社の仕事やったことあったから書いてるのですが(；´Д｀)
Re:割り算させない (スコア:1)
0がデータエラーでない限りありえないということであれば、データチェックのバグと考えるのが普通で、そのバグの回避を下流の処理で行わせなければならないようなシステムの方こそ品質に問題があります。
上流処理にデータチェック処理が存在しないということであれば、それはまた別の意味で問題ですが…。
Re: (スコア:0)
入力値のダイナミックレンジが大きすぎて、入力を制限できない場合はありますよ。
レジスタ幅で表現できるダイナミックレンジぎりぎりとか、
時にはそれをを上回る計算をさせるようなときに、(当然精度は落ちる)
逆数を求めると値が小さすぎて0になってしまって、それで除算するとエラーとか。
式の項数が少ないうちは入力を制限できますけど、
計算式の項が10項を超える方程式とかを解かせる様な場合に、
入力から出力が0になる事を予想する事が困難、
または入力をチェックするよりも実際に計算させてみる方が速いな事もありえます。
Re: (スコア:0)
その例だと桁落ちを放っておくのがまずいだけでは？
Re: (スコア:0)
桁落ちに対応する為に、レジスタ幅を超える演算をメモリと対話しながら行うと、
計算速度が低下してしまうのが問題で、それは許容できない場合です。
Re: (スコア:0)
そりゃアルゴリズムの実装の問題だろう
処理系の仕様を熟知していなければならないのは当然の話
確認的動作させなきゃわからない、という状況なら
処理系に実装されている例外処理を使うべきかもしれない
すべからく実装コストと実行コストのバランスで
プログラマが「判ってない」ってのは笑止、っていう話だが
このトピでもそういう状況なのを云っているのを散見する
Re: (スコア:0)
計算速度的にチェックルーチンの追加が許容できないとき、
#2835055でいうところの事前チェックでゼロ除算エラーが
発生したらどうするの？
Re: (スコア:0)
しょぼい一般論しか話せないお前のような「わかってない」半可通は黙れよ。
Re: (スコア:0)
×すべからく
Re: (スコア:0)
その際の動作は、プログラムに要求されている仕様によるんじゃないでしょうか。
仕様が定義されていなければ、案件として上にあげて、仕様を決めてもらったらいいと思います。
Re: (スコア:0)
仕様を決めても計算量が増えたら間に合わないらしいから
速いCPUを持ってくるしかないんじゃないかな。
さもなければ誤差だらけかもしれない演算結果を受入れ、
本番でゼロ除算が起こったら素直に諦める。
Re: (スコア:0)
前提条件で対応が変わるものに、
前提条件を定めないまま、結論を出してもしょーがないと思います。
Re: (スコア:0)
大手SIerが人足かき集めて作った大規模基幹システムなんてザルなのが当たり前だと思ってました。
変なデータがくるんだけどって問い合わせたら、
今さら変えられないから受信側でチェックしろってところまでがテンプレでしょ？
Re: (スコア:0)
それ根本的に間違ってるよ。おもしろ狙いじゃなくて本気で言ってるの?
あり得ないことが起きるのが現場なんだよ。あり得ないことがあり得てないことをチェックしろよ
なんでそういうあり得ないからあり得ないのでチェックしないみたいな思考するかな
Re: (スコア:0)
たぶん着目点・立ち位置のちがいだと思いますけど。
ただ、このスレッドの流れは
>業務計算のプログラムとか除算の嵐です。
からきてると考えると、チェックするのが妥当だと感じてます。
＃これってサニタイジングの一種ですよね。
＃サニタイジング言うなってそりゃ荒れるわ。。
Re: (スコア:0)
いやさ、
「あり得ないもの」を「正常に処理しなきゃいけない」っていう動機が無いわけよ。
「あり得ないもの」が「ある」時点で、どう取り繕おうが「終わってる」のには変わりないわけよ。
それを顕在化させるか、既に意味のないものだから無視するかというケースはそれぞれにあるわけで
普遍的な正解があるわけではない。
業務系で言うなら、
「割り勘処理に人数0人の例外処理をホントに仕様化する必要あるの？」
って話だから。
チェックするのが正しいけど、チェックする事に何の意味もないし、チェックしなくて困る奴もいない。
Re: (スコア:0)
>チェックするのが正しいけど、チェックする事に何の意味もないし、チェックしなくて困る奴もいない。
ただ、実際問題として全部一人で見切れるボリュームならよいけど、
かき集められた元うどん職人とかが書いたコードとかから
いきなり0とか投げつけられることもあるわけで。
よたよた進んで密かに計算間違うぐらいなら、盛大に「エラーです」と止まってくれた方がよいし、
自分の責任では無いと表明できるのです。
これは仕様の綺麗さとか、ポリシーとかではなくて、単に保身・保険の問題です。
Re: (スコア:0)
> で、データエラーというのは頻繁に起こるわけです（爆笑）
うーん。昔、新人君が、先輩ライブラリの中で落ちます。ライブラリバグってます！
ていうんで、見てみたら引数に NULL を渡してただけだったってのを思い出しました。
まっとうなプログラムなら、どこでイレギュラーなデータを除去するかを
規定するもんだと思うんですが。
で、それより後は、デバッグを簡単にするために ASSERT でチェックするだけ。
＃ でも日本人の性なのか、どこまでも半端なチェックでごまかされてだけってことは多いんだよなぁ
Re: (スコア:0)
>チェックに疲れ果てたベテランプログラマー
本来やりたいことからすれば、余計な処理と言えるわけで。。
必要なのは分かってるが、堅牢にしようとすればチェック処理の方が多くなるのはもやっとしません？
Re:割り算させない (スコア:1)
>必要なのは分かってるが、堅牢にしようとすればチェック処理の方が多くなるのはもやっとしません？
堅牢なことは至上命題で大前提だと思いますよ。高速化とかエレガントなアルゴリズムとかは、その後についてくると思ってます。
だから、殆どもやっとはしないです、個人的には。
まぁ、この手のチェックや回避策の処理自体をミドルウェアや言語系でやってくれると助かるんですけどね。
Re: (スコア:0)
同じく、もやっとしない。
堅牢なのに高速化を阻害しないデータ構造とか、実装に関する設計がエンジニアの腕の見せ所だと思ってます。
Re: (スコア:0)
至上命題ってどういう意味ですか？
ぐぐっても分かりませんでした。
Re:割り算させない (スコア:1)
あれま…
「至上」の「命題」って事です。
要は、最優先事項とかそういう意味です。
Re: (スコア:0)
命題に至上もなにもありませんよ。
命題とは、真偽の判断に使う文章でしかありません。←これが命題
ひょっとして至上命令ですか？
揚げ足をとるのをとってみる (スコア:0)
つまり至上命題は間違った日本語ですよってことが言いたいようです
http://www.sankei.com/life/news/150222/lif1502220004-n1.html [sankei.com]
Re: (スコア:0)
社会人にとっては業界用語みたいなものだから、
辞書に載っていないので間違いと言い切れるものでもないのでは。
適切な用語がないから新語が生まれてくる。
実社会では何事も正/誤で割り切れないことも多いものなのです。
Re: (スコア:0)
いや誤だろ
自分の無知をひけらかすことになるんだから、今指摘されててよかったんじゃねーの
Re: (スコア:0)
それは仕方がありません。
交通にしても料理にしても工場にしても建設現場にしても、安全を確保した上で仕事をしているわけで。
もし安全のためのチェック処理のほうが多くなっても、それが必要なものであれば省略してはいけません。
それが自分自身のためでもありますし、客のためでもありますし、職業倫理でもあります。
法律の縛りがあるかないか、という差はありますが。
Re: (スコア:0)
「それが必要なものであれば」の判断が難しいのだと思うよ。
判断が難しいので、安全に倒して冗長だろうがなんだろうが全てチェックし始めて、
privateメソッドの引数や戻り値も疑ってチェックコードだらけになり、
使用しているライブラリの結果も疑い、最終的にチェックコードを書くのを面倒になった結果、
メソッド分割もせず、外部ライブラリどころか標準ライブラリすらほとんど使用しなくなり、
スパゲッティ大盛りな超巨大メソッドになったものを、なんとかしてくれと依頼されるわけです。
# そこまでしてチェックコードを書くのに、ユニットテストはやらない不思議
Re: (スコア:0)
実時間処理でそんな面倒なことするなんて想像も出来ない
我が社ではそのような場合、バッファは常に非ゼロの有限値（疑似乱数等）で初期化
割り算は常に分母に微少な定数を加えてから計算
時間がもったいないから、いちいち余分なチェックなんてしない
Re: (スコア:0)
定数を加えるコストと
ゼロ条件分岐のコストが
極端に違うならもったいないと言えるかもだが
イミディエート値のロードと、レジスタ値の0チェック比較したら
(たぶん除数は既にレジスタにロードされてる)
定数加算の方がコスト掛かると思う
比べてみた?
Re: (スコア:0)
元ACじゃないけど、ふつう定数のロードはループの外にあるから、
レジスタが十分にあるなら無視してもよいコストでは？
とすれば、0と比較する分無駄は多いと思うけど。