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.

编辑：

我根据评论做了一个小测试程序：

var d: Double;
    id: int64 absolute d;
    lDouble: Double;
begin
  id := E4863E234B78FC;
  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 具有比 ARM（64 位）更高的内部精度（80 位）。

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

为了完整起见，这里是正在发生的事情：

调用 Round(d*n);，其中 d 是双精度数，n 是数字，在 x86 环境中调用 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 = E4863E234B78FB;
  id2 : Int64 = E4863E234B78FC; // <-- the fTimeStamp value
  id3 : Int64 = E4863E234B78FD;
  // 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 结尾），而扩展计算给出的值稍微高一点。这是对平台不同舍入结果的解释。

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

iOS 上 TDateTime 的舍入错误

Rounding error with TDateTime on iOS

delphi

sqlite

firemonkey

delphi-xe7