gzgz8080 最近的时间轴更新 gzgz8080 最近的时间轴更新 |
gzgz8080V2EX 第 104065 号会员，加入于 2015-03-12 13:09:55 +08:00 |
gzgz8080 最近回复了
2022-12-21 12:45:00 +08:00 回复了 ljiaming19 创建的主题 › 程序员 › 有没有通过 AI 自动生成论文致谢部分的网站/软件 |
ctrl+c 、ctrl+v 、ctrl+f 替换、ctrl+s 保存
2022-11-07 14:49:18 +08:00 回复了 shijingshijing 创建的主题 › 程序员 › Twitter 貌似出了问题又在把裁掉的人请回来。 |
说明离职交接没做好啊，上午通知，下午赶人，谁有时间做工作交接？
2018-01-10 14:21:55 +08:00 回复了 Aresn 创建的主题 › JavaScript › 你不知道的前端算法之文字避让 |
感觉这个可以用遗传算法来解决，把显示重叠的一批点进行杂交，经过数论迭代后能近似地选出最优点。
2017-09-27 14:43:46 +08:00 回复了 zjsxwc 创建的主题 › 程序员 › windows 下如何压缩 zip 后 macOS 解压不会乱码 |
zip 是标准压缩算法，不论你在哪个系统都不会乱。
估计是你原文件的字符集编码问题。
估计是你原文件的字符集编码问题。
2017-09-27 14:42:06 +08:00 回复了 tinytin 创建的主题 › 硬件 › 好久不关注，现在内存简直天价啊 |
用过 ssd 就回不去用机械硬盘了，感觉差了几个数量级
2017-09-26 15:37:06 +08:00 回复了 jnasw 创建的主题 › 分享创造 › Python 实现中文文字转语音（ Text-to-Speech） |
多音字咋办？还要联系上下文词组分析？
2017-09-22 15:45:05 +08:00 回复了 ZUYI 创建的主题 › 分享创造 › 这样能实现用 圆周率 来 压缩文件 吗？ |
@noe132 这肯定会通过一定的统计值来确定最佳的分段长度。
因为越短的分段，越容易在前面匹配到。
我测试了一下：
999999 出现在 pi 的 762 位：压缩率有 50%；
9999999 出现在第 1722776 位：压缩率只有 0 ；
99999999 出现在第 66780105 位：压缩率也为 0 ；
999999999 的话已经搜索很久都没找到了。
所以设置合适的分段长度确实可以提高压缩率的。
因为越短的分段，越容易在前面匹配到。
我测试了一下：
999999 出现在 pi 的 762 位：压缩率有 50%；
9999999 出现在第 1722776 位：压缩率只有 0 ；
99999999 出现在第 66780105 位：压缩率也为 0 ；
999999999 的话已经搜索很久都没找到了。
所以设置合适的分段长度确实可以提高压缩率的。
2017-09-22 14:42:01 +08:00 回复了 ZUYI 创建的主题 › 分享创造 › 这样能实现用 圆周率 来 压缩文件 吗？ |
2017-09-22 12:40:12 +08:00 回复了 ZUYI 创建的主题 › 分享创造 › 这样能实现用 圆周率 来 压缩文件 吗？ |
看了 GitHub 上的 pifs 项目，原理就是用时间换取空间。
因为理论上所有的数值组合都可能出现在 pi 的其中一段，但有可能在非常后面才出现。
思路是不错的，但是限于当前的 cpu 计算能力，只能将文件分成多个小段，再对每个小段进行 pi 压缩。
至于最终性能，github 上也说了，压缩 400 行的文本文件花了 5 分钟。
就像以前蒸汽机车刚发明时跑得比马车还慢，还被不少人骂没前途吗？
随着并行计算的发展，每段都可以并发处理；甚至用量子计算机来计算 pi，那能力可就杠杠的。
以后就可以用一个偏移量加长度来表示任意文件内容了。
以后此算法的潜力还真的无法估量。
因为理论上所有的数值组合都可能出现在 pi 的其中一段，但有可能在非常后面才出现。
思路是不错的，但是限于当前的 cpu 计算能力，只能将文件分成多个小段，再对每个小段进行 pi 压缩。
至于最终性能，github 上也说了，压缩 400 行的文本文件花了 5 分钟。
就像以前蒸汽机车刚发明时跑得比马车还慢，还被不少人骂没前途吗？
随着并行计算的发展，每段都可以并发处理；甚至用量子计算机来计算 pi，那能力可就杠杠的。
以后就可以用一个偏移量加长度来表示任意文件内容了。
以后此算法的潜力还真的无法估量。
Select Language