一次pytorch中出现的nan问题

最新推荐文章于 2025-03-04 16:09:16 发布

人物roMantic

最新推荐文章于 2025-03-04 16:09:16 发布

阅读量4.8k

点赞数 2

文章标签： python

本文链接：https://blog.csdn.net/qq_38507163/article/details/111181447

版权

博客讲述了在PyTorch中遇到loss变为nan的问题，经过排查发现是由于负数开方操作导致。文章指出，数学上虽然负数的某些次方有实数解，但在Python和PyTorch中会得到虚数或nan。通过举例说明了(-27)**(1/3)的结果，并提出解决方案：在开方前确保数值为正或者对负数进行特殊处理。建议在计算时要避免负数开方，以免出现nan错误。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

nan排查

最近调试代码时，发现一个loss全部变为nan。网上主流的解释大多千篇一律，比如

1.学习率太高。

2.loss函数

3.对于回归问题，可能出现了除0 的计算，加一个很小的余项可能可以解决

4.数据本身，是否存在Nan，可以用numpy.any(numpy.isnan(x))检查一下input和target
...

我这儿问题可以确定，是由于数学运算造成的nan。最后具体定位到，是由于一个池化操作造成的。在pycharm中单步调试，使用如下表达式判断x中是否有nan，因为nan!=nan结果是True，而其他任何实数!=实数本身结果均为False：

torch.sum(x!=x)
torch.sum(x[:1000] != x[:1000])  # 依次这样二分法查找第一次出现nan的那个位置

最后发现是对负数开方将会产生nan，如下

p = 3.
 x_i = (torch.mean(x_i**p, dim=-1) + 1e-12)**(1/p) # 如果x_i中有负数，那么开方之后，对应位置就会为nan

解释

主流的计算器，编程语言均是不支持负数的开方的，即便是数学上成立，计算器还是会给出虚数解, 对于pytorch来说，就成了nan。比如：

>>>(-27)**(1/3)
(1.5000000000000004+2.598076211353316j)

-27的1/3次是存在实数解的，但是计算结果还是一个虚数解。所以以后要开方的话，一定要对负数特别处理，比如把负号拿出来：

>>>-(1)**(1/3)
-1.0
>>>-(27)**(1/3)
-3.0

这篇博文也提到了python中这个问题，实际上一般的计算器也是这样的。