SQLITEのROUND関数の結果の誤差について

現在SQLITEを使って小数の演算などをしています。
その中でROUND関数を使って四捨五入しているのですが、結果が予期せぬものになるケースがあります。

round(2.124,2)　⇒ 2.12 OK
round(2.125,2)　⇒ 2.12 NG (2.13が期待値）
round(2.126,2)　⇒ 2.13 OK

一方で正しく四捨五入されるパターンもあります。

round(8.454, 2)　⇒ 8.45 OK
round(8.455, 2)　⇒ 8.46 OK
round(8.456, 2)　⇒ 8.46 OK

これは何故発生するのでしょうか？
そしてround(2.125,2)　⇒ 2.13 とするための回避策はあるのでしょうか？

※SQLITEのSQL文での回避策を探しております。

ikadzuchi

2018/05/31 13:10

最終桁が「5」で四捨五入として正しいものと正しくないものの例をもう少し大量に挙げてもらえますでしょうか。

行動規範の内容に同意します

回答3件

ベストアンサー

端数処理

ここに書いてある「偶数への丸め（round to even）」というものでしょうね。

そしてround(2.125,2)　⇒ 2.13 とするための回避策はあるのでしょうか？

*100 して、0.5足して切り捨て、そして100で割る。（マイナスの場合は考えてください）

投稿2018/05/31 09:19

y_waiwai

総合スコア88000

(2進の)浮動小数点数の仕様です。
10進数で切りの良い小数は2進浮動小数点数では正確に表せません。
~~例えば2.125は内部的に2.12499999のような値になるのでしょう。~~ →追記参照
偶数への丸めは無関係です。
環境によってはdecimal型などの名前で10進浮動小数点数が使えますがどうやらSQLiteには無いようです。
対処法としては正攻法ではそもそも入力データに小数を使わないようにすべきですが、
現状のデータのままでどうにかするなら取れる方法は「十分に小さい数を足してからroundする」くらいだと思います。

追記:
上のように書きましたが、コメントで指摘のあったように2.125は2進小数で厳密に表せる値でした。失礼しました。
ただ、状況は浮動小数点数の誤差によく似ているので、何らかの形で上記のような内容が関係している可能性はあります。

調べてみると興味深い情報が見つかりました。
http://d.hatena.ne.jp/hnw/20131229
こちらの(本文ではなく)コメント欄にSQLiteの内部処理について、「0.005を足してから第3位以下を切り捨てることで四捨五入を実現」とあります。
これだと「0.005」の部分に誤差が含まれますので何桁でroundするかにより切り捨てか切り上げかが一定しないことになりそうで、ちょっと疑問が残ります。

投稿2018/05/31 11:21

編集2018/05/31 13:08

ikadzuchi

総合スコア3047