LibreOffice CalcとExcelの計算結果誤差をみなさんで検証していただいた結果まとめ

いさな @jo3emc

@ikunya @LibreOffice_Ja 独自の丸めという意味ではLibOもやってそうでは…。 クローズドではないですし、分かりやすくはありますが。

いさな @jo3emc

@LibreOffice_Ja 再確認結果。今回は小数点第18位までプリントしてみました。LibOはセル書式で、その他は各々演算後に書式変換で桁指定。 LibOは小数点第15位（有効数字16桁目）で丸められて有効数字15桁に揃えられてしまう模様。演算でも読込でも貼付でも同様。 gccとTclは有効数字18桁目から0に。Pythonは四倍精度？ pic.twitter.com/AV16deJ8Tf

拡大

いさな @jo3emc

@LibreOffice_Ja ちなみに倍精度の有効数字は16桁弱ですと。 そういえばこんな話以前にもBugzillaかどっかで見たような…。 独自処理って点ではExcelとどっこいで筋は良くない。しかも精度は制限される方向。表計算の小数演算ってことである意味順当な割り切りとも言えますが…誤差の蓄積を考えると少しもやりますね。 pic.twitter.com/sT4RYGCe7V

拡大

RGB000 @19666_61

浮動小数点演算は沼だなぁ togetter.com/li/1367733#c64… 「LibreOffice CalcとExcelの計算結果誤差をみなさんで検証し..」togetter.com/li/1367733 にコメントしました。

山吹色のかすてーら @sir_manmos

pc98のMicrosoft Basicでsqrt(36)が6にならなかったことを思い出す。これは内部でsqrt(x)を4byte のfloat でexp(log(x)/2)やってるのが原因だったよう。Newto.. togetter.com/li/1367733#c64… 「LibreOffice CalcとExcelの計算結果誤差をみなさんで検証し..」togetter.com/li/1367733 にコメントしました。

みの @minourii

なるほど、こないだ流れてきたフィボナッチ数列の話は、Excel が数値計算の丸め誤差を特殊な処理で消しているという話。「計算間違いだ！」というクレームが来て面倒だから Excel はあえてそういう処理をしているんでしょうね。でも数値計算として正しいのは LibreOffice や R の方。

川原 龍人🌕💉💉 @ryu_11_qpg

統計をやるのは必ずしも反対ではないが、数学でやるべきでないと思う、というのは何回か言ったかな。やはり情報でやるのがよいのでは。Rを使うのかLibreOfficeにするのかなどはあるが(Excelみたいに有償のものを使うとなると問題が出そう)

TAGA Yoshitaka @TagaYoshitaka

#LibreOffice Calc で二進浮動小数らしくないふるまい。 en.wikipedia.org/wiki/Numeric_p… の例で、Excel/G Spread/Numberが、-3.55E-15 を返すところで 0.00E+00 バージョン: 6.2.4.2 Build ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64 CPU threads: 4; OS:Mac OS X 10.14.5 pic.twitter.com/ZhUltWWW4p

拡大

K.Shirakata @argrath

LibOとExcelで差が出るやつ、Excelでも1/3は0.33333333333333300000とかになるので計算自体はdoubleでやってるっぽいんだな。だから丸め方の問題か…。ソース読めるわけでもないしこれ以上は確認難しそう。