我的小包裹有一个相当复杂的问题。基本上，我正在构建一个 GARCH(1,1) 模型，其中rugarch包含专门为此目的设计的包。它使用一系列求解器（由Rsolnpand提供nloptr，通用非线性优化）并且工作正常。我正在testthat通过提供基准解决方案来测试我的方法，该解决方案之前是通过在 Windows（这是要使用的包的主要平台）下手动运行代码获得的。
现在，当解决方案在多次连续运行中不一致时，我最初遇到了一些问题。差异在我为求解器指定的容差范围内（默认值solver = 'hybrid'，如文档所建议的那样），所以我猜测它使用了某种随机化。所以我去掉了随机种子和并行化（“合法”原因）并且问题得到了解决，我每次在 Windows 下都得到相同的结果，所以我运行 R CMD CHECK 并testthat成功了。
之后我决定自动化一点，现在构建过程由travis控制。令我惊讶的是，Linux 下的结果与我的基准测试不同，日志指出
read_sequence(file_out) 不等于 read_sequence(file_benchmark)
平均相对差：0.00000014688
多次rebuild产生相同的结果，并且差异总是相同的，这意味着在Linux下解决方案也是一致的。作为临时修复，我根据平台设置容差限制，并且测试通过（请参阅最新版本）。
所以，总结一下：
- 数字过程分别在 Windows 和 Linux 平台上产生相同的输出；
- 但是，这些输出是不同的，并且不是由随机种子和/或并行化引起的；
我一般只关心在 Windows 下的支持，不打算公开发布，所以这对我的包本身来说没什么大不了的。但我提请注意这一点，因为其中一个被广泛使用的求解器可能存在问题。
不，我不是要修复我的代码：依赖于平台的容差非常难看，但到目前为止它已经完成了工作。问题是：
- 还有什么可以“合法地”（或“自然地”）导致所描述的差异的吗？
- 是否需要低级数值例程才能在所有平台上产生相同的结果？会不会是我期望太高？
- 我应该非常关心这个吗？这是常见的情况吗？