MongoDB 的用户权限系统比较有趣，每个 DB 都有独立的用户账户，但是你可以授权 A 数据库的 user 能访问 B 数据库。所以 MongoDB 的连接串里面的数据库指的是“到底从哪个数据库里面查找你给的用户”。

相亲了就要马上结婚？什么奇怪的念头。我以为这就是你为啥还没谈恋爱的原因

Tabby 的启动速度也太慢了。。。

@GuuJiang 21L 我 reject sampling 修正了，22L 是实验结果

@icySoda 另外你的 原问题，14 这个数同时出现在 Group B 和 group C 了。我把它放进 group C 了

('accept rate:', 0.6822678583611926)
[0.50017, 0.45079, 0.04904]

接受率在 0.7 左右，比我想的 0.5 要好 hhh

@Mutoo @icySoda 你们说得对，我把一个重采样的丢弃操作放错位置了。

https://ideone.com/fx3OHz

@icySoda 这个就符合条件了。

reject sampling 是有理论证明的，无需怀疑。如果结果不符合，一定是 reject sampling 没写对（滑稽）

顺便这叫 reject sampling

https://blog.csdn.net/jteng/article/details/54344766

@icySoda 我的代码方法没有出入，完全按照楼主的要求来。

@Maboroshii
@Mutoo
@GuuJiang

你看我 7L 的代码，还有 6L 的分析。从期望这只要多采样一倍就行。。。估计是最合适的方案了

加上计数器统计总共的采样次数：

https://ideone.com/e1Ek8y

可以知道这次实验，生成 100 个数字只需要采样 129 次，丢弃率只有不到 30%

@Mutoo 不用放到末尾，加个 next 指针就行。洗牌后，每个桶内每次取 next 指针的数字就行。当 next 指针用完整个桶在重新洗牌。。。

@icySoda 不过这其实和原问题的分布略有不同，但是我觉得足够相近了。这套重新洗牌是最快的实现方案，不然你就得维护过去六个元素的集合，如果下一个采样到的元素属于这个集合就重新采样。。。不过大概也不会太慢。

每个点上重新采样一次的概率是 6/32 ，大概 1/5 。期望采样 2 次就能拿到一个合适的数字。倒也不是不行

早会不用太久，每人一分钟说一下今日计划就行。十人小组也就十分钟。

开早会的意义在于明确每日目标，应该和晚上小结会配合一起开。

不然来上班很可能不知道该做点啥，最后摸鱼结束一天。

你得说说原始需求，你的问题抽象不可解

解决方案：拍完照就整理好，不要积攒到一堆再搞

这就是为啥互联网大裁员。以前资本入驻互联网，为了全面垄断的预期，拼命砸钱耗死对手，所以什么人都养得起。现在政策变了，不允许全面垄断了，互联网即将转变为成熟的行业 —— 计较成本，不追求全面垄断了。所以这种人不一定会养得起了 lol

看上去 JDK 相当不给力啊。不过也对，毕竟 JVM 有很多 JIT 技术，大概在 ARM 上还不行。

反正我用 pytorch 跑神经网络，m1 pro 对比 2018 年 i5 的 macbook pro ，可以快 2 倍。