范围生成器`r_` - 具有复杂(但不是虚构)步骤的切片;使用幅度

问题描述

玩 NumPy 连接和范围构建对象 r_ 我偶然发现了以下行为:显然,无论是实数、虚数还是适当的复数,一个复杂的步骤都将其绝对值作为类似 linspace 的步骤.

Playing with the NumPy concatenation and range building object r_ I stumbled over the following behavior: apparently, a complex step no matter whether real, imaginary or proper complex has its absolute value taken as the number of steps in a linspace like way.

>>> import numpy as np
>>> 
>>> np.r_[0:12:4]           # start : stop : step
array([0, 4, 8])            # that's expected
>>> np.r_[0:12:4j]          # start : stop : imaginary step
array([ 0.,  4.,  8., 12.]) # that's in the docs
>>> np.r_[0:12:4+0j]        # real step of complex type ?
array([ 0.,  4.,  8., 12.]) # this is not as far as I can tell
# you can even do stuff like
>>> np.r_[0:12:-4+3j]        # proper complex step ?
array([ 0.,  3.,  6.,  9., 12.])

问题:我只是想知道这是否是官方功能,因为我找不到它的文档.

Question: I just wanted to know whether that's an official feature, because I couldn't find it documented.

为什么相关?嗯,r_ 主要是为了节省击键的便利,在某些情况下,此功能可以为您节省几个字符.

Why is it relevant? Well, r_ primarily being a keystroke saving convenience there are a few cases where this feature could save you a few characters.


解决方案

代码确实取绝对值:

if isinstance(step, complex):
    size.append(int(abs(step)))

但这不是书面保证.docs 只保证虚数的行为,不保证任意复数:

but this is not a documented guarantee. The docs only guarantee behavior for imaginary numbers, not arbitrary complex numbers:

如果 step 是一个虚数(即 100j),则它的整数部分被解释为所需的点数,并且包含 start 和 stop

if step is an imaginary number (i.e. 100j) then its integer portion is interpreted as a number-of-points desired and the start and stop are inclusive

您不应依赖于非纯想象复杂输入的行为,因为它不是书面保证.

You should not rely on the behavior for not-purely-imaginary complex inputs, as it is not a documented guarantee.

也就是说,这可能是为了保证.我能够追踪 numpy.r_ 的代码的最远回溯是 这个提交.(这不是它的起源 - 我可以找到可追溯到 scipy.r_ 的引用.py" rel="nofollow noreferrer">更进一步 - 但尽管找到了对 scipy.r_ 的引用,但我还是无法找到 scipy.r_<的代码/code>,我怀疑 SciPy 和 NumPy GitHub 存储库都不包含原始代码.看起来像 这 将是正确的提交,除了 GitHub 似乎只有原始非 Git 提交的一部分.)

That said, it is possible that it was intended to be a guarantee. The furthest back I've been able to trace numpy.r_'s code is this commit. (That's not where it originated - I can find references to scipy.r_ dating back even further - but despite finding references to scipy.r_, I have not been able to locate the code for scipy.r_, and I suspect neither the SciPy nor NumPy GitHub repositories contain the original code. It seems like this would be the right commit, except that GitHub seems to only have a fragment of the original non-Git commit.)

r_ 没有记录在我可以追踪到的最早提交中,但 mgrid 也出现在该提交中,并且 mgrid'复数的类似行为在该提交中记录为

r_ was not documented in the earliest commit I can trace it to, but mgrid was also present in that commit, and mgrid's similar behavior for complex numbers was documented in that commit as

However, if the step length is a COMPLEX NUMBER (e.g. 5j), then the integer
part of it's magnitude is interpreted as specifying the number of points to
create between the start and stop values, where the stop value
IS INCLUSIVE.

我能够追踪 numpy.r_ 的文档的最远距离是 此提交 7 年后,标记为从 doc wiki 合并".我相信 doc wiki 现在已经消失了,我无法确定最初是谁贡献了这些文档,但这些文档似乎不是基于 numpy.r_ 的作者的最初意图.

The furthest I've been able to trace numpy.r_'s documentation is this commit 7 years later, labelled "Merge from doc wiki". I believe the doc wiki is now gone, and I have been unable to determine who originally contributed those docs, but it seems likely that those docs were not based on the original intent of numpy.r_'s author.

相关文章