在编程世界中哪些是几乎无法解决的问题？

Question

当节点数量增加时，

Travelling salesman problem被认为实际上是“无法解决的”。

哪些其他编程问题被认为无法解决？

Answer 1

首先，无法解决的问题和难以解决的问题之间存在很大差异。我知道这听起来很明显，但很多人将难以解决的问题（例如旅行推销员）标记为无法解决，因为更好地说它们无法有效解决，即在多项式时间内。

最着名的无法解决的问题是暂停问题。有关详细信息，请参阅this page。表明问题无法解决的一种常见技术是表明它等同于暂停问题。

Answer 2

Internet Explorer 6

Answer 3

The Halting Problem。证明无法解决。

Answer 4

为非交互式内容创建牢不可破的DRM，目标用户仍可使用该内容...

Answer 5

如果您正在寻找与旅行商问题类似的问题，那么我建议您谷歌解决NP完全问题。这是一类没有任何已知有效解决方案的问题，这意味着一种在多项式时间内计算结果的算法。 NP问题类的有趣之处在于，没有人能够证明任何解决它们的算法必须采用指数时间。这可能是计算机科学中最大的未解决的问题。

应该说，虽然通常很容易找到NP问题的 解决方案，但棘手的业务是找到最佳解决方案。

以下列出了其他NP完全问题：

• Bin包装，如何填充容器以使最佳数量的东西适合它。我认识一个经营公司的人，帮助船公司以最佳方式包装船只。他的程序找不到最佳解决方案，但通常可以帮助以更智能的方式包装船舶，而不是手动完成。
• SAT解决，表明命题公式是可满足的。这是一个相当理论上的问题，但英特尔用它来自动证明它们的电路设计是正确的。 SAT解决方案现在变得相当不错，可以很快解决相当大的问题。
• 安排，给定需要完成的工作数量以及完成这些工作所需的大量资源，可以计算出完成工作的最有效方法。航班人员必须经常解决这个问题，因为他们拥有自己的资源，人员和飞机，他们希望尽可能高效地使用，同时仍为所有航班提供服务。像杰普森这样的公司有优化这个的计划。
• 图形着色。采用无向图并尝试着色每个节点，使得边缘连接的两个相邻节点没有相同的颜色。目标是使用尽可能少的颜色。编译器使用它将寄存器分配给局部变量。图着色算法越好，得到的寄存就越多，而不是存储在寄存器中。

我可以继续，但我认为我所知道的其他大多数问题都是理论上的。你最好自己去谷歌搜索。

Answer 6

任何算法都无法解决不可判定的问题。

http://en.wikipedia.org/wiki/Undecidable_problem

NP完全问题可以在多项式时间内非确定性地求解。所以它们确实是可以解决的，特别是在量子计算机上很快。

不可判断问题的例子包括Halting问题，它说：给定一个算法，决定算法最终是终止还是继续（例如：在无限循环中）。阿兰·图灵证明了停机问题是不可判定的。

Answer 7

试图找到一个对他们编写的代码感到满意的开发人员！

Answer 8

正如许多人已经回答的那样，无法解决的问题是停止问题：编写程序H，将程序P作为输入并回答是否输入程序{ {1}}将永远循环或不循环。请注意，我们的程序P可以正确回答许多输入程序，但挑战在于编写一个可以为所有程序回答这个问题的程序。

为什么暂停问题无法解决？证明非常简单而且很有趣： 假设我们可以编写解决暂停问题的程序H。 （目标是通过假设我们将产生仅仅是无意义的结果，因此我们的假设是错误的。）现在，构造一个使用H作为子例程的程序EVIL。我们可以像这样写H：

EVIL

按顺序进行简要说明。 EVIL p = if H p then loop else false 接受一个程序，如果该程序停止，则EVIL循环。输入程序永远循环，然后EVIL返回false。

下一步非常酷：将EVIL应用于自身！问题是，EVIL的答案是什么？这显然取决于EVIL EVIL是否永远循环。让我们考虑两种选择：

• 假设EVIL永远循环。但是当我们将feed作为输入程序时，它必须返回EVIL，因为false检测到它将永远循环。但是返回H与我们刚才所说的false永远循环相矛盾，所以显然情况并非如此。

• 好的，EVIL不会循环。好吧，当我们向自己提供EVIL时，它会循环，因为EVIL返回了H。所以我们在这里也有矛盾。

无赖！两种选择（true循环或它不会）导致矛盾。所以我们的假设必定是错误的。没有EVIL这样的程序可以决定函数是否停止。

---

有很多有趣的问题是由于停止问题而无法计算的。我最喜欢的一些来自编译器技术。例如：找到最小的等效程序。

另一个是：假设您已使用断言对程序进行了注释，请编写一个程序，检查是否在运行时违反了任何断言。这样的程序有时被称为模型检查程序，它们可能非常有用，但它们永远不会完整，即当问题变得太难时，它们有时必须回答“我不知道”。

Answer 9

我发现knapsack problem特别有趣，因为它适用于许多不同的域名。

Answer 10

获取所有三个：范围（功能），时间范围（计划），预算（资源开发人员）;而不是“挑两个”。

Answer 11

NP Complete问题就是这样。

Answer 12

让程序员记录他们的代码。

Answer 13

Post Correspondence Problem：

给定两个单词列表（a1，a2，..，an）和（b1，b2，..，bn），找到一系列索引，以便连接的单词相等。

E.g。鉴于列表（1：a，2：ab，3：bba）和（1：baa，2：aa，3：bb），序列（3,2,3,1）是解决方案，因为bba + ab + bba + a = bb + aa + bb + baa。

这个问题看起来应该有一个算法来解决它（我们只是谈论找到一个序列，以便字符串匹配，没有像图灵机那样复杂）;但它就像停止问题一样不可判断。

Answer 14

实际上，NP-complete问题，比如旅行推销员，很难解决一般，而是一个特定的实例（甚至是某些领域的大多数实例） [例如编译Haskell代码]）可能很容易解决！

从理论上讲，有很多问题非常困难 - 但是由于困难的案例非常罕见且相当人为，所以它们实际上很容易解决。我觉得特别有趣的两个例子是NP完全。 Haskell中的类型检查就是其中之一：事实上，Haskell中的一般类型推断比NP完全更糟糕：类型验证是NP完全的;类型推断是NP难的。但在实际代码中，它实际上是近似线性的。另一个是称为3-SAT的逻辑问题。我曾经参加过一个名叫Daniel Jackson的人的精彩演讲，谈论他设计的一种名为Alloy的正式规范语言。 Alloy将其规格检查降低到3-SAT。丹解释了这句话：“坏消息是，分析Alloy规格是3-SAT，所以它是指数和NP完全。但好消息是分析Alloy规格是3-SAT，所以我们可以很快解决它

- MarkCC

Answer 15

并非所有编程语言都可以解决问题。例如，我宁愿用perl然后使用applescript做一个regrep。大多数编程语言（如PHP）都有“错误”，直到php团队中的某个人修复了php引擎才能解析。

他可能意味着代码变得非常复杂并且不值得完成项目，因为它花费了太多时间

Answer 16

许多答案都提到Halting Problem。其他无法解决的问题包括languages not accepted by Turing machines。这种语言的一个例子是图灵机器的语言，它不接受自己的编码。