解决停滞不前的问题比人们想象的容易吗?

解决停滞不前的问题比人们想象的容易吗?

就像我认为的那样困难。

My dear, they already are!

依赖型看起来是一个好的发展?

我认为非图灵完备但可证明的语言可能会有增长。在相当长的一段时间里,SQL属于这一类(现在不再是这样了),但这并没有真正削弱它的实用性。我认为,这样的系统肯定有一席之地。

哇,这是个令人困惑的问题。

第一:停滞不前的问题不是一个实际意义上的“问题”,而是一个关于数学本质的陈述,类似于Gdel的不完全性定理。

第二:构建一个完美的病毒扫描器是很难解决的(因为它相当于停止问题),这正是“整个行业围绕着这个挑战而建立的”的原因。如果一个完美病毒扫描的算法能够被设计出来,那只需要有人做一次,然后就没有必要再建立一个产业了。故事结束了。

最后:如果这个问题能够以任何方式“解决”,它肯定会“比人们想象的要容易”,因为图灵证明了它是不可解决的。从数学的角度来看,一般情况是唯一相关的情况。具体案例是工程问题。

有很多程序可以解决停顿问题,而且这些程序很多都是有用的。

如果你有一个编译器会告诉你“停止”、“不停止”或“不知道”,那么它可以告诉你程序的哪个部分导致了“暂停”或“不知道”的情况。如果你真的想要一个绝对停止或没有停止的程序,那么你应该用消除编译器警告的方法来修复那些“不知道”单元。我想我们都会惊讶地发现,尝试解决这个普遍不可能解决的问题往往被证明是有用的。

作为一个日常的程序员,我想说继续下去是值得的 解决停滞不前的问题,即使你只接近这个极限,却永远达不到。正如你所指出的,病毒扫描证明是有价值的。谷歌搜索并没有假装是“为Y找到最好的X”的绝对答案,但它也非常有用。如果我释放一种新的病毒(muwahaha),这是创造一个更大的解决方案集,还是仅仅揭示了一个现有的问题领域?不管技术上有什么不同,有些人会务实地开发并收取后续的“检测和移除”服务。

科学的 其他问题的答案。。。

顺便说一句,我认为模板的图灵完备性表明暂停被高估了。大多数语言保证编译器会停止,而不是C++。这是否将C++作为语言减少了?我不这么认为;它有很多缺陷,但不总是停止的编译不是其中之一。

停顿问题只有在一般情况下才有意义,因为如果停顿问题是可判定的,那么所有其他不可判定的问题也可以通过约化来判定。

所以,我对这个问题的看法是,不,在重要的情况下这并不容易。也就是说,在现实世界中,这可能不是什么大事。

http://en.wikipedia.org/wiki/Halting_problem#Importance_and_consequences

我不知道人们认为这有多难,所以我不能说是否更容易。然而,你的观察是正确的,一个问题的不可判定性(一般来说)并不意味着该问题的所有实例都是不可判定的。例如,我可以很容易地告诉你 while false do something 终止(假设while和false的明显语义)。

像你提到的终结者项目这样的项目显然存在(在某些情况下甚至可能起作用),所以很明显并非所有项目都是无望的。还有一个竞争(我相信每年)的工具,试图证明重写系统的终止,重写系统基本上是一个计算模型。但事实上,在许多情况下,终止合同是很难证明的。

全部的 程序(以及许多其他有关软件的问题)并不意味着不值得寻找部分解决方案。从某种意义上说,这就是我们需要软件工程的原因:因为我们不能仅仅把任务委托给计算机。

此外,我们不必担心一般情况,这并不意味着终止问题被高估了:值得寻找部分解决办法 我们知道,总的解决办法很难。