我的小package有一个相当复杂的问题。基本上，我正在构建一个带有rugarch包的GARCH（1,1）模型，该模型正是为此目的而设计的。它使用一系列求解器（由Rsolnp和nloptr提供，通用非线性优化）并且工作正常。我通过提供基准测试解决方案，使用testthat测试我的方法，这是先前通过在Windows下手动运行代码获得的（这是使用该软件包的主要平台）。
现在，当解决方案在几次连续运行中不一致时，我最初遇到了一些问题。差异在我为解算器指定的容差范围内（默认solver = 'hybrid'，正如文档所推荐的那样），所以我的猜测是它使用某种随机化。所以我带走了随机种子和并行化（＆＃34;合法＆＃34;原因）并且问题解决了，我每次都在Windows下得到相同的结果，所以我运行R CMD CHECK和{{1}成功。
之后我决定自动化一点，现在构建过程由travis控制。令我惊讶的是，Linux下的结果与我的基准测试不同，log表示
read_sequence（file_out）不等于read_sequence（file_benchmark）
平均相对差异：0.00000014688
重建几次产生相同的结果，差异总是相同的，这意味着在Linux下解决方案也是一致的。作为临时修复，我根据平台设置容差限制，并且测试通过（参见最新版本）。
所以，总结一下：
我通常只关心Windows下的支持而不打算公开发布，所以这对我的软件包本身来说并不是什么大问题。但我要引起注意，因为其中一个解决方案可能会被广泛使用。
不，我没有要求修复我的代码：依赖于平台的容忍度非常难看，但到目前为止它还能胜任。问题是：