html 装 emmet 插件可减少输入

因为你多次<-使用的是同一个 buffer ，可能 SaveFile 里 f.Write 还没执行完，Gets 里 resp.Body.Read 就把上一次的内容覆盖了

和 bubbletea 比有什么亮点吗

@samohyes 好吧，这个确实因人而异。。

我之前喜欢一个人出去玩，后来就用一个人旅行的经验去规划两个人的旅行。对方可能中间会提出一点意见，然后我们一起修正这个计划。感觉不管是规划还是旅行，都是很开心的一件事。

好奇楼主如果一个人旅游，会怎么安排呢

草榴？

单身狗过啥七夕

ctrl+shift+r 一下，就变了

刚看到一脸懵逼，还找了半天前情提要

b 站关注 Mastertingus

小心掉 san

建议配 docker ，省心

有没可能楼主用电脑上的 v 站，只是不会搞外区帐号🤔

妙啊

你是 gg 还是 mm

我来说一个很多人不会注意到的随机性来源：并行化计算和浮点运算造成的不确定性。

首先要知道，IEEE754 浮点数的加法和乘法是不符合结合律的。也就是说在某些情况下 (a+b)+c!=a+(b+c)，一个反例是在 64-bit 情况下

1e40+((-1e40)+1e10) == 0.0
(1e40+(-1e40))+1e10 == 1000000000.0

因此，对于同一批浮点数相加，它们加的顺序会影响最终的结果。

其次要知道，GPU 算法通常会将一个问题分为几个子问题，对子问题并行计算，再将子问题的结果汇总为最终的结果。

比如你要用 GPU 计算 3 个浮点数的和，你可以开 3 个线程使用 atomicAdd 把这些数加在结果数上。

atomicAdd 能保证没有 race condition ，但是不能保证加的顺序，你这次跑可能是 (a+b)+c ，下一次就可能是 (b+c)+a 。而根据前一条，浮点数的运算顺序会影响运算结果。因此，你每次跑都有可能得到不一样的结果。

只要你的运算涉及将多路并行的浮点数结果汇总，这种随机性就无可避免，不管你如何固定应用层的随机种子。这种随机性的影响可能很小，但在漫长的训练过程中会不断放大，直到产生肉眼可见的差异。

为了克服这种随机性以得到确定性的结果，有时你需要和运算效率做 trade-off ，即以更慢的但是顺序确定的方式汇总浮点数。这也是 torch.backends.cudnn.deterministic 这个开关的由来。

但需要注意的是，torch.backends.cudnn.deterministic 不能保证完全消除这种不确定性。因为这涉及算法的重新设计，而不像固定一个种子这么简单。如果 cudnn 等库的作者考虑不周，那还是会有这种随机性。

一些 CUDA 运算有随机性，会导致结果不同

前一阵我还在知乎看到真有人在复现 木兰 lang