使用import numpy as np我已经注意到了
np.tan(np.pi/2)
给出标题中的数字而不是 np.inf
16331239353195370.0
我很好奇这个号码.它与某些系统机器精度参数有关吗？我能用某些东西计算出来吗？(我正在思考类似的事情sys.float_info)
编辑:相同的结果确实可以在其他环境中重现,如Java,octace,matlab ......但是建议的欺骗并不能解释原因.
我天真地尝试创建一个递归生成器.没工作.这就是我做的:
def recursive_generator(lis):
yield lis[0]
recursive_generator(lis[1:])
for k in recursive_generator([6,3,9,1]):
print(k)
我得到的只是第一项6.
有没有办法使这样的代码工作？基本上yield在递归方案中将命令转移到上面的级别？
del似乎有一些困扰我的记忆.请参阅以下内容:
In [1]: import math
In [2]: math.cos(0)
Out[2]: 1.0
In [3]: del math.cos
In [4]: math.cos(0)
---------------------------------------------------------------------------
AttributeError Traceback (most recent call last)
<ipython-input-4-9cdcc157d079> in <module>()
----> 1 math.cos(0)
AttributeError: module 'math' has no attribute 'cos'
精细.让我们看看如果删除整个数学包会发生什么:
In [5]: del math
In [6]: math.cos(0)
---------------------------------------------------------------------------
NameError Traceback (most recent call last)
<ipython-input-6-9cdcc157d079> in <module>()
----> 1 math.cos(0)
NameError: name 'math' is not defined
所以现在数学本身就像预期的那样消失了.
现在让我们再次导入数学:
In [7]: import math
In [8]: math.cos(0)
---------------------------------------------------------------------------
AttributeError Traceback (most recent call …我有点失望，np.inf // 2评估为np.nan而不是np.inf，就像正常除法的情况一样。
有什么原因让我想念为什么nan比 更好的选择inf？
我做了一个实际测量最大递归限制的小函数:
def f(x):
r = x
try:
r = f(x+1)
except Exception as e:
print(e)
finally:
return r
知道我期待什么我检查过:
In [28]: import sys
In [29]: sys.getrecursionlimit()
Out[29]: 1000
然而
In [30]: f(0)
maximum recursion depth exceeded
Out[30]: 970
数字不固定,总是在~970左右,并且在python的不同实例之间略有变化(例如从spyder到system cmd提示符).
请注意我在python3上使用ipython.
这是怎么回事？为什么实际限制我会低于sys.getrecursionlimit()价值？
你能帮助理解native int类型和numpy.int32或numpy.int64类型之间的主要区别(如果有的话)是什么？
这令我感到困惑.即使不知道优先顺序,也可以检查收集表达式的两种可能方法是False:
>>> (0 is 0) == 0
False
>>> 0 is (0 == 0)
False
但
>>> 0 is 0 == 0
True
怎么会？
在for循环上下文中使用try-except时,到目前为止执行的命令显然已经完成了
a = [1, 2, 3, 'text', 5]
b = []
try:
for k in range(len(a)):
b.append(a[k] + 4)
except:
print('Error!')
print(b)
结果
Error!
[5, 6, 7]
然而,对于列表推导而言,情况并非如此
c=[]
try:
c = [a[k] + 4 for k in range(len(a))]
except:
print('Error!')
print(c)
结果是
Error!
[]
在发生异常之前构建的中间列表是否保留在任何位置？它可以访问吗？
我很惊讶
>>> import math
>>> 1**math.nan
1.0
虽然我们也是这样,但也是如此
>>> 0j**math.nan
0j
我没有找到任何其他例子.是否有一个我错过的理由或逻辑使得这个选择成为正确的选择？或者这是一个滑倒？
我在期待nan.至于除了1或之外的其他所有数字0j.
编辑1:感谢jedwards的评论,我有一个参考.但我仍然不明白为什么.为什么这个决定作为标准？另外,找不到参考0j**mat.nan......
编辑2:所以按照下面的答案和其他一些东西,逻辑可能是这样的:任何涉及的计算都nan应该返回,nan除非计算总是返回相同的答案而不管参数.在这种情况下,我们nan作为论据的事实不应该影响结果,我们仍然应该得到固定的答案.
这当然解释1**math.nan和math.nan**0.这也解释了为什么0**math.nan给nan,而不是0(因为0**n是0为所有,但,当n=0它与结果1),并可能被展宽到为什么math.nan*0是nan如果我们同意该说法不一定是有限的.
但如果这是现场背后的逻辑,那么0j**math.nan应该是nan,因为0j**n是0对所有n除的n=0地方0j**0是1.所以...确实0j**math.nan有不同的推理？或者是实施中的问题？
我注意到有复杂无穷大的有趣结果.
In [1]: import numpy as np
In [2]: np.isinf(1j * np.inf)
Out[2]: True
In [3]: np.isinf(1 * 1j * np.inf)
Out[3]: True
In [4]: np.isinf(1j * np.inf * 1)
Out[4]: False
这是nan相关的.但最终的结果是奇怪的.
这是一个numpy bug吗？我应该采取哪些不同的做法？