我有一组整数,我想拥有最紧凑的表示。 我有以下约束/功能:
我尝试了一些事情,但我对结果并不满意,而且我确信存在更好的解决方案:
我很高兴听到你的任何想法。提前谢谢!
更新:
事实证明,delta编码似乎接近最优解。对于集合中元素的其他其他分布,这可能会有所不同。
答案 0 :(得分:10)
您可以通过计算来了解您可以做的最好的事情。 (我希望stackoverflow允许TeX方程像math.stackexchange。无论如何......)
ceiling(log(Combination(2^32,1000)) / (8 * log(2))) = 2934
因此,如果正如您所说的那样,选择是均匀分布的,那么对于该特定情况,您可能希望的最佳压缩是2934字节。最佳比率是4000字节的未编码表示的73.35%。
Combination(2^32,1000)
只是压缩算法可能输入的总数。如果它们是均匀分布的,那么最佳编码是一个巨大的整数,它通过索引标识每个可能的输入。每个巨型整数值唯一地标识其中一个输入。想象一下,在巨大的表格中按索引查找输入。 ceiling(log(Combination(2^32,1000)) / log(2))
是索引整数所需的位数。
更新
我找到了一种使用现成的压缩工具接近理论最佳的方法。我排序,应用delta编码,并从中减去一个(因为连续的不同元素之间的差值至少为1)。然后诀窍是我写出所有高字节,然后是下一个最重要的字节,等等。增量的高字节减去一个往往是零,所以将很多零组合在一起,这是标准压缩实用程序所喜爱的。此外,下一组字节往往偏向低值。
对于示例(1000个统一且不同的样本来自0..2 ^ 32-1),通过gzip -9
运行时平均得到3110个字节,通过xz -9
得到3098个字节( xz使用与7zip相同的压缩LZMA。这些非常接近2934的理论最佳平均值.Gzip也有18字节的开销,而xz的开销为24字节,包括头文件和预告片。因此,对于gzip -9
和xz -9
的3074,与理论上最佳的更公平的比较将是3092。比理论上最好的大约5%。
更新2:
我实现了排列的直接编码,平均达到了2974个字节,比理论上最好的只有1%多一点。我使用GNU multiple precision arithmetic library来编码一个巨大整数中每个排列的索引。编码和解码的实际代码如下所示。我为mpz_*
函数添加了注释,从名称中可能并不明显它们正在做什么算术运算。
/* Recursively code the members in set[] between low and high (low and high
themselves have already been coded). First code the middle member 'mid'.
Then recursively code the members between low and mid, and then between mid
and high. */
local void combination_encode_between(mpz_t pack, mpz_t base,
const unsigned long *set,
int low, int high)
{
int mid;
/* compute the middle position -- if there is nothing between low and high,
then return immediately (also in that case, verify that set[] is sorted
in ascending order) */
mid = (low + high) >> 1;
if (mid == low) {
assert(set[low] < set[high]);
return;
}
/* code set[mid] into pack, and update base with the number of possible
set[mid] values between set[low] and set[high] for the next coded
member */
/* pack += base * (set[mid] - set[low] - 1) */
mpz_addmul_ui(pack, base, set[mid] - set[low] - 1);
/* base *= set[high] - set[low] - 1 */
mpz_mul_ui(base, base, set[high] - set[low] - 1);
/* code the rest between low and high */
combination_encode_between(pack, base, set, low, mid);
combination_encode_between(pack, base, set, mid, high);
}
/* Encode the set of integers set[0..num-1], where each element is a unique
integer in the range 0..max. No value appears more than once in set[]
(hence the name "set"). The elements of set[] must be sorted in ascending
order. */
local void combination_encode(mpz_t pack, const unsigned long *set, int num,
unsigned long max)
{
mpz_t base;
/* handle degenerate cases and verify last member <= max -- code set[0]
into pack as simply itself and set base to the number of possible set[0]
values for coding the next member */
if (num < 1) {
/* pack = 0 */
mpz_set_ui(pack, 0);
return;
}
/* pack = set[0] */
mpz_set_ui(pack, set[0]);
if (num < 2) {
assert(set[0] <= max);
return;
}
assert(set[num - 1] <= max);
/* base = max - num + 2 */
mpz_init_set_ui(base, max - num + 2);
/* code the last member of the set and update base with the number of
possible last member values */
/* pack += base * (set[num - 1] - set[0] - 1) */
mpz_addmul_ui(pack, base, set[num - 1] - set[0] - 1);
/* base *= max - set[0] */
mpz_mul_ui(base, base, max - set[0]);
/* encode the members between 0 and num - 1 */
combination_encode_between(pack, base, set, 0, num - 1);
mpz_clear(base);
}
/* Recursively decode the members in set[] between low and high (low and high
themselves have already been decoded). First decode the middle member
'mid'. Then recursively decode the members between low and mid, and then
between mid and high. */
local void combination_decode_between(mpz_t unpack, unsigned long *set,
int low, int high)
{
int mid;
unsigned long rem;
/* compute the middle position -- if there is nothing between low and high,
then return immediately */
mid = (low + high) >> 1;
if (mid == low)
return;
/* extract set[mid] as the remainder of dividing unpack by the number of
possible set[mid] values, update unpack with the quotient */
/* div = set[high] - set[low] - 1, rem = unpack % div, unpack /= div */
rem = mpz_fdiv_q_ui(unpack, unpack, set[high] - set[low] - 1);
set[mid] = set[low] + 1 + rem;
/* decode the rest between low and high */
combination_decode_between(unpack, set, low, mid);
combination_decode_between(unpack, set, mid, high);
}
/* Decode from pack the set of integers encoded by combination_encode(),
putting the result in set[0..num-1]. max must be the same value used when
encoding. */
local void combination_decode(const mpz_t pack, unsigned long *set, int num,
unsigned long max)
{
mpz_t unpack;
unsigned long rem;
/* handle degnerate cases, returning the value of pack as the only element
for num == 1 */
if (num < 1)
return;
if (num < 2) {
/* set[0] = (unsigned long)pack */
set[0] = mpz_get_ui(pack);
return;
}
/* extract set[0] as the remainder after dividing pack by the number of
possible set[0] values, set unpack to the quotient */
mpz_init(unpack);
/* div = max - num + 2, set[0] = pack % div, unpack = pack / div */
set[0] = mpz_fdiv_q_ui(unpack, pack, max - num + 2);
/* extract the last member as the remainder after dividing by the number
of possible values, taking into account the first member -- update
unpack with the quotient */
/* rem = unpack % max - set[0], unpack /= max - set[0] */
rem = mpz_fdiv_q_ui(unpack, unpack, max - set[0]);
set[num - 1] = set[0] + 1 + rem;
/* decode the members between 0 and num - 1 */
combination_decode_between(unpack, set, 0, num - 1);
mpz_clear(unpack);
}
有mpz_*
函数可以将数字写入文件并将其读回,或将数字导出到内存中的指定格式,然后将其导回。
答案 1 :(得分:2)
主题仍然打开吗?
我正在为此工作。
(PS:我是游戏创作者,而不是数学家)
几个星期以来无法睡个好觉,因为我想知道为什么我们不使用A ^ B + C变体(或其他)来压缩图像和信息。
我的乌托邦目标是通过使用不太可能的从计算机GPU创建的A ^ B + C公式组合来压缩4.600.000数字。 基本上,我尝试这样做是因为它可以在不超过30 fps的情况下通过Wifi在不小于100字符的情况下存储/流式传输小图像,而不会浪费带宽。
我的现实目标是将200位数字压缩为<5个字符。
PS:为此,我已经创建了“ Base Chinais”
如果要使用它:
-https://github.com/EloiStree/2019_09_19_MathCompressionOfImage/wiki/SouthChinais
-https://gitlab.com/eloistree/2019_09_06_UnicodeBasedId
Base(Chinais)䶯= 38727
它允许在碸^灾+㔩
中转换2307 ^ 200 + 32450
如果您尝试使用原始压缩BigInteger,则基础版提供了4-4.5倍的
压缩:
1413546486463454579816416416416462324833676542
4钉澻둲觋㷬乮䄠櫡䒤갱
所以现在我需要将<200位数压缩为9999 ^ 9999 + 99999999
如果您对A ^ B + C有任何想法或选择,请随时警告我。
我花了大量的时间在Unity3D上进行实验。
我将在sujet上发布我发现的内容:
https://github.com/EloiStree/2019_09_19_MathCompressionOfImage/wiki
希望它将帮助下一个落入这里的人们。
想和我谈谈Discord。
https://eloistree.page.link/discord
答案 2 :(得分:1)
如果整数是随机的,不相关的,并且真的遵循[0,2³²-1 [的均匀分布定律,则可能证明你不能从平凡的表示中压缩数组。我错过了你的问题吗?
对于非随机数数组,我通常使用简单的deflate。这是一种常用的算法,因为它对一般而非完全随机的数组很好。您拥有所有主要语言中具有可调压缩级别的良好库的事实当然是另一个优势。
我使用deflate压缩物理传感器测量的小阵列(大约300到2000 32位整数)并获得70%的增益,但这是因为连续的传感器测量很少有很大差异。
找到适合所有情况的明显更好的算法可能并不容易。大多数改进都来自您的数字系列的特殊性。
您可能还会注意到,通过将多个集合压缩在一起可以获得更好的压缩增益。当然,根据您的应用,这可能非常不方便。