アカウント名:
パスワード:
> ゼロ除算発生時に「0」を返す
よりもバリデーションでゼロ除算を発生させない方向には向かえないんですかね？
>ゼロ除算のチェックに疲れ果てたからでは?
> >ゼロ除算のチェックに疲れ果てた> からでは?
どんなシステムかはわかりませんが、入力値のバリデーションがチェックに疲れるほどあるシステムに問題がありますね。
もうつくっちゃったから仕方がないのですかね？
計算の途中で０になるケースもあるだろうし、入力値とは限らないと思うが。計算式を全部関数化してしまえというのであれば、入力値の確認だけですむけどそれはそれでどうなんだろう・・・。
ただポインタのNULLチェックのほうがはるかに面倒な気がするけど。関数のほとんどがNULLチェックで、肝心のロジック自体は１～２行というのを良く見るわ。
計算の途中で０になるケースもあるだろうし、入力値とは限らないと思うが。
ないでしょ。計算したら0になってその値で割るなんて。
いやいや、いくらでもあるでしょう。プログラム中割り算なんていくらでも使うし、その割る数が入力値じゃないケースの方が圧倒的に多いし、それが理論上0になる可能性がある場合なんていくらでもあるでしょう。例えば実行件数を時間の差分で割る場合とか、時間の差分はOSの時刻を変更されたら0になることだってあり得ますよね？
> 例えば実行件数を時間の差分で割る場合とか、> 時間の差分はOSの時刻を変更されたら0になることだってあり得ますよね？もう考え方が違うのかな？なんのために0や1で割るのかですよ。意味のない計算は通さないか結果を返すようにしてしまうので。
それも仕様次第でもありますが、コーダーの経験次第でもあるかな？
システムが一つとは言ってないのでは？
「コーディング規約で除算前に0チェックすることが強制されていて、そうしないとレビューで弾かれる」みたいな状況かと。
# これに「仕様や要件では0除算時の動作が考慮されていない」が加わると悲惨なことになる
例外を投げてくれるから(間違った結果を抱えたまま突っ走ることがないから)こそ手抜きしたいときはチェックをサボれるのに、なんかもうこの時点で発想が正反対。「MS-DOSでは無造作にポインタアクセスしても終了時に変なメッセージが出るくらいで何も実害なかったのにWindowsやUNIXは不正な処理だのコアダンプだのウザい」とか思ってるんだろうか。
問題があるとしたらデバッグが面倒くさいことの方で、0除算を見つけることじゃないよねぇ。
こういう人は他人のコードをコピペする時にきっちりバリデーションしてるか確認するのをサボるでしょう。
この人は、そのうち入力値のセキュリティチェックに疲れ果てた、とか言い出して、脆弱なソフトウェアを作ってしまうのでは。
パスワードを入れて面倒なUIを使うのに疲れはてるとデータをローカルのエクセルに入れてしまう。
単純な（おばかな？）対処法↓x/y や log(x) を計算するときは常に x/(y+C) や log(x+C) とする（Cは微小な定数）x の値が微小だった場合の演算精度が問題にならない数値計算ではそうやって問題を回避してる
そもそも教科書に載ってる理論的なアルゴリズムの数式からして x/(y+C) になってたりする再帰的な処理をする都合で、絶対途中で発散させたくないから教科書からしてそうなってるのよ（まあ、分野にもよるだろうが）
y==-Cである可能性はないのでしょうか？y!=-Cをチェックするならy!=0をチェックする手間と変わらんですよね？
まあ数値計算対象なら C > 0 で、 y > 0 とか、収束条件が abs(y) C とか、何らかの条件がある場合のやり方だね。
いつも同じやり方が正解にはならいので、場合によって様々なやり方を選択すれば良い。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
仕様次第かな？ (スコア:2)
> ゼロ除算発生時に「0」を返す
よりもバリデーションでゼロ除算を発生させない方向には向かえないんですかね？
Re: (スコア:0)
>ゼロ除算のチェックに疲れ果てた
からでは?
Re:仕様次第かな？ (スコア:2)
> >ゼロ除算のチェックに疲れ果てた
> からでは?
どんなシステムかはわかりませんが、
入力値のバリデーションがチェックに疲れるほどあるシステムに問題がありますね。
もうつくっちゃったから仕方がないのですかね？
Re: (スコア:0)
計算の途中で０になるケースもあるだろうし、入力値とは限らないと思うが。
計算式を全部関数化してしまえというのであれば、入力値の確認だけですむけど
それはそれでどうなんだろう・・・。
ただポインタのNULLチェックのほうがはるかに面倒な気がするけど。
関数のほとんどがNULLチェックで、肝心のロジック自体は１～２行というのを良く見るわ。
Re: (スコア:0)
計算の途中で０になるケースもあるだろうし、入力値とは限らないと思うが。
ないでしょ。
計算したら0になってその値で割るなんて。
Re:仕様次第かな？ (スコア:2)
いやいや、いくらでもあるでしょう。
プログラム中割り算なんていくらでも使うし、その割る数が入力値じゃないケースの方が圧倒的に多いし、それが理論上0になる可能性がある場合なんていくらでもあるでしょう。
例えば実行件数を時間の差分で割る場合とか、時間の差分はOSの時刻を変更されたら0になることだってあり得ますよね？
Re: (スコア:0)
> 例えば実行件数を時間の差分で割る場合とか、
> 時間の差分はOSの時刻を変更されたら0になることだってあり得ますよね？
もう考え方が違うのかな？
なんのために0や1で割るのかですよ。
意味のない計算は通さないか結果を返すようにしてしまうので。
それも仕様次第でもありますが、コーダーの経験次第でもあるかな？
Re: (スコア:0)
システムが一つとは言ってないのでは？
Re: (スコア:0)
「コーディング規約で除算前に0チェックすることが強制されていて、そうしないとレビューで弾かれる」みたいな状況かと。
# これに「仕様や要件では0除算時の動作が考慮されていない」が加わると悲惨なことになる
Re: (スコア:0)
例外を投げてくれるから(間違った結果を抱えたまま突っ走ることがないから)こそ手抜きしたいときはチェックをサボれるのに、なんかもうこの時点で発想が正反対。
「MS-DOSでは無造作にポインタアクセスしても終了時に変なメッセージが出るくらいで何も実害なかったのにWindowsやUNIXは不正な処理だのコアダンプだのウザい」とか思ってるんだろうか。
Re: (スコア:0)
問題があるとしたらデバッグが面倒くさいことの方で、0除算を見つけることじゃないよねぇ。
Re: (スコア:0)
こういう人は他人のコードをコピペする時にきっちりバリデーションしてるか確認するのをサボるでしょう。
Re: (スコア:0)
この人は、そのうち入力値のセキュリティチェックに疲れ果てた、とか言い出して、脆弱なソフトウェアを作ってしまうのでは。
Re: (スコア:0)
この人は、そのうち入力値のセキュリティチェックに疲れ果てた、とか言い出して、脆弱なソフトウェアを作ってしまうのでは。
パスワードを入れて面倒なUIを使うのに疲れはてると
データをローカルのエクセルに入れてしまう。
Re: (スコア:0)
単純な（おばかな？）対処法↓
x/y や log(x) を計算するときは常に x/(y+C) や log(x+C) とする（Cは微小な定数）
x の値が微小だった場合の演算精度が問題にならない数値計算ではそうやって問題を回避してる
そもそも教科書に載ってる理論的なアルゴリズムの数式からして x/(y+C) になってたりする
再帰的な処理をする都合で、絶対途中で発散させたくないから教科書からしてそうなってるのよ（まあ、分野にもよるだろうが）
Re: (スコア:0)
y==-Cである可能性はないのでしょうか？
y!=-Cをチェックするならy!=0をチェックする手間と変わらんですよね？
Re: (スコア:0)
まあ数値計算対象なら C > 0 で、 y > 0 とか、収束条件が abs(y) C とか、何らかの条件がある場合のやり方だね。
いつも同じやり方が正解にはならいので、場合によって様々なやり方を選択すれば良い。