锁定老帖子 主题:银弹的数学解释
该帖已经被评为良好帖
|
|
---|---|
作者 | 正文 |
发表时间:2009-09-02
3柯模哥罗夫复杂性 是一个程序语言,我们可以把等式(2)看作是寻找一个对于给定参数y输出结果x的最短程序。参数y对于度量 的长度没有什么贡献。忽略参数y,我们可以得到一个更简洁的表述, 这里是一个空字符串。 例如,我们可以选择Java作为描述系统的程序语言,那么对于某个字符串x,那么它的柯模哥罗夫复杂性就是可以输出x的最短Java代码的长度。为了确定是否使用库L可以缩短代码长度,我们可以考虑将Java和库L整合成一个描述系统,称为Java+L,然后比较CJava+L(x) 和CJava(x)的长度。显而易见的是,在这里选择什么语言是无关紧要的。
|
|
返回顶楼 | |
发表时间:2009-09-02
Trustno1 写道 houniao 写道 没看明白,挺抽象,不知道谁能不能用一个简单的比喻来描述一下
大师通常是能将复杂问题简单化的 偶不是"大师",赫赫。 那只能有空的时候自己花时间了解下了 呵呵 |
|
返回顶楼 | |
发表时间:2009-09-08
还有没??
|
|
返回顶楼 | |
发表时间:2009-09-08
事实3.2(不可压缩性[19, §2.2]) 设是一个整型函数且 .令x是一个随机平均选定的字符串。那么几乎可以保证
事实3.2 指出,可以将字符串压缩到 或者 (反阿克曼函数)的编码系统其存在的可能性为0. 事实3.2的证明仅仅使用了自然数系统地证明,而没有涉及到描述系统的可计算性。因此等式(3)可以应用在任意的描述系统上,甚至描述系统是不可计算的。比如说,如果我们在论述2.4节时允许使用一个无穷不可计算但是可枚举的库,那么事实3.2也是适用的。不过,它并不适用于像H值小于1时的非均匀分布情形。在本文的后半部分,我们应该假定编译后的程序在事实3.2的意义下都是不可压缩的。
推论3.1 在现有的主流计算结构下,编译后的C程序几乎都满足柯模哥罗夫不可压缩性。 注意,在某一个问题域上,”几乎都满足柯模哥罗夫不可压缩性”并不是在讨论某个特定的编译后程序的可压缩性,而是指如果一个人均匀地随机选取一个可用的编译后程序,那么以相同的方法找到一个更短的程序的可能性为0。在后续的章节里,我们主要研究的问题域是那些 非均匀分布的程序,比如H<1,此时这种不可压缩性的概率会有所改善。 我们对推论3.1做了一个不严谨的证明。这个证明指出,在当前的计算架构下,长度为sbit的编译后程序所描述的确切的行为数目的增长方式约为 。这个结果暗示了编译后程序几乎都满足柯模哥罗夫不可压缩性。C语言的特性非常有利于归并一个程序中的二进制块。比如说,一个二进制字符串z = 0110100111011010,可以用下面这种C语言的声明方式来进行编码。 unsigned char z[2] = {0x69, 0xda}; 此外,这种数组的可以按照邻接的二进制数据存放在编译后程序中,因此一个长度为m的二进制字符串会按照m byte精确的存放在编译后程序中。我们可以用一个长度为常数的小程序将这个数组打包。这个程序从内存中读取二进制字符串然后输出到console。每一个m byte长度的二进制字符串都可以用这样一个程序来表示,其最终长度为c+m bytes,这里c是一个常数表示读取打印工作所需要的额外代码消耗。每一个这样的程序都只会执行唯一的行为,因此sbit长度的编译后程序其确切的行为数目是 。我们可以将这种通过替换编译后程序的字符串的证明方式应用到事实3.2。它显示编译后的C程序几乎都满足不可压缩性。 注意,未编译过的程序都是高度可压缩的。比如,C语言的源代码可以不含有确定的长度,比如NULL字符0x00.这意味着他们可以(至少)压缩 。因此将我们的讨论的问题限制在编译后程序是非常必要的。 |
|
返回顶楼 | |
发表时间:2009-09-16
houniao 写道 没看明白,挺抽象,不知道谁能不能用一个简单的比喻来描述一下
大师通常是能将复杂问题简单化的 俺看了正文后第一个反应是──结论是什么?有没有简单的方法直接估计出我现在的工作是否有重用的可能。 后来意识到这是由于自己懒得动脑子的原因,嘿嘿,与大家共勉 |
|
返回顶楼 | |
发表时间:2009-09-16
lz 太有水平啦
|
|
返回顶楼 | |
发表时间:2009-09-17
不错很精彩,还有没??
|
|
返回顶楼 | |
发表时间:2009-09-18
看不懂,我基础知识不过关
|
|
返回顶楼 | |
发表时间:2009-09-19
t1的东西果然华丽~~ 立刻转出去震慑别人虽然我也没看 XD
|
|
返回顶楼 | |
发表时间:2009-09-23
fsword 写道 houniao 写道 没看明白,挺抽象,不知道谁能不能用一个简单的比喻来描述一下
大师通常是能将复杂问题简单化的 俺看了正文后第一个反应是──结论是什么?有没有简单的方法直接估计出我现在的工作是否有重用的可能。 后来意识到这是由于自己懒得动脑子的原因,嘿嘿,与大家共勉 结论在第4楼 引用 可复用性只跟领域内在的随机分布有关系,跟人为构造的程序结构没有关系,不是说你发明了NB的不得了的语言,类库或者模式就能提高软件的复用性。
直接估计出我现在的工作是否有重用的可能: 简单的方法 : 找有经验的专家咨询(如何保证其说的是真话?) 笨办法: 自己把所有的路走一变. 第3条路:外事不决问谷哥. |
|
返回顶楼 | |