iOS 上的 TDateTime 舍入错误

Question

从时间戳 (TDateTime) 计算 32 位 ID 时，我收到一个奇怪的错误。在某些情况下，不同处理器上的值是不同的。

fTimeStamp 字段是从 SQLite 数据库中的 Double 字段中读取的。 下面的代码从fTimeStamp 计算一个 32 位 ID (lIntStamp)，但在某些（罕见的）情况下，即使源数据库文件完全相同（即存储在文件中的 Double 相同），不同计算机上的值也会不同.

...
fTimeStamp: TDateTime
...

var
  lIntStamp: Int64;
begin
  lIntStamp := Round(fTimeStamp * 864000); //86400=24*60*60*10=steps of 1/10th second
  lIntStamp := lIntStamp and $FFFFFFFF;
  ...
end;

TDateTime(Double)的精度是15位，但是代码中的取整值只用了11位，所以应该有足够的信息来正确取整。

举一个值的例子：在特定的测试运行中，lIntStamp 的值在 Windows 计算机上为 $74AE699B，在 iPad 上为 $74AE699A（= 只有最后一位不同）。

Round函数在各个平台上实现的不同吗？

PS。我们目前的目标平台是 Windows、MacOS 和 iOS。

编辑：

我基于cmets做了一个小测试程序：

var d: Double;
    id: int64 absolute d;
    lDouble: Double;
begin
  id := $40E4863E234B78FC;
  lDouble := d*864000;
  Label1.text := inttostr(Round(d*864000))+' '+floattostr(lDouble)+' '+inttostr(Round(lDouble));
end;

Windows 上的输出是：

36317325723 36317325722.5 36317325722

在 iPad 上的输出是：

36317325722 36317325722.5 36317325722

不同之处在于第一个数字，它显示了中间计算的舍入，所以出现问题是因为 x86 的内部精度（80 位）比 ARM（64 位）更高。

Answer 1

假设所有处理器都符合 IEEE754，并且您在所有处理器中使用相同的舍入模式，那么您将能够从所有不同的处理器中获得相同的结果。

但是，您的代码可能存在编译代码差异或实现差异。

考虑如何

fTimeStamp * 24 * 60 * 60 * 10

被评估。一些编译器可能会执行

fTimeStamp * 24

然后将中间结果存储在 FP 寄存器中。然后将其乘以 60，并存储到 FP 寄存器。等等。

现在，在 x86 下，浮点寄存器是 80 位扩展的，默认情况下，这些中间寄存器会将结果保存为 80 位。

另一方面，ARM 处理器没有 80 个寄存器。中间值以 64 位双精度保存。

所以这是一个机器实现的差异，可以解释你观察到的行为。

另一种可能性是 ARM 编译器会在表达式中发现常量并在编译时对其求值，从而将上述情况简化为

fTimeStamp * 864000

我从未见过可以做到这一点的 x86 或 x64 编译器，但也许 ARM 编译器可以做到。这是编译代码的区别。我不是说它会发生，我不知道移动编译器。但它没有理由不能发生。

然而，这就是你的救赎。用那个单次乘法重写你的表达式。这样，您就摆脱了以不同精度存储中间值的任何范围。然后，只要Round 在所有处理器上的含义相同，结果就会相同。

我个人会避免关于舍入模式的问题，而不是Round 会使用Trunc。我知道它有不同的含义，但出于您的目的，这是一个任意选择。

然后你会留下：

lIntStamp := Trunc(fTimeStamp * 864000); //steps of 1/10th second
lIntStamp := lIntStamp and $FFFFFFFF;

---

如果Round 在不同平台上的行为不同，那么您可能需要自己在 ARM 上实现它。在 x86 上，默认舍入模式是银行家。这仅在两个整数之间的中间时才重要。因此，检查Frac(...) = 0.5 是否并相应地四舍五入。该检查是安全的，因为 0.5 是完全可表示的。

另一方面，你似乎声称

Round(36317325722.5000008) = 36317325722

在 ARM 上。如果是这样，那是一个错误。我无法相信你所说的。我相信传递给Round的值其实是 36317325722.5 在 ARM 上。这是唯一对我有意义的事情。我不敢相信Round 有缺陷。

Answer 2

为了完整起见，这是发生了什么：

在 x86 环境中，调用 Round(d*n);（其中 d 是双精度数，n 是数字）将在调用 Round 函数之前将乘法转换为扩展值。在 x64 平台或 OSX 或 IOS/Android 平台上，没有提升到 80 位扩展值。

分析扩展值可能很棘手，因为 RTL 没有写入扩展值的完整精度的功能。 John Herbster 写了这样一个库http://cc.embarcadero.com/Item/19421。 （在两个地方添加FormatSettings 使其在现代Delphi 版本上编译）。

这是一个小测试，它以输入双精度值的 1 位变化为步长写入扩展和双精度值的结果。

program TestRound;

{$APPTYPE CONSOLE}

uses
  System.SysUtils,
  ExactFloatToStr_JH0 in 'ExactFloatToStr_JH0.pas';

var
  // Three consecutive double values (binary representation)
  id1 : Int64 = $40E4863E234B78FB;
  id2 : Int64 = $40E4863E234B78FC; // <-- the fTimeStamp value
  id3 : Int64 = $40E4863E234B78FD;
  // Access the values as double
  d1 : double absolute id1;
  d2 : double absolute id2;
  d3 : double absolute id3;
  e: Extended;
  d: Double;
begin
  WriteLn('Extended precision');
  e := d1*864000;
  WriteLn(e:0:8 , ' ', Round(e), ' ',ExactFloatToStrEx(e,'.',#0));
  e := d2*864000;
  WriteLn(e:0:8 , ' ', Round(e),' ', ExactFloatToStrEx(e,'.',#0));
  e := d3*864000;
  WriteLn(e:0:8 , ' ', Round(e),' ', ExactFloatToStrEx(e,'.',#0));
  WriteLn('Double precision');
  d := d1*864000;
  WriteLn(d:0:8 , ' ', Round(d),' ', ExactFloatToStrEx(d,'.',#0));
  d := d2*864000;
  WriteLn(d:0:8 , ' ', Round(d),' ', ExactFloatToStrEx(d,'.',#0));
  d := d3*864000;
  WriteLn(d:0:8 , ' ', Round(d),' ', ExactFloatToStrEx(d,'.',#0));

  ReadLn;
end.

---

Extended precision
36317325722.49999480 36317325722 +36317325722.499994792044162750244140625
36317325722.50000110 36317325723 +36317325722.500001080334186553955078125
36317325722.50000740 36317325723 +36317325722.500007368624210357666015625
Double precision
36317325722.49999240 36317325722 +36317325722.49999237060546875
36317325722.50000000 36317325722 +36317325722.5
36317325722.50000760 36317325723 +36317325722.50000762939453125

---

请注意，问题中的fTimeStamp 值在使用双精度计算时具有精确的双精度表示（以 .5 结尾），而扩展计算给出的值略高一些。这是平台不同舍入结果的解释。

---

如 cmets 中所述，解决方案是在舍入之前将计算存储在 Double 中。这不会解决后向兼容性问题，而这并不容易实现。 也许这是以另一种格式存储时间的好机会。