IM 当入口确实有，slack 就有 jira 的插件

1. 协同文档还有 confluence ，和 jira 一样是 Atlassian 的
2. 用 IM 很难说，但想象了一下要查过去某个 ticket 会很麻烦

因为你设置了 3 倍行距？

"Can you flowing my requirement?" 这句话本身就挺怪的，不知道是不是打错了。更常见的应该是 fulfill 或者 follow

有一点，跨国比较的时候，不少国家是有房产税的

这个图片说的是多项式拟合时次数过低和过高时带来的欠拟合和过拟合，和楼主描述的不是同一回事

关于 h1b 抽签，今年本科学历的中签率估计只有 20%，硕士及以上大概 40%，所以即使是抽 4 次也是有可能翻车的，得做好准备。同时 day-1 cpt 不管是找工作，还是之后 h1b 、绿卡被 RFE 的风险，都要考虑清楚。

day-1 cpt 更多的是给 h1b 3 抽 4 抽不中拿来续命的。如果想润，建议申请更正规的学校和专业

像之前有人回复的，这个更像利用了 hash 的搜索算法。并且，这样的算法想要有实用性，得证明碰撞的概率够低，并且不同的 hash 算法碰撞还得足够独立的，不然就会多次冲突导致要添加很多层 bitmap 。

所以比较重要的部分是，如何选择 hash 的算法，而不是楼主描述的这个过程。举个例子，对于给定的查询集合，比如一堆文件，可以生成一堆 hash 函数：h(x), h(x+1), h(x+2)...，来试验怎么样的组合能在最少的次数完成这个多重 hash map 的构造。同时，hash 函数的值域越大，碰撞概率越低，但对应的 bitmap 需要的空间也越大，这里如何选择也是需要研究的。要有实用性，这些选择都应该能自动完成，但楼主提到的部分并没有讨论这些问题

试图总结一下楼主的算法，看看整理的对不对：
前提：需要查询的集合是有限并且已知的
算法：
1. 取某种 hash 算法 A ，对整个查询集应用一次这个 hash 算法 A 。假设这个 A 算法可能产生的值有 1000 种，那么需要一个对应大小的 bitmap ，用来记录每个 hash 在这个给定的查询集合上是否冲突。
2. 在 hash 算法合适的情况下，会有少量的冲突，这时候再取 hash 算法 B ，重复步骤 1 并产生一个新的 bitmap
3. 如此不停的重复直到无冲突

查询：
对某个 input X ，先应用 hash 算法 A ，查看对应的 bitmap A 是否有冲突，没有则可以直接用 hash map A ；否则再用 hash 算法 B ，查看对应的 bitmap B ，以此类推

1. 原神设置的 5 星几率很低，而保底抽数同样设置的相对低，这样使期望和保底数已经很接近了，整体上已经降低了玩家之间的方差，脸黑也就是比期望多了十抽，而同时狗的概率非常低。
2. 在整体人群概率已经验证了没问题的前提下，要假设有猫腻也是可行的，比如给玩家分层，一部分人欧一部分人非，这样平均下来还是期望的概率。但是这样的分层如果简单，依然可以被假设检验验证出来，只是需要的样本数更多。同样，分层的假设越复杂，比如同一个人每个月每个卡池的概率也是动态变化的，那这样的假设就更难以验证。到那种地步，基本也就是“抛开事实不谈”了，完全取决于你有多不相信策划

maxmin 举个现实中直观的例子，比如刚毕业找初级的职位，又想挑工资高的，那就要找初级职位给的多的，也就是 max_{公司} ( min_{公司, 职位} (工资) )

感觉是我理解错题意了，这么化简不对

对于 0 和 1/3 ，先验里它们概率一样，观测时也无法区分（都是左边），那他们的后验概率也应该一致吧？只要算左右再平分就好

不如拿几十块钱弄个结实的篮子和绳子，再把剩下的钱给保安让他帮你把快递放到篮子里

以前用过 https://github.com/ray-project/ray

肉蛋奶便宜大家都知道，楼主分享了网站，大家可以直接看看别的东西的价格参考。比如节日热销：
https://www.saveonfoods.com/sm/pickup/rsid/987/holidays

他写了
Well that was useless!

That exercise didn't tell us anything about how far the black dot gets after N steps!

平方的期望告诉你点整体是离起点越来越远的，差不多是你说的没方向的期望