Oracle11g ->客户端-> Pro*C程序双精度表示

Question

11g Oracle实例中的编号(12，3)字段存储数字271.448

它是FETCHed从游标到32位Pro*C中的双变量(11.1.0.6版)。使用Visual 2010进行预处理的C程序用于编译.c文件。

将271.448 (到stdout)立即打印到具有fprintf的双变量中，格式说明符"%3.14f“给出：271.44800000000004

然而，如果我这样做的话：

1. 从dual中选择to_char(cast(271.448 as binary_double)，'999.99999999999999')；
2. 但是引用了有问题的行/字段，而不是数字文本。
3. 从dual中选择to_char(to_binary_double(271.448)，'999.99999999999999')；
4. 作为3。但是引用了有问题的行/字段，而不是数字文字。
5. 将271.448直接分配给非Pro*C测试C程序中的double，并使用%3.14f“说明符打印到stdout
6. 使用double.html进行转换。

我得到的271.44799999999998是-> 5)，2.71447999999999979081621859223E2是6)

我预料到Oracle Db与Pro*C/C之间的表示略有不准确，但不存在不一致之处。

与谷歌的几个小时，使我稍微更多的知识全面，但没有更明智的我的具体问题。有人能告诉我我错过了什么或者可能发生什么吗？

Answer 1

我不知道你的问题到底是什么：“为什么所有的答案都不像271.448000000000000000000000000 ?”

但你要处理的是几个陈述：

• 甲骨文内部编号及其奇怪的存储细节 (N.B.：OCI支撑Pro*C)
• C语言，通常：
• 64位IEEE754双

以及几个转换和/或格式化步骤：

• To_char(271.448 as binary_double)，'999.99999999999999')
• to_char(to_binary_double(271.448)，'999.99999999999999')
• 双d= 271.448；printf("%3.14f\n"，d)；
• “二进制转换器”站点(或者可能使用"%3.27f“作为格式字符串)

我认为这里的关键区别在于Oracle的内部数字格式与典型的C表示，因此您的核心问题实际上可能是“为什么所有这些格式都不精确地存储271 + 56/125 ?”我不是提供这种答案的人--我们生活在搜索引擎时代是件好事：

为什么有理数不作为零信息丢失的分数来实现和存储？

或

浮点数是一个漏洞百出的抽象。