《数学之美》第一章读后感+代码规范总结

《数学之美》第一章读后感

我在几个月之前看了《数学之美》前几章,彼时它给我的震撼是很大的,因为它从建模的思想告诉了我计算机发展到现在很多算法的设计都是有生活原型的。那时候我就在想,得好好看看数学建模的视频和资料,好好看看《数学之美》这本书。但是后来也没再看下去。

 

借着写作业的机会,我再次打开了这本书,看完了第一章:文字和语言vs数字和信息。

 

第一章讲述了文字、语言是如何与数字、信息联系在一起的。

 

远古时期人类用声音提醒同类注意危险其中信息的产生、传播和反馈与今天最先进的通信在原理上没有任何的差别。说话人发声相当于编码,通过空气传播相当于信道,再经过接收者理解相当于解码。

 

语言和词汇多到一定程度的时候,因为人类记不住所有的,于是记录信息的载体——文字便诞生。

 

信息革命在5000甚至10000年前的非洲,最早保存信息的方式——图形。

 

还是因为记不住,概念的第一次概括和分类就开始了,例如“日”本意是太阳,表示一天。这种概念的聚类,在自然语言处理和机器学习的聚类有很大的相似性。只不过,远古人类可能需要几千年,但是计算机只需要几小时至几天。

 

因为聚类,所以产生了歧义。而辨别歧义的最好方法便是根据上下文。

 

翻译这件事之所以能达成,仅仅是因为不同的文字系统在记录信息的能力上是等价的。文字只是信息的载体,而非信息本身。

 

信息的冗余是信息安全的保障。罗塞塔石碑上的内容是同一信息重复三次,因此只要有一份保存下来,信息就不会丢失。这段历史也是为什么很多翻译软件和服务部叫“罗塞塔”。

 

我们采用十进制的原因是以为古人最初的计数方式是掰指头,如果我们有十二根指头,那我们今天采取的就是十二进制了。

 

玛雅文明把脚趾头也用上了,所以他们是二十进制。

 

十进制背九九乘法表,二十进制就是19×19了,很少人能背出来,这也是玛雅文明发展缓慢的一个原因。

 

在中国解码的规则是乘法(更高明)。在罗马,解码的规则是左减右加,比如,IV就是5-1+4,VII就是5+2=7。

 

阿拉伯数字是古印度发明的,阿拉伯人传入欧洲。它的革命性不仅在于简洁有效,还在于数字和文字的分离。

 

几十个字母的语言成为了欧亚大陆语言体系的主体,因此,今天我们把所有西方的拼音文字称为罗马式的语言。从象形文字到拼音文字是一个飞跃,因为标志着人类在描述物体的方式上,从物体的外表进化到了抽象的概念。

 

拼音文字和意型文字(汉字)常用字短,生僻字长,这完全符合信息论中的最短编码原理。

 

因为书写材料的珍贵难得,古时的书面文字总是简短且难懂,但口语却和我们今天的白话相差不大。这种现象非常符合今天信息科学的一些基本原理:如果信道较宽,信息不必压缩就可以直接传递;如果信道很窄,信息在传递前需要尽可能地压缩,然后在接收端进行解压缩。这个现象与我们今天宽带互联网和移动互联网上的视频播放设定完全一致,前者是经过宽带传输,因此分辨率可以做得高得多;后者由于空中频道带宽的限制,传输速度要慢到一到两个数量级,因此分辨率要低得多。

 

犹太人发明的类似于我们今天计算机额和通信中校验码的方也让我大开眼界。

 

莎士比亚原著打败完善本的历史证明语言大于语法。

 

以上就是我总结的第一章的内容。这部分内容用浅显易懂的语言概括讲述了语言、文字、数字、信息的历史与联系,内容全面而丰富,也是我的《数学之美》启蒙章节。

 

 

 

代码规范总结

腾讯公司代码规范:

 

Java:

1、 首先,代码都要做到:代码要缩进;变量的命名要有意义;要有适当的注释。

2、 达意>简洁

3、 骆驼法则:单词之间不使用特殊符号分割,而是通过首字母大写来分割。比如: SupplierName, addNewContract,而不是 supplier_name, add_new_contract。

4、 尽量使用通俗易懂的英文单词,如果不会可以向队友求助,实在不行则使用汉语拼音,避免拼音与英文混用。比如表示归档,用archive比较好, 用pigeonhole则不好,用guiDang尚可接受。

5、 注释应该少而静。另外,我有一个坏习惯,就是不要或者不确定的代码喜欢注释掉,但是注释不是用来管理代码版本的,如果有代码不要了,直接删除,svn会有记录的,不要注释掉,否则以后没人知道那段注释掉的代码该不该删除。

6、 每个if while for等语句,都不要省略大括号{}

看下面的代码:

if (a > b)

a++;

如果在以后维护的时候,需要在a > b 时,把b++,一步小心就会写成:

if (a > b)

a++;

b++;

这样就错了,因为无论a和b是什么关系,b++都会执行。 如果一开始就这样写:

if (a > b) {

a++;}

相信没有哪个笨蛋会把b++添加错的。而且,这个大括号使作用范围更明显,尤其是后面那行很长要折行时。

7、在需要留空的地方放一个空语句或注释,告述读者,你是故意的

比如:

if (!exists(order)) {

;

}

或:

if (!exists(order)) {

//nothing to do

}

8、???减少嵌套的方法有很多:

合并条件
利用 return 以省略后面的else
利用子方法

9、???善用TODO:

在代码中加入 //TODO: ,大部分的ide都会帮你提示,让你知道你还有什么事没有做。比如:

if (order.isPaid()) {
//TODO: 更新订单
}

 

 

c++:

1、 不允许把多个短语句写在一行中, 即一行只写一条语句。

2、 程序块要采用缩进风格编写, 缩进的空格数为4个。说明: 对于由开发工具自动生成的代码可以有不一致。

3、  对齐只使用空格键, 不使用TAB键。

4、 在两个以上的关键字、变量、常量进行对等操作时, 它们之间的操作符之前、之后或者前后要加空格; 进行非对等操作时, 如果是关系密切的立即操作符(如->), 后不应加空格。

说明: 采用这种松散方式编写代码的目的是使代码更加清晰。

由于留空格所产生的清晰性是相对的, 所以, 在已经非常清晰的语句中没有必要再留空格, 如果语句已足够清晰则括号内侧(即左括号后面和右括号前面)不需要加空格, 多重括号间不必加空格, 因为在C/C++语言中括号已经是最清晰的标志了。

在长语句中, 如果需要加的空格非常多, 那么应该保持整体清晰, 而在局部不加空格。给操作符留空格时不要连续留两个以上空格。

5、对于变量命名, 禁止取单个字符(如i、j、k… ), 建议除了要有具体含义外, 还能表明其变量类型、数据类型等, 但i、j、k 作局部循环变量是允许的。
说明: 变量, 尤其是局部变量, 如果用单个字符表示, 很容易敲错(如i写成j), 而编译时又检查不出来, 有可能为了这个小小的错误而花费大量的查错时间。

 

 

竞赛规范:

 

整体规范
1. 空行:在长代码的条件下,若代码量较大,应给不同作用的代码块中间用适当的空行隔开。若代码量过大,因适当的使用函数。

2. 括号:左括号不换行。

3. 缩进:推荐用两个空格作为缩进。

5. 变量名/函数名:(1) 应使用和作用有关的英文,可由多个单字组成。

(2) 简单变量名(一两个字母)应作用明显,不宜过多。

(3) 推荐使用大驼峰命名法(帕斯卡命名法):多个单词组成的名字应每个单词首字母大写。

例如 a, b, c, d 此类命名不宜过多。

首字母大写:PrintEmployeePaychecks()

下划线:print_employee_paychecks()

错误:Print_Employee_Paychecks()(下划线 + 首字母大写)、printemployeepaychecks() (全小写)

5. 成对书写:输入'()','[]','{}' 时应成对输入,避免疏漏。

6. 注释:注释时,'//' 应与代码行相隔两个空格,'//'后再添加一个空格。若在一行上,不宜过长。若有条件,推荐使用英文注释。

int left = 1, right = n; // left is the leftmost index of Array;
7. 对齐:应严格按照代码格式进行缩进。'{' 不换行,且每个 '{}' 直接的代码块应增加一个缩进格式!

8. 空格:每个运算符的两旁应严格增加一个空格,由逗号分隔的多个表达式前,严格用一个空格!(第一个表达式除外)

例如:if (a == b)、sum += a;、a && b、power(a, b, c, d, c + 1) 红色下划线处均为一个空格。

 

细节规范
1. 头文件:引入头文件,"#include" 与 "<...>" 之间应有一个空格。

#include <cstdio>
#include <cstring>
#include <iostream>
#include <algorithm>
2. 定义常量:若题目已经给定常量,应用 "const" 类型定义,并给上界适当留出空间。

const int maxn = 1e5 + 10;
const int mod = 1e9 + 7;
3. 重命名:若题目需要使用到 long long ,应使用 "LL" 进行重命名。

posted @ 2021-09-12 22:38  庞小凤  阅读(151)  评论(0编辑  收藏  举报