这样能实现用 圆周率 来 压缩文件 吗?

2017-09-22 09:06:56 +08:00
 ZUYI

FPGA 能实现这样的功能吗? 三排二进制存储位,第一、第二排做 与非 运算,得到第三排。第三排相当于并联的电阻,1 电阻小,0 电阻大,加电压后,能测试出电流的大小。1 多则电流大,0 多则电流小。 第一排放 1G 的压缩过的文件( 1 与 0 差不多一样多),圆周率从第二排排队经过,第三排产生比照数据。第三排的传感器达到一定阀值,则记录圆周率的位置。将这个位置的值放在第三排数据前,然后压缩并存入第一排。重复以上过程,直到获得极短的数据。

7201 次点击
所在节点    分享创造
49 条回复
ZUYI
2017-09-22 11:09:38 +08:00
@churchmice @sennes @Xs0ul @twilight @lovestudykid @BOYPT @whileFalse @roychan 其实你想想,只要有 50%以上匹配就可以了,不用达到 90%相似(我太着急了,把意思搞混淆了,对不起)。因为,经过压缩的文件 1 和 0 的比例是一样的,圆周率中 1 和 0 的比例也是一样的。那么根据概率,只要有 50%以上匹配,就会有 25%以上的 1 匹配,与非运算后就会实现将原来的压缩文件中 1 的比率( 50%)降低(存入第三排进行判断是否降低),从而再次压缩(获得原压缩文件 90%左右的大小)并存入第一排。 另外,不是电流相加,只是把第三排所有的二进制位(应该类似并联的二极管吧,)统一加上个电压,测电压下降的幅度,来判定比率是否下降。
LU35
2017-09-22 11:10:41 +08:00
@shuax 你可能没理解这个理论,有可能你的整个数据都可以在 pi 中顺序保存。
唯一的问题是 pi 的数据有多大,还有检索这个数据所花的时间。
Xs0ul
2017-09-22 11:23:05 +08:00
@LU35 #22 其实和 pi 没有关系,你完全可以把 pi 换成 0.0 1 00 01 10 11 000 001 ... 这样有规律的无限小数,这样根本不需要检索,可以直接获得位置。然而这样压缩还是没意义的。
ETiV
2017-09-22 12:06:44 +08:00
@twilight 我感觉阈这个字完全就是为了阈值这个词创建的……
churchmice
2017-09-22 12:10:15 +08:00
@ZUYI 首先 FPGA 里面没有分离式的电阻,用电阻这些就是无稽之谈,其次你这种测电压下降的方法考虑过精度没有?你 9999 个电阻并联跟 10000 个电阻并联你算算这电压表的精度得达到多少才能帮你区分出来?有没有考虑过最后电阻本身的误差就已经超过你想要实现的精度了?
ZUYI
2017-09-22 12:35:19 +08:00
@churchmice 0.0001 的差异,确实太小了,测不准。但如果是 0.01 呢? 0.05 呢? FPGA 里有没有其它可以达到这个目的的结构呢?或者别的什么硬件能实现这个功能?
twilight
2017-09-22 12:35:57 +08:00
@ETiV

阈字很早就有了,参见: http://www.zdic.net/z/27/kx/9608.htm

把 threshold 翻译成“阈值”也算得上“信达雅”了。
gzgz8080
2017-09-22 12:40:12 +08:00
看了 GitHub 上的 pifs 项目,原理就是用时间换取空间。
因为理论上所有的数值组合都可能出现在 pi 的其中一段,但有可能在非常后面才出现。

思路是不错的,但是限于当前的 cpu 计算能力,只能将文件分成多个小段,再对每个小段进行 pi 压缩。
至于最终性能,github 上也说了,压缩 400 行的文本文件花了 5 分钟。

就像以前蒸汽机车刚发明时跑得比马车还慢,还被不少人骂没前途吗?

随着并行计算的发展,每段都可以并发处理;甚至用量子计算机来计算 pi,那能力可就杠杠的。
以后就可以用一个偏移量加长度来表示任意文件内容了。

以后此算法的潜力还真的无法估量。
shuax
2017-09-22 13:16:35 +08:00
@gzgz8080 偏移量不用存的?
rekulas
2017-09-22 13:27:41 +08:00
@gzgz8080 想多了 更有可能的情况是原文 100kb 存储偏移量用了 10M
gzgz8080
2017-09-22 14:42:01 +08:00
@shuax @rekulas
可以设定偏移量超过一定长度时再用 pi 压缩一次偏移量啊,只要头部加一个记录压缩次数的信息就行。
noe132
2017-09-22 14:47:22 +08:00
@gzgz8080 然后越压越大越压越大,最后 10kb 压缩成了 42gb
UncleRiver
2017-09-22 15:21:21 +08:00
pi 的小数部分是无限不循环的,但是能否由此推论出任意一个数字序列都会出现在 pi 的小数部分里?
举例来说,一个无限不循环的序列可以完全不出现“ 123 ”。
或者放宽要求来说,我们能否证明,在 pi 的小数部分,一定可以找到与任意一个数字序列相似度 90%的那一段?
jedihy
2017-09-22 15:28:20 +08:00
这样字典也就是 pi 会占无穷大的空间的。
gzgz8080
2017-09-22 15:45:05 +08:00
@noe132 这肯定会通过一定的统计值来确定最佳的分段长度。
因为越短的分段,越容易在前面匹配到。
我测试了一下:
999999 出现在 pi 的 762 位:压缩率有 50%;
9999999 出现在第 1722776 位:压缩率只有 0 ;
99999999 出现在第 66780105 位:压缩率也为 0 ;
999999999 的话已经搜索很久都没找到了。
所以设置合适的分段长度确实可以提高压缩率的。
hahastudio
2017-09-22 15:51:49 +08:00
pi 认为是 normal number 但还没被证明
chuanqirenwu
2017-09-22 15:55:44 +08:00
talk is cheap, show me the code.
Luckyray
2017-09-22 15:58:25 +08:00
想起来一个段子,就是说外星人来到地球,收集了所有信息,然后在飞船上一个特点的地方点了个点,就把信息带回去了,因为这个点到飞船头部的距离是个非常长的数字.....可以解码成信息...
楼主的概念是不是跟这个有点像?
shuax
2017-09-22 16:25:14 +08:00
@gzgz8080 次数不用存的?
mhycy
2017-09-22 16:28:12 +08:00
一排电阻?楼主该看看 R2R DAC 电路。。。。
先把电源稳定性解决了再说

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/392719

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX