已知问题

而大多数错误和问题都是使用 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之前):

参见: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

参见:https://github.com/astropy/astropy/issues/7582

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>

以及与 full 一个人做不到 zerosonesempty .

广播时数量会失去单位

广播数量时,必须通过 subok=Truebroadcast_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>

参见:https://github.com/astropy/astropy/issues/7832

数量浮动比较np.isclose公司失败

使用NumPy函数比较浮点数 isclose 在1.17之前的NumPy版本上失败 ab 是用公式

\[|a - b| \le (a_\textrm{tol} + r_\textrm{tol} \times |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将自动在文件上禁用)。

参见:https://github.com/astropy/astropy/issues/968

中的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.int64numpy.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(...) .

将复数转换为浮点时的不一致行为

尝试使用 float 还是NumPy的 numpy.float 关于一个标准复数(例如。, 5 + 6j )结果是 TypeError . 相反,使用 floatnumpy.float 关于NumPy的复数(例如。, numpy.complex128 )删除虚分量并发出 numpy.ComplexWarning . 这种不一致性持续存在于 Quantity 基于标准复数和NumPy复数的实例。要得到复数的实部,建议使用 numpy.real .

构建/安装/测试问题

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

这也表明您的区域设置不正确。

若要修复这些问题中的任何一个,请设置此环境变量以及 LANGLC_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.

参见:https://github.com/astropy/astropy/issues/717

某些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工作,那么这可能是可以接受的。

IPython问题:https://github.com/ipython/ipython/pull/2738

与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 .