既知の問題¶
多くの誤りや問題は使用されていますが astropy issue tracker 本稿では、これらの問題が修復が困難であり、解決するためにユーザが何らかの介入を行う必要があるか、または他の項目またはパケット内のエラーによって引き起こされる可能性がある問題を提示する。
このページに記載されている問題は2つに分類される：1つ目は現在修復や解決方法がない実際のアルゴリズムとインタフェースにおける既知の問題と欠陥であり，ユーザが作成して使用している. astropy それがそうです。その中のいくつかの問題は依然としてプラットフォームに特定されており、他の問題は非常に一般的だ。2つ目は，構成，構築，実装時によく見られる問題である. astropy それがそうです。これはまた、試験キットが、それを実行するコンテキスト/プラットフォームに従って偽陰性を報告する可能性がある場合を含む。
既知の欠陥¶
いくつかの操作では、数が単位を失ってしまいます¶
数はNumPyのサブクラスです ndarray いくつかのNumPy動作(およびNumPyを内部で使用するSciPy動作では)、このサブクラスは無視され、これは、通常の配列に戻るか、または戻るかを意味する。 Quantity 職場がありません。例えば、Asterpy 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>
このような行動が生じることが知られている特定の関数(Asterpy 4.0およびNumpy 1.17の前のバージョン)の不完全リストは以下のとおりである。
numpy.hstack,numpy.vstack,numpy.c_,numpy.r_,numpy.appendパンダデータフレーム
Https：//github.com/avatipy/avospy/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/avatipy/avospy/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>
放送時には、数が単位を失ってしまいます¶
数量を放送するときは必ず通過しなければならない 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>
これは1つの量を 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/avatipy/avospy/Issues/7832を参照
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
NumPy 1.10上のnp.linspaceの数は失敗しました¶
linspace NumPyにおける誤りのため，NumPy 1.10.0から1.10.5を用いた場合，数を正しく扱うことができなかった.解決策は、NumPy 1.10.6以上にアップグレードされ、エラーが修復されました。
MMAPサポート astropy.io.fits GNU Hurdについて¶
ヘドには他にもプラットフォームがあるかもしれません flush() メモリマップファイルが実現されていないため、mmap‘d Fitsファイルへの変更書き込みが信頼できない可能性があり、無効にされています。Mmapを使用して書き込み可能モードでFITSファイルを開くことを試みると警告をもたらします(mmapはファイルを自動的に無効にします)。
Https：//github.com/avatipy/avospy/Issues/968を参照
Unicode Endiannessエラー io.fits 大端プロセッサの¶
大端プロセッサ(例えばSPARC，PowerPC，MIPS)では，使用する. Table.read インターフェースです。この問題は後続のエラー修復バージョンで修復されます astropy (会いましょう) bug report here ）。
Windows環境でのカラー印刷¶
ログメッセージおよび他のカラーテキストのカラー印刷はWindowsでは機能しませんが、IPythonコンソールで動作している場合にのみ機能します。Windows上のBasic Pythonコマンドラインインタプリタは現在色をサポートしていません。
numpy.int64 入力を分解しない Quantity 対象者.¶
巨大な人. int() 通過する. __index__ 同時に…。 numpy.int64 あるいは…。 numpy.int_ 通過しないで __index__ それがそうです。これは上流修復が ``numpy` is required in order for `` Asterpy.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 それがそうです。対照的に使われているのは float あるいは…。 numpy.float NumPyからの複数について(例えば、 numpy.complex128 )架空のコンポーネントを削除して発行する numpy.ComplexWarning それがそうです。この不一致は Quantity 標準複数とNumPy複数のインスタンスに基づく.複数の実部を得るためには、利用をお勧めします numpy.real それがそうです。
構築/インストール/テスト問題¶
ニシキヘビユーザーはアップグレードすべきです conda いいえ、違います pip¶
昇進して世代を変える. astropy Pythonリリースでは pip 古いバージョンと新しいバージョンが混在したファイルのインストールが破損する可能性があります。ニシキヘビのユーザーは以下の内容を使用して更新する必要があります conda update astropy それがそうです。発表の間に一時的な遅延がある可能性があります astropy PyPIとその通過について conda パケットマネージャ；ユーザは、以下のコマンドを使用して、新しいバージョンの可用性をチェックすることができます conda search astropy それがそうです。
MacOS XおよびLinuxの領域設定エラー¶
MacOS Xでは，実行時に以下のようなエラーが見られる可能性がある. 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
これはまたあなたの地域設定が正しくないということを見せてくれる。
この2つの問題のいずれかを解決するためには、この環境変数と 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.
Https：//github.com/avatipy/avospy/Issues/717を参照
いくつかの文書文字列はIPython<0.13.2に表示できません¶
IPythonコンソール(IPythonバージョン0.13.2前)のいくつかのプラットフォームにUnicode文字を含む長い文字列が表示されると失敗する可能性があります：
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符号化エラーを隠蔽することができるからである。しかし、あなたのアプリケーションがテキスト処理を処理せず、文書文字列のみを動作させたい場合、これは受け入れられるかもしれません。
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 V 2.0.x(LTS)、pytest 3.6以降を使用する必要があります。コアパッケージのバージョン3.0.x以降では、これらの問題は発生しません。
新しいバージョンにも影響を与えない問題があります astropy Pytest 4.0以降を使用してテストを行う場合、これは、収集テスト時に問題が生じる可能性があり、本例では、症状は、テスト収集保留および/またはテストを再帰的に実行するように見える。Astropyを使用して作成されたパッケージを維持している場合 package template 最新のバージョンに更新することで _astropy_init.py ファイルです。この問題の根本的な原因はpytestが現在最高レベルを取ろうとしているからです test() テストとして関数を設定する必要があります test.__test__ 属性は、 False それがそうです。