何らかの形でコンピュータに関わっていれば計算誤差については解りきった事だけれど、一般の人には理解しずらいらしい。無理数と勘違いすることが多くて、こちらとしても面倒くさいのでそのまま放置している。一般事務で無理数なんか使わない。消費税等料率が関係してくる場合に発生するが都度丸める(円未満切り捨て、切り上げ、四捨五入のいずれか、消費税の場合はいずれかを一度選択したら以後変更できなかった、はず)ので、冷静に考えれば気がつくと思うのだけれど。

 

コンピュータでの内部表現に基づくので、例えば整数しか扱わないのなら結構な数まで問題ない。厳密にはBCDにしてきちんと管理すれば良い(とはいえいつか誤差は生じるので本質的な解決にはならない)のだけれど、処理が重くなることと、実は2進のままでも問題無いかのようにごまかせるので余り積極的に採用されないようだ。最初からBCDにしていたのはポケコンに搭載されていたBASICくらいか。

 

いずれにせよ桁数の管理は利用者で責任を持たなくてはならないし、そのためには計算機の挙動を理解する必要があるので、ちょっと調べてみました。

 

実行環境は Thinkpad R500(CPU core2duo),OSはLinuxMint17.3(amd64, xfce)です。

 

例題は1.2から1.1を引いて差の0.1を求める、というもの。そして、求めた差のコピペをどのように扱うか、です。

 

 

Libreoffice5.3のcalc


一見正しく計算しているように見えますが、計算結果(D)のコピーで馬脚を現しています。内部的に誤差を抱えたままで表示の際に丸めているようです。

 

 

gnumeric 1.10.17


gnumericの旧バージョン、gtk2時代の最終版です。
これはちょっと分かりにくいです。計算結果(D)の時点で誤差を表示していれば話は簡単なのですが、そこでは見かけ上丸めておいて、後段の計算(C-D)では誤差を含んだまま計算しています。さらに、値のコピペは丸めた後の値を持ってきています。表が大きくなった場合、誤差がどこで生じたか見つけるのが大変そうです。

 

 

Googleスプレッドシート

Libreofficeと同じ。誤差どうのこうのより、手元の環境ではレスポンスが悪くて使う気になりません。

 


Python2.7


これはちょっと考えものです。生で表示すると誤差あり、printを通すと誤差丸め、当然丸めきれないこともある、さらに書式指定だと桁数が不足して符号だけ示して終わる、もうバラバラです。いろいろできるようにしておいたからユーザーの責任で選んで使え、ということでしょうか。

 

 

Lua5.1.5


Python2.7と同じですが、結果を表示するにはprint()を要するので混乱は多少緩和されています。

 

 

Python3.4.3


自分では使わないのだけれどインストールした何かが使っているのか、HDDに存在するので試してみました。これは流石に首尾一貫しているようです。

 

 

Processing 3.3.3


インストールしたはいいが、まったく使っていないProcessingです。Pycairoに辟易しているのでいい加減こちらに移動したいのですが。
折角なのでコンソールではなくてウィンドウに表示してみました。nfの使い方を間違えたのか、誤差の様子が他と違うようです。
「浮動小数点(float)は小数点以下4桁くらいまで精度が保たれます。」(※)と明確にされていますのでこれで問題ないと言えます。

 

 

しかし、結構な金額を出して買ったPCが小学生でも間違えないような引き算を(事情はどうあれ)間違えるというのは情けないですね。

 

 

 

 

※Processingをはじめよう第2版 オライリー・ジャパン / オーム社 p227(Processingクイックリファレンス - データ型)

Comment





   

Search

Calendar

S M T W T F S
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< December 2017 >>

Archive

Mobile

qrcode

Selected Entry

Link

Profile

Search

Other

Powered

無料ブログ作成サービス JUGEM