なぜ多くの言語で簡単に数値計算が出来ない？ なぜいまだにCOBOL？

Question

なぜ、いまだに多くのプログラミング言語で、intがどうのdoubleがどうのとかで「近似値です」とか「金融計算には気を付けましょう」とか「小数点以下の計算は正しくありません」とかの問題が解決されないんでしょうか？

言語仕様レベル、あるいはせめて標準組み込みライブラリのレベルで、「金融計算、数値計算が普通に誰でも簡単に正しく出来る」言語があっても良さそうなのに、なぜいまだにそれが存在しないのでしょうか？　なぜいまだにいちいち「気を付けて計算」しないと誤差が発生する状態が放置されているのでしょうか？

いまだに「まだその辺の計算はCOBOLでやる価値がある」みたいな状況っておかしくないですか？　整数の計算を正しくやるとか、人間の感覚で言うところの「正しい小数の計算」とかって、そんなに実現が難しい話なんでしょうか？

質問の要点をまとめますと、多くのプログラミング言語において、。コンピュータ知識や言語仕様に詳しくない人間でも、金利計算などの数値計算で普通に「人が期待する結果」を簡単に出せる仕様にならないのはなぜか？です。

Comments

[BeatStar]

多分ですけど、ハードウェアレベルの問題だからじゃないかなと。

float型とかの誤差とかがそうですし。
ざっと検索した結果、https://osakanav.com/basic-information-series-that-anyone-can-understand-9%EF%BC%8D-fixed-point-display-floating-point-display とかがヒットしました。
これらによると、32ビットでは 1 + 7 + 24 ビットの並びで構成されているようです。
それぞれの範囲で表現できないとかで誤差が生じるっぽいですね。

となると、Windowsであれば 32ビット版 -> 86ビット版 のようにOSレベル(いやハードウェアレベル?)でどうこうしないと対応できないのではないでしょうか。

[fana]

人が行う計算の多くは「近似値」でも事足りるから　では？

[YAmaGNZ]

適切な型を使ってないだけでは？Decimalなりあるでしょうに

[Zuishin]

> まだその辺の計算はCOBOLでやる価値がある

どういう意味か説明してください。

[退会済みユーザー]

＞YAmaGNZ
Decimal型がある言語はまだいいけど、PHPとか用意されてない言語がいまだにあるのはなぜかな？と。
多くの人がこの誤差に苦しみ、それの解決ノウハウがネットで蓄積されてる。だったら言語仕様で解決すればいいのに、なぜしないの？と。それを処理系に実装するのがそんなに大変なことなのかな？っていう疑問です。

[Zuishin]

ていうか、お前 teratail_dayo だな。
この間大量に凍結されたのにまだ残ってたのか。

[退会済みユーザー]

＞fana
多くの場面で近似値では困るから「小数の計算に気を付けましょう」というようなノウハウ記事がネットにあふれているのでは？

[otn]

> あるいはせめて標準組み込みライブラリのレベルで、
メジャーな汎用の言語だと、大抵DecimalとかBigDecimalといったライブラリがあると思います。
言語仕様レベルでサポートする言語は無いのか？という指摘はもっともですが。

[退会済みユーザー]

＞otnさん
そうですね、ライブラリで用意されていることは多いようです。
でもおっしゃる通り、intとかfloatとかと同列レベルでDecimal型があってもいいのに、なぜないの？という素朴な疑問です。

[otn]

お金計算に特化した、原則十進演算の言語があってもいい気がしますね。
汎用言語で、2進浮動小数点計算も、多倍長十進演算も、どちらもシンプルに書けて、効率よく処理できる言語の設計は難しそうです。PL/Iという先達はいますが。

ただ、十進演算でも割り算が入ると（割り切れない場合に）誤差が発生するので、どこまでうれしいかはよく考えないと。

[jimbe]

> 整数の計算を正しくやるとか、人間の感覚で言うところの「正しい小数の計算」とかって、そんなに実現が難しい話なんでしょうか？

難しい話なんでしょうね。近似値で困ってないので知りませんが。

[退会済みユーザー]

＞近似値で困ってないので

近似値で困ってない！？　逆に普段どんなものを開発してるのか知りたいですね・・・
たとえば身近な消費税の計算とかでも問題起きたりするのに。

[退会済みユーザー]

＞otnさん
お話が高度すぎて私にはもうついていけない次元ですが、とにかく十進数「も」正しく計算するのは簡単ではない…ということなんですね。

[xebme]

この質問の前提がおかしいまま議論がなされていると思います。
数値計算には、2進数、10進数の計算が含まれているのではないでしょうか？10進数の計算だけが数値計算だと思いこんでいませんか。
16ビットアーキテクチャの時代に、ATMむけに、Cで10進数計算をプログラムしていたと聞いています。2進数の精度不足のため仕方なかった。しかし、64ビットアーキテクチャなら2進数で計算して10進数に変換しても事足りる。(Powerのようにパック10進の回路を備えたCPUもありますが)
むしろ「10進数の計算が必要だからCOBOLが使われている」という俗説をそのまま信じているのが問題では。COBOLが使われている理由はご自分で考えてください。

[退会済みユーザー]

> xebme
> 10進数の計算だけが数値計算だと思いこんでいませんか。

思ってません。誰もそんな話はしてません。

> むしろ「10進数の計算が必要だからCOBOLが使われている」という俗説をそのまま信じているのが問題

信じてません。
質問文やその他回答者とのやり取りをよく読んで理解してから書き込んでください。

[xebme]

> teratail_begin
タイトルはそう読める。
本文はわたしにとって不毛な議論でした。退出します。

[K_3578]

正直この内容ならプログラミング言語タグでやって欲しい。COBOLは例として挙げてるからいいにせよ、
他に挙げている言語タグで検索した人にとってはノイズだと思います。

他のモダンな言語で使えないのか、という意味ならここに挙げていない言語も含むべきだしそれなら
全てを含有する「プログラミング言語」タグが適切ではないかと。

[退会済みユーザー]

細けぇなぁ～
器が小せぇなぁ～

[K_3578]

コメントの流れを見る限りイエスマン以外と話したくないらしいので面倒だから以降コメントしませんが、
意見の主張をしたいだけならteratailでやるべきではない、とだけ言っておきます。
https://teratail.com/help/avoid-asking

[退会済みユーザー]

ネチネチネチネチしつけぇなぁ～
「いかにも」だなぁ～

[Zuishin]

https://teratail.com/questions/366188

> 答えを知らない人はスルーすれば済む話です。

こいつです。

Answer 1

全然おかしくありません。
プログラム言語には作られた目的があり、その目的によっては計算結果が近似値でこと足ります。
COBOLは事務処理を目的に作られた言語の為、計算に強いということです。
ですので、COBOL以外にも厳密な計算結果が求められる目的で作られた言語は誤差が発生しない計算が簡単に出来ます。

Comments

[退会済みユーザー]

＞計算結果が近似値でこと足ります。

うーん、違うと思う。
だって身近な金利計算とか多くの人が求めている計算すら正しく出来ないんだもの。
決して特殊な用途じゃなくて。

[kaina]

だからプログラムが作られた目的があると書きました。
例えばあなたが挙げているPHPはWebブラウザ上で操作する「Webアプリケーション」の制作に特化した言語であり、金利計算を行うという用途は目的では無いわけです。
但し、金利計算が全く出来ないというわけでは無く、あなたのいう「言語仕様が分かっていれば出来る」ようになっています。

[退会済みユーザー]

いや、Webアプリでも小数の計算とか金利計算とかしますよ。
たとえばブラウザで使える電卓のようなサービスとか、知らないんですか？

[kaina]

「言語仕様が分かっていれば出来る」というのが読めませんか？
最初に回答に書いている通りCOBOLの場合は事務処理を目的に作られていると書いた通り、言語仕様から厳密な計算を早く出来るように設計されているわけです。

[退会済みユーザー]

うーん、ちょっと質問と回答が噛み合ってないですね。
60年も前の言語の当初目的の話をされてもねぇ…。その頃とはハードウェアが違いすぎるし。
なぜ最近の言語はその古い言語が出来ていることすらいまだに出来ない or やろうとしないのか？という質問ですから…。

[kaina]

めんどくさくなったので以下のページ見て下さい。
https://qiita.com/ma2shita/items/d8aeec9e2921dc3536f4

[kaina]

BCDとは
https://ja.wikipedia.org/wiki/%E4%BA%8C%E9%80%B2%E5%8C%96%E5%8D%81%E9%80%B2%E8%A1%A8%E7%8F%BE
何故COBOLは10進演算が早いのか
https://www.cobol.co.jp/cobol-nyuumon/ouyou/o010-programtoshorisokudobun/

[kaina]

ついでにPythonもタグにあるのでこちらも
https://docs.python.org/ja/3/library/fractions.html

[退会済みユーザー]

「60年前のCOBOLが出来ていたことがなぜモダン言語で出来ない（やらない）のか？」という質問の答えになってません。

誰も必要としないマイナー機能ならわかりますが、小数絡みってのは金利計算とか普通の人が必要となる場面が多々あります。

[BluOxy]

> 多くの場面で近似値では困るから「小数の計算に気を付けましょう」というようなノウハウ記事がネットにあふれているのでは？
> 身近な金利計算とか多くの人が求めている計算すら正しく出来ないんだもの。

ノウハウ記事がネットにあふれているからといって、多くの人が困っているとは限らないのではないですか。そもそも何をもって「多い」と断定しているのでしょうか。話が極端に聞こえます。

世界中にエンジニアが約2000万人いて、もし数値の計算で困っている人が1万人ぐらいだったら1万人という数だけ見て多いと考えるのか、1/2000の割合しかいないから少ないと考えるか。

1万人ではなく、もしかすると10万・100万・1000万人の方々が困っているかもしれませんが、大事なのはこのような想像ではなく実際のデータが議論には必要で、そこが判明していない訳ですから「多くの人が困っている」と断定できる材料は存在しないのではないでしょうか。

材料がない訳なので、kainaさんの回答の「目的によっては計算結果が近似値でこと足ります」に対して「違うと思う」と想像（もしくは直接目に見えたものだけで判断する極めて主観的な事実）で否定して終わらせず、考えられる1つの答えとして受け入れても良いのではないでしょうか。

そうすれば質問と回答が噛み合うと思うのですが、いかがでしょう。

[退会済みユーザー]

＞想像ではなく実際のデータが議論には必要

「計算誤差で困っているエンジニアの人数データ」なんてあるわけないでしょう。
なんでもかんでもナントカの一つ覚えみたいにデータデータとかくだらないこと言ってないで、現実を見ましょう。

私はこういう問題についてはデータドリブンではなく想像ドリブン・解決したいドリブンでやるべきだと思ってますので。

[BluOxy]

はい。あるわけないのですから、人の話に対して想像で否定していたら現実的な話ができないという話をしています。想像で否定するのをやめたら質問と回答が噛み合うと思うのですが、いかがでしょう。

[退会済みユーザー]

＞想像で否定していたら現実的な話ができない

は？？？
私は否定のためではなく、より良い便利をスタートするために想像してるんですが？

根拠なしに想像で否定してるのはあなたでしょう。

[BluOxy]

> 多くの場面で近似値では困るから「小数の計算に気を付けましょう」というようなノウハウ記事がネットにあふれているのでは？
> 身近な金利計算とか多くの人が求めている計算すら正しく出来ないんだもの。

この引用を見る限り「多くの人が数値の計算に困っている」という人によって解釈が別れる表現を具体的にしないまま、それを根拠に「違う」と書いていますよね。

そして、「多くの人」がどれぐらいかざっくりなデータさえないから分からないんですよね。
ざっくりなデータさえないということは根拠なしで「違う」と否定していますよね。

だから、それをやめませんかと意見を書いています。

先程から書き方を変えただけで同じ趣旨を伝えているつもりですが、違う趣旨を書いているように見えますか？
また、私の書いたこの意見にどんな「想像」が含まれていますか？

[BluOxy]

根拠なしは違ったかもしれませんね。

「ノウハウ記事がネットにあふれている」という非常に薄い根拠で「違う（近似値でこと足りていない）」と否定していますが、その根拠を宛にしても現実的な話にならないということです。

まあ、もしその根拠が正しいと信じて止まないのであれば質問と回答が噛み合わない理由が理解できました。
私は非常に薄い根拠で議論する人は極端だと感じますよ。

[退会済みユーザー]

ま、BluOxyさんと議論しても何の得にもならないので、気に入らないならこのページを見なければいいと思いますよ。

他にも面倒くさい嫌がらせの低評価ボタンを押している暇な人たちが多いですが、嫌なら見なけりゃいいのに。スルーしとけばどんどん過去に流れていくんだから。

[Zuishin]

過去ってなんだよ。残るからいい加減にしろ。

Answer 2

なぜ、いまだに多くのプログラミング言語で、intがどうのdoubleがどうのとかで「近似値です」とか「金融計算には気を付けましょう」とか「小数点以下の計算は正しくありません」とかの問題が解決されないんでしょうか？

「言語仕様はシンプルに」って流れがありそうです。

10進演算はライブラリに任せ、必要な人が使えればいい。
数式のままの微分/積分はライブラリに任せ、必要な人が使えればいい。
機械学習/深層学習はライブラリ(と専用ハードウェア)に任せ、必要な人が使えればいい。

...至極真っ当な考えじゃありませんかね。不要な人には邪魔なんだから。

標準組み込みライブラリのレベルで...

標準にするには需要が少ないから、と考えます。
全体からすれば"ニッチ"なんじゃないかと。

Comments

[退会済みユーザー]

0.1＋0.2＝0.3
↑これを正しく計算できるのが「ニッチ」ですか？？？
うーん、普通のまともな人間の考えじゃないですね。
計算機の「常識」に毒され過ぎです。

[episteme]

計算機で解決したい問題領域の大きさに比べれば十分ニッチです。

[退会済みユーザー]

「計算機で解決したい問題領域」の認識がそもそも違うので、同意できないっすね。

[episteme]

でしょうね。

Answer 3

なぜ人は10進数にこだわるのですか？
三等分すらまともに出来ずに正しい計算もできないなんて不要ではありませんか？

と言われてそうだと納得できますか？
結局すべてを満たす正しい計算というのは表現不可能です

その上で、パソコンは２進法で処理します
もっと言うと、電子回路は２進数で表現する世界です

• 電圧が高い／低い
• N極／S極
• 平ら／出っ張ってる
• 明るい／暗い

勿論、それらは程度や強さで細かく分ける事が出来ますが、大量生産を前提にすると個体の誤差が出てくるのでメーカーやロットが異なっていても上手く動作するようにと考えると「電圧が｛凄く高い／中間／凄く低い｝」の３つに分類され、凄く高いと凄く低いはどのメーカーのどのロットの物でも高いと低いをうまく伝える事が出来ます
ところが、中間は出力する個体と受け取る個体によっては高いとなったり低いとなったりします
これではうまく伝わらないので使えませんよね

そういう事から２値が扱いやすいため２進数で処理を行うように作られています
その為、２進数系のN進数以外を扱う場合は直接扱えないことから単純な処理とならずに複雑な処理を行う必要が出てきます
つまり、処理が遅くなります
他の方が書いている必要が無いというのは処理速度を遅くしてでも正確な１０進数の取り扱いが必要なのか？という観点で一般的にはそこまで必要ではなく、処理速度の方が重要となることが多いため大抵の言語では基本的な数値の扱いは２進数となっています

例えばラーメン屋に行ってメンの重さをミリグラム単位で正確な量を要求しますか？
それとも気づかない程度の差があっても構わないとしますか？
注文してから２時間かかるけどミリグラム単位で正確な量の麺を提供するラーメン屋と、５分で出てくるけど１０ミリ前後の誤差があるラーメン屋さんとどちらへ行きますか？

これだけだと同じお金を払ってるのに１０グラム少ない量しか提供されるのは許さないという人もいるかもしれません
ですが、お昼休憩だった場合は２時間待ちだと提供までの待ち時間の半分しかたっていないのに休憩時間が終わってしまうなら正確なお店には行けませんよね？

それと同じでお金の計算が主な目的であるのならば処理が遅くなっても誤差が出てはいけません
でも、ほぼリアルタイムに処理を行いたい場合だと処理が重くなって間に合わなくなってしまうと困ります
多少の誤差が出ても構わない内容であるのなら誤差には目をつむって速度を重視するでしょう
でも言語で使用する数値型が全て10進で非常に遅い場合は常に間に合わない事態に陥ってしまいます

それが適材適所でしょう、全て10新型にする必要が無いとする根拠です

尤も全ての人がちょっとしたメールのやり取りに毛が生えた程度の事しかしないPCの使い道しかないのであるならば、処理が遅くってもRyzen Threadripperの最上位モデルの64コア128スレッドで並列処理してしまえば良いというのであれば常に10進で扱うのでもありかもしれませんが、通常はそうでもありませんし、もっと重い処理を行いたい人も多いはずです
動画見るだけでもデコード処理で重いはずですが、これが10倍以上の重さになったら低解像度の動画をカクカクでしか見れない世界になるかもしれません

Comments

[退会済みユーザー]

そんな話は誰もしてないっす。
「レガシーなCOBOLが60年前に実現できていることを、なぜモダン言語でもいまだに出来ないorやらないのですか？」という質問です。

処理速度が云々というのはハッキリ言って現実離れした話です。60年前ならそれも重要だったでしょうけど、今のハードウェアでそんなこと気にする必要すらない誤差でしょう。むろん、速度を気にする必要がある場面はその「遅い型」を使わなければいいだけの話だし。なんでデコードの話が出てくんの？っていう。デコードまで10進数計算しろなんて誰も言ってないでしょ。

[len_souko]

必要な場合のみ適用するのであるならばDecimal型を実装している言語を選択すればいいだけでは？

COBOL以外が出来ないかのように書いてるから数値型全てを10進で処理せよという主張であるかと解釈したので、それだと何をするにも内部的に数値を扱うところ全てで処理が重くなるから困る場面の方が多いという話をしています

質問に対して僕の解釈が間違っているのなら、質問文に明記してください
なお、僕の回答は僕が書き始める前に見た内容を元に記述しています
コメントなどの対応を見て「Decimalでえぇやん」という適材適所ではなくて全ての計算処理で10進数の処理が出来て当然であるという主張だと解釈しました
その為、10進での正確な処理が不要な場合でも10進で正確に処理できなければならないのなら回答に記載した理由で処理が不必要に重くなるから、時代が進むごとにCPUの処理能力が上がったところで使用用途自体の要求処理能力も増えているので、結局スピード命な処理の所で問題が起きるから無理ですよと言う理由を回答として記述しました

> デコードまで10進数計算しろなんて誰も言ってないでしょ。

全ての数値計算を10進で行う場合、デコード処理でも普通に１０進処理が出てくるはずです
例えば配列のインデックスが出てくるだけでも１０進処理が出てきます
結果に出てくる数値以外の所でも数値処理は出てきます

[退会済みユーザー]

＞全ての計算処理で10進数の処理が出来て当然であるという主張だと解釈しました

大丈夫っすか、いろいろ

Answer 4

参考）
https://qiita.com/ma2shita/items/d8aeec9e2921dc3536f4

見たかもしれませんが、こういう記事がありました。
C#は標準でDecimal型があるそうです。
記事の筆者も最初はCOBOLだけかと思っていたそうですが、実はそうでもないみたいです。

金利計算などの数値計算で普通に「人が期待する結果」を簡単に出せる仕様にならないのはなぜか？です。

質問の答えは参考リンク先にもないようですが、TakaiYさんの回答にもあるように10進数の厳密な少数計算は面倒なんでしょうね。有名なのは10進数の「0.1」は2進数だと「0.0001100110011001……」と循環小数になってしまい、正しく表現できないというのがあります（参考リンク先もこれを使って色々と検証しているようです）。

Comments

[退会済みユーザー]

とても参考になる記事をありがとうございます。
C#はライブラリ頼みではなく言語標準でDecimal型が使えるんですね。これは知りませんでした！

この記事にもあるような「0.1 + 0.2 = 0.3」という計算は別に特殊でもなんでもなく日常でも必要となりうる計算だと思うので、モダン言語ならこれくらいは人間が自然に期待する通りの結果を返してよ…と思ってしまいます。

[AbeTakashi]

お気持ちはわかりますが、参考リンク先にもありましたが「適材適所」なんでしょうね。すべてDecimalで計算するとコンピュータの計算速度は著しく落ちるでしょう。

参考）
https://ts0818.hatenablog.com/entry/2019/01/14/181837
「本来、コンピュータでは二進法で演算するのがコンピュータ資源（レジスタ、メモリ、計算量）の有効利用になる。それでも二進化十進数が有効な場合があるのは、二進法と十進法との変換を回避することに「社会的な価値」があるからである。」

という引用がありますが、これが実情だと思います。

[退会済みユーザー]

他に回答者への返答にも書きましたが、
「すべてDecimalで」
なんて一言も書いてませんし、思ってもみませんでした。

teratailの回答者って、なぜみんな「0か1か」の極端な話ばかりするんでしょうね？
「適材適所」と言ってるくせに「全部十進数で計算すると遅くなる云々…」って矛盾してることにも気が付かないのかな？っていう。C#のように言語仕様としてDecimal型も用意しつつ、適材適所で型を宣言してプログラミングすればいいだけなのでは？という疑問です。

※AbeTakashiさんへの批判ではなく他の回答者に向けて書いてます。

[fana]

すみません．プログラミング初心者なので意味が掴めないでいます．

> C#は標準でDecimal型がある

だから…？　という感じです．
Decimalを紹介したところで，特段何も解決していない（何らかの程度問題の差でしかない）ように思うのですが，どのような意味合いなのでしょうか？

Decimal型を使おうが誤差が発生するならば，この型を用いて

> 数値計算

なんてやった日には残念なことにもなり得る気がしますが，どうなのでしょうか？
残念具合が軽いのでしょうか？　でもその程度が軽かろうが相応に残念なのであれば，
結局のところ，DecimalならDecimalなりに

> いちいち気を付けて

やる必要があるのではないでしょうか．
そうであれば，

> コンピュータ知識や言語仕様に詳しくない人間

が，何も気にせずに「正しい結果」を得られるとは思えないのですが．

[退会済みユーザー]

＞fana
つか、誰と戦ってんの？？？
他人の些細な間違いをネチネチあげつらったり、つまらないルールに拘泥し続けたり、そのくせ自分は何もポジティブな解決策を提示しない。典型的なテラテイラーの悪いところだよ。

[fana]

誰とも戦ってはいないです．

この回答で解決となっている
→ということはこれが質問内容の解決に繋がっているハズ
→…なのだけども，残念ながら私には「何がどう解決したのか？」ということ自体がわからない（→そして知りたい）

ということで尋ねています．
ご教示願えるとありがたいです．

私が解決策を提示していないのは，この話の意味を尋ねる程度の初心者だからです．
「しない」ではなく，単に「できない」ということです．

Answer 5

すべての言語がDecimalのような整数/小数を基本としていない理由は、基本的には速度に問題があるからでしょう。

int と Decimal だとたとえば10倍とか100倍とかのオーダの違いがでます。
1時間で終る処理が、10時間とか数日になってしまうのは問題でしょう。

これの背景には、少し前はまだそれほどコンピュータの性能が高くなかったということもあります。たとえば、javaはオブジェクト指向が徹底した言語ですが、それに外れた基本データ型があります。これがある原因も計算速度ってことだったそうです。

また、実装が面倒というのもあるでしょう。それほどニーズが高くない領域に手間はかけたくないということです。 いろいろなところで困っている人がいてという記事がたくさんあるということですが、逆に言えばそういうノウハウがあれば解決できるレベルであるとも言えます。

Comments

[退会済みユーザー]

＞int と Decimal だとたとえば10倍とか100倍とかのオーダの違いがでます。

えー、そうなんですか！？　知りませんでした。
でもそれはどうしてなんでしょう？
あと、COBOLはむしろ数値計算に関しては他言語より速いらしいですが、TakaiYさんがご指摘の「Decimalだと遅い」と矛盾するような・・・？？？

＞実装が面倒というのもある

なるほど、そうなんですね。
具体的にどのように面倒なのでしょう？

[TakaiY]

COBOLを知らないのであれですが、そもそもCOBOLは数値演算がうまくできるという特徴を持った言語でしょうから、そのあたり面倒くさがらずにやっているということでしょう。

> どのように面倒
他の方も指摘しているように、64bit intなどの数を2進数で扱い、それをそのままCPUで計算できます。 特に工夫は不要です。
Decimalだと、10進数をそのまま格納する方法を考えなくてはなりません。例えば 1バイト(8bit)(COBOLだと4bit)に0～9の数を割り当てて並べるなどです。こうした場合、CPUの演算機能は使えませんから、全ての演算を自前で実装する必要があります。

Answer 6

• 人間の感覚で言うところの「正しい小数の計算」とかって、そんなに実現が難しい話なんでしょうか？

人間の感覚は時代や分野によって違うことを理解してください。

江戸時代の貨幣制度では、金一両の半分は金二分であり、金一分の半分は二朱でした。
こういう通貨制度だと、今の十進法よりもコンピュータの二進法の方がフィットします。

江戸時代のお金のしくみをお読みください。

また、1971年までの英国の通貨制度では、ポンド＝20シリング、1シリング＝12ペンスでした。これは2でも3でも4でも6でも割り切れるのが便利だからでした。

イギリスの貨幣制度の略史をお読みください。

12進法は今でも1ダースとか1グロスに残っていますし、米国などで使われている長さの単位では、1フィートは12インチです。

角度については全周が360度という単位をよく使います。10進法に近づけようとしてグラードというのも考えられましたが、全く普及していません。

コンピュータについては、ハードウェア的には性能と効率のためにほとんどの場合に内部表現を2進法にしています。ただし普通は十進演算もサポートしています。多くのコンピュータ言語が字ssン演算をサポートしていますが、需要が少ないのであまり力をそそいでいないのです。

teratail_beginさんの主張は、十進法が「正しい」のだから、米国はフィートを廃止すべきであるというよなものなのですよ。

Comments

[退会済みユーザー]

いや、全然違う話にすり替えないで下さいよ。
とっくの昔にCOBOLで実現できてることをなぜ他の言語でできないのか？
Decimal型程度のものをなぜ全ての言語で実装しないのか？
という話です。

ニーズが少ない特殊なことだから…という理由なら分かりますが、普通にニーズが多い計算です。
多くの人がこの誤差に苦しみ、それの解決ノウハウがネットで蓄積されてる。つまりニーズが多いということです。
だったら言語仕様で解決すればいいのに、なぜしないの？と。それを処理系に実装するのがそんなに大変なことなのかな？っていう疑問です。

[退会済みユーザー]

あと米国はヤードポンド法を早急に廃止すべきだとは思いますけどね。