FLOAT型では桁数が足りないことに気付いたので、DECIMAL(20,13)に変更したのですが
ALTER TABLE `tablename` CHANGE `hoge` `hoge` DECIMAL( 20, 13 ) NULL DEFAULT NULL ;
ところがこのSQLを投げると、hogeカラムに入っていた999.999だった値が999.9990234375000に変更されてしまいます。
固定桁数の小数点表示になるので足りない部分が補足されるのはわかるのですが、元が無い値なので0で足りない部分を埋めてくるものだと思っていたのですが、そうではないのでしょうか。
この勝手に増やされた0.0000234375という値はどこから着たのでしょうか。
どなたかわかる方いらっしゃいましたらお教えいただけますと幸いです。
よろしくお願いいたします。
No.1
966
247
200pt
これを理解するには、浮動小数点型というものが、どういうものかを理解する必要があります。
computer programming I
上記ページが分かりやすいと思うのですが、浮動小数点型は、２進数の世界でデータを表現しているため、10 進数でキリの良い数値であっても、２進数では循環小数となってしまう場合があります。
その「２進数では循環小数」を、浮動小数点型では、決められたビット長の範囲でしか保存出来ないので、無限の桁数を有限の桁数で切り取ってしまうことになります。
この為、浮動小数点型は、人間が考えている 10 進数の数字と誤差を持っている事が多いです。10 進数表示で有効桁が数桁のうちは、誤差なく浮動小数点で表現できているように見えますが、有効桁数を大きくすると、実際には誤差が生じている事が分かります。
で、DECIMAL 型の場合は、10 進数の一桁一桁を、そのままの形で保存します。
MySQL :: MySQL 5.1 リファレンスマニュアル (オンラインヘルプ) :: 7.14.2 DECIMAL データ型の変更
つまり、浮動小数点型が２進数でデータを保持しているために生じる 10 進数との誤差が、DECIMAL 型へ変換することで現れた、ということになります。
きゃづみぃ
2012/07/25 20:42:33
1
1
1
1
1
143
137
大変分かりやすい説明ありがとうございました！
2012/07/25 17:25:56御マニュアルの「近似値」という説明を読んで、「近似値も何もそこに10進数の値がばっちり書いてあるじゃないか」と首をかしげていたのですが、オリジナルのデータは2進数なのですね。よくわかりました、ありがとうございます。
ということは、一度2進数で保存してある以上、発生する誤差はどうしようもないのですねぇ・・直接変換せずにドコかに一度値をプールしておいて、型を変えてから改めてその値を流し込む感じしか手がなさそうに思えますね。
参考になりました、ありがとうございました。