アカウント名:
パスワード:
LIST10 SUM=020 FOR I=0 TO 10000-130 SUM=SUM+0.140 NEXT50 PRINT SUMRUN1000OK■
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
金の計算と帳票処理なら (スコア:0)
二進化十進 (スコア:1)
良いものは良い。
なんか文句がある人がいるんでしょうか。
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:2, すばらしい洞察)
Re: (スコア:0)
と不思議に思った数秒後に、
FP-1100のBASICは10進演算していたのを思い出した。(だから遅かったよNE!)
・・・懐かしい思い出をありがとう。
Re: (スコア:1)
Z-80にもDAA命令があるのでBCD演算の実装はまあ、浮動小数の実装と比べて、
そんなに極端な差は出ないと踏んだんでしょうけど、
MSXのユーザーの大半は使ってなかったと言う…。
あと懐かしいといえばNCB(Number Crunch BASIC)てのもありましたねー。
ナンバークランチングをBASICでやろうと言うのも凄い話なんですが(^^;
とにかくBCDを実装した言語はパソコンにも割とあったと言うお話です。
ちなみにIA-32のSIMD命令にもちゃんとBCD演算を考慮した命令(四則演算)は残ってますし、
IBMメインフレームじゃなくても、実装は十分出来ると思うんで
Re:二進化十進 (スコア:0)
正気の沙汰ではありませんね。
ひょっとして御社ではそれでシステムの設計をなさってる…?
Re:二進化十進 (スコア:1)
極端な例を書けば、MPEGビットストリームでは各パートごとに有効ビット数がありますし、
ゲーム機の演算ハードウェアは有効ビット数が決まってます。
いや、それ以前にアセンブラ使うならレジスタのビット長をちゃんと把握して無いと計算できませんよ?
C/C++を使う場合も、自分の使っている演算長はちゃんと把握していないと固定小数点演算なんて、
アンダーフローやオーバーフローをバリバリ出してあっという間に計算が破綻するなんて割とざらですが?
FloatやDoubleだって、有効ビット数を考えて居ないと、たとえば演算で回転変換をかけたりすると、
数回転しただけで破綻しますよ。
・・・そこまで極端な事を言わなくても、たとえば、浮動小数を使っている、と言う自覚があれば、
当然誤差の含まれた計算をしている、という意識が働くわけで、数値を==で比較する、なんて、
阿呆なコードは書かないわけで、(NANや初期化直後の0とかは除いて…)、いずれにしろ、これも
「演算精度をプログラマが自覚している」って事でしょ?
むしろ上記を考えない、と言うのはプログラマとして大問題を抱えてるのではないですか?
Re: (スコア:0)
> むしろ上記を考えない、と言うのはプログラマとして大問題を抱えてるのではないですか?
当然プログラマは精度等について自覚している必要はあります。
でもそれは
> 計算精度なんてもともとプログラミング時にプログラマが設計すべきものでしょ。
とは何の関係もないことです。
普通の会社では、精度は「プログラミングよりずっと前に」「むしろプログラマ以外の人が」設計するものですが、ホント。
あなたがたは与えられた精度を満たすようなコードを書いているだけで、設計時の精度の決定には噛んだ経験はなさそう、
もしくは、愚か者ゆえにそこから何も学ばなかった(ベンジャミン・フランクリン)ようですね。