所以我发送一个 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 匹配的圆周率数据考虑过花多少时间吗？而且理论上存在这个解吗？我一直以为这压缩算法是来搞笑的

@misaka20038numbe 以前我还知道自己在做梦，同时也有能力控制自己在梦里干啥，于是经常做一些不可描述的事情，不过随着年龄的增长越来越少了

@SlipStupig 找个律师科普一下午就都清楚了，不要心疼那个钱，做到最后被坑有你哭的，当初别人也跟我这么说，我不信结果现在被坑了

一开始把股票什么都谈清楚，落实到纸上，找个律师好好帮你看看

阿甘那个是
run，forest run.不是 gump

通过 ISO26262 认证了吗？

谁能给我科普一下红外面部识别是什么高科技？是哪个网站 YY 出来的？

当年花 2k6 买的

出国是一条不归路，自己想清楚

买大法的 mdr-1000x 啊，现在 Amazon 直接打 75 折，300 刀

pixel oreo,解了 bl, root 了，装上 suhide 喜滋滋，android pay 也可以打开（不能添加大陆的卡），play store 也是认证状态