香农编码(人与人工智能)

香农编码，人与人工智能？

有意思的话题，但是表述有点含糊。含糊在于：聪明你是如何定义的？如果说类似于《最强大脑》中能够具有超强心算和敏锐的辨别能力的话，人工智能已经在很多领域比人类“聪明”了。

我们不妨换个表述，人类和AI哪个更“智慧”？

人类与动物的本质区别是：人类创造文明后，并非被动地去适应大自然发展，而是发明了各种各样的工具去改造大自然，以更好地让人类延续。

其次，人类发明了语言，通过语言和共同想象（《人类简史》观点），个体被连接成群体，通过群体智慧，发明了更多更先进的用于改造大自然的工具，让人类更好地在地球生存。

为了让知识能被更好地传递，人类发明了纸和笔来记录信息。到了计算机时代，人类发明了硬盘用来存储数据。

如果不考虑材料、能源的消耗和损坏，我们可以将文字和图像以二进制的形式编码写入硬盘，通常这种存储方式在很多方面被认为是优于人类大脑的，至少不会遗忘。

那么，是否有可能，人们也能发明一种机器思考的方式？甚至像硬盘一样，这种思考方式会优于人类大脑？

人类和机器思考方式的不同，在于人类的思考方式是发散性的。比如看到一副画，人类第一感觉可能是这副画美不美，带给我什么感觉？甚至有的人会因此触发其它方面的灵感。但是机器不这么理解，它会去识别画中有哪些物体，形状、数量、颜色……通通把信息变成二进制的数字来表述去识别。

这样看来，人类和人工智能哪个更“智慧”？

人与机器最主要的区别在于人是感性的，人的智慧主要来源于感性层面，而机器再强大，也只能是纯理性的，当有一天机器具备全方位的感性思维时才能被称为“智能”，否则也只是一个算法工具而已。

我们刚才称之为灵感的东西，其实就叫做“创造力”。人类的创造力绝大多数来源于“遐想”。

那么是否有可能写出让机器“遐想”（类似于《西部世界》的“沉思”）的程序？它被创造出来唯一的目的就是遐想，看到照片它可以选择识别出其中有树有水，也可以想到可能和某一个文学作品或艺术作品描绘的场景很像，然后根据不同的路径得出不同的结果。刚开始也许它就像一个3岁的孩子一样胡说八道，也许渐渐地它会形成自己固有的思考路径（算是审美和性格吧）。这样乱想下来觉得，也许创造力本身就来源于对信息的“偏向性”吸收和整合吧，一个全知全能的程序可能永远不懂得创造。

人类的想象力是受限的

AI可能很难学会情感，但我总相信创造力会被归于计算。人类的想象力是受限的，我们无法想象自己从未见过的东西，从远古的图腾到现代的科学发明，所有虚构都建立在真实事物的基础上。这跟机器学习非常相似。刘慈欣在诗云里勾画了外星人穷尽地球的能量，想要计算出最美的诗却失败了的故事，失败是因为计算没有情感，但创造力实际已经被计算代替了。

目前的AI的智能，充其量不超过一个一到三岁的孩子，而且还极其偏科。但是当视觉识别，听觉识别，触觉味觉识别的人工智能水平都上来，再加上通用学习能力的算法和超大规模的数据，有朝一日，计算机也是可以拥有情感和创造力的，不过这一天其实还早，我们现在连什么是创造力自己都还说不清。

创造力或许和大数据有关

但是，创造力和大数据肯定是有交集的。比如有时候我听到了一首歌曲给了我创作文章的灵感，创造力（创新）就是在人脑所有的数据集中不分类别的进行连接。这也是让我觉得最后计算机自己也能创新的原因。

所以，AI最终是会有创造力的，它会是一个能打败除人类创造力精英（神人？）之外的新物种。

到了那个时候，是否还有人会纠结于人类和AI哪个更“聪明”？

香农定理是什么？

香农定理（Shannon's Theorem），也称为信息论基本定理，是由美国数学家克劳德·香农（Claude Shannon）在1948年提出的。它是信息论的重要基石，描述了信息传输的极限。

香农定理主要内容如下：

1. 信息的度量：香农引入了“位”（bit）作为信息的度量单位，一个位代表一个二元选择的信息。

2. 信源熵：对于一个具有离散概率分布的离散信源，其熵（entropy）用来衡量其自身产生的不确定性或者信息量。

3. 信道容量：香农定理给出了信道的理论极限容量，即在给定的信噪比条件下，信道可以传输的最大信息速率。

简而言之，香农定理揭示了信息传输的理论极限。它指出，在给定的信道条件下，我们可以通过编码和解码的方式最大化信息的传输速率，而且在这个速率以下，可以实现可靠的传输，即使信道存在噪音。

香农定理在通信领域有着广泛的应用，在无线通信、数据压缩、纠错编码等方面发挥着重要的作用。

信息论的创始人是谁？

1、信息论的创始人香农，被称为是“信息论之父”。

2、人们通常将香农于1948年10月发表于《贝尔系统技术学报》上的论文《通信的数学理论》作为现代信息论研究的开端。这一文章部分基于哈里·奈奎斯特和拉尔夫·哈特利先前的成果。

3、熵度量的是消息中所含的信息量，其中去除了由消息的固有结构所决定的部分，比如，语言结构的冗余性以及语言中字母、词的使用频度等统计特性。

4、信息论将信息的传递作为一种统计现象来考虑，给出了估算通信信道容量的方法。信息传输和信息压缩是信息论研究中的两大领域。这两个方面又由信道编码定理、信源－信道隔离定理相互联系。

传输信道的信道编码有哪些方式？

1、信道编码的种类主要包括：线性分组码、卷积码、级联码、Turbo码和LDPC码。

2、其中分组码又分为：汉明码，格雷码，循环码（BCH码，RS码，CRC循环冗余校验码。

信道编码，也叫差错控制编码，是所有现代通信系统的基石。

几十年来，信道编码技术不断逼近香农极限，波澜壮阔般推动着人类通信迈过一个又一个顶峰，信道编码在发送端对原数据添加冗余信息，这些冗余信息是和原数据相关的，再在接收端根据这种相关性来检测和纠正传输过程产生的差错，这些加入的冗余信息就是纠错码，用它来对抗传输过程的干扰。

程序出现bug是必然出现的情况？

程序出现bug，既不是必然现象，也不是程序员水平有限，而是一种正常现象，只要控制到合理范围内即可。

所有的软件、框架，基本都有bug，不然也不会有那么多的小版本进行维护升级。如阿里巴巴温少开源的FastJson，目前版本已经到了1.2.72。

我们可以看一下这个版本的发版说明，也解决了不少的bug。

更有甚者，到现在还有1334个未解决的问题，诚然，也不全是问题。

再如我们经常使用的强大如斯的Spring框架，不也每隔一段时间就发布一个小版本吗？不照样有bug存在，还得发布版本来解决bug嘛。

所以，并不是程序员水平有限。

什么是bug？

bug是计算机领域专业术语，bug原意是“臭虫”，现在用来指代计算机上存在的漏洞，原因是系统安全策略上存在的缺陷，有攻击者能够在未授权的情况下访问的危害。

漏洞是在硬件、软件、协议的具体实现或系统安全策略上存在的缺陷，从而可以使攻击者能够在未授权的情况下访问或破坏系统。具体举例来说，比如在Intel Pentium芯片中存在的逻辑错误，在Sendmail早期版本中的编程错误，在NFS协议中认证方式上的弱点，在Unix系统管理员设置匿名Ftp服务时配置不当的问题都可能被攻击者使用，威胁到系统的安全。因而这些都可以认为是系统中存在的安全漏洞。bug狭义的概念是指软件程序漏洞或缺陷，广义的概念还包括测试工程师或用户所发现和提出的软件可更改的细节、或与需求文档存在差异的功能实现等。

从bug的释义上，我们可以简单的了解到，其实bug并不可完全避免。相反，正是由于bug的出现和存在，软件才能不断的完善和升级，从而带给使用者更完美的体验。

那为什么会出现bug？

设计者考虑不全面

软件设计者在设计框架、或某个功能、接口时，未考虑到比较全面的情况。如保存个人信息时，有人在手机号项里填写了固话，而设计者未考虑全面，没有应对之策，只考虑了手机号的情况。

所以在用户填写了不符合要求的数据项时，就会出现问题。

开发者未考虑全面

比如开发者遇到需要判断用户类型的逻辑，判断了3种类型：司机、教师、医生，并且没有设置默认情况的对应逻辑。在非这三类用户如银行职员使用软件时，便会发生不匹配的异常，即bug。

测试者未测试到位

所谓测试，必须要在软件上线前，进行详细而周到的测试，并不是要完全消灭bug，而是要把bug降低到某个范围之内，如10个。当然，这就需要测试者要投入比较大的精力去设计测试用例，稍有不慎，便会漏掉某个情况，而漏掉的这个情况，就会恰巧被使用者遇到，即产生了bug。

以上都是大方面上的原因，当然，还有一些客观因素，上不得台面，为什么这么说呢，往下看看就知道了。

时间原因

大多数情况，都要求在最短的时间内，做出更多的成绩。要求你1天干完3天的工作量，说实话，这情况我也遇到过。结果可想而知，换来的效果并不理想，bug百出，客户发火，项目经理埋怨。其实，也没啥埋怨的，项目经理自己答应客户1天干完3天的工作量，然后又倒逼开发者半天就要做完，不是自找的？

说到这里，我前几年净遇到这样的情况了，多的是啥也不懂的项目经理，随意答应客户要求，包括时间要求等，可以说，害人害己。

在非常有限的时间里，要做完有限的工作量，除了囫囵吞枣，一气呵成，貌似也没有别的办法了，效果肯定不用想，好不到哪里去。

个人原因

不排除开发者马虎的因素。诚然，这个因素还占比比较大。作为程序员，严谨应该是第一要义。可有的程序员根本不当回事，以完成任务为第一要义，不管后果。这是非常不可取的。

领导原因

在程序员的日常工作中，被上司掣肘的情况时不时都会发生。更甚至，最怕遇到外行指挥内行的情况。不管会与不会，瞎指挥一通。完全要按照他的意愿来。最后，出了问题，依然是程序员背锅。

历史原因

这在旧项目中比较常见。俗话说，宁肯新造，不远挖旧。旧代码就想定时炸弹，改不好就会引起连锁反应，像大厦倾塌般不可救药。往旧代码上添加新功能，如履薄冰，战战兢兢。都已完成功能为第一要义，哪儿还管你开发原则、设计模式。

运营原因

运营搞错的情况也不是没有。前一段公司有个项目有个bug，这边一个同事修改好了之后，要求运营手工删除旧代码。结果运营就删了主类，没有删内部类。造成bug一直存在的情况，前前后后搞了好几天才解决，一直查不到原因，没想到最后是研发人员无奈登录服务器才看到的此情况，真是气煞人，也就是典型的业务能力问题，还不负责任。

其它原因

当然了，还有一些其它方面的原因，这里并没有罗列到。大家如有想到的，可以在评论里留言，共同探讨。

为啥说以上都是上不得台面的客观因素呢？因为公司和领导都是以结果为导向，从不管你是和原因，况且在他们眼里，这些都可以避免，好吧，我承认，只要花时间和金钱，真的可以避免。软件除了问题，难不成你要在领导和老板面前一直强调是谁的锅吗？当然，这场景每天不止一次的出现。

最后，不管是何客观因素，都不如修炼自身内功，保证自己层面不犯错误，才是当务之急。