3.正しさを追ってみる(計算編)
前章ではコンピュータの原理に基づく数値の取り扱いについて学びました。あくまで単体の数値とちょっとした軽い計算に終始しましたがここではもう少し計算の幅を広げて正しさを追ってみます。
正しい計算というものをまず疑ってみたいと思います。
普段の紙面上で行われる純粋な数学的計算であればシンプルと言えます。等号で結ばれた式は常に前後のどちらからでも行き来が可能で、シンプルながらに強烈な意味を持つものであったりします。
一方この紙面上のものでもプログラムでも一部においてはこの可逆性が破られるものがあります。
分野によって数多くあるのは事実ですが、一つの例としては四捨五入を計算仕様として含むものです。
これは一方向のみの計算が可能で常に上流から下流に向けて下るしかない計算になります。
使用されている分野を例示するというのは難しいものがありますが一つには税金関連があります。
○○を計算する際には小数点何桁を四捨五入、あるいは切り捨てなどの計算に関する規則が法律として、あるいはもう少し下位に位置する通達として定められています。こういった計算では処理がなされた後の数値からは前の数値に戻るということは絶対に出来ません。
仮に前の数値も以降の計算で常に保持し続けるようなプログラムも組めなくはないですがあまり効率や意味があるとは思えません。
このように純粋に数学的に可能な計算とは異なる仕様を前提に計算や処理が行われるというケースがある以上正しさを通常の計算と同様に考えるのは少し危険です。
もちろん通常と同様に出来るケースも存在しますがすぐに述べる例によって危険が取り除かれるわけではないことをご記憶願います。
このような特殊な処理に関しては通常文書などの形でその詳細を記載してプログラムの使用者と作成者で合意を計ります。 このあたりの話は先の章に書くことにします。
さて特殊な仕様を最初から考えることがあるというのはわかりましたが、そうでない場合にそこまで気を付ける必要があるのか、ということを考えてみましょう。
前章での話を少し思い出しで頂きますと、コンピュータはその性質、特に数値を記憶するという方式の点からある程度以上大きなもの、小さなものは扱えないという話をしました。
ではもしここでその条件はクリアしているものの、そこそこに大きな数とその数にかなり近いがちょっとだけ小さい数を考えてみましょう。ここではちょっとというのは小数点以下のレベルで違っているものとします。
この時に大きさの差によっては問題が発生します。何を言っているのかを理解するためもう一度コンピュータの性質を今度はより深めにお話します。
通常コンピュータで数値の記憶を行う際には、正負の区別の為の記憶領域を先頭にして、仮数と桁数の形で記憶が行われます。
この表記は、1.23456*10^5という形であり先頭の方を仮数と呼びます。またこの形で表す時に仮数の小数点以下の数字の数が有効数字の桁数となります。この時に近しいが少しだけずれているという数値を次の二つで考えてみます。
1.234*10^5, 1.233*10^5この二つの差はどうでしょう。
単純に比較すると0.001*10^5で少し整理すると、1*10^2となります。これは特に誤表記ではなく、計算前には有効数字が3桁あったものが計算後には0まで落ちてしまったということです。
これは元々の数値の記憶の仕方で一番小さな値が差を取ったことで表記上一番大きくなってしまうという問題です。
本当なら最初からその分を見越して余分に有効数字を取るというのも手段ですが最初から予想しておくのは全く知識がないと酷でしょう。
このように近しい値で少しずれているという数では悪さが起きる可能性があるということです。
これをさらに巧みに拡張したものとしてRumpの例題と言うものが在ります。
これは相当に小さいはずの数が計算が繰り返されることでそのずれを増幅し最後にはとんでもないズレ方になるという事例になります。
ただしこれは非常に厄介なことにその知識が有って少し調整しただけでは解決する問題ではなく、もうちょっとを要求されるものとなっています。そういったところに技巧が光ります。
本来はこのようなシビアな計算の管理だったり問題を思考することは稀で、通常の業務においてはむしろ気にしないという人も多いかと思われます。
これらの問題を気にしなくてはいけないのは初期の設計と試算の段階で、特に数値ミスのずれが許されない金融領域などの領域です。
私自身の経験に基づくものであれば、通常金融の計算では基準として1という金額での時価等を計算します。これにより通貨や大小どのような金額でも最終結果にただ掛算をすることが出来るため効率的な処理ができます。ただしその反面掛算する金額は1億や100億などかなり大きな桁になるため、10^8などが頻繁に出現することになります。
こういった計算が多いということはそれだけ時価の出力も精度を上げる必要があり、もし厄介な計算がありそうであればその影響の見積もりや検証を行う必要にも至ります。
運がいいことに私自身はそこまでシビアな要求があったことはありませんが起こりうる事例とは考えております。
さてこのような事例が存在しうるということを知っていただいた以上、かつて言われていたようなエクセルでの計算結果を電卓で確かめるという操作が決して非難されるものではないということを言っても大丈夫でしょう。
エクセルはそのセル範囲に対して種々の関数を設定し計算が可能という特徴からユーザーにとってかなり自由度の高い計算設定ができます。
問題はこれを職場で使った際に意図せず変な操作が行われてしまうこと、加えて(昔は)信頼性も疑うという点から電卓でのチェックが行われていたものと推察します。
前者は関数の参照範囲がズレてしまったり、そもそも計算されていないと言ったミスが考えられるほか、後者では何かしらの理由で数値の四捨五入等を行う際にはそのタイミングと処理内容の入力ミスがないかという問題があります。
さらにある程度より前のバージョンでは一部計算にバグがあったこともあり再検証の必要性がありました。
検証ではさすがにもう一度同じエクセルで、というのも憚られることから諸々あり電卓になったものと考えます。
今でこそこのような問題もあまりなく、そもそもの信頼性も上がっていることから電卓チェックの必要性は下がったかもしれません。しかし未だ旧バージョンだったり拡張子が.csvとなっているcsvファイルでは無視できるものではありません。
特にcsvファイルはデータの書き出しや読み込みに便利なため使われることがありますが、通常のエクセルファイルである.xlsxファイルに比較したときに情報が落ちてしまうという懸念があります。
これは.csvファイルで大きな数を上記の仮数と指数での表記に置き換えて表記するというものであり安易に選択すると一定以下の桁の数が全て0となってしまいます。
それで計算上問題ないというある程度荒っぽい計算なら良いのですが、請求書などを作成する際には致命的な問題になりえます。
