C Prolog的时间复杂性比天真的蛮力好吗？

在（最好的）Prolog中解决任何问题的时间复杂性是否比天真的暴力回溯实现更好

我一般说语言序言。。。我想知道是否有一些众所周知的算法，例如，在Scheme中使用call/cc回溯的“doing Prolog”是一个糟糕的选择

编辑：“解决任何问题”我指的是所有的Prolog程序。“问题中的问题”：我想知道语言设计：完全延续是否比部分延续有任何实际效用（主要优势是Prolog风格，但如果它们不能与Prolog在时间复杂性上竞争，这并不严重），另外，如果另一种语言能够完全吸收Prolog，或者通过将程序限制为Prolog形式实现了优化（类似于Fortran over C中可能的优化）

编辑：我所说的时间复杂性是指大O，也就是说，在通用语言中不可能天真地模仿Prolog的修剪。

如果你要求解决任何问题，Prolog肯定会在线性时间内解决一些问题。例如，下面的

append/3

谓词：

append([H|A],B,[H|R]) :-
    append(A,B,R).
append([],L,L).

现在因为在每一步，只有一个候选谓词，没有分支，没有指数时间复杂性。谓词在第一个列表的长度上呈线性运行

---

此外，还可以允许在Prolog中使用tabling，这可能导致某种动态规划，这种动态规划有时可以在快速算法中使用蛮力回溯算法。

IMHO，这取决于问题。如果它真的只能通过蛮力和回溯来解决，我认为（即使是一个理想化的“最佳”）Prolog也不会比e。G一个写得很好的C程序

另一方面，如果您有这样的问题，Prolog可以使用它的数据库和演绎方法（因此，不一定是暴力回溯），那么它可能比另一个暴力回溯程序具有更好的性能

---

最后，每种编程语言最终都会创建运行在CPU上的机器代码（希望如此）来解决您的问题。同样的机器代码也可以由其他语言生成，或者或多或少由程序员直接生成。因此，Prolog是解决某些问题的好方法，但它不一定是最佳/最快/唯一的选择。

您的问题似乎是，如果我在Scheme中编写类似Prolog的代码，它的性能会比我在Prolog中编写Prolog的性能差吗

没有直截了当的答案。事实上，问题中映射到Prolog的部分可能会比Prolog中的表现更差。为什么？因为Prolog的内部函数都是用Prolog编写的，而您的内部函数都是用Scheme编写的。正如@CommuSoft在

append/3

中指出的那样，内部函数的Prolog实现能够利用Prolog的优势。你将要在这些地方打一场艰苦的战斗。另外，我们的Prolog实现已经足够老了，已经花了几十年的时间来改进统一的性能，因为这是这里有趣的领域

同时，大多数实质性的Prolog程序最终都会有一些过程性的部分。这些比特可能与C或Scheme没有竞争性，因为它们优化起来没有那么有趣，因此需要在Scheme和ML中对此进行研究。所以你会在这些领域获胜

作为Scheme用户，我认为您会发现以Scheme样式编写程序更有利可图：功能性的，带有少量宏以给它一种声明性的感觉。如果你有一个问题对于Prolog来说是非常好的，你可以随时抛出它，但是把它和你程序的其他部分隔离开来。让你的语言成为你的语言

我不同意@ahuemmer关于C和Prolog的观点，因为人工是有限的，程序除了性能之外还有很多方面。C的作者成本要高得多，因此您将更难采用较差的策略，并最终导致代码灵活性较差。即使您将问题空间限制在较小且定义良好的范围内，Prolog程序员也会有更多的时间来试验和发现更好的解决方案，可能具有更好的时间复杂性。如果我们谈论的是无限量的劳动，那么C版本的性能可能会超过第一个Prolog版本。但是你必须考虑所有的维度。

---

总的来说，我认为让程序员适应语言比让语言适应问题更重要。

简单的暴力搜索在翻译成Prolog时仍然是简单的暴力搜索

没关系：纯Prolog非常适合描述和运行暴力搜索。尽管如此，用Prolog编写的暴力搜索可能无法击败任何暴力搜索的手工优化低级版本。另一方面，Prolog非常容易输入，您可能很快就会通过一些原型找到更好的搜索策略，而这些其他策略通常会轻易地以巨大的优势击败任何暴力实现。即使简单地翻译，Prolog也非常擅长回溯，并且在一些较低级别的代码中（更小或更大，取决于您使用的Prolog实现）能够有效地进行回溯

然而，Prolog在描述搜索问题时比许多其他语言具有的关键优势是约束：由于所谓的约束传播，搜索空间通常可以被显著地自动修剪。您不需要特殊规定：约束求解器将为您执行此操作

约束的承诺，以及在很大程度上已经变成现实的承诺，是：（1）你陈述了需求，（2）序言