我没有得到Golomb/Rice编码:它确实输入了更多的输入,或者是它?

Han*_*etz 12 compression

或者,也许,我没有得到的是一元编码:

Golomb或Rice编码中,N通过将数字除以另一个数字将数字拆分为两部分M,然后将该除法的整数结果编码为一元,其余为二进制.

在Wikipedia 示例中,它们使用42 as N和10 as M,因此我们最终q得到4(在一元中:1110)和r2 的余数(在二进制010中)的商,因此得到的消息是1110,010或8位(可以跳过逗号).42的简单二进制表示是101010或6位.

对我来说,这似乎是由于一元表示q总是必须比二进制更多位.

显然,我在这里错过了一些重要的观点.它是什么?

Han*_*etz 22

重要的一点是,Golomb代码并不意味着比一个特定数字的最短二进制编码短.相反,通过提供特定种类的可变长度编码,如果编码值来自大范围,则它们与固定宽度编码相比减少了每个编码值的平均长度,但是最常见的值通常很小(因此是在大多数情况下仅使用该范围的一小部分).

例如,如果要传输0到1000范围内的整数,但绝大多数实际值在0到10之间,则在固定宽度编码中,大多数传输的代码都会有前导不包含任何信息的0:

要覆盖0到1000之间的所有值,需要使用固定宽度二进制的10位宽编码.现在,由于您的大多数值都低于10,因此至少大多数数字的前6位将为0并且将携带很少的信息.

要使用Golomb代码对此进行纠正,可以将数字除以10,然后分别编码商和余数.对于大多数值,所有必须传输的是剩余部分,最多可以使用4位进行编码(如果使用截断的二进制数,则余数可以更少).然后,商在一元中传输,0对于10以下的所有值,编码为单个位,10对于10..19,110对于20..29等.

现在,对于大多数值,您已将消息大小减小到最多5位,但您仍然能够在没有分隔符的情况下明确地传输所有值.

这对于较大的值来说成本相当高(例如,990..999范围内的值需要100位商数),这就是为什么编码对于双侧几何分布是最佳的.

可以使用随后的行程编码来解决较大值的商中的1位长行程.但是,如果商在结果消息中占用太多空间,则可能表示其他代码可能比Golomb/Rice更合适.