已知问题¶
而大多数错误和问题都是使用 astropy issue tracker ,本文档列出的问题太难修复,可能需要用户进行一些干预才能解决,或者是由其他项目或包中的错误引起的问题。
本页中列出的问题分为两类:第一类是实际算法和接口中已知的问题和缺点,目前还没有修复或解决方法,用户在编写使用 astropy
. 其中一些问题仍然是特定于平台的,而其他问题则是非常普遍的。第二类是在配置、构建或安装时出现的常见问题 astropy
. 这还包括测试套件可以根据运行它的上下文/平台报告误报的情况。
已知缺陷¶
一些操作会使数量失去单位¶
数量是从纽比的子类 ndarray
在某些NumPy操作中(以及在内部使用NumPy的SciPy操作中),子类被忽略,这意味着要么返回一个普通数组,要么 Quantity
没有单位。E、 g.,在astropy 4.0和numpy 1.17之前:
>>> import astropy.units as u
>>> import numpy as np
>>> q = u.Quantity(np.arange(10.), u.m)
>>> np.dot(q,q)
285.0
>>> np.hstack((q,q))
<Quantity [0., 1., 2., 3., 4., 5., 6., 7., 8., 9., 0., 1., 2., 3., 4., 5.,
6., 7., 8., 9.] (Unit not initialised)>
对于所有版本:
>>> ratio = (3600 * u.s) / (1 * u.h)
>>> ratio
<Quantity 3600. s / h>
>>> np.array(ratio)
array(3600.)
>>> np.array([ratio])
array([1.])
在某些情况下可以使用变通方法。以上内容:
>>> q.dot(q)
<Quantity 285. m2>
>>> np.array(ratio.to(u.dimensionless_unscaled))
array(1.)
>>> u.Quantity([q, q]).flatten()
<Quantity [0., 1., 2., 3., 4., 5., 6., 7., 8., 9., 0., 1., 2., 3., 4., 5.,
6., 7., 8., 9.] m>
以下是已知会显示这种行为的特定函数的不完整列表(在astropy 4.0和numpy 1.17之前):
numpy.hstack
,numpy.vstack
,numpy.c_
,numpy.r_
,numpy.append
Pandas数据帧
参见:https://github.com/astropy/astropy/issues/1274
使用数量设置数组切片时必须小心:
>>> a = np.ones(4)
>>> a[2:3] = 2*u.kg
>>> a
array([1., 1., 2., 1.])
>>> a = np.ones(4)
>>> a[2:3] = 1*u.cm/u.m
>>> a
array([1., 1., 1., 1.])
设置单个数组项或使用数量列表:
>>> a = np.ones(4)
>>> a[2] = 1*u.cm/u.m
>>> a
array([1. , 1. , 0.01, 1. ])
>>> a = np.ones(4)
>>> a[2:3] = [1*u.cm/u.m]
>>> a
array([1. , 1. , 0.01, 1. ])
如果单位不取消,两者都会抛出异常,例如:
>>> a = np.ones(4)
>>> a[2] = 1*u.cm
Traceback (most recent call last):
...
TypeError: only dimensionless scalar quantities can be converted to Python scalars
Numpy数组创建函数不能用于初始化数量¶
尝试以下示例将在1.20版之前的NumPy上引发UnitConversionError,并在以后的版本中忽略该单元:
>>> my_quantity = u.Quantity(1, u.m)
>>> np.full(10, my_quantity)
Traceback (most recent call last):
...
UnitConversionError: 'm' (length) and '' (dimensionless) are not convertible
目前解决这个问题的方法是:
>>> np.full(10, 1) << u.m
<Quantity [1., 1., 1., 1., 1., 1., 1., 1., 1., 1.] m>
广播时数量会失去单位¶
广播数量时,必须通过 subok=True
到 broadcast_to
或者一个裸体 ndarray
将返回:
>>> q = u.Quantity(np.arange(10.), u.m)
>>> b = np.broadcast_to(q, (2, len(q)))
>>> b
array([[0., 1., 2., 3., 4., 5., 6., 7., 8., 9.],
[0., 1., 2., 3., 4., 5., 6., 7., 8., 9.]])
>>> b2 = np.broadcast_to(q, (2, len(q)), subok=True)
>>> b2
<Quantity [[0., 1., 2., 3., 4., 5., 6., 7., 8., 9.],
[0., 1., 2., 3., 4., 5., 6., 7., 8., 9.]] m>
这类似于将数量传递给 array
::
>>> a = np.array(q)
>>> a
array([0., 1., 2., 3., 4., 5., 6., 7., 8., 9.])
>>> a2 = np.array(q, subok=True)
>>> a2
<Quantity [0., 1., 2., 3., 4., 5., 6., 7., 8., 9.] m>
数量浮动比较np.isclose公司失败¶
使用NumPy函数比较浮点数 isclose
在1.17之前的NumPy版本上失败 a
和 b
是用公式
这将导致以下回溯,当使用它与数量:
>>> from astropy import units as u, constants as const
>>> import numpy as np
>>> np.isclose(500 * u.km/u.s, 300 * u.km / u.s)
Traceback (most recent call last):
...
UnitConversionError: Can only apply 'add' function to dimensionless quantities when other argument is not a quantity (unless the latter is all zero/infinity/nan)
如果不能升级到numpy 1.17或更高版本,一种解决方案是:
>>> np.isclose(500 * u.km/u.s, 300 * u.km / u.s, atol=1e-8 * u.mm / u.s)
False
数量np.linspace公司NumPy 1.10故障¶
linspace
在使用NumPy 1.10.0到1.10.5时,由于NumPy中的错误,无法正确处理数量。解决方案是升级到NumPy 1.10.6或更高版本,在这个版本中,bug得到了修复。
的mmap支持 astropy.io.fits
在GNU赫德¶
在赫德和其他平台上, flush()
内存映射文件没有实现,因此向mmap的FITS文件写入更改可能不可靠,因此被禁用。尝试使用mmap以可写模式打开FITS文件将导致警告(并且mmap将自动在文件上禁用)。
中的Unicode Endianness错误 io.fits
对于大端处理器¶
在big-endian处理器(例如SPARC、PowerPC、MIPS)上,使用 Table.read
接口。这将在的后续bug修复版本中修复 astropy
(见 bug report here )
Windows上的彩色打印¶
日志消息和其他彩色文本的彩色打印在Windows中也可以工作,但只有在IPython控制台中运行时才可以。Windows上的基本Python命令行解释器当前不支持颜色。
numpy.int64
不分解输入 Quantity
物体¶
Python 的 int()
通过 __index__
虽然 numpy.int64
或 numpy.int_
不可穿过 __index__
. 这意味着上游修复 numpy` is required in order for ``astropy.units
要控制在这些函数中分解输入:
>>> np.int64((15 * u.km) / (15 * u.imperial.foot))
1
>>> np.int_((15 * u.km) / (15 * u.imperial.foot))
1
>>> int((15 * u.km) / (15 * u.imperial.foot))
3280
转换无量纲 Quantity
因此,建议使用 int(...)
.
构建/安装/测试问题¶
Anaconda用户应该使用 conda
,不是 pip
¶
升级 astropy
在 Python Python发行版中使用 pip
可能导致旧版本和新版本的文件混合在一起的损坏安装。Anaconda用户应使用更新 conda update astropy
. 在 astropy
关于PyPI及其通过 conda
包管理器;用户可以使用 conda search astropy
.
MacOS X和Linux中的区域设置错误¶
在MacOSX上,运行时可能会看到以下错误 pip
::
...
ValueError: unknown locale: UTF-8
这是由于 LC_CTYPE
环境变量未正确设置为 UTF-8
默认情况下,这不是有效的区域设置。
在MacOS X或Linux(或其他平台)上,您可能还会遇到以下错误:
...
stderr = stderr.decode(stdio_encoding)
TypeError: decode() argument 1 must be str, not None
这也表明您的区域设置不正确。
若要修复这些问题中的任何一个,请设置此环境变量以及 LANG
和 LC_ALL
环境变量,例如。 en_US.UTF-8
使用,在 bash
::
export LANG="en_US.UTF-8"
export LC_ALL="en_US.UTF-8"
export LC_CTYPE="en_US.UTF-8"
为了避免将来出现任何问题,您应该将这一行添加到您的示例中。 ~/.bash_profile
或 .bashrc
文件。
要测试这些更改,请打开新的端子并键入 locale
,你应该看到这样的东西:
$ locale
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
如果是这样,你可以继续尝试跑步 pip
再次(在新航站楼)。
在IPython中运行测试时日志记录测试失败¶
When running the Astropy tests using astropy.test()
in an IPython
interpreter, some of the tests in the astropy/tests/test_logger.py
might
fail depending on the version of IPython or other factors.
This is due to mutually incompatible behaviors in IPython and pytest, and is
not due to a problem with the test itself or the feature being tested.
某些docstring无法在IPython<0.13.2中显示¶
在IPython控制台(IPython版本0.13.2之前)的某些平台上,显示包含Unicode字符的长docstring可能会失败:
In [1]: import astropy.units as u
In [2]: u.Angstrom?
Out[2]: ERROR: UnicodeEncodeError: 'ascii' codec can't encode character u'\xe5' in
position 184: ordinal not in range(128) [IPython.core.page]
可以通过将默认编码改为 utf-8
通过将以下内容添加到 sitecustomize.py
文件::
import sys
sys.setdefaultencoding('utf-8')
请注意,总的来说, this is not recommended ,因为它可以隐藏应用程序中的其他Unicode编码错误。但是,如果应用程序不处理文本处理,并且只希望docstring工作,那么这可能是可以接受的。
与pytest 3.7及更高版本的兼容性问题¶
由于 pytest 与测试集合相关,核心的测试 astropy
对于版本2.0.x(LTS)的包,以及对于使用核心包的测试基础设施并正在针对2.0.x(LTS)进行测试的包,在pytest 3.7、3.8或3.9中无法正确执行。此错误的症状是不收集测试或只收集RST文件中的测试。此外, astropy
2.0.x(LTS)与pytest 4.0及更高版本不兼容,因为在这种情况下,pytest的不推荐错误可能会导致测试失败。因此,当测试 astropy
应使用v2.0.x(LTS)、pytest 3.6或更早版本。在3.0.x及更高版本的核心包中不会出现这些问题。
有一个无关的问题也会影响到最新版本的 astropy
当使用pytest 4.0和更高版本进行测试时,这可能会导致在收集测试时出现问题-在这种情况下,症状是测试集合挂起和/或以递归方式运行测试。如果您正在维护一个使用Astropy创建的包 package template ,则可以通过更新到最新版本的 _astropy_init.py
文件。这个问题的根本原因是pytest现在试图获取顶层 test()
作为一个测试,所以我们需要确保我们设置一个 test.__test__
函数的属性 False
.