我正在使用numpy.log 1p函数来计算非常小的复数的log(1 + x)值，并且得到了意想不到的结果.
我预计输出实际上应该等于函数输入.而在下面的简单例子中，情况似乎并非如此.
np.log1p(1e-14 * (1 + 1j))
Out[75]: (9.992007221626358e-15+9.9999999999999e-15j)
np.log1p(1e-15 * (1 + 1j))
Out[76]: (1.110223024625156e-15+9.999999999999989e-16j)
np.log1p(1e-16 * (1 + 1j))
Out[77]: 1e-16j
scipy.special中的log 1p函数似乎工作正常，但不幸的是，我需要使用numpy函数(用于numba).
我目前在Python 3.10.10上使用numpy版本1.26.4
np.__version__
Out[78]: '1.26.4'
numpy docs人说:
对于实值输入，log 1 p对于x很小以至于1 + x == 1的浮点精度也是准确的.
这似乎是一种间接的方式，表明他们"放弃"了复杂的输入.事实上，在普通Python(没有cmath.log1p)中，在Windows上:
>>> import cmath
>>> p = 1e-14 * (1 + 1j)
>>> p
(1e-14+1e-14j)
>>> cmath.log(1 + p)
(9.992007221626409e-15+9.9999999999999e-15j)
这与你得到的非常接近.所以看起来复杂c的numpy.log1p(c)确实是在调用numpy.log()之前将1.0添加到c.
结果"应该"接近p - p**2/2的p如此小(仅log(1+p)在p=0左右的泰勒展开式的前两项):
>>> p - p**2/2
(1e-14+9.9999999999999e-15j)
这本质上是由mpmath扩展模块交付的:
>>> import mpmath
>>> p = mpmath.mpc(1, 1) * 1e-14
>>> p
mpc(real='1.0e-14', imag='1.0e-14')
>>> mpmath.log1p(p)
mpc(real='1.0e-14', imag='9.9999999999999006e-15')
因此，这看起来像是numpy当前log1p()实现的(没有充分记录)限制.
因此，如果您必须为此使用numpy，则必须提供自己的替代方案.