Prolog中发生检查的最坏情况是什么？

许多论文确实注意到，当

发生时，下面这样的等式统一问题可能会在指数时间内运行。\u check=true

。没有规定这是顶级查询或子句体，只是等式统一问题：

   X1 = f(X0, X0),
   X2 = f(X1, X1),
   ..
   Xn-1 = f(Xn-2, Xn-2),
   Xn = f(Xn-1, Xn-1).

如果为真，这可能是发生检查的最坏情况，因为正态变量共享统一是线性的。每个Prolog系统 是否有必要将这个等式统一问题视为最坏情况

---

如果Prolog系统没有

ocurses\u check=true

标志，可以尝试将

统一为

而不是

（=）/2

，这里是一个比较。我在一个子句体中测试了等式统一问题。链接到测试的源代码和基准测试结果位于此答案的末尾：

test :-
    B = f(A, A),
    C = f(B, B),
    D = f(C, C),
    X = f(D, D).

Etc..

Jekejeke Prolog 1.4.6和SWI Prolog 8.3.17仍然是线性的。Jekejeke Prolog使用静态分析，并不总是有效。SWI Prolog是动态执行的，我猜处理循环项会产生副作用。但是GNU Prolog 1.4.5是指数型的。我使用了n=4、6、8和10：

开源：

线性还是指数？

---

这个假设还没有完全被证实。有一些证实 我们可以看看VM代码。有一种危险，那就是我还活着 看，看，看，我什么也没看到

这是我对SWI序言的怀疑。关于这一点
等式统一问题，现在在子句体中：

X1 = f(X0, X0),
X2 = f(X1, X1),
..
Xn-1 = f(Xn-2, Xn-2),
Xn = f(Xn-1, Xn-1).

当发生时，只有一个方程被优化掉。\u check=true？这将
解释不同的唇数和不同的性能：

/* (=)/2, occurs_check=false */
% % 2,000,000 inferences, 0.222 CPU in 0.226 seconds (98% CPU, 9007995 Lips)

/* unify_with_occurs_check/2 */
% % 12,000,000 inferences, 1.382 CPU in 1.411 seconds (98% CPU, 8680009 Lips)

/* (=)/2, occurs_check=true */
% 11,000,000 inferences, 1.264 CPU in 1.270 seconds (100% CPU, 8704963 Lips)

---

Oki，Doki.

如果OC将它跟随的变量存储在哈希表中（这样它就不会跟随同一个变量两次），并且忽略“新鲜”变量，该怎么办。那么，最糟糕的情况是什么呢？“以一个新的子句开头的等式（X，X），如果你把它与一个目标等式（Y，f（Y））统一起来，它将是STO。”在这里，你首先要做的是

X=Y

。它们都是新鲜的。之后，它们就不再新鲜了@MaxB：它在哈希表中跟随，在许多实现中标记就足够了。