JJ怪大战 发表于 2020-8-21 11:20
有逗号，可以算pi啊
你这个解压效率比7z还低，大小比deflate还大
PercyDan 发表于 2020-8-21 11:22
你这个解压效率比7z还低，大小比deflate还大
可以不停压缩直到压缩率最大
JJ怪大战 发表于 2020-8-21 11:22
可以不停压缩直到压缩率最大
那么你还得不停地逆推
理论上可以，
虽然一般的家用计算机计算到报废都不一定能找到匹配序列
虽然一般的家用计算机计算到报废都不一定能找到匹配序列
洞穴夜莺 发表于 2020-8-21 11:23
但是你保存压缩次数又会占用空间，最终可能还是没有压缩到
而且压缩解压消耗资源极大 ...
没必要，追加在资源末尾就可以了
完蛋，我看不懂了
PercyDan 发表于 2020-8-21 11:19
那么还得多重逆推
md5也是啊，多长的长度都一样
1的md5：
毕竟这个压缩包原理是把文件的大小转化为计算量的大小
JJ怪大战 发表于 2020-8-21 11:32
毕竟这个压缩包原理是把文件的大小转化为计算量的大小
所以我认为毫无意义
如果文件含大量无法转化为ASCII字符的数据（比如Unicode 0xFFD）
那你咋办
PercyDan 发表于 2020-8-21 11:37
所以我认为毫无意义
如果文件含大量无法转化为ASCII字符的数据（比如Unicode 0xFFD）
那你咋办 ...
那就把十六进制转化为10进制
JJ怪大战 发表于 2020-8-21 11:43
ffd=4093
0在π里面老靠后了
啥呀，萌新不懂
都是大佬,我看不懂
这个方式让我想到了科幻小说中的一个设定，给定一个无理数，以及开始和截止位置，得到想要传递的数据。可行，但是效率很低。
哇，字都认识，连起来一句都没看懂
雨韵 发表于 2020-8-22 11:48
这个方式让我想到了科幻小说中的一个设定，给定一个无理数，以及开始和截止位置，得到想要传递的数据。可行 ...
经过尝试性计算，抛洒点法求Pi，精确到小数点后五位需要9.8s，使用i7-9750H
雨韵 发表于 2020-8-22 11:48
这个方式让我想到了科幻小说中的一个设定，给定一个无理数，以及开始和截止位置，得到想要传递的数据。可行 ...
如果给定该无理数截止位置呢？再通过切分数据再合并的方法进行压缩，这样就可以用有限的空间进行压缩
JJ怪大战 发表于 2020-8-22 12:58
如果给定该无理数截止位置呢？再通过切分数据再合并的方法进行压缩，这样就可以用有限的空间进行压缩 ...
我下载了Pi的小数点后十亿位作为字典，尝试进行编程
雨韵 发表于 2020-8-22 13:12
我下载了Pi的小数点后十亿位作为字典，尝试进行编程
谢谢，本人不才，惭愧
有一点我没有完全理解，你的意思是在Pi中找到上述“14159265358979”这个字符串，然后返回这个字符串的第一个数字和最后一个数字、字符串长度和开始位置是吗？
雨韵 发表于 2020-8-22 14:42
有一点我没有完全理解，你的意思是在Pi中找到上述“14159265358979”这个字符串，然后返回这个字符串的第一 ...
对，然后组合起来，用“,”隔开，第一个数和最后一个数记录下来是当保险（不记录也可以）
这个问题让我想起压缩炸弹
洛初墨 发表于 2020-8-22 14:44
这个问题让我想起压缩炸弹
想多了，我好像有，但我不给你
.............我能说没听懂吗
雨韵 发表于 2020-8-22 14:42
有一点我没有完全理解，你的意思是在Pi中找到上述“14159265358979”这个字符串，然后返回这个字符串的第一 ...
切分数据再合并是指在π中找不到原数据时将原数据切分成几个小份，再在π中查找，分别记录下数据（字符串的第一个数字和最后一个数字1，字符串长度1，开始位置1）（字符串的第一个数字和最后一个数字2，字符串长度2，开始位置2）……（字符串的第一个数字和最后一个数字n，字符串长度n，开始位置n）……
最后合并起来如：a1,b1,c1,a2,b2,c2,……an,bn,cn的形式
请不要在我的帖子下灌水
JJ怪大战 发表于 2020-8-22 14:52
切分数据再合并是指在π中找不到原数据时将原数据切分成几个小份，再在π中查找，分别记录下数据（字符串 ...
我测试了aaa到ZZZ的数据情况，测试后约为0.5298062699135184，也就是说有一半可能在Pi中查找不到对应的数据。以这种形式来看，这个算法可能并不优秀。
数据报表：
共计算：140608个数据
无法获取：74495个数据
计算时间： 1584.6016519069672 s
无法获取数据预览（取前三百个）由于使用多线程计算，所以数据比较乱
雨韵 发表于 2020-8-22 17:06
我测试了aaa到ZZZ的数据情况，测试后约为0.5298062699135184，也就是说有一半可能在Pi中查找不到对应的数 ...
那么，如果把十进制换成二进制，是不是能增大检测概率呢？
审核打架就打架独家星劫
萌新表示一点也看不懂
雨韵 发表于 2020-8-22 17:06
我测试了aaa到ZZZ的数据情况，测试后约为0.5298062699135184，也就是说有一半可能在Pi中查找不到对应的数 ...
https://www.mcbbs.net/thread-1107906-1-1.html
对于压缩方式，我总共发了三个帖子讨论，
后面的数据找不到的问题我尝试用二进制的方法解决
JJ怪大战 发表于 2020-8-22 17:08
那么，如果把十进制换成二进制，是不是能增大检测概率呢？
并不会，因为Pi是十进制的，改成二进制只会降低概率
本帖最后由 JJ怪大战 于 2020-8-22 17:17 编辑
这种算法感觉极其耗用内存和cpu，但不知道是否有这样一个无理数使数据均能方便查找
这又要牵扯到最短的排序问题了
雨韵 发表于 2020-8-22 17:06
我测试了aaa到ZZZ的数据情况，测试后约为0.5298062699135184，也就是说有一半可能在Pi中查找不到对应的数 ...
这种算法感觉极其耗用内存和cpu，但不知道是否有这样一个无理数使数据均能方便查找
这又要牵扯到最短的排序问题了
雨韵 发表于 2020-8-22 17:15
并不会，因为Pi是十进制的，改成二进制只会降低概率
所以硬盘越大，压缩率越小了
JJ怪大战 发表于 2020-8-22 17:16
这种算法感觉极其耗用内存和cpu，但不知道是否有这样一个无理数使数据均能查找
这又要牵扯到最短的排序问 ...
任何一个无理数都可以，只不过是多少位的问题。甚至有人猜想，在Pi的某一段信息，是可以被翻译成有意义的信息的。
雨韵 发表于 2020-8-22 17:19
任何一个无理数都可以，只不过是多少位的问题。甚至有人猜想，在Pi的某一段信息，是可以被翻译成有意义的 ...
我去看看有没有十亿位内包含大量不重复信息的无理数
JJ怪大战 发表于 2020-8-22 17:18
所以硬盘越大，压缩率越小了
十进制100：100
二进制100：1100100
十进制95184726：95184726
二进制95184726：101101011000110011101010110
差了很多位，占用空间倍增
雨韵 发表于 2020-8-22 17:20
十进制100：100
二进制100：1100100
π的二进制包含了任意一个有限长的二进制串，所有n位长的二进制串都以相等的概率出现在pi的二进制中
世界基础 数学。
雨韵 发表于 2020-8-22 17:20
十进制100：100
二进制100：1100100
https://github.com/philipl/pifs
竟然已经有人早就提出了此想法
我还是落后了啊
但是那个软件是极其耗用磁盘空间的，被人戏称为运气压缩
可是我想到了数据所处序号过大的问题
表示一脸懵 0.0
JJ怪大战 发表于 2020-8-22 17:22
π的二进制包含了任意一个有限长的二进制串，所有n位长的二进制串都以相等的概率出现在pi的二进制中 ...
实际上你指的这个相等概率出现，其实就是十进制下的相等出现概率与补码概率之和