有种数据结构叫最大 /最小堆

坑不多，但是一些库的兼容性还是要考虑下的，比如 libpng 新版是 14，旧版是 12，你有些软件如果依赖这个的话就 gg 了

@monkeybrother 这这么牛逼那公司的有线局域网不是早翻天了？关键数据现在谁还用明文再传？

@nopy 不用，一众套现软件比如元＊＊啥的个人很容易注册

@simple_plan 其余的需要别人点你的链接才可以赠送

最新版的 vnc server 6.3 我的 Debian8/9 上都跑不起来，往后回退一个版本就行

@silov 公司交的部分直接统筹掉了

所以我发送一个 10000，双方时钟得跳 1000 下对吧？这效率得有多低下啊？

@ZUYI 首先 FPGA 里面没有分离式的电阻，用电阻这些就是无稽之谈，其次你这种测电压下降的方法考虑过精度没有？你 9999 个电阻并联跟 10000 个电阻并联你算算这电压表的精度得达到多少才能帮你区分出来？有没有考虑过最后电阻本身的误差就已经超过你想要实现的精度了？

@sennes 电阻并联，电流相加，我猜是这个意思
根据最终电流的大小判断到底匹配了几个

@nutting 「圆周率(Pi)压缩法」就是一个例子，常被用来开压缩算法的玩笑 —— 但不止是玩笑而已，理论上确实管用。方法是你把想要的压缩文件二进制化，然后在二进制化的 Pi 序列里找这段数据。由于 Pi 是无限不循环小数，所以任何你所选择的二进制数据最终都会在 Pi 里被找。这是个疯狂的但是尚未被彻底推翻的理论上可行的算法。但是如果我们只是要对单个文件进行压缩，而不是多个，这个方法一定管用。

于是你只需要标记 Pi 的起始位置和你文件的大小，压缩过程就愉快地完成了。这可以把任意的文件压缩到非常小的地步，而且可能会用掉你海量的时间来找到对应的二进制串，完全是拼人品的算法。

不过，理论上，如果你人品不够，找到的数据位于非常遥远的地方，那用这逗比算法得到的压缩包也可能会非常大。但是最近有一些逗比孩子对此还发表了论文，指出你可能得到比你要压缩的数据还大的压缩包。github 上就有一个这样的玩意儿叫 PIFS(Pi 文件系统)，这个开源项目声称不管怎么说，100% 的压缩率在数学上是不可能的。

@ZUYI
1 ）你产生 100bit 的随机数，去圆周率里面匹配匹配看究竟需要多少次？按你说的 90%的相似度再去计算下
2 ）硬件上 10 比特里面有 9bit 相似怎么做？很简单啊，每一个比特相加看看结果是不是 9，但是这样会用到 10 个进位加法器。如果是 1G 比特呢？要实现 90%相似度检测需要 0.9G 个加法器，这一方面是巨大的硬件开销，一方面会导致时钟频率很低很低很低，几乎不可行。当然会有一些算法可以稍微优化下，但是数量级不会改变。不要说什么电流相加这种方法，最后转化到数字电路里面还是 0/1 的操作，电流你能无限相加吗？加到后来是不是都能电死恐龙了“

@ZUYI 而且 90%匹配比 100%匹配硬件上的开销提升的不是一点半点，你要加一堆 mux 一堆比较强，这时钟频率就更上不去了

@ZUYI 仔细一想，不现实，硬件里面你要计算 1G 比特的 A 是不是等于 1G 比特的 B，需要花费的时间很大，我怎么估计都需要 0.1 秒了，然后你这个还要迭代，就算你迭代个 1G 次吧，自己算算需要花费多少时间

可以实现，但是你这玩意要找到 1G 匹配的圆周率数据考虑过花多少时间吗？而且理论上存在这个解吗？我一直以为这压缩算法是来搞笑的