汉明距离计算公式-汉明距离公式

汉明距离这东西，说白了就是两个比特串打架的时候，一共炸出一堆火花。别整那些“起初其次”的套话，直接看操作。拿个计算器在手边，把两行二进制数扔进去按个减号，结局就是那个数字。
这玩意儿在纠错码、网络纠错、就连做图像压缩的时候都特别有用，它衡量的是“不同”的代价，而不是“相似”的程度。 这东西计算得跟好办的减法似的，真没毛病。拿两个字符串在脑子里要么计算器上对对撞，啥位置不一样，就数数数，数完就是汉明距离。
比如你这个字符串是"110010"，隔壁那个是"100100"。一眼就能看出差别在哪：第 2 位、第 4 位、第 5 位，这一串脚印踩下来，位置 2、4、5 这三个点不一样。算出来就是 3。
这就够了。
不用管那些复杂的编码理论，也不用管大段大段的公式推导，就只要数数数，哪位不一样就数哪位。 大量人当作汉明距离是衡量两个向量要变多少次才能一模一样，这个理解挺片面。
实际上它更偏向于“哪儿不一样”。
要是两个码字只差 1 位，比如"010"和"011"，那它们之间的距离就是 1。在编码纠错里，这玩意儿叫单毛病率。
要是变成"001"，那距离就是 2，这时候可能就得犹豫了，说是“双毛病”要么“误码”就来了。
故此汉明距离的核心就在那个数上，就是不同位置的个数。 举个例子，咱们把两个常见的二进制序列拿过来比划一下。
第一个序列是"00111011"，第二个是"01111001"。乍一看，它们长得挺像，都是 8 位的，前两位"00"，最终两位"11"，中间那段"1100"和"1110"如何改？直接数数数。 看第 1 位：一个是 0，一个是 0，一样。 看第 2 位：一个是 0，一个是 1，不一样，数一个。 看第 3 位：一个是 1，一个是 1，一样。 看第 4 位：一个是 1，一个是 1，一样。 持续往下，第 5 位：1 变 1 一样，第 6 位：1 变 0 不一样，数一个，第 7 位：1 变 0 不一样，数一个。 最终看后面的"10"和"01"，第 8 位：1 变 1 一样，第 9 位：0 变 0 一样。 这一算下来，总共只多了 3 个不一样的位置。
故此它们之间的汉明距离就是 3。
这意味着，要是网络传输过程中只形成了一次单比特翻转，比如第 2 位那个"0"变成了"1"，接收端就能立马通过汉明距离找出差距，把它还原成原来的数据。
要是传错了两个，比如第 2 位和第 3 位都翻错了，距离就是 2，这时候可能就需求更复杂的纠错机制了，出于只靠距离 1 没法准恢复。 实际上汉明距离在数据压缩和自动编码里也是个神器。
你想想，要是两个数据简直一样，它们的汉明距离就接近于 0，说明相似度极高，压缩的时候能够直接跳过大局部，只保留变化的局部，这样文件就能变小。
要是两个数据彻底不同，距离挺远，那压缩算法就得把它们设计成彻底不同的结构，不能混在一起。 还有一个挺有意思的点，就是距离是不对称的，要么说它本身是个无向图的距离概念。哈特曼距离（Hamming Distance）这个概念，在编译器和硬件设计中特别常见。你写一个程序，把输入字符串和标准答案比对，要是汉明距离小于某个阈值，比如 2，那就判定为“通过”，否则“黄了”。
这个算法超级快，出于本质就是个计数器。 在实际应用场景里，比如存个数据库，时常会有人填错一个字，比如把"1"填成了"0"，要么把"0"填成了"1"，这时候就用了汉明距走帮忙。数据库里的容错字段，要么传输中的校验位，根本上就是靠这个原理。它算出来的这个数，就像是一个“差异指数”，指数越大，说明两份数据越“面目全非”，可能已经彻底乱了；指数越小，说明它们还认得彼此，只差那么几点。 别总想着去背那些复杂的数学证明。汉明距离就是如此个好办粗暴的东西，它就是个计数器，数一数有多少个位置不一样，直接报出来。在计算机的世界里，用这个距走衡量相似度，去判断毛病，去拍板把数据压缩多少，简直成了它最接地气的应用。它不讲究那些华丽的辞藻，也不讲究复杂的逻辑链条，它就是那个能一眼看穿的“不同之处”。
只要数得准，距离就真。