学术技术与工程技术是两码事

那那,本总现在在培训中心接受无聊的入职培训,就顺便免费给你上上逻辑课.

所谓的因果关系,逻辑学上都是有严格定义的.不是说你觉得能推出来就能推出来.鉴于你对数学的厌烦，本人就勉为其难用冗长而不严谨的中文来表述一下,没有A就没有B，A是B的本质.以及没有A就没有B,没有B就没有C，于是A就是C的本质之间的区别.

在因果关系问题上，最容易犯的错误是两个。一是将因果关系混同于充分/必要条件关系，在既不存在充分条件、也不存在必要条件的情况下，就认为不存在因果关系了。二是将因果关系混同于统计相关性关系，找到了数据上的正相关，就以为找到了因果关系。

这两种错误，前者通常对应于单个经验事件或比较直接的因果关联，后者通常对应于大量经验事件或比较复杂的因果关联。今天台上小妞比较PP，本总心情不错就给你讲讲前半段.后半段想听就付钱过来.

比如讲某甲将某乙从五楼上推下来，某乙落地后死掉了。通常情况下，某甲应该为此负责，因为我们认为某甲推某乙下楼是某乙死亡的原因。但如果用充分/必要条件关系来检验，这个因果关系就不成立。因为即使某乙不被推下去，他也未必不死，所以某甲推某乙下楼不是必要条件。另一方面，如果某乙落地的地方刚好是一个充气垫子，或者某乙身负绝世轻功，那么他即使被推下去也未必死，所以这里也不存在充分条件。

这和我们的常识显然是相悖的。由此可见，因果关系不一定是充分条件关系，也不一定是必要条件关系。在这里我们需要INUS定义，它可以帮助我们解决这一问题。

INUS定义是一个叫马奇的人提出来的，所以它也被称为“马奇定义”。INUS是它的定义的缩写：

An insufficient but necessary part of a condition which is itself unnecessary but sufficient for the result.（结果的一个不必要但是充分的条件中，一个不充分但是必要的组成部分）

这句话可以进一步简缩一下，就是：

所谓原因，就是结果的一个充分条件组中的一个必要组成部分。

也就是说，假设A和B是两个事件，那么在以下的情况下，我们称A是B的原因：

1、A加上其他某些事件，可以组成一个复合条件C，C是B的充分条件；

2、如果把A从C中间拿掉，C就不再是B的充分条件。

套用到我们上面的例子中，不难发现：

1、“某甲推某乙下楼”加上“楼下是硬地”加上“某乙不会绝顶轻功”是“某乙死亡”的充分条件；

2、单纯“楼下是硬地”加上“某乙不会绝顶轻功”不是“某乙死亡”的充分条件。

由此我们可以得到结论，“某甲推某乙下楼”是“某乙死亡”的原因。

当然，从上面我们也可以看出，一个结果通常不止一个原因。那么，什么是“主要原因”呢？被“辩证法”搞胡涂了的人可能会问这个问题。其实在逻辑上是没有什么“主要原因”可言的。只不过我们在实践中会根据语境来进行选择使用它们罢了。

比如“楼下没有充气垫子”和“某乙不会绝顶轻功”同样是“某乙死亡”的原因。但我们不会说某乙活该，或者去责问那块地的主人为什么不摆上一个充气垫子，这是因为我们在责任认定时，除了因果关系认定之外，还有“不能预计”、“不能选择”这样的免责条款。

那那,本总现在在培训中心接受无聊的入职培训,就顺便免费给你上上逻辑课.

所谓的因果关系,逻辑学上都是有严格定义的.不是说你觉得能推出来就能推出来.鉴于你对数学的厌烦，本人就勉为其难用冗长而不严谨的中文来表述一下,没有A就没有B，A是B的本质.以及没有A就没有B,没有B就没有C，于是A就是C的本质之间的区别.

在因果关系问题上，最容易犯的错误是两个。一是将因果关系混同于充分/必要条件关系，在既不存在充分条件、也不存在必要条件的情况下，就认为不存在因果关系了。二是将因果关系混同于统计相关性关系，找到了数据上的正相关，就以为找到了因果关系。

这两种错误，前者通常对应于单个经验事件或比较直接的因果关联，后者通常对应于大量经验事件或比较复杂的因果关联。今天台上小妞比较PP，本总心情不错就给你讲讲前半段.后半段想听就付钱过来.

比如讲某甲将某乙从五楼上推下来，某乙落地后死掉了。通常情况下，某甲应该为此负责，因为我们认为某甲推某乙下楼是某乙死亡的原因。但如果用充分/必要条件关系来检验，这个因果关系就不成立。因为即使某乙不被推下去，他也未必不死，所以某甲推某乙下楼不是必要条件。另一方面，如果某乙落地的地方刚好是一个充气垫子，或者某乙身负绝世轻功，那么他即使被推下去也未必死，所以这里也不存在充分条件。

这和我们的常识显然是相悖的。由此可见，因果关系不一定是充分条件关系，也不一定是必要条件关系。在这里我们需要INUS定义，它可以帮助我们解决这一问题。

INUS定义是一个叫马奇的人提出来的，所以它也被称为“马奇定义”。INUS是它的定义的缩写：

An insufficient but necessary part of a condition which is itself unnecessary but sufficient for the result.（结果的一个不必要但是充分的条件中，一个不充分但是必要的组成部分）

这句话可以进一步简缩一下，就是：

所谓原因，就是结果的一个充分条件组中的一个必要组成部分。

也就是说，假设A和B是两个事件，那么在以下的情况下，我们称A是B的原因：

1、A加上其他某些事件，可以组成一个复合条件C，C是B的充分条件；

2、如果把A从C中间拿掉，C就不再是B的充分条件。

套用到我们上面的例子中，不难发现：

1、“某甲推某乙下楼”加上“楼下是硬地”加上“某乙不会绝顶轻功”是“某乙死亡”的充分条件；

2、单纯“楼下是硬地”加上“某乙不会绝顶轻功”不是“某乙死亡”的充分条件。

由此我们可以得到结论，“某甲推某乙下楼”是“某乙死亡”的原因。

当然，从上面我们也可以看出，一个结果通常不止一个原因。那么，什么是“主要原因”呢？被“辩证法”搞胡涂了的人可能会问这个问题。其实在逻辑上是没有什么“主要原因”可言的。只不过我们在实践中会根据语境来进行选择使用它们罢了。

比如“楼下没有充气垫子”和“某乙不会绝顶轻功”同样是“某乙死亡”的原因。但我们不会说某乙活该，或者去责问那块地的主人为什么不摆上一个充气垫子，这是因为我们在责任认定时，除了因果关系认定之外，还有“不能预计”、“不能选择”这样的免责条款。

你还别说,现在真有一个热门的行当叫做模型验证.去年图林奖的得主Edmund M. Clarke的专攻项目.这个问题忽悠不忽悠,可以去和图灵奖评审委员会较较真.
另外这方面,目前工程化和应用化的做的也不错.Standford的 Dawson Engler 的一篇Paper拿到了OSDI08的Best Paper award .具体的可以看这里.
http://www.usenix.org/events/osdi08/tech/full_papers/cadar/cadar.pdf

KLEE可以为任意source code自动生成覆盖率达90%以上的Test Case。

Dawson自己对这篇paper的评价是：This is one of the very best we've done in the past ten years。当然人家也不是吹牛的.这个人现在是bug finding方面是个超级明星，他的工具为Linux Kernel，OpenBSD，EXT3等等找出了400百多个bug，他还用自己的研究成果startup了一个叫Coverity专做source code static analysis的公司，生意十分红火。

除了现有的算法成果以外,model checking仍然是一个有待深入探索的问题.比如Model checking的关键问题是test case的state explosion,随着程序路径的增加，测试状态呈几何级数增加.怎么降低状态数量,除了现在局部优化算法外最有希望的就是引入代数几何.http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.49.2570.不远的将来的测试工作就不再是依靠人肉苦力的堆积,而是需要专业的几何学家为工程师们设计自动化算法.

所以凡是你现在认为机器不可能做到需要以人类优雅高深的哲学思想解决的事情,都是计算机科学家数学家们现在捞钱的金饭碗.

这里的数据结构说白了就是建模

不要说你在这里发贴的本质就是你妈
了解一下什么叫哲学概念上的意识

真的比较可怜在学术圈子里浸淫过久跑到工程圈子的人，要是一直在学术圈子那是让人敬佩，但跑到工程圈子里来指手画脚恐怕就要被人笑话了。
工程这路子人有时会提一个名词：toy，知道是什么么？玩具。
玩具是什么？好看，也能干点事，就是真章的时候没法用。