"因为操作昂贵，所以只要在必须 resize 的情况下才 resize，其余需要 resize 的情况，就交给 putVal 再去触发 resize。"
@amiwrong123
我觉得你说的这条不是太合适, 我们可以讨论.
resize 昂贵, 但如果 table 里面东西越少, 这个"昂贵"的操作越"廉价". 所以我们就要找一个情况, 看 table 需要这个昂贵操作的概率有多大, 如果很大, 我们就尽量早做, 如果没那么肯定, 那就等到该做的时候做. 这是我对那个 if 语句的想法.

再回来说你的例子, 好像你觉得本来 12, 变成了 24, 好像空间占用一下多了一倍. 其实你仔细想想, 你这个是特例, 不能推广到所有该 x 空间的都变成 2x, 因为你的那个 size 增长是线性的, 但是 resize 的结果是指数的, 你说的这个情况只有在那个 t 是整数, 而且刚好等于 threshold 的情况才会发生. 你再想想, 当不是初始化缺省值的 case 下, 这种情况发生会很小, 而且这种害处只体现在 table 本身很大的时候. 可是, 当 size 越大,这种情况出现的概率就越低.

@CEBBCAT ... please read my comment twice

@CEBBCAT 为什么要删除.git 　你是需要 git archive 吧?

"一名系统洁癖程序员...." 既然是程序员, 先问自己, 自己做的东西, 过了自己洁癖这关了吗?　是不是做到极致了．

很容易啊, 启动多少次机器就买多少块硬盘, 装一次系统, 把所有硬盘都写了.
每次都启动新硬盘.
有洁癖的人甚至不能接受穿过的衣服, 所以都用新的, 要绝对的惯自己就要在别处投入.

至于真伪随机数, 以及分布问题这个网上大把文章. 我想说的是, 你们公司干嘛用程序来做啊?! 年会是集会对吧, 我们也有, 开会, 讲话, 聚餐等. 你们每人有个卡, 每个号码有个副券对应, 放箱子里, 抓阄多好!

而且可以让普通员工上台露面抽奖, 比如 财务之星, 销售大王... 如果都是技术人员, "年度代码提交量最多", "注释最多", "后端王子", "前端皇后"..... 多有意思, 上场抽奖时候还能后面大屏幕播放一些他 /她的有关背景...

@MeteorCat 推荐你 borg 备份恢复

@honjow 还真是有这个可能, 你一说我想起来了, 我有同事就是 ls 后面跟的选项 5,6 个如背口诀一般咔咔就写上了, 我还问他, 这些都什么意思?　他说他也不知道, 反正每次 ls 都这么写, 不管目录有什么.

@amiwrong123
关于+1. loadfactor 缺省有个值, 75%, 尽管 resize 都是按照 2 的幂, 这样计算, 这个商不会出现小数(默认起始 capacity 也是 16). 但是不要忘记, capacity and loadfactory 是可以用户给定的. 可是, resize 的算法是固定的, 所以会出现小数的情况. 如果要出现不整除的情况很容易, 你设计一个 2 的幂无法整除的除数的倒数就好了.

resize 需要 re-hash, 这是 hash-table data structure 里最 expensive 的操作. 但是又必须做. 所以才有了 loadfactor, threshold 那些零碎. 这些都没有必定有效的策略, 都是按照概率来的. 后面的子集情况是特殊情况, 但是有一部分 key 重叠是常见情况.

试了 deepin 播放器, 界面不错, 歌词那块不好用.
还是装了 osdlyrics 跟 deadbeef 配合使用.

1. 你删个连接(file), 为什么要 -r?
2. 为什么要-f
3. 你手再抖下, /前加个空格可咋整?

@cowlogli mbp16 正在 it 部门评估中, 明年上架了就去领一个. 手里的 HP 也不用交上去.
没有 gnu 是肯定不行的, 我还看了在 mbp 上装 linux, 好像新的 mac 很多功能不行, 比如声音等, 想想也就是用浏览器, 脚本, docker, ide, 可能 mac 也凑合了. 毕竟家里还是 linux.

@dyrone 还人工群发广告的公司.... 技术能好到哪去

为什么 /factor +1 比较好理解, 因为后面比较 threshold 等都是 int 比较, 刚刚 /factor 是个 float, 你后面的例子正好整除, 但是大多数不会是整数结果, 如果是 3.1, 比如, 那我们应该取 4 不能是 3, 也就是(int)(3.1+1)

另一个为什么不把自身的 size 加上. 我理解是当 s 就比 threshold 大了, resize 的 requirement 的概率就很大(并不是 100%), 而且 the more empty the table is, the cheaper the resize() costs. 所以提前 resize(), 因为 resize 是按照 2 的幂来的, 后面 put 是否需要不一定. 如果加上自身的, 即使> threshold, 虽然可能也会需要 resize, 可概率不如不加大, 所以就等到需要的时候再进行. (这是我的理解)

至于你 concern 的那个 "可能在最后的循环里的某个 putVal 里，又会再次 resize 啊" 这个对于加不加自身 size 几乎没影响. 如果需要后面再次 resize 的情况, 你＋了自身 size 判断, 一样会需要再 resize.

什么叫智能鼠标？有什么特殊功能？

这得具体情况具体分析. 没法一概而论

不明白你中文描述的问题是什么。
.* 一直都是 greedy 不管在哪。
英文搜索还挺精准呀。
你的链接 404

@input2output my resource ends