gzgz8080's recent timeline updates
gzgz8080

gzgz8080

V2EX member #104065, joined on 2015-03-12 13:09:55 +08:00
gzgz8080's recent replies
ctrl+c 、ctrl+v 、ctrl+f 替换、ctrl+s 保存
说明离职交接没做好啊,上午通知,下午赶人,谁有时间做工作交接?
Jan 10, 2018
Replied to a topic by Aresn JavaScript 你不知道的前端算法之文字避让
感觉这个可以用遗传算法来解决,把显示重叠的一批点进行杂交,经过数论迭代后能近似地选出最优点。
zip 是标准压缩算法,不论你在哪个系统都不会乱。
估计是你原文件的字符集编码问题。
Sep 27, 2017
Replied to a topic by tinytin 硬件 好久不关注,现在内存简直天价啊
用过 ssd 就回不去用机械硬盘了,感觉差了几个数量级
多音字咋办?还要联系上下文词组分析?
Sep 22, 2017
Replied to a topic by ZUYI 分享创造 这样能实现用 圆周率 来 压缩文件 吗?
@noe132 这肯定会通过一定的统计值来确定最佳的分段长度。
因为越短的分段,越容易在前面匹配到。
我测试了一下:
999999 出现在 pi 的 762 位:压缩率有 50%;
9999999 出现在第 1722776 位:压缩率只有 0 ;
99999999 出现在第 66780105 位:压缩率也为 0 ;
999999999 的话已经搜索很久都没找到了。
所以设置合适的分段长度确实可以提高压缩率的。
Sep 22, 2017
Replied to a topic by ZUYI 分享创造 这样能实现用 圆周率 来 压缩文件 吗?
@shuax @rekulas
可以设定偏移量超过一定长度时再用 pi 压缩一次偏移量啊,只要头部加一个记录压缩次数的信息就行。
Sep 22, 2017
Replied to a topic by ZUYI 分享创造 这样能实现用 圆周率 来 压缩文件 吗?
看了 GitHub 上的 pifs 项目,原理就是用时间换取空间。
因为理论上所有的数值组合都可能出现在 pi 的其中一段,但有可能在非常后面才出现。

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

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

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

以后此算法的潜力还真的无法估量。
About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   2674 Online   Highest 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 13ms · UTC 14:47 · PVG 22:47 · LAX 07:47 · JFK 10:47
♥ Do have faith in what you're doing.