最近我发现了一件奇怪的事:结果 var d: double;begin d := StrToFloat('-1.79E308'); 与ASE和SQL Server通过的字符串值’-1.79E308’转换为float字段类型不同 INSERT INTO my_table (my_float_field) VALUES (-1.79E308)
var d: double; begin d := StrToFloat('-1.79E308');
与ASE和SQL Server通过的字符串值’-1.79E308’转换为float字段类型不同
INSERT INTO my_table (my_float_field) VALUES (-1.79E308)
对于Delphi内存转储是9A BB AD 58 F1 DC EF FF
对于ASE / SQL Server,数据包中的值选择为99 BB AD 58 F1 DC EF FF.
谁错了,服务器还是Delphi?
我们工作的前提是StrToFloat产生最接近的可表示的二进制浮点值到提供的十进制值.您出现的两个十六进制值是相邻的.您可以看到它们在有效数字中相差1.以下是一些解码这两个值的Python代码:
>>> import struct >>> struct.unpack('!d', 'ffefdcf158adbb9a'.decode('hex'))[0] -1.7900000000000002e+308 >>> struct.unpack('!d', 'ffefdcf158adbb99'.decode('hex'))[0] -1.79e+308
请记住,Python使用最短的可能值来打印浮点值,其中最接近的可表示值是实际值. ffefdcf158adbb99在Python的眼中解码为打印的值为-1.79e 308,足以证明ffefdcf158adbb99是最接近的可表示值.换句话说,Delphi代码给出了错误的答案.
而且,出于好奇,在相反的方向:
>>> hex(struct.unpack('<Q', struct.pack('<d', float('-1.79e308')))[0]) '0xffefdcf158adbb99L'
值得注意的是,32位Delphi编译器产生了ffefdcf158adbb99,但64位Delphi编译器产生了ffefdcf158adbb9a.这是一个明显的缺陷,应该作为错误报告提交给Quality Portal.