问题标签 [deterministic]

我想知道是否可以使用挂钩（如 Detours）来消除任意应用程序中的不确定性。

我们可以假设单线程应用程序（忽略由竞争和调度引起的不确定性）。

我的第一个猜测是重写rand()，以便为任何要求伪随机数的函数提供可预测和可重复的输出，而不管种子如何。

是否有任何其他常用功能我应该考虑覆盖？

我知道这里没有完美的解决方案，但适用于大多数应用程序的解决方案可能会做到。此外，如果有另一种方法可以解决这个问题，我会很感兴趣地阅读它。

我正在使用使用 QEMU 的 Marss 周期精确模拟器。它是一个完整的系统模拟器，提供用户和内核统计信息。但是，即使我只使用用户统计数据，不同运行之间的统计数据也会有很大差异。我在火星网站上问过这个问题，但没有得到好的答案。我想知道它是否与qemu有关。或者任何可以使模拟具有确定性的 qemu 选项/变体。我尝试使用 -icount auto ，但仍然存在一些变化。对于简单标量 eio 文件，我从未观察到任何变化。我将不胜感激。

如何编码对最后一个元素具有确定性的 member/2。目前我正在使用：

当我查询以下内容时：

解释器在返回 2 后继续搜索，因为还有一个选择点。我怎样才能实现 member/2 以便不再发生这种情况？

但是 member/2 的完整语义应该被保留，即答案如下：

应该仍然像以前一样工作。

再见

不太了解 Haskell 中并发和并行上下文中的确定性。一些例子会有所帮助。谢谢

鉴于：

• SQL 服务器
• 表调用TEST_TABLE
• TEST_TABLE被调用TEST_FIELD类型的列VARCHAR(50) NOT NULL
• 第 1 行：10YR3/6
• 第 2 行：10YR3/2
• 询问：SELECT TEST_FIELD FROM TEST_TABLE WHERE ...

问题：

在我的 where 条件下，我需要测试字符串最后一个字符中的值。我注意到在 Where 子句中执行以下相同的行为。

1. RIGHT(TEST_FIELD,1) > 3
2. CAST(RIGHT(TEST_FIELD,1) AS INT) > 3

在案例 1 中通过一些推断的演员表，他们的行为是否相同？案例 1 是确定性的吗？

提前致谢。

马特

我正在编写一个着色器，它偶尔会在 2D 地图上使一个点闪闪发光。（“闪光”只是一个颜色更亮的像素。）我希望闪光块随机均匀地分布在（无限）平面上，但我希望闪光是基于 X 和 Y 坐标的确定性。我尝试从坐标创建种子并Random从该种子创建 Java，但到目前为止我的尝试已经产生了可识别的模式。此函数将被频繁调用（数百万次），因此性能至关重要。

我首先尝试模仿我的hashCode()实现，它使用质数乘数来避免冲突。这导致整个地图出现明显的裂痕，其中一系列点共享相同的种子。

然后我尝试通过连接坐标来创建种子，如下所示：

这似乎也会产生模式化的数据，尽管模式并不那么明显。选定的坐标出现在线条中，根本不均匀分布。

我避免使用 MD5 或其他加密散列算法，因为我担心性能影响。

我有ParentClass一个观察 NSNotification 的类。ParentClass 处理通知。ChildClass继承 ParentClass 并处理通知。发送通知的顺序是否具有确定性？

换句话说，ParentClass 是否总是在 ChildClass 之前处理通知，反之亦然？

我正在开发一个需要浮点确定性的 C 应用程序。我还希望浮点运算相当快。这包括 IEEE754 未指定的标准超越函数，如正弦和对数。与硬件浮点相比，我考虑过的软件浮点实现相对较慢，因此我正在考虑简单地从每个答案中舍入一两个最低有效位。精度损失对我的应用程序来说是一个足够的妥协，但这是否足以确保跨平台的确定性结果？所有浮点值都是双精度值。

我意识到运算顺序是浮点结果差异的另一个潜在来源。我已经有办法解决这个问题了。

如果今天使用的主要浮点硬件实现有软件实现，那就太好了，所以我可以直接测试这样的假设。

我目前正在使用 ARM Cortex M3 处理器和 64 KB SRAM 构建嵌入式系统。目前，我正在寻找一种方法来确保 STL 容器的确定性性能，其中包括确保我不会在运行时耗尽内存。

我主要关心 STL 容器如何执行动态内存分配。虽然我可以使用自定义分配器让这些结构从我预留的池中获取内存，但我需要为每个结构设置一个单独的池，以确保结构的一个实例不会占用另一个实例的空间。

我正在与该项目中的其他人合作，他们不想关心内存的原始分配，而是希望能够利用“众所周知的”数据结构（堆栈、队列、双端队列等）。因此，我目前正在考虑围绕 C 数组构建包装器以提供这些结构。这将启用支持这些容器所需的内存的静态分配，并允许其他开发人员根据编译器提供的代码大小信息在运行时了解他们已实例化的容器的大小。在我看来，这保证了在运行时不会发生内存中断问题，并大大简化了系统设计。

另一种选择是在系统初始化时分配 STL 容器。在初始化期间之后，不会发生额外的动态内存分配。然而，据我所知，标准的 C++ STL 数据结构不支持这一点——它要求诸如堆栈之类的容器能够被预先分配（类似于向量）。

如果对我提出的围绕标准 C 数组构建类的建议有任何评论，我将不胜感激？另外，有没有更简单的方法在编译时分配静态大小的 STL 容器，例如静态大小的堆栈或队列？（我知道矢量可以做到这一点，但其他我不确定）

注意：我已经阅读了另一个问题（Embedded C++ to use STL or not），但是这个问题的作者没有说明他们有多少内存（除了他们如何使用 ARM7 进程）或似乎是考虑类似于我的解决方案。

第二个注意事项：我知道对于一些开发人员来说，64 KB 的 SRAM 可能看起来像很多内存。事实上，我已经在内存显着减少的 AVR 处理器上进行了开发，所以我理解这个观点。然而，从我目前（可能是不知情的）的观点来看，在谈论 STL 容器时，64 KB 的内存并不算多。

给定一个 Runnable 对象，例如

我希望能够执行确切数量的操作，例如

这样，如果我第一次执行此操作会达到：

任何其他时间我用相同的参数调用该方法都会导致执行到同一点。

我环顾四周，看不到任何合适的东西（例如，据我所知，ScheduledThreadPoolExecutor 不会工作）。

我是否必须转移到字节码级别才能完成这项工作？从我读过的内容来看，JIT 也可能在这里引起问题。