@justaname #23
前面提到的也都是在 windows 下用 pwsh 。你如果说的是在 linux 下的话，在 gnu 的环境里当然是 bash 更搭，但学习记忆曲线还是不低的。想用 pwsh 在 linux 下做交互确实是要学习那一套 best practice ，我也尽量不碰，只是偶尔用 pwsh 做一些简单的 parallel processing 。

@Chipmunker #22 这个不可避免吧，我配置好的 zsh 甚至 bash 启动和 pwsh 差不多慢，pwsh 无配置启动（-nop ）也挺快的。

@NessajCN
要比较学习曲线的话，pwsh 首先文档齐全，其次 verb-noun 的全名绝对更好记，加上 tab 提示 /补全，函数名 alias ，参数名前缀匹配，-?帮助，现代化的语法和语言特性，绝对是更好学的那个。

@NessajCN
pwsh 可以说是非常现代非常易用的 shell 了，且不说类似 fish/zsh 的 tab 补全和提示，pwsh 的函数 /cmdlet 是可以自动提示 /补全 /预测参数的，而且 pwsh 不区分大小写，常用命令都有 alias ，参数按前缀匹配，这一条命令纯手打也就是 rm -r -fo 。

还有 explorer.exe 本身的效率问题，加载的插件和层层逻辑太多了。

仔细看了下，上面环境写的是 torch 1.8.0 + cuda 11.1 ，但下面 requirements.txt 写的是 cuda==1.7.0 。改成 torch==1.8.0+cu111 就可以了，这个 whl 是存在的。

`torch==1.7.0` 改成 `torch==1.7.0+cu110`, 这是 1.7.0+cuda11 的唯一一个 whl ，参见 https://download.pytorch.org/whl/torch/

你也可以选一个更新的 torch ，一般都没问题，就是不过 torchvision 接口不太稳定，不同版本可能有坑。

@jokeface 这方面 PowerShell (pwsh7) 很好用，参数只需要 prefix 匹配，比如-Directory 可以简写为-d ，-di ，-dir ；官方的 PSReadLine 可以 tab 自动补全 /选择参数，第三方 PSFzf 可以实现模糊搜索历史命令。

不过我只在 Windows 下用 pwsh 作为默认 shell ，Linux 下只用 pwsh 写脚本（类似 Python ），因为不太确定各种环境变量的支持如何。而且 pwsh 的迭代也很快，Linux 下行为不一定稳定（ imo ）。

另一个粗暴点的 workaround 是`wsl --shutdown`主动重启，可以搭配使用。

@2NUT #37 WSL2 能和宿主 Windows 互操作，能直接调用互相的 binary ，由此能衍生不少花样，对特定人群有不可替代性。

例如，WSL2 支持 GPU 穿透并和宿主 Windows**共用一张不支持虚拟化的 GPU**，比如 GeForce 系列 GPU 。此时 WSL2 直接使用宿主 Windows 的 GPU 驱动，调用直接转发到宿主 GPU ，除了很小的转发 overhead 之外，没有性能损失（不过首发时 GPU 带宽好像默认是 PCIEx8 而非 x16 ）。而其他 VM 即使支持 GPU 穿透，据我所知在不支持 vGPU 显卡上需要独占该显卡。

@Dragonphy #31 他发的那个 issue 里描述的是重启 WSL2 后打开第一个 linux distro 时可以互操作，打开第二个后就不行了。

https://github.com/microsoft/WSL/issues/8843#issuecomment-1254778464

@lambdaq #28 为了更方便地处理 wsl 的特殊需求吧。wsl2 是一个运行 linux distro container 的 host vm ，本来用的是微软自己的（多个） init binary 。除了 pid 1 的 init 之外，其他的 init 用来管理 linux distro containers ，跑 9p server ，处理 linux 和 windows binary 的互操作之类的。

@ipwx 加一个常量 tolerance epsilon 肯定比比没有要好，但还是有点蒙住眼睛骗自己问题解决了的味道，无法被称为“正确”。要知道浮点数的分布不是均匀的，ulp 不是一个常量，而 machine epsilon 只是定义为 1 右边 ulp 的一半。

一个比只加常量 tolerance epsilon 更好一点点的方案是根据比较的两数来 scale 这个 tolerance epsilon 。此时 x < y 会被定义为 | x - y | / | x | <= epsilon or | x - y | / | y | <= epsilon 。

@0attocs #32 *1+2^-53 的 64 位浮点数表示

@des #22 而且你提的“精度损失基本都发生在“进制转换”的过程中”说法本身也很奇怪。且不说多少涉及实数 /浮点数的问题 /程序里有你所谓的“进制转换”，你这里的 error 完全就是 rounding error ，跟什么进制转换没必然关系，只要需要浮点数 /有限精度表示就有可能引入 error 。都是二进制就没事了吗，2^-53 的 64 位浮点数表示会带来精度损失吗？

@des #28 在你这套荒谬逻辑下“进制转换也是不会损失精度的，提前是使用得当”，而你举的例子只是使用不当。

@knowckx #19 需要区分<和<=时的一种做法是考虑用 a <= b + delta 代替 a < b ，但一般只有在为某个涉及浮点数比较的分析而定义语义时需要考虑吧。一般情况下更应该考虑的是问题本身是否是 well-conditioned 的以及算法+实现本身是否 stable 。

@des #22 浮点加减运算怎么可能不会损失精度，运气好的话 relative error 是 bounded by epsilon/2 。运气不好的话很多加减运算本身可以是 ill-condition 的，遇上浮点加减运算的 rounding error 之后 relative error 会高得离谱。比如考虑实数：

x = 1 + 2^-52 + 2^-53 + 2^-54
y = 1 + 2^-54

实数减法 x - y 的结果是 2^-52 + 2^-53 = 3 * 2^-53 ，但 64 位浮点数减法 fp(x) fp(-) fp(y) 的结果是 2^-51 = 4 * 2^-53 ，relative error 是夸张的 |(4^-53 - 3 * 2^-53) / 3 * 2^-53| = 1/3 。

@Kazetachinu 文档写的是旧版本不兼容，15.5.5 开始兼容。我已经用了一段时间了。