Categories: 日記

2/16(土) 掛川・晴

 どどどどどどわーーーーーーっ。何だこれ,何だこれは〜。全く同じ引数を与えてるのに,丸めモードによって全く違う値が出るではないかーーーーーーっ!!!!

cos( 2.15050720034533157e+02) = 1.47832900163407915e-01 (3.0e+00, 2.1e+01)
RN, RZ: 1.47832900163407915e-01, 3.17951687246473957e+00
RP, RM: 1.47832900163407915e-01, 3.17951687246473957e+00

 ちなみにサンプルプログラムはこれ。この結果はFedora core 4 x86_64 + Athlon64 X2 3800+ + gcc 4.1.1でコンパイルしたプログラムが出力したものの一部である(全体はこちら・極端にでかい差が出た時のみ4モードでの値を表示)。どうもPentium D + CentOS 4 の環境でも同じ現象が発生するようだ。MacOS X 10.4 + Core2Duo + Xcodeの環境ではこの現象は再現しない(結果はこちら・エラーなしなのでcosの値のみ表示)。32bit環境だと無事で,64bit環境特有のバグとか? しかし検索してもそんな現象はどっこも報告されてないようだしなぁ・・・。
 結果を眺める限り,デフォルトのRN(Round to Nearest)モードでは常に正常値であり,他の3つのモードでおかしくなるようだ。うーん・・・?
 どーりでワシの代数方程式のルーチンも,GSLのルーチンも結果が変だと思ってたんだよなぁ。まあワシのミスではないことが判明したが,cos関数なんて基本的なものでこんな重大なbugがあっちゃ困るんだよなぁ。しかも計算機誕生の黎明期ならともかく,21世紀になってるってのにさぁ。
 さて,誰に聞けば良いのかなぁ? GSL MLでもMPFR MLでも畑違いだし・・・とりあえず,NA-Digestに投げて聞いてみようかなぁ。
 原因が分かって一安心なんだけど,暫くはワシの64bit環境ではおっそろしくて三角関数が使えないぞ〜。どうすりゃ良いんだ全く。秋田行きまでもうちっとだってのにさぁ。
 頭を抱えつつ寝ます。

T.Kouya

Share
Published by
T.Kouya

Recent Posts

11/17(日) 駿府・晴

 (色々)^nあった物事が一応…

3日 ago

8/9(金) 徳島→駿府・晴

 昨日の宮崎県沖地震が南海トラ…

3か月 ago

7/28(日) 駿府・酷暑

 梅雨明け前から35℃越えの日…

4か月 ago

7/6(土) 駿府・晴

 梅雨のさなかにも拘らず,今週…

5か月 ago