ゼロ除算についてあらためて考える

小学生の頃だったろうか。「10 をゼロで割るとどうなるか？」という先生の質問に悩んだことがある。友達のひとりは「割り切れない」と答え、私はわけもわからずに関心した。

しかし、結局、正解は「ゼロで割り算をしてはいけない」というものだった。そんな問題出すんじゃないよ！　これでは、「割り切れない」ではなく「やりきれない」ではないか。

★

普通の生活で、ゼロでの割り算をしなければならないような状況はないので、そんなことを気にする人は少ないかもしれない。しかし、プログラマにとって、ゼロ除算の回避は常識である。

プログラムがゼロ除算をすれば、その時点でエラーを出して異常終了してしまう。このため、プログラマが割り算を「書く」場合には、割る側の値（除数）がゼロにならないように、細心の注意を払う必要がある（※１）。簡単そうに思われるかもしれないが、除数が変数だったり関数の戻り値だったりすれば、なかなか大変なのである。

★

さて、そもそも「ゼロで割り算をしてはいけない」理由はなんだろうか。簡単な数字の計算なのに。

プログラミングの世界でよく目にする説明は、「ゼロ除算の結果の値は無限大（負の場合はマイナス無限大）になり、扱いきれなくなるため」というものだ。割り算では、除数が（正の数なら）小さくなるほど答えは大きくなるのだから、除数が０なら答えは「無限大」になるというわけだ。確かに、一般的にプログラムで扱う数値は有限（例えば、Ｃ言語の int なら INT_MIN～INT_MAX）なので、無限大は表現できない。

プログラマとしての理解はそんなところで十分かもしれない。私もその程度に考えていたが、今まで特に不都合はなかった。しかし、厳密には、これでは説明になっていないらしい。

★

調べているうちに、分かりやすい資料を見つけた。∫Integral Interval∫ さんの「０で割ってはいけない世界」（PDF）である。

資料によれば、そもそも「無限大」は数ではない。数だとすると、「無限大＋１」という計算ができるはずだが、その時点で、無限大より大きい数が出来てしまうことになり、おかしなことになる。「無限大」は数ではなく「状態」だというのだ（※２）。

また、割り算の除数を正の数からどんどん小さくしていけば、答えはどんどん大きくなるが、逆に負の数から大きくしていけば小さくなる。つまり、除数がゼロになった時点で、答えは「プラス無限大」であると同時に「マイナス無限大」でもある、というおかしなことになるのだ。

つまり、「無限大」という得体の知れない言葉では、説明したことにならないというわけだ。では、どう説明すべきか・・・ということについては、上記資料を参照いただきたい。結局のところ、ゼロ除算を認めるとゼロ以外の数が扱えなくなってしまうということらしい。

確かに、無理やりゼロ除算の答えを出そうとすると、矛盾が発生する。例えば、仮に「１÷０＝ａ」とすると、「１＝ａ×０」が成立するはずだが、ゼロは何に掛けても０なので、「１＝０」となってしまうのである。

★

普段、何気なく順守してきた「ゼロ除算禁止のルール」だが、調べてみると奥が深かった。学生時代に文系であった私は、数学的知識は少ない方だ。今になってその面白さの一端に触れた気がする。

← このブログを誰かに読ませたいと思った方は、クリックを

※１
設計の時点で考慮されていればよいが、そこまでの細かさを期待できない場合が多い。

※２
例えば、データベースの「NULL」が数ではなく状態であるのと同じことだろう。

■関連記事
・五捨五入
・切捨て御注意

■リンク
・ゼロ除算【divide by zero】（e-Words）
・ゼロ除算（IT用語辞典バイナリ）
・数学の美しい世界へ（∫Integral Interval∫ さん）
・「a÷0」がいけない訳。（しらぎくさいと。さん）
・なぜ０で割ってはいけないのか / １÷０ / 何で0で割っちゃいけないんだ？（2ch）

異端の数ゼロ―数学・物理学が恐れるもっとも危険な概念

posted with amazlet on 06.01.01

チャールズサイフェ Charles Seife 林大
早川書房 (2003/10)

おすすめ度の平均:

[アリストテレス＆キリスト教]vs[ゼロ概念]の話が面白かった

とてもおもしろい！

不思議な数「0」の魅力に魔力

Amazon.co.jp で詳細を見る

プログラマの数学

posted with amazlet on 06.01.09

結城浩結城浩
ソフトバンククリエイティブ (2005/03/24)
売り上げランキング: 4,427

おすすめ度の平均:

文系の方向けの良書

文系プログラマにはよい

「情報工学をかじったことのないプログラマ」向けの本

Amazon.co.jp で詳細を見る

五捨五入

「四捨五入」といえば、読んで字のごとく、桁を丸め込むときに端数が４以下なら切り捨て、５以上なら切り上げることである。同様に、「五捨六入」は５以下を切り捨て、６以上を切り上げる。

では、「五捨五入」とは何だろうか（※１）。これは、端数が４以下なら切り捨て、６以上なら切り上げ、５なら結果が偶数になるように切り捨てたり切り上げたりするというものだ。例えば、3.5 を五捨五入して整数に丸めると 4 になるが、2.5 だと 2 になる。つまり、「最も近い偶数に丸める」という計算方法なのである。

この方法は、ISO 31-0:1992 や JIS Z 8401:1999、IEEE 754 で数値を丸める標準的な方法として規定されている（※２）。例えば、VB の丸め込み関数 Round() などは、そのような動きをする。

我々は普段、四捨五入には慣れ親しんでいるが、五捨五入についてはそうでもない。しかし、五捨五入の方が誤差が少ないため、システムの要件としては、好まれることもあるようだ（※３）。

★

こうした微妙な計算方法の違いが、不幸なバグを生むことは多い。

例えば、四捨五入をするつもりで、「標準」の丸め込み関数を使って、痛い目にあったという話はよく耳にする。

あるいは、仕様書などに「四捨五入せよ」と書いてあったが、実際には五捨五入すべきだった、といったケースもある。

学校で学んできたような一般的なやり方が、どの業界でも一般的（標準的）だとは限らない。そのことを端的に示したよい例かもしれない。

← このブログを誰かに読ませたいと思った方は、クリックを

※１
「銀行型の丸め」と言った方が通りがいいだろうか。他にも、「偶捨奇入」、「偶数への丸め」、「JIS丸め」など、いろいろな呼び方がある。なお、JIS規格に従えば、単に「丸め」と言ったら、五捨五入のことを指すようだ。

※２
こちらのページによると、JIS規格では、五捨五入が「規則Ａ」、四捨五入が「規則Ｂ」として規定されていて、特に明記されていなければ、規則Ａを使うこととされているようである。また、「切捨て御注意」に書いたような、負の数の問題については、「絶対値にしてから適用する」とされているようだ。JIS Z 8401:1999 の原文は、JSA Web Store から PDF を購入することが出来る。

※３
5 は 0 と 10 の中間に位置するのだから、切り上げと切り捨てを平等に行うほうが誤差が少ない。例えば、3.5 + 2.5 は 6.0 だが、四捨五入後に加算すると、4 + 3 = 7 と１大きくなる。五捨六入だと、3 + 2 = 5 で逆に１小さくなる。五捨五入なら 4 + 2 で、ぴったり 6 だ。誤差の問題だけでいえば、奇数に丸めてもいいのだが、0 を基点に考えたほうが分かりやすいから、偶数に丸めるのだろう。

■関連記事
・切捨て御注意
・ゼロ除算についてあらためて考える
・曖昧言葉

■リンク
・端数処理（ウィキペディア）
・油断ならない四捨五入（「株式会社データアクション」さん）
・[.NET] 四捨五入 (「biac のそれさえもおそらくは幸せな日々」さん)

Excelで遊ぶ手作り数学シミュレーション

posted with amazlet on 06.04.03

田沼晴彦
講談社 (2004/01/21)
売り上げランキング: 41,420

おすすめ度の平均:

エクセルのもう一つの使い方！

文系にこそ

パソコンに眠っているEXCELを使いこなそう

Amazon.co.jp で詳細を見る

プログラミングのための線形代数

posted with amazlet on 06.04.03

平岡和幸堀玄
オーム社 (2004/10)
売り上げランキング: 3,237

おすすめ度の平均:

最高

ビジュアル系

線形代数の概念を徹底的に解説した本

Amazon.co.jp で詳細を見る

バグの気持ち

バグはプログラマの盲点を突いてくる。自分の作ったプログラムがそんな動きをするなんて！　と、バグが出て初めて気がつくのだ。あまりの巧妙な手口に、「バグには意思があるに違いない」などと思ったプログラマもいるのではないだろうか。

ところで、グレムリンというモンスターをご存知だろうか？　同名の映画で知っているという人も多いと思うが、元々は、飛行機などの機械の周りに出没して、それらを故障させる妖精である（イギリス空軍で見つかったらしい）。また、そこから原因不明の機械の異常を GE（Gremlin's Effect）と呼ぶようになったとか。

これはソフトウェアのバグに似ている。バグ（虫）の元祖は、コンピュータの中に入り込んで回路を遮断してしまった蛾である（アメリカ海軍で見つかったらしい）。蛾は妖精の化身だとか、人の魂だとかいわれることもある。だとすれば、意思があってもおかしくはない。プログラマのミスを自分のせいにされて怒っているのだろう。

★

などと言ってはみたものの、バグが人間の盲点を突いてくるのは、当然である。システムの開発中に、考えうる全てのケースをテストしたのであれば、残ったバグは必然的に盲点を突いたものになるからだ。

ソフトウェアの品質が上がれば上がるほど、バグは突然に予想外の形で現れる。だからこそ、人々は、驚き、感心し、怖れ、そこに意思の力すら感じるのだろう。

逆に、品質管理が杜撰であれば、「なさけないバグ」ばかりが頻発する。とてもではないが、バグに意思の力を感じるようなことはないだろう。

★

グレムリンは、実はとても機械が好きで、人間の発明を手伝って技術の発展に貢献してきたそうだ。しかし、人間は自分達だけの力でやったと思っていて、彼らに感謝しなかった。だから、怒って機械を壊すのだそうだ。

我々も、バグの重要さを忘れてはいないだろうか。「バグが出ました」→「直しました」で終わってはだめだ。バグをよく分析し、開発方法の改善に努めなければ、次も同じバグを出すことになる。

バグをありがたく受け止め、感謝することがなければ、ますますバグの怒りを買うことになる、というわけである。

クリックお願いします →

■関連記事
・怖いこと
・「バグ」の使い方
・オブジェクトの気持ち

いつまでバグを買わされるのか―平気で欠陥商品を売る業界の内幕

posted with amazlet on 06.05.03

マークミナシ Mark Minasi 植木不等式
ダイヤモンド社 (2000/09)
売り上げランキング: 189,598

おすすめ度の平均:

ソフトウェア生産者にも

Amazon.co.jp で詳細を見る

グレムリン特別版

posted with amazlet on 06.05.03

ワーナー・ホーム・ビデオ (2006/04/14)

Amazon.co.jp で詳細を見る

曖昧言葉

「ブランク（blank）」とは、「空っぽ」だとか「空白」といった意味だ。コンピュータ業界でもよく使われる言葉ではあるが、厳密に定義せずに使っていると、誤解が生じることがある。

例えば、「文字列がブランクである」というだけでは、意味がはっきりしない。ブランクを「空っぽ」と考えれば「長さ０の状態（""）」だが、「空白」と考えれば「半角スペースで埋まっている状態（" "）」かもしれない。場合によっては、スペースだけでなく、「タブ」も含める場合もあるだろう。

コンピュータ業界の言葉というと、厳密に定義されているように感じる人もいるかもしれない。しかし、実は意味が曖昧なものも多い。

もうひとつの例は、「シフトJIS」である。「シフトJIS」は文字コードの一種だ。この言葉が使われる場合、本来のシフトJIS（SJIS, Shift_JIS）ではなく、マイクロソフト独自のコードである「CP932, Windows-31J）」を意味することが多いのだ。SJIS と CP932 は微妙に違っており、間違えると一部の文字が文字化けする。「文字コードはシフトJISで」などと言われたら、注意したほうがよい。

曖昧な言葉が何の説明もなく使われると、当然、誤解が生じやすく、バグの原因ともなる。曖昧な言葉はなるべく使わないようにすべきだ。使う場合は、意味をきちんと定義したり、補足するようにしたいものだ。

もちろん、そのためには、それぞれの言葉をよく理解することが必要である。

プログラマという仕事をしていると、新しい言葉に出会う機会も多いだろう。自分の経験から何かを学ぶことは重要なことだ。しかし、「用語」に関していえば、出会ったときの文脈だけを元にして覚えるのではなく、改めて意味を調べてみることも大切だろう。

クリックお願いします →

■関連記事
・コンピュータに興味がないプログラマ
・タブ区切りのCSV？

曖昧性とのたたかい―体験的プロジェクトマネジメント論

posted with amazlet on 06.05.03

名内泰蔵
翔泳社 (2005/03)
売り上げランキング: 48,531

おすすめ度の平均:

学んだこと

やっと登場

使いこなすべき本

Amazon.co.jp で詳細を見る

2006-'07年版 [最新] パソコン用語事典

posted with amazlet on 06.05.03

大島邦夫堀本勝久
技術評論社 (2005/10/01)

Amazon.co.jp で詳細を見る

うちの社員は信用できません

情報セキュリティの強化ということで、会社に私物のノートパソコンを持ち込めなくなってからしばらく経つ。おかげで、ブラウザの「お気に入り」や、アプリケーションの設定など、自宅と会社のパソコンで、全て２重管理しなければならない。もちろん、ライセンス上、１台にしかインストールできないソフトは、どちらかでしか使えない。私のように、趣味と仕事が重なる部分が大きい人間にとっては、これは非常に面倒だ。

別の会社では、「USB メモリ」を含め、フロッピーディスクや CD-R のようなリムーバブルメディアへの使用（書き込み）が禁止になったところもある。専用のソフトウェアを導入して、書き込めなくしているようだ。これも、業務内容によっては不便なことだろう。

一般に、セキュリティを高くするほど、仕事の効率は悪くなる。どの程度の厳しさをもって、セキュリティポリシーを設定すべきかは難しい問題である。

★

企業にとって、セキュリティ対策を施すことは、対外的なアピールの意味もあるようだ。「我社の情報セキュリティは万全です。安心してお任せください」というわけだ。

しかし、あまりに厳しい対策をしている会社を目にすると、「おたくの社員はそんなに信用できないのか？」と思ってしまう。

★

セキュリティ意識の低さや不注意による情報漏洩を防いだり、悪意のある者（モノ）が外部から侵入してくるのを防いだりするためには、ルール作りや社員教育、システム的な防御は有効だ。

しかし、内部の人間が悪意を持っている場合の対策は難しい。「信用している者に裏切られる」というリスクに対して、いったいどんな対策ができるというのだろう？　誰も信用しない？　そんなことは無理だ。どんな組織や社会も「信用」を前提にしなければ、成立しない。

本気で情報セキュリティを考えるならば、どうしても「信用できる人間を育てる」というところまで考えざるをえない。もちろん、それは、人事や契約といった企業の問題にとどまらず、貧富の格差、子供の教育（躾け）といった社会全体の問題にまで至る。

もちろん、そこまでいくとシステム屋として考える範疇ではない。しかし、本来、仕事とは関係なく、誰もが考えるべきことのはずである。考えない人が増えたからこそ、信用を裏切ってまで「情報」を金に換えるような大人が増えているのではないだろうか。

クリックお願いします →

■関連記事
・セキュリティを確保せよ