numpy 🚀 - Windows 10を2004に更新した後、polyfitおよびeig回帰テストが失敗する

編集：あなたは明らかにpipを使用しています。最近、線形代数ライブラリと固有値分解（statsmodelsのテストの実行のコンテキストで）を使用して、WindowsAMD64で奇妙な結果が発生しました。

時間がある場合は、32ビットのPythonとpipを使用して、同じ問題が発生するかどうかを確認してください。 32ビットウィンドウでは表示されませんでしたが、64ビットウィンドウでは再現可能でした。

MKLを出荷するcondaを使用する場合、エラーは発生しません。

編集：WindowsAMD64でNumPy1.18.5を使用しているときにも表示されます。

bashtage 2020年07月03日

最新のWindows10アップデート後にテストが失敗する

更新前にテストは失敗しましたか？

charris 2020年07月03日

@charrisはありません。更新前は、テストスイートは合格です。

speixoto 2020年07月06日

@speixoto具体的にどのアップデートだったか知っていますか？それがピップ取り付けホイールの問題を解決するかどうかを確認したいと思います。

bashtage 2020年07月06日

アップデート1809（10.0.17763）は、 @ bashtageのテストの失敗を引き起こしていません

speixoto 2020年07月06日

1909年も何も引き起こしていませんでした。それは2004年に始まったばかりです。

Caiptain1 2020年07月06日

私はそれが2004年かそれ以降であると100％確信していません。 2004年はうまくいったと思います。

FWIW CI（Azureまたはappveyor）でこれらのクラッシュを再現することはできませんが、AMD64で2004年に更新された2台のマシンでローカルに再現できます。

あなたのどちらかが32ビットPythonでそれらを取得するかどうかを確認しようとしましたか？

bashtage 2020年07月06日

2004年のアップデートに対して多くの問題が報告されているようです。多分これも報告されるべきですか？

charris 2020年07月06日

1909年と2004年の新規インストールで以下を実行しました。

pip install numpy scipy pandas pytest cython
git clone https://github.com/statsmodels/statsmodels.git
cd statsmodels
pip install -e . --no-bulid-isolation
pytest statsmodels

1909年には失敗はありませんでした。 2004年には、すべて線形代数関数に関連する30の失敗がありました。

デバッガーで2004年にテストを実行すると、関数を最初に呼び出すと誤った結果が返されることがよくありますが、再度呼び出すと正しい結果が生成されます（繰り返し呼び出されても正しい結果が得られます）。これが原因の推測に役立つ情報かどうかはわかりません。

bashtage 2020年07月07日

以前のバージョンのNumPyにも問題がありますか？ 1.19.0を実行していると思います。

charris 2020年07月07日

pip +1.18.4とscipy1.4.1を使用すると、同じ一連のエラーが発生します。

これらは本当に一般的です：

ERROR statsmodels/graphics/tests/test_gofplots.py::TestProbPlotLongely::test_ppplot - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/graphics/tests/test_gofplots.py::TestProbPlotLongely::test_qqplot_other_array - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/graphics/tests/test_gofplots.py::TestProbPlotLongely::test_probplot - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/graphics/tests/test_regressionplots.py::TestPlot::test_plot_leverage_resid2 - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/regression/tests/test_regression.py::TestOLS::test_params - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/regression/tests/test_regression.py::TestOLS::test_scale - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/regression/tests/test_regression.py::TestOLS::test_ess - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/regression/tests/test_regression.py::TestOLS::test_mse_total - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/regression/tests/test_regression.py::TestOLS::test_bic - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/regression/tests/test_regression.py::TestOLS::test_norm_resids - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/regression/tests/test_regression.py::TestOLS::test_HC2_errors - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/regression/tests/test_regression.py::TestOLS::test_missing - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/regression/tests/test_regression.py::TestOLS::test_norm_resid_zero_variance - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/tsa/tests/test_stattools.py::TestADFConstant::test_teststat - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/tsa/tests/test_stattools.py::TestADFConstant::test_pvalue - numpy.linalg.LinAlgError: SVD did not converge
ERROR statsmodels/tsa/tests/test_stattools.py::TestADFConstant::test_critvalues - numpy.linalg.LinAlgError: SVD did not converge

bashtage 2020年07月08日

1.18.5 + MKLを使用して実行すると、エラーは発生しません。これがOpenBLASのバグなのかWindowsのバグなのかはわかりません。おそらく後者ですが、到達するのは非常に難しく、診断は低レベルのデバッグの私の能力を超えています。

同じ物理マシンで、pipパッケージを使用してUbuntuで実行すると、エラーは表示されません。

bashtage 2020年07月08日

👍2

これは最も奇妙な動作です。最初の呼び出しで失敗し、2番目以降で機能します。もう1つの理解しにくい動作は、失敗したテストを単独で実行した場合、エラーが表示されないことです。

svd

bashtage 2020年07月08日

最後の更新：最適化されたBLASなしでNumPyのソースビルドを使用してテストした場合、それらは同一のセットではありませんが、エラーが表示されます。

bashtage 2020年07月08日

たぶん、OpenBLAS開発者にpingする価値があります。 float32でもfloat64と同じくらい頻繁に発生しますか？

mattip 2020年07月08日

NumPy 1.19.0の完全なテストを実行すると、 python -c "import numpy;numpy.test('full')"上記と同じエラーが表示されます。

FAILED Python/Python38/Lib/site-packages/numpy/lib/tests/test_regression.py::TestRegression::test_polyfit_build - numpy.linalg.LinAlgError: SVD did not conv...
FAILED Python/Python38/Lib/site-packages/numpy/linalg/tests/test_regression.py::TestRegression::test_eig_build - numpy.linalg.LinAlgError: Eigenvalues did n...
FAILED Python/Python38/Lib/site-packages/numpy/ma/tests/test_extras.py::TestPolynomial::test_polyfit - numpy.linalg.LinAlgError: SVD did not converge in Lin...

bashtage 2020年07月08日

テストを排他的に実行するだけの場合は、pingを正しく覚えていれば合格するはずなので、さらに奇妙な動作を意味します。

Caiptain1 2020年07月08日

私が知っている唯一の方法は、マイクロソフトに提出したことです。

https://aka.ms/AA8xe7q

他の人が検索でこれを見つけた場合の投稿：

これが解決されるまで、Windowsユーザーは2004年にConda / MKLを使用する必要があります

bashtage 2020年07月08日

👍2

これは小さな再現例です：

import numpy as np
a = np.arange(13 * 13, dtype=np.float64)
a.shape = (13, 13)
a = a % 17
va, ve = np.linalg.eig(a)

を生成します

 ** On entry to DGEBAL parameter number  3 had an illegal value
 ** On entry to DGEHRD  parameter number  2 had an illegal value
 ** On entry to DORGHR DORGQR parameter number  2 had an illegal value
 ** On entry to DHSEQR parameter number  4 had an illegal value
---------------------------------------------------------------------------
LinAlgError                               Traceback (most recent call last)
<ipython-input-11-bad305f0dfc7> in <module>
      3 a.shape = (13, 13)
      4 a = a % 17
----> 5 va, ve = np.linalg.eig(a)

<__array_function__ internals> in eig(*args, **kwargs)

c:\anaconda\envs\py-pip\lib\site-packages\numpy\linalg\linalg.py in eig(a)
   1322         _raise_linalgerror_eigenvalues_nonconvergence)
   1323     signature = 'D->DD' if isComplexType(t) else 'd->DD'
-> 1324     w, vt = _umath_linalg.eig(a, signature=signature, extobj=extobj)
   1325
   1326     if not isComplexType(t) and all(w.imag == 0.0):

c:\anaconda\envs\py-pip\lib\site-packages\numpy\linalg\linalg.py in _raise_linalgerror_eigenvalues_nonconvergence(err, flag)
     92
     93 def _raise_linalgerror_eigenvalues_nonconvergence(err, flag):
---> 94     raise LinAlgError("Eigenvalues did not converge")
     95
     96 def _raise_linalgerror_svd_nonconvergence(err, flag):

LinAlgError: Eigenvalues did not converge

LAPACKは0または1からカウントされますか？不正な値はすべて整数のようです。
DGEBAL
DGEHRD
DORGHR
DHSEQR

bashtage 2020年07月08日

それはOpenBlasの問題（または2004年からOpenBLASの間の問題）のように見えます。これが私の要約です：

NumPyのみpython -c "import numpy;numpy.test('full')"

最適化されたBLASがない：完全に合格
OpenBLAS：完全に失敗する
MKL：パスフル

pytest statsmodelsテストするstatsmodels

Pip NumPyおよびSciPy：SVDおよびQR関連のコードに関連する失敗
MKL NumPyおよびSciPy：合格
最適化されたBLASがない：失敗しますが、OpenBLASを使用するscipy.linalgルーチンを含むものはほとんどありません。
最適化されたBLAS、SciPYリナルグなし：合格

bashtage 2020年07月08日

👍2

2004年に何が変わったのかを知るのはいいことです。ライブラリをコンパイル/リンクするときに別のフラグが必要になるかもしれません。

charris 2020年07月08日

_もし_それがOpenBLASのバグであるなら、WindowsベースのCIのどれもビルド19041（別名Windows 10 2004）以降を使用していないので、彼らがそれを見た可能性は低いです。

bashtage 2020年07月08日

明確にするために、これらのレポートのいずれもWSLに関係していないというのは本当ですか？

charris 2020年07月08日

👍1

いいえ。すべて、condaが提供するpython.exeまたはpython.orgが提供するpython.exeいずれかを使用します

bashtage 2020年07月08日

環境変数OPENBLAS_CORETYPE=HaswellまたはOPENBLAS_CORETYPE=NEHALEMが明示的に設定されている場合、テストは失敗しますか？

carlkl 2020年07月08日

Atom、SandyBridge、Haswell、Prescott、Nehalemを試しましたが、すべて同じ結果でした。

bashtage 2020年07月09日

最も奇妙なことは、あなたが走ると

import numpy as np
a = np.arange(13 * 13, dtype=np.float64)
a.shape = (13, 13)
a = a % 17
va, ve = np.linalg.eig(a)  # This will raise, so manually run the next line
va, ve = np.linalg.eig(a)

eigへの2回目（およびそれ以降）の呼び出しは成功します。

bashtage 2020年07月09日

SciPyには同様のエラーがあります

import numpy as np
import scipy.linalg
a = np.arange(13 * 13, dtype=np.float64)
a.shape = (13, 13)
a = a % 17
va, ve = scipy.linalg.eig(a)

上げる

 ** On entry to DGEBAL parameter number  3 had an illegal value
 ** On entry to DGEHRD  parameter number  2 had an illegal value
 ** On entry to DORGHR DORGQR parameter number  2 had an illegal value
 ** On entry to DHSEQR parameter number  4 had an illegal value
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-58-8dfe8125dfe3> in <module>
      4 a.shape = (13, 13)
      5 a = a % 17
----> 6 va, ve = scipy.linalg.eig(a)

c:\anaconda\envs\py-pip\lib\site-packages\scipy\linalg\decomp.py in eig(a, b, left, right, overwrite_a, overwrite_b, check_finite, homogeneous_eigvals)
    245         w = _make_eigvals(w, None, homogeneous_eigvals)
    246
--> 247     _check_info(info, 'eig algorithm (geev)',
    248                 positive='did not converge (only eigenvalues '
    249                          'with order >= %d have converged)')

c:\anaconda\envs\py-pip\lib\site-packages\scipy\linalg\decomp.py in _check_info(info, driver, positive)
   1348     """Check info return value."""
   1349     if info < 0:
-> 1350         raise ValueError('illegal value in argument %d of internal %s'
   1351                          % (-info, driver))
   1352     if info > 0 and positive:

ValueError: illegal value in argument 4 of internal eig algorithm (geev)

bashtage 2020年07月09日

最後に、 np.complex128への変換も発生しますが、 np.float32またはnp.complex64への変換

bashtage 2020年07月09日

コードのPython部分は長整数でコンパイルされていますが、OpenBLASはFortran（LAPACK）部分でINTERFACE64 = 1なしでビルドされていますか？
（これでも、最初の呼び出しが失敗したが、その後は成功した理由や、更新19041の前に機能した理由は説明されません）

martin-frbg 2020年07月09日

Windows 10ユーザーは、Microsoftのフィードバックハブでこの問題に賛成することができます。

https://aka.ms/AA8xe7q

bashtage 2020年07月31日

@bashtageのリクエストで、コードを少し掘り下げました。浮動小数点の状態のいくつかの側面が、入力時に異なっていると思います。それはこれによって確認されるようです：

np.complex128への変換も発生しますが、np.float32またはnp.complex64への変換はどちらも問題なく機能します。

最初の警告メッセージ（成功した場合は表示されないようです）「DGEBALパラメーター番号3への入力時に不正な値がありました」は、この状態が原因で発生しますhttps://github.com/xianyi/OpenBLAS/blob/ce3651516f12079f3ca2418aa85b9ad571c3a391/lapack -netlib / SRC / dgebal.f＃L336。これは、NaNへの事前計算がいくつでも発生する可能性があります。

再現手順をいじってみると、modをfloat32として実行すると「修正」されることがわかりました。

import numpy as np
a = np.arange(13 * 13, dtype=np.float64)
a.shape = (13, 13)
a = (a.astype(np.float32) % 17).astype(np.float64) # <-- only line changed
va, ve = np.linalg.eig(a)

ですから、そのコードパスには、状態を適切にリセットしているものがあると思いますが、それが何であるかはわかりません。うまくいけば、numpyの内部に精通している誰かがそれがどこで起こっているのか知っているかもしれません。

zooba 2020年08月06日

ある種、WINDOWSのmingwで見た古いバグを思い出します。このバグでは、浮動小数点レジスター構成がワーカースレッドに継承されなかったため、非正規化数がゼロにフラッシュされず、後続の計算が混乱することがありました。
これが現在のハードウェア上の現在のWindowsに何らかの形で関連しているかどうかはわかりませんが、
OpenBLASビルドはCONSISTENT_FPCSR = 1で行われました（またはそのビルドオプションを追加すると役立つ場合）。

martin-frbg 2020年08月06日

@mattipOpenBLASビルドでCONSISTENT_FPCSR = 1かどうか知っていますか？

bashtage 2020年08月06日

残念ながら、そうなっているように見えます。

https://github.com/MacPython/openblas-libs/blob/444203b6dff90c2f0d2304fb3d85e1ac6db5c1e8/appveyor/build_openblas.sh#L68

bashtage 2020年08月06日

まあ、少なくともこれは邪魔にならない。とにかく接続はかなりリモートのようでした。

martin-frbg 2020年08月06日

こんにちは！私はしばらくの間同様の問題を経験していて、私のすべてのテストは、Windows 10（2004）とOpenBlasの間で何か怪しいものを示しています。私は通常、3台のPC（2台のWindows10ワークステーションと古いWindows7ラップトップ）でプログラムを実行します。 2台のワークステーションをバージョン2004のWindows10にアップグレードした頃、Pythonスクリプトがlinalgとsvd（）の収束に関連するエラーで誤動作し始めました。また、スクリプトを初めて実行したときにクラッシュが発生しましたが、ほとんどの場合、 2回目の試行（Jupyterノートブックの実行）で動作しました。古いラップトップリグはエラーなしで同じプログラムを実行し続けました！ miniconda、python 3.6があり、すべてのパッケージはpipを使用してインストールされます（envは3台のマシンでまったく同じです）。
今日、私はpipのデフォルトのnumpy（1.19.0）インストールを削除し、https：//www.lfd.uci.edu/からnumpy + mkl（numpy-1.19.1 + mkl-cp36-cp36m-win_amd64.whl）バージョンをインストールしました。〜gohlke / pythonlibs /。これまでのところ、linalgとsvd（）の収束に関連するエラーはなくなりました。他に何か見つけたら、ここに戻って報告します。

ダリオ

dario-passos 2020年08月11日

👍2

OpenBLAS dllがVC9バージョンのlib.exeによって作成されているのは奇妙ですか？これは、Python2.7で使用されたバージョンです。それは問題ではないかもしれませんが、VC9がどこにも使用されていないことを考えると奇妙に感じます。

誰か（おそらく私）の次のステップは、シングルスレッドのOpenBLAS（ USE_THREAD=0 ）を使用してNumPyマスターを構築し、これで問題が解決するかどうかを確認することです。

bashtage 2020年08月11日

私はいくつかの実験を試みましたが成功しませんでした：

スレッドを無効にするUSE_THREADS=0
ILP64 INTERFACE64=1 <-アクセス違反のあるNumPyのテストでのセグメンテーション違反

bashtage 2020年08月12日

そのWin10セットアップでLAPACKテストスイートを実行できますか？私は最近、cmakeビルドを修正してそれを生成しました。おそらく、それは、何の問題もなく、いくつかの手がかりを提供します。

martin-frbg 2020年08月12日

                        -->   LAPACK TESTING SUMMARY  <--
SUMMARY                 nb test run     numerical error         other error
================        ===========     =================       ================
REAL                    409288          0       (0.000%)        0       (0.000%)
DOUBLE PRECISION        410100          0       (0.000%)        0       (0.000%)
COMPLEX                 420495          0       (0.000%)        0       (0.000%)
COMPLEX16               13940           0       (0.000%)        0       (0.000%)

--> ALL PRECISIONS      1253823         0       (0.000%)        0       (0.000%)

私はのような多くの行を見ますが

-->  Testing DOUBLE PRECISION Nonsymmetric Eigenvalue Problem [ xeigtstd < nep.in > dnep.out ]
---- TESTING ./xeigtstd... FAILED(./xeigtstd < nep.in > dnep.out did not work) !

ですから、これらが信頼できるかどうかはわかりません。

bashtage 2020年08月12日

テストの大部分はセグフォールトであるように見えますが、生き残ったテストは完璧です...これは私が予想したよりも少し極端です。
（COMPLEXとCOMPLEX16はスタックサイズの点で少し厳しいので、デフォルトのOS設定で失敗する可能性がはるかに高くなりますが、REALとDOUBLEは通常約1200000のテストが実行されます。これは、MSがデフォルトのスタックで何かを変更したかどうか疑問に思います。ただし、制限またはレイアウト）

martin-frbg 2020年08月12日

いくつかの背景。すべてがgcc.exe / gfortran.exeで構築されています。これらは、.aファイルを生成するために使用され、その後DLLにパッケージ化されます。具体的には：

$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\git\numpy-openblas-windows\openblas-libs\mingw64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/git/numpy-openblas-windows/openblas-libs/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/7.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-7.1.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64 --enable-shared --enable-static --disable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-libstdcxx-filesystem-ts=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2 --with-libiconv --with-system-zlib --with-gmp=/c/mingw710/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/c/mingw710/prerequisites/x86_64-w64-mingw32-static --with-mpc=/c/mingw710/prerequisites/x86_64-w64-mingw32-static --with-isl=/c/mingw710/prerequisites/x86_64-w64-mingw32-static --with-pkgversion='x86_64-posix-seh-rev0, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -fno-ident -I/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/include -I/c/mingw710/prerequisites/x86_64-zlib-static/include -I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -fno-ident -I/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/include -I/c/mingw710/prerequisites/x86_64-zlib-static/include -I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS=' -I/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/include -I/c/mingw710/prerequisites/x86_64-zlib-static/include -I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' LDFLAGS='-pipe -fno-ident -L/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/lib -L/c/mingw710/prerequisites/x86_64-zlib-static/lib -L/c/mingw710/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 7.1.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project)

$ gfortran -v
Using built-in specs.
COLLECT_GCC=C:\git\numpy-openblas-windows\openblas-libs\mingw64\bin\gfortran.exe
COLLECT_LTO_WRAPPER=C:/git/numpy-openblas-windows/openblas-libs/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/7.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-7.1.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64 --enable-shared --enable-static --disable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-libstdcxx-filesystem-ts=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2 --with-libiconv --with-system-zlib --with-gmp=/c/mingw710/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/c/mingw710/prerequisites/x86_64-w64-mingw32-static --with-mpc=/c/mingw710/prerequisites/x86_64-w64-mingw32-static --with-isl=/c/mingw710/prerequisites/x86_64-w64-mingw32-static --with-pkgversion='x86_64-posix-seh-rev0, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -fno-ident -I/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/include -I/c/mingw710/prerequisites/x86_64-zlib-static/include -I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -fno-ident -I/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/include -I/c/mingw710/prerequisites/x86_64-zlib-static/include -I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS=' -I/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/include -I/c/mingw710/prerequisites/x86_64-zlib-static/include -I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' LDFLAGS='-pipe -fno-ident -L/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/lib -L/c/mingw710/prerequisites/x86_64-zlib-static/lib -L/c/mingw710/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 7.1.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project)

bashtage 2020年08月12日

問題はNumPyとOpenBLASの間の受け渡しにあると私は本当に思います。最初の呼び出しがエラーである場合にこの動作が他にどのように発生するかは想像できませんが、2番目以降はすべて問題ありません。それを解決する方法（またはTBHでさえ深い問題を正確に診断する方法）...？

bashtage 2020年08月12日

MSプラットフォームを廃止し、その後も幸せに暮らしますか？ lapackテストに失敗した場合、ハンドオフの問題は、Fortran（= OpenBLASのLAPACK部分）とCの間、またはFortranと「その他」の間にあります。

martin-frbg 2020年08月12日

iccを使用してOpenBLASでNumpyを構築できるかどうか知りたいです
そして、問題が解決しないかどうかを確認してください。しかし、それは大きな質問です。

水曜日、2020年8月12日には、19：04マーティン・クローカーの[email protected]は書きました：

MSプラットフォームを廃止し、その後も幸せに暮らしますか？それが失敗した場合
lapackは、ハンドオフの問題がFortran（= LAPACKの一部
OpenBLAS）とC、またはFortranと「その他」。
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/16744#issuecomment-673026759 、または
退会
https://github.com/notifications/unsubscribe-auth/ABKTSRLSHZ2XWF4OE7J3QO3SALKSJANCNFSM4OP5IXNQ
。

bashtage 2020年08月12日

IntelコンパイラでOpenBLASをビルドするだけでおそらく十分でしょう（ただし、少なくとも最近登場したVSでは十分に問題があるようで、現時点ではifc / ifortの有効なライセンスを持っていません。

martin-frbg 2020年08月12日

bashtage 2020年08月20日

これが解決されるまで、Windowsユーザーは2004年にConda / MKLを使用する必要があります

@bashtageご提案ありがとうございます。
私の場合、Condaバージョンのnumpyを適用した後、pandasqlでsqliteを使用するとエラーが発生します。

しかし、このバージョンのnumpy + mklを使用しても問題はありません。

krazyeom 2020年08月26日

@bashtage錆びたリンクの問題が修正された、新しいMSVCプレリリースがあるようです。試してみる価値はありますか？

mattip 2020年08月26日

参考：関連するSciPyの問題： https ：

WarrenWeckesser 2020年08月26日

Windowsビルド17763.1397（8月11日）で問題が修正されたという報告があります。＃17082を参照してください。

charris 2020年09月01日

😕1

Windowsビルド17763.1397（8月11日）で問題が修正されたという報告があります。＃17082を参照してください。

https://support.microsoft.com/en-us/help/4565349/windows-10-update-kb4565349

ビルド17763.1397は、Windows 10バージョン1809専用です（適用対象：Windows 10、バージョン1809、すべてのエディションWindowsServerバージョン1809WindowsServer 2019、すべてのエディション）。
この場合、Windows10バージョン1809では問題はありません。

これは最近、Windows10のバージョン2004のアップデートバージョンです。
https://support.microsoft.com/en-us/help/4566782
2020年8月11日-KB4566782（OSビルド19041.450）。

Windows 10、バージョン2004でも同じ問題が発生します

krazyeom 2020年09月01日

19042.487での同じ障害（これは20H2ブランチです）：

-- Docs: https://docs.pytest.org/en/stable/warnings.html
=============================================== short test summary info ===============================================
FAILED lib/tests/test_regression.py::TestRegression::test_polyfit_build - numpy.linalg.LinAlgError: SVD did not conve...
FAILED linalg/tests/test_regression.py::TestRegression::test_eig_build - numpy.linalg.LinAlgError: Eigenvalues did no...
FAILED ma/tests/test_extras.py::TestPolynomial::test_polyfit - numpy.linalg.LinAlgError: SVD did not converge in Line...
3 failed, 11275 passed, 559 skipped, 20 xfailed, 1 xpassed, 1 warning in 398.16s (0:06:38)

bashtage 2020年09月01日

OpenBLASのlapackテストで（部分的な）失敗を再現できます。これは、スタックサイズの要件が異常に高いことが知られているEIG（固有値）テストにのみ影響します。そこでSIGSEGVは、main（）の前でも入力された__chkstk_ms_で発生します。 peflagsユーティリティ（ peflags -x4194304 -X4194304 EIG/xeigtsts.exe ）を使用して、それぞれの実行可能ファイルのデフォルトの「スタック予約サイズ」と「スタックコミットサイズ」の値を2倍にすると、プログラムは正常に動作し、C / Fortranの相互作用と引数の受け渡しが問題ありません。私はまだこれをnumpyの場合に適用しようとはしていませんが（誰のpeflag設定で調整するのかわからない-python.exe？）、19041.450別名のgcc9.1.0のmsys2mingw64バージョンでビルドするとOpenBLAS自体は正常に機能するようです2004年

martin-frbg 2020年09月01日

👍1

@ martin-frbgそれは進歩のように見えます。

charris 2020年09月02日

Windows / MSYS2でnumpyを構築するためにすべての依存関係をインストールしようとして、うさぎの穴に行きました。

martin-frbg 2020年09月03日

@ martin-frbg、Msys2ベースのnumpyパッケージはpacmanでインストールできます。 Msys2ビルドスクリプトとパッチは、 https ： //github.com/msys2/MINGW-packages/tree/master/mingw-w64-python-numpyおよびhttps://github.com/msys2/MINGW-packages/treeから入手できます。

carlkl 2020年09月04日

最近のトリアージ会議では、これは比較的優先度の高いものとして取り上げられました。 @ hameerabbasiと私は喜んでお手伝いします。私たちは何ができる？

@bashtage editbin /STACK:3145728 python.exeスタックを大きくしてみてください

ビルドしたライブラリの代わりに、OpenBLASのリリースのライブラリを使用してNumPyをビルドしてみる方法はありますか？おそらく私たちのビルドは少しずれています。

mattip 2020年09月09日

ビルド内のlibopenblas.dllを、現在のdevelopブランチ、または0.3.8や0.3.9などの古いリリースから作成されたものに置き換えて、効果があるかどうかを確認することはおそらく可能でしょうか。（私は今、これに何らかの関係がある可能性のある特定のコミットメントを念頭に置いているわけではありません）。残念ながら、msys2パッケージを使用してもインストールエラーが発生します。現在、self.ld_versionがバージョンチェックで何も返さないため、テストを実行できません。

martin-frbg 2020年09月09日

ありがとう。 Windowsを更新して2004をビルドしようとしています。週末までに終了するかどうかを確認しましょう。

mattip 2020年09月09日

また、 https： //github.com/numpy/numpy/issues/16744#issuecomment -655430682からのbashtageの「小さな再現例」では、msys2のセットアップでエラーは発生しません。（私が知る限り、mingw64 / usr / libのlibopenblasは、Haswell用に構築されたシングルスレッドの0.3.10です）

martin-frbg 2020年09月09日

@ martin-frbg MSVCを使用してOpenBLASを構築することは可能ですか？

charris 2020年09月09日

プレーンMSVC？実行可能ですが、MSVCがアセンブリカーネルをサポートしていないため、最適化が不十分なライブラリを提供します。これは、TARGET = GENERIC用にOpenBLASを構築した場合と実質的に同じです。

martin-frbg 2020年09月09日

また、＃16744（コメント）からのbashtageの「小さな再現例」は、私のmsys2セットアップでエラーを発生させません。（私が知る限り、mingw64 / usr / libのlibopenblasは、Haswell用に構築されたシングルスレッドの0.3.10です）

それはNumPyとOpenBLASの間のインターフェースと関係があると確信しています。 NumPyの32ビットビルドにもこの問題はありません。私が話したマイクロソフトの人々からの考えは、これはおそらくスレッド同期の問題である可能性が高いと思われます。最初の呼び出しで間違った値がどのように存在し、その後の呼び出しでどのように修正されるかを説明できます。

bashtage 2020年09月10日

👍1

Windows / MSYS2でnumpyを構築するためにすべての依存関係をインストールしようとして、うさぎの穴に行きました。

苦痛です。私はそれをしましたが、いくつかの実験を試みるためにそれを自動化することは長い時間がかかりました。基本的に、 https：//github.com/MacPython/openblas-libsからステップをコピーして.aファイルを取得してから、。 NumPyをビルドするための

DLLビルドを取得する最も簡単な方法は、appveyorアカウントを開いてから、 https：//github.com/MacPython/openblas-libsのクローンを作成すること

bashtage 2020年09月10日

https://github.com/MacPython/openblas-libsを見ると、OpenBLASはINTERFACE64=1でビルドされているようです。これは、Msys2ビルドのOpenBLASとnumpyには当てはまりません。

carlkl 2020年09月10日

@carlklこの問題は、NumPyまたはOpenBLASのMsys2ビルドに関するものではありません。これは、Msys2が提供するgfortranを使用してFortranソースをコンパイルするWin32 / AMD64ビルドに関するものですが、MSのlib.exeを使用してコンパイル済みライブラリからWin32DLLをビルドします。

bashtage 2020年09月10日

@bashtage https://github.com/numpy/numpy/issues/16744#issuecomment -689785607で報告されたため、msys2内でセグメンテーション違反を再現できなかったため、これについて言及しました。そして、言及されたmsys2環境には、msys2が提供するopenblasとnumpyバイナリパッケージが含まれていると思います。

Windowsの64ビットnumpyがMSVCで同様のフラグを使用してコンパイルされているかどうかはわかりません。

carlkl 2020年09月10日

ところで：scipyリポジトリにフラグ-fdefault-integer-8が見つかりません。
-fdefault-integer-8でコンパイルされたコードが、このフラグなしでコンパイルされたコードとABI互換性があるかどうかはわかりません。

別の側面が頭に浮かびました。おそらく-fdefault-integer-8を-mcmodel=largeと組み合わせる必要があります。

編集：覚えておいてください：Windows64にはILP64ではなくLLP64メモリモデルがあります。
LLP64の意味：long：32ビット、ポインター：64ビット

carlkl 2020年09月10日

では、Win10-2004の問題が発生したnumpyビルドはどのサイズの整数を使用しますか？ OpenBLASが構築されたものと一致したほうがよいですが、IIRCのこのトピックは、このスレッドの早い段階ですでに取り上げられています（また、不一致は、Windowsのパッチレベルに関係なく、より顕著な破損につながる可能性があります）

martin-frbg 2020年09月10日

少なくともOpenblasは、 https：//github.com/MacPython/openblas-libs （appveyor.ymlを参照）を使用して3つのバリアントでビルドできます。

32ビット
64ビット
INTEGER64で64ビット

しかし、Windowsでのnumpy64ビットビルドに何が使用されているのかわからない場合。

carlkl 2020年09月10日

_そして不一致は、Windowsのパッチレベルに関係なく、おそらくより顕著な破損につながるでしょう_

-fdefault-integer-8は、LapackのFortran部分にのみ適用されます。基礎となるメモリモデル（LLP64）は変更されないため、FortranLapackパーツ以外で問題が発生する可能性があるかどうかはわかりません。

carlkl 2020年09月10日

うーん、

https://github.com/numpy/numpy/blob/60a21a35210725520077f13200498e2bf3198029/azure-pipelines.ymlによると

- job: Windows pool: vmImage: 'VS2017-Win2016' ... Python38-64bit-full: PYTHON_VERSION: '3.8' PYTHON_ARCH: 'x64' TEST_MODE: full BITS: 64 NPY_USE_BLAS_ILP64: '1' OPENBLAS_SUFFIX: '64_'
他のすべてのバージョン（ Python36-64bit-full 、 Python37-64bit-full ）は、NPY_USE_BLAS_ILP64なしでビルドされます。

carlkl 2020年09月10日

pypi.orgのNumpyバイナリはすべて、32ビット整数のopenblasで構築されています。 https://github.com/MacPython/numpy-wheels/blob/v1.19.x/azure/windows.yml

ビルドプロセスのgfortranとMSVCの詳細については、こちらを参照してopenblas.aファイルを使用し、gfortranを使用してDLLを生成します。 https://github.com/numpy/numpy/blob/74712a53df240f1661fbced15ae984888fd9afa6/numpy/distutils/fcompiler/gnu.py#L442 MSVCツールを使用して.defファイルから.libファイルを生成し、NumpyCコードをMSVCでコンパイルしますその.libファイルを使用してgfortranで生成されたDLLにリンクされます。

うまくいかない可能性のある理論上の可能性の1つは、静的なopenblas.aアーティファクトを生成したmingwと、numpyのビルド時に使用されるmingwバージョンとの間に何らかのmingwバージョンの不一致がある場合です。ただし、これが問題を引き起こす可能性があるかどうかはわかりません。

pv 2020年09月10日

choco install -y mingw --forcex86 --force --version=5.3.0使用されているwindows.ymlは古くなっているようです。 7.3.0または8.1.0使用してみませんか？ 2、3年前にgcc-5.xで発生した問題を思い出すことができます。

carlkl 2020年09月10日

windows.ymlで使用されているchocoinstall -y mingw --forcex86 --force --version = 5.3.0は古くなっているようです

これは32ビットWindowsビルド専用であるため、おそらくこの問題とは関係ありません。

pv 2020年09月10日

他のすべてのバージョン（ Python36-64bit-full 、 Python37-64bit-full ）は、NPY_USE_BLAS_ILP64なしでビルドされます。

Python3.6と3.8でも同じエラーが発生します。

bashtage 2020年09月10日

残っているアイデアが1つあります（私は暗闇の中で掘っています）：

OpenBLASは-fno-optimize-sibling-callsでコンパイルされるようになりました。https： //github.com/xianyi/OpenBLAS/issues/2154、https ： //github.com/xianyi/OpenBLAS/pull/2157、https ：// gccを参照してください。 .gnu.org / bugzilla / show_bug.cgi？id = 90329。
編集：参照： https ：

Numpyは、distutilsのgfortran部分にこのフラグを適用しませんでした。 numpyがMSVCでコンパイルされていることを知っています。したがって、numpyではなくscipyで問題が発生することが予想されるため、これも間違った旅行になる可能性があります。

carlkl 2020年09月11日

pypi.orgのNumpyバイナリはすべて、32ビット整数のopenblasで構築されています。 https://github.com/MacPython/numpy-wheels/blob/v1.19.x/azure/windows.yml

テストで使用されるビルド構成がリリースで使用されるものと異なるのはなぜですか？これはリスクのように聞こえます。

bashtage 2020年09月11日

Azureビルドにアーティファクトを追加できますか？これにより、テスト用のホイールを簡単に入手できるようになります。ここでの私の唯一の懸念は、無料のアーティファクトの制限がかなり小さいIIRC、1GBであり、それに達したときに何が起こるかわかりません（FIFOは良いでしょうが、エラーを含む他のことをするかもしれません）。

bashtage 2020年09月11日

テストで使用されるビルド構成がリリースで使用されるものと異なるのはなぜですか？

サポートされているすべてのPythonバージョンをNPY_USE_BLAS_ILP64ないWindowsでテストし、Python 3.8もNPY_USE_BLAS_ILP64テストします。https：//github.com/numpy/numpy/blob/v1.19.2/azureを参照して

Azureビルドにアーティファクトを追加できますか？

おそらくこれを試して、エラーが発生した場合の制限について調べるのは簡単です。ただし、ウィークリーホイールは、テストビルドを忠実に再現することを目的としています。不一致がある場合は、エラーとして扱い、修正する必要があります。

mattip 2020年09月11日

おそらくこれを試して、エラーが発生した場合の制限について調べるのは簡単です。ただし、ウィークリーホイールは、テストビルドを忠実に再現することを目的としています。不一致がある場合は、エラーとして扱い、修正する必要があります。

メインリポジトリへのPRで実験し、アーティファクトを取得して2004年にテストする方が簡単だと思っていました。

bashtage 2020年09月11日

理にかなっています。

mattip 2020年09月11日

repo bashtage / numpyでAzureパイプラインをオンにすることができます

mattip 2020年09月11日

もう少し情報：最初に失敗する呼び出しは、OpenBLAS内のDNRM2がNANを返すためです。私にとって、これは繰り返し可能です。

a = np.arange(13 * 13, dtype=np.float64).reshape(13, 13)
a = a % 17
np.linalg.eig(a)

** On entry to DGEBAL parameter number 3 had an illegal value 。これは、「 DNRM2がNANを返した」という別の言い方です。 mod操作は重要です。これがないと、 eig呼び出してもこのエラーは出力されません。

mod ufuncとOpenBLASの呼び出しの間にどのような相互作用があるのでしょうか？

mattip 2020年10月01日

mod操作は重要です。これがないと、 eig呼び出してもこのエラーは出力されません。

これとまったく同じ配列を手動で作成すると、エラーが繰り返し発生しますか？

hameerabbasi 2020年10月01日

このコードは失敗を引き起こしません：

a = np.array([x % 17 for x in range(13 * 13)], dtype=np.float64)
a.shape = (13, 13)
np.linalg.eig(a)

mattip 2020年10月01日

👍1

前のmodは、レジスタを未定義の状態のままにすることができますか？ nrm2.Sを再度チェックしていませんが、数年前に、レジスタをそれ自体とXORしてクリアするためにアセンブリXORを実行することで問題が発生し、NaNでは失敗したと思います。

martin-frbg 2020年10月01日

以下の場合、float64 %は、値ごとにnpy_divmodを呼び出すことになります。

mattip 2020年10月01日

...これは、最初の行でnpy_fmod()呼び出します。これはfmod（）です。これが私が試したいくつかの変更です。「エラー」は、 a % 17; np.linalg.eig(a)を呼び出すコードを実行すると、OpenBLASから「不正な値」メッセージが表示されることを意味します
コード| 結果
--- | ---
mod = npy_fmod@c@(a, b); （元のコード）| エラー
mod = 100; //npy_fmod@c@(a, b); | エラーなし
mod = npy_fmod@c@(a, b); mod = 100.0; | エラー

したがって、MSVCのfmod 、OpenBLASを混乱させるようなことをしているようです。

mattip 2020年10月01日

それは面白くて奇妙です。

charris 2020年10月01日

ナイーブ（プラットフォームでは提供されていない）バージョンのfmodを使用して、それが修正されたかどうかを確認できますか？

bashtage 2020年10月01日

または、 HAVE_MODFを0強制します。

bashtage 2020年10月01日

ナイーブバージョンのfmodはないと思いますか？

mattip 2020年10月01日

HAVE_MODFマクロがあるようですが、このパスはどこにつながりますか？

mattip 2020年10月01日

floatとlongdoubleが欠落している場合は、doubleバージョンにフォールバックします。 numpyをビルドするには、doubleバージョンが必須です。 undefはおそらく、コンパイラのインライン関数、つまりずっと前にWindowsで問題だったISTRを回避するためのものです。

charris 2020年10月01日

問題がucrtbase.dllからのfmod実装であることを「証明」したかったのです。そこで、ctypesを使用して関数をdllから引き出し、 fmodを直接呼び出す代わりにそれを使用する小さな回避策を作成しました。テストはまだ失敗します。次に、古いバージョンのucrtbase.dllに切り替えました（ fmod関数の場合のみ）。テストに合格します。 VisualStudioフォーラムでスレッドを開きました。誰かがマイクロソフトに連絡するためのより良い方法を知っているなら、それは素晴らしいことです。

diff --git a/numpy/core/src/npymath/npy_math.c b/numpy/core/src/npymath/npy_math.c
index 404cf67b2..675905f73 100644
--- a/numpy/core/src/npymath/npy_math.c
+++ b/numpy/core/src/npymath/npy_math.c
@@ -7,3 +7,27 @@

 #define NPY_INLINE_MATH 0
 #include "npy_math_internal.h"
+#include <Windows.h>
+
+typedef double(*dbldbldbl)(double, double);typedef double(*dbldbldbl)(double, double);
+
+dbldbldbl myfmod = NULL;
+
+typedef double(*dbldbldbl)(double, double);
+extern dbldbldbl myfmod;
+
+
+double __fmod(double x, double y)
+{
+    if (myfmod == NULL) {
+        HMODULE dll = LoadLibraryA("ucrtbase_old.dll");
+        //HMODULE dll = LoadLibraryA("c:\\windows\\system32\\ucrtbase.DLL");
+         myfmod = (dbldbldbl)GetProcAddress(dll, "fmod");
+    }
+    return myfmod(x, y);
+}
+
+long double __fmodl(long double x, long double y) { return fmodl(x, y); }
+float __fmodf(float x, float y) { return fmodf(x, y); }
+
+
diff --git a/numpy/core/src/npymath/npy_math_internal.h.src b/numpy/core/src/npymath/npy_math_internal.h.src
index 18b6d1434..9b0600a34 100644
--- a/numpy/core/src/npymath/npy_math_internal.h.src
+++ b/numpy/core/src/npymath/npy_math_internal.h.src
@@ -55,6 +55,11 @@
  */
 #include "npy_math_private.h"

+double __fmod(double x, double y);
+long double __fmodl(long double x, long double y);
+float __fmodf(float x, float y);
+
+
 /*
  *****************************************************************************
  **                     BASIC MATH FUNCTIONS                                **
@@ -473,8 +478,8 @@ NPY_INPLACE @type@ npy_@kind@@c@(@type@ x)
 /**end repeat1**/

 /**begin repeat1
- * #kind = atan2,hypot,pow,fmod,copysign#
- * #KIND = ATAN2,HYPOT,POW,FMOD,COPYSIGN#
+ * #kind = atan2,hypot,pow,copysign#
+ * #KIND = ATAN2,HYPOT,POW,COPYSIGN#
  */
 #ifdef HAVE_@KIND@@C@
 NPY_INPLACE @type@ npy_@kind@@c@(@type@ x, @type@ y)
@@ -484,6 +489,13 @@ NPY_INPLACE @type@ npy_@kind@@c@(@type@ x, @type@ y)
 #endif
 /**end repeat1**/

+#ifdef HAVE_FMOD@C@
+NPY_INPLACE @type@ npy_fmod@c@(@type@ x, @type@ y)
+{
+    return __fmod@c@(x, y);
+}
+#endif
+
 #ifdef HAVE_MODF@C@
 NPY_INPLACE @type@ npy_modf@c@(@type@ x, @type@ *iptr)
 {

mattip 2020年10月02日

fmod呼び出しの後にコードを追加して、 ST(0) nanが含まれないようにするとどうなりますか？または、合成的にnanに設定しますか？
呼び出し規約は、これらのレジスタの動作にいくつかの制約を課しますか？

pv 2020年10月02日

問題がucrtbase.dllからのfmod実装であることを「証明」したかったのです。そこで、ctypesを使用して関数をdllから引き出し、 fmodを直接呼び出す代わりにそれを使用する小さな回避策を作成しました。テストはまだ失敗します。次に、古いバージョンのucrtbase.dllに切り替えました（ fmod関数の場合のみ）。テストに合格します。 VisualStudioフォーラムでスレッドを開きました。誰かがマイクロソフトに連絡するためのより良い方法を知っているなら、それは素晴らしいことです。

少なくとも、紺碧のアカウントを持っている人なら誰でも、おそらくここでは多くの人が、それを賛成することができます。この問題が最初に発生したときに作成した、Azure MLで作業している連絡先に連絡して、何かできるかどうかを確認します。

bashtage 2020年10月02日

少なくとも、紺碧のアカウントを持っている人なら誰でも、おそらくここでは多くの人が、それを賛成することができます。

先端をありがとう、賛成！

larsoner 2020年10月02日

ナイーブバージョンのfmodはないと思いますか？

いいえ。これは、IEEE-754仕様で特定の動作をするために必要なトリッキーな機能です。また、非常に遅いので、おそらく仕様に関連しています。

charris 2020年10月02日

fmodのハードワークは、VS2019バリアントであっても、 fprem x87命令によって実行されます- @ mattipの要点（最後の行） https://gist.github.com/mattipを参照してください/ d9e1f3f88ce77b9fde6a285d585c738e。（ fprem1はremainderバリアントです。）

MMXまたはSSEレジスタと組み合わせて使用する場合は注意が必要です-ここで説明されているように： https ：

https://github.com/xianyi/OpenBLAS/issues/2709#issuecomment -702634696で説明されているように、利用可能ないくつかの代替実装があります。ただし、これらはすべてコンパイルにgcc（mingw-w64）が必要です。 OpenLIBMは、MSVCAFAIKではコンパイルされません。また、インラインアセンブラコードはMSVCでは許可されていません。原則として、numpyビルド中にfmodヘルパーライブラリをビルド（mingw-w64）して使用（MSVC）することができます。

carlkl 2020年10月02日

fmod呼び出しの後にコードを追加して、ST（0）にnanが含まれないようにするとどうなりますか？または、合成的にnanに設定しますか？呼び出し規約は、これらのレジスタの動作にいくつかの制約を課しますか？

WindowsでOpenBLASを呼び出す前に、レジスタをクリアするためのアセンブリを少し追加できると思います。少しのテストセットアップでこれを試してみましたが、masmアセンブリfooが弱いです。 fldz複数回呼び出すだけのプロシージャを作成しようとしましたが、使用すると例外が発生します。助けて？

lots_of_fldz.asm ：

.code
lots_of_fldz proc
    fldz
    fldz
    fldz
    fldz
    fldz
    fldz

lots_of_fldz endp
end

別のファイル：

#include <iostream>
#include <Windows.h>

extern "C" {
int lots_of_fldz(void);
}

int main()
{
    typedef double(*dbldbldbl)(double, double);
    //HMODULE dll = LoadLibraryA("D:\\CPython38\\ucrtbase_old.dll");
    HMODULE dll = LoadLibraryA("c:\\windows\\system32\\ucrtbase.DLL");
    if (dll == NULL) {
        return -1;
    }
    dbldbldbl myfmod;
    myfmod = (dbldbldbl)GetProcAddress(dll, "fmod");
    double x = 0.0, y = 17.0;
    double z = x + y;
    z = myfmod(x, y);
    lots_of_fldz();
    /* CRASH */
    std::cout << "Hello World!\n";
    return 0;
}

それらをVisualStudioプロジェクトに入れ、このガイドに従ってmasmコンパイルをオンにします

mattip 2020年10月04日

@ mattip 、mingw-w64（64ビット）の対応するfmod関数にあるものと同じtext:セグメントを作成する64ビットfmod関数のアセンブラーファイルを作成しました。これがバグのあるfmod関数の代わりとして機能するかどうかはわかりませんが、少なくとも1つは試してみる必要があります。結果のobjファイルをnpymath.libに追加できます。

fmod.asm：（64ビット）

.code
fmod PROC
    sub    rsp , 18h
    movsd  QWORD PTR [rsp+8h] , xmm0
    fld    QWORD PTR [rsp+8h]
    movsd  QWORD PTR [rsp+8h] , xmm1
    fld    QWORD PTR [rsp+8h]
    fxch   st(1)
L1:
    fprem
    fstsw  ax
    sahf
    jp     L1
    fstp   st(1)
    fstp   QWORD PTR [rsp+8h]
    movsd  xmm0 , QWORD PTR [rsp+8h]
    add    rsp,18h
    ret
fmod endp
end

masmコマンド： ml64.exe /c fmod.asmはfmod.obj作成します（ml64.exeの64ビットバリアントを使用）

「

objdump -D fmod.obj
....
Disassembly of section .text$mn:
0000000000000000 <fmod>:
   0:   48 83 ec 18            sub    $0x18,%rsp
   4:   f2 0f 11 44 24 08      movsd  %xmm0,0x8(%rsp)
   a:   dd 44 24 08            fldl   0x8(%rsp)
   e:   f2 0f 11 4c 24 08      movsd  %xmm1,0x8(%rsp)
  14:   dd 44 24 08            fldl   0x8(%rsp)
  18:   d9 c9                  fxch   %st(1)
  1a:   d9 f8                  fprem
  1c:   9b df e0               fstsw  %ax
  1f:   9e                     sahf
  20:   7a f8                  jp     1a <fmod+0x1a>
  22:   dd d9                  fstp   %st(1)
  24:   dd 5c 24 08            fstpl  0x8(%rsp)
  28:   f2 0f 10 44 24 08      movsd  0x8(%rsp),%xmm0
  2e:   48 83 c4 18            add    $0x18,%rsp
  32:   c3                     retq

carlkl 2020年10月04日

@carlklありがとう。 OpenBLAS関数を呼び出す前に、x86_64で使用できるST（N）レジスターをリセットするアセンブラーがあれば幸いです。今日、この問題はfmod変更のために発生しましたが、明日は別の機能になる可能性があります。戻り時にST(N)レジスタをリセットするために関数が必要かどうかはわかりません。そのような要件がない場合、 fmodは実際にはバグがなく、Windowsの変更により、OpenBLASでレジスターを使用する前にリセットできず、修正または回避できるようにする必要があります。

上記のfldzを使用してレジスタをリセットしようとしましたが、テストプログラムが機能しません。

mattip 2020年10月04日

@mattip 、私のアセンブラhttps ：

https://docs.microsoft.com/de-de/cpp/build/x64-calling-convention?view=vs-2019から：

The x87 register stack is unused. It may be used by the callee, but consider it volatile across function calls.

carlkl 2020年10月04日

OpenBLAS nrm2.Sの開始時に（PROFCODEマクロの後に） fninitを呼び出して、その理論を確認することもできると思います

martin-frbg 2020年10月04日

からの興味深いビット
SystemVアプリケーションのバイナリインターフェイスAMD64アーキテクチャプロセッサの補足ドラフトバージョン0.99.6

_MXCSRレジスタの制御ビットは呼び出し先に保存されます（呼び出し間で保持されます）が、ステータスビットは呼び出し元に保存されます（保存されません）。

_x87ステータスワードレジスタは呼び出し元で保存されますが、x87制御ワードは呼び出し先で保存されます。_

_すべてのx87レジスタは呼び出し元で保存されるため、MMXレジスタを使用する呼び出し先はより高速なfemms命令を使用できます。_

Windowsの64ビット呼び出し規約とはかなり異なります。

carlkl 2020年10月04日

@ martin-frbg、 fninitは危険です： The FPU control word is set to 037FH (round to nearest, all exceptions masked, 64-bit precision). X87の拡張精度は、すべての場合、特にWindowsでは必要ではありませんでした。

carlkl 2020年10月04日

簡単なテストのためだけに、リリースバージョンではこれは必要ありません。 OpenBLASがそれ自体の「前」に何らかの形でクリーンアップする必要があるとはまだ確信していませんが、レガシーx87fpuでのWindowsの動作に関する明確なドキュメントは見つかりません。 Agner Fogがhttp://www.agner.org/optimize/calling_conventions.pdfで呼び出し規約に関するドキュメントを持っていることに気づきました（FPレジスタのWin64処理の説明は13ページから始まりますが、コンテキストスイッチ全体の基本的な可用性と動作に焦点を当てています）。

martin-frbg 2020年10月04日

https://github.com/numpy/numpy/issues/16744#issuecomment-703305582を参照して

The x87 register stack is unused. It may be used by the callee, but consider it volatile across function calls.

これは、x87命令（Win64）を使用しないことを意味すると思います。もしそうなら、頑張ってください。言い換えれば、呼び出し先は危害を加えないようにする責任があります。

carlkl 2020年10月04日

うーん、MSVCコンパイラの動作を具体的に説明しているようですが、私はmingwエコシステムにいると思いますか？

martin-frbg 2020年10月04日

いいえ、Numpy（Pypi）はWindows上のMSVC（Visual Studio 2019）でコンパイルされています。 OpenBLASの場合、mingw-w64が使用されます（Fortranパーツのため）。また、ScipyFortranの部分はmingw-w64でコンパイルされています。ただし、CPythonとそのバイナリ拡張機能は、MSVCによって設定された標準に大きく基づいています。

carlkl 2020年10月04日

ところで：これがhttps://github.com/mingwpyの開発の理由であり、現在再び息を吹き返しています。（恥知らずなプラグ）

carlkl 2020年10月04日

別のビット：

mingw-w64は、MSVCと（ほぼ）同じ呼び出し規約を使用します。唯一の顕著な違いは、x86（32ビット）でのスタック配置の違いです。SIMDとサポートされていないvectorcallます。

carlkl 2020年10月04日

面白い。 x86は影響を受けません。 AMD64のみ。

日、2020年10月4日には、22時19分carlkl [email protected]は書きました：

別のビット：
mingw-w64は、MSVCと（ほぼ）同じ呼び出し規約を使用します。唯一の
注目すべき違いは、x86（32ビット）でのスタック配置の違いです-
SIMDおよびサポートされていないvectorcallに関連します。
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/16744#issuecomment-703317784 、または
退会
https://github.com/notifications/unsubscribe-auth/ABKTSRMFHWZVLDYDFGBM6YDSJDRGTANCNFSM4OP5IXNQ
。

bashtage 2020年10月04日

MSVC 32ビットはおそらくfpuを勘当していませんか？ fpuの一時的な置き換えを行います-nrm2.Sを使用してnrm2_see2.S（実行可能な場合、残念ながらコードベースに未使用で致命的なアセンブリルーチンが多数あります）またはOS用のプレーンCバージョン== Windowsの場合。（ただし、ここで説明する他の問題は別のものである必要があります。x86_64の他のすべての古いアセンブリルーチンは少なくともSSE2であると思います）

martin-frbg 2020年10月04日

@mattip、多分に呼び出し_fpresetの後にdivmod台無しにFPU状態からリセットするために十分なのですか？

carlkl 2020年10月05日

多分_fpresetへの呼び出し

いいえ、 ST(N)レジスタをリセットしたり、失敗したテストを修正したりすることはありません。

mattip 2020年10月05日

_fninitを試してみましたか？これにより、FPUスタックがリセットされます。または、 https：//stackoverflow.com/questions/19892215/free-the-x87-fpu-stack-ia32/33575875に記載されているfldz代わりにffreeまたはfstp ？

carlkl 2020年10月05日

https://developercommunity.visualstudio.com/content/problem/1208774/fpu-exception-in-fmod0-x-in-windows-10-version-200.htmlを参照して

carlkl 2020年10月05日

アセンブラコマンドを試してみますが、上記のコメントのテストプロジェクトがクラッシュします。誰かが私のコードを修正して機能させる必要があります（実際、 fninitは良い候補のようです）。その後、OpenBLASを呼び出す前に、NumPyのレジスタをリセットするアセンブラ命令を発行できます。

mattip 2020年10月05日

このようなもの？

.code
reset_fpu proc
    finit
    fldz
reset_fpu endp
end

finitはwaitとfninitです。 fninit後にfldzが必要かどうかはわかりません。

carlkl 2020年10月05日

コメントで述べたように、コンパイルされたアセンブリコードの呼び出しを正しく機能させるために何かが欠けています。これは私がそのコメントで持っていたものとほとんど同じです。コードはexited with code -2147483645クラッシュします。完全なコードを見て、それを機能させることができるかどうかを確認してください。

mattip 2020年10月05日

私はそれを試すことができます（明日）。ただし、このスニペットが役立つ場合があります。

https://www.website.masmforum.com/tutorials/fptute/fpuchap4.htm
（私が見つけたこのトピックについて最も読みやすいサイトの1つ）

FLDZ (Load the value of Zero)

Syntax:    fldz  (no operand)

Exception flags: Stack Fault, Invalid operation

This instruction decrements the TOP register pointer in the Status Word 
and loads the value of +0.0 into the new TOP data register.

If the ST(7) data register which would become the new ST(0) is not empty, both 
a Stack Fault and an Invalid operation exceptions are detected, setting both flags 
in the Status Word. The TOP register pointer in the Status Word would still 
be decremented and the new value in ST(0) would be the INDEFINITE NAN.

A typical use of this instruction would be to "initialize" a data register intended 
to be used as an accumulator. Even though a value of zero could also be easily 
loaded from memory, this instruction is faster and does not need the use of memory.

私が理解しているように、st（7）が使用されている場合、fldzはセグメンテーション違反を起こす可能性があります。

FFREE (Free a data register)

Syntax:   free st(x)

This instruction modifies the Tag Word to indicate that the specified 80-bit data register 
is now considered as empty. Any data previously in that register becomes unusable. 
Any attempt to use that data will result in an Invalid exception being detected and an 
INDEFINITE value possibly being generated.

Although any of the 8 data registers can be tagged as free with this instruction, 
the only one which can be of any immediate value is the ST(7) register when 
all registers are in use and another value must be loaded to the FPU. 
If the data in that ST(7) is still valuable, other instructions should be used 
to save it before emptying that register.

あなたは試すことができます：

.code
reset_fpu proc
    ffree st(7)
    fldz
reset_fpu endp
end

carlkl 2020年10月05日

申し訳ありませんが、はっきりさせていません。差し迫った問題は、どのアセンブラがではありません。当面の問題は、適切に、我々は2ファイル（でそれを使用することができますし、それを実証するような方法で呼び出し可能なプロシージャを作成する方法です*.asmとmain.c / main.cpp ）コンパイルして実行するプロジェクト。それができたら、さまざまな呼び出しと、それらがOpenBLASにどのように影響するかを引き続き調査できます。

mattip 2020年10月05日

@mattip 、わかりました。絶対にやってみますが、時間がかかるかもしれません。

carlkl 2020年10月05日

UCRTでのfmodの_tempory_の悪い動作は、OpenBLASによって_修復_される必要があるという印象を受けました： https ：
この場合の厄介なパッチは、ビルド中にOpenBLASバージョンが次のOpenBLASリリースよりも古くないことを保証するためのものです。

carlkl 2020年10月07日

@matti numpy/__init__.pyサニティチェックがあります。この問題を検出するために追加できる簡単で信頼性の高いテストはありますか？

charris 2020年10月07日

a = np.arange(13 * 13, dtype=np.float64).reshape(13, 13)
a = a % 17
va, ve = np.linalg.eig(a)

mattip 2020年10月07日

@mattip 、スニペットをありがとう。ただし、この種のテストを実行できるデスクトップにアクセスするには、しばらく時間がかかります。現在、私はほとんど何もインストールできない最小限のプログラミング環境のラップトップで作業しています。

carlkl 2020年10月07日

OpenBLAS v0.3.12の更新をマージし、そのバージョンを使用したローカルビルド+ Windows Update2004がテストスイートに合格しました。

mattip 2020年10月26日

🎉5 👍4

Windowsが更新されるまでこれを開いたままにしておきます。

charris 2020年10月28日

プレリリースホイールは新しいOpenBLASで構築されていますか？このバグが発生していたダウンストリームプロジェクトでさらにテストを行ってください。

bashtage 2020年10月28日

テストエラーがあったため、Windows 3.9プレリリースホイールは現在欠落しています（現在は修正されています）。固定ライブラリは、本日または明日リリースされる1.19.3で使用されます。

charris 2020年10月28日

/MTオプションは、Windowsで静的リンクを有効にします。 1909バージョンのMicrosoftSDKを使用して、libucrt.libに対して静的にリンクできる場合があります。これは、2004年と20H2のucrtbase.dllバグの回避策として機能する可能性があります。それは車輪を大きくするでしょう、それは欠点です。

bashtage 2020年11月02日

この/ MTの問題がまだ有効かどうかは

carlkl 2020年11月02日

NumPyがMTで構築される唯一のモジュールである場合、それは
OK。もちろん、NumPyがMTの場合、
ダウンストリームもMTである必要があるため、これは問題になります。

月、2020年11月2日には、19時37 carlkl [email protected]は書きました：

この/ MTの問題かどうかはわかりません
https://stevedower.id.au/blog/building-for-python-3-5-part-twoはまだです
有効ですが、考慮する必要があります。
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/16744#issuecomment-720682011 、または
退会
https://github.com/notifications/unsubscribe-auth/ABKTSRJIVAQLECK4E2EVSSDSN4C65ANCNFSM4OP5IXNQ
。

bashtage 2020年11月02日

この問題の推奨される回避策はありますか？私の状況は、2004年の更新に更新されたマシンを使用していて、pipを使用してnumpy / scipy / pandasなどをインストールするデスクトップソフトウェアを使用していることです。このソフトウェアはすべて、Microsoftの更新によって引き起こされるこの問題の影響を受けます。

condaを使用してnumpyをインストールすることは、私が取り組んでいるソフトウェアのオプションではないため、推奨事項をいただければ幸いです。

johnkabler 2020年11月02日

Dockerが必要ない場合は、1.19.3を固定できます。それは私のWindowsシステムのすべてのテストに合格します。

bashtage 2020年11月02日

ありがとう。 1.19.3はこの問題でpipと連携します。

johnkabler 2020年11月03日

悪いBLAS検出のリンクは、MSのサイトに多くのノイズの多い投稿を引き起こしています。これが爆発しないことを願っています。

別の方法は、Win64でサードパーティのfmodを使用することだと思います。

bashtage 2020年11月03日

NumPyに、リリース後4か月間、これほど深刻な未修正のバグがあった場合、特にユーザーに以前のバージョンにダウングレードするための明確な指示を提供しなかった場合、どのような対応になるのでしょうか。ユーザーは簡単に1.19.3にピン留めできますが、それでは問題は解決しません。レジスターを混乱させた後、レジスターを使用する別のパッケージに移動するだけです。おそらくscipy、おそらくtensorflowです。

mattip 2020年11月03日

回避策の別のアイデア：FPUを使用し、その状態を良好な状態に保つ他の関数がucrtにあるかどうかを確認します。ある場合は、fmodの後にこれを呼び出すことができます。これは、特別なファイルやビルドプロセスを必要としないため、 @ mattipが優れています。

bashtage 2020年11月03日

この問題を回避するためにこれ以上の努力を払うべきではないと思います。問題を軽減するために私たちが行う追加の作業は、貴重な開発者の時間を費やし、これを修正するためのマイクロソフトへのプレッシャーを軽減します。また、前述のように、 fmodを呼び出したり、レジスタを使用したりする他のプロジェクトのコードは、NumPyに接続せずにこの問題にぶつかる可能性があります。

mattip 2020年11月03日

この問題を回避するためにこれ以上の努力を払うべきではないと思います。問題を軽減するために私たちが行う追加の作業は、貴重な開発者の時間を費やし、これを修正するためのマイクロソフトへのプレッシャーを軽減します。また、前述のように、 fmodを呼び出したり、レジスタを使用したりする他のプロジェクトのコードは、NumPyに接続せずにこの問題にぶつかる可能性があります。

エラーメッセージへの反応を見て、それは明らかにあまり役に立ちません。たとえば、最新のNumPy機能を使用したいWindowsユーザーは、ピップホイールではなくMKLに付属のディストリビューションを使用することをお勧めします。このスレッドへのリンクも含める必要があります。

これは明らかにMSの修正責任ですが、ユーザーが他人の過失を指摘するのに苦痛を与えることは、プロジェクトが善意を維持するための良い方法となることはめったにありません。

bashtage 2020年11月03日

@bashtage痛みを引き起こすことについてあなたが何を意味するのかよく

charris 2020年11月03日

痛みを引き起こすことについてあなたが何を意味するのかよくわかりません。

NumPyのインポートは見事に失敗し、回避策は提供されていません。既知の回避策のリストが明確に表示されていると、ほとんどのユーザーにとって最も役立ちます。

（a）これを回避するが線形代数コードであるcondaやEnthought DeploymentManagerなどのMKLベースのディストリビューションを使用する
（b）バグから保護されているバージョンのOpenBLASに同梱されているNumPy1.19.3に戻します。このオプションは、コンテナーで実行しているユーザーには適さない場合があります。
（c）ソースからビルドします。このオプションはパフォーマンスの低いBLASになりますが、サードパーティの配布が許可されておらず、コンテナが使用されているか、NumPyの最近の機能またはバグ修正が必要な環境に適している場合があります。

fmodのバグに注意を喚起するのは間違いではないと思いますが、そうすると、ユーザーを待っている解決策があるかのように、ユーザーをそのフォーラムに送ります。

リンクを削除して、代わりにユーザーをここに配置することもできますが、2004年に実行した場合、結果は信頼できないことをユーザーに警告する必要があります。計算結果を信頼できない場合は、そのプラットフォームでの計算を避ける必要があります。

これはオプションではありません。ユーザーは、NumPy + OpenBLAS（例：0.3.12）を回避するだけで済みます。 NumPy + Windows（2004 / 20H2（現在2つのリリースバージョンが影響を受けています））を回避する必要はありません。

bashtage 2020年11月03日

👍2

MKLベースの配布

MKLに関する問題の報告もありました。

NumPy1.19.3に戻す

しかし、それはfmodの使用に起因する他の潜在的な問題を修正しません。問題は、結果が正しいことを確認する方法がないことです。

人々は2004年にPythonを使うべきではありません、多分代わりにWSLを使うでしょうか？可能であれば、Windowsホイールに古いucrtを含めても問題ありませんが、他のプロジェクトについてはどうでしょうか。以前のWindowsバージョンに戻る簡単な方法はありますか？

charris 2020年11月03日

MKLに関する問題の報告もありました。

NumPyには、MKLで失敗するテストはありません。障害が報告されていない場合、問題があると推測するのは難しいようです。 fmodのバグは、MKLのBLASには現れません（おそらくFPUを使用していないためです）。

しかし、それはfmodの使用に起因する他の潜在的な問題を修正しません。問題は、結果が正しいことを確認する方法がないことです。

いいえ。ただし、Windowsのセキュリティ問題やその他の多くのバグも修正されません。ここでの問題は非常に特殊です。

fmodは、正しい結果が生成されるという点で問題ありません。
システムコンパイラはx87コードを生成しないため、この問題が発生するには、アセンブラでコードを記述する必要があります。

これらの2つは、ほとんどすべてのコードで問題を解決するのが非常に難しいことを私に示唆しています。 OpenBLAS、手書きカーネルを含むFFTライブラリ、またはMKLなどの最高パフォーマンスのコードのみが＃2をトリガーする可能性があります。

また、OpenBLAS 0.3.12が期待どおりに機能した場合、NumPyがリリースされ、この問題がユーザーに提起されることはなかったため、修正をリリースすることは合理的だと思います。

人々は2004年にPythonを使うべきではありません、多分代わりにWSLを使うでしょうか？可能であれば、Windowsホイールに古いucrtを含めても問題ありませんが、他のプロジェクトについてはどうでしょうか。以前のWindowsバージョンに戻る簡単な方法はありますか？

多くのユーザーにとって、これは実際には多くのユーザーにとってオプションではないと思います。エンタープライズデスクトップの企業ユーザー、初心者の学生（condaを使用する必要があります）、またはダウングレードできない2004または20H2のラップトップを購入した人。

bashtage 2020年11月03日

Condas numpyがMLKに対してリンクされているだけでなく、古いバージョン（10.0.17134.12）のように見える独自のバージョンのucrtbase.dllもすでに出荷されていることに注意してください。

jenshnielsen 2020年11月03日

👍1

ここで@bashtageに大体同意します。インポートが失敗し、それを修正するための合理的な推奨事項がない場合、ユーザーにとっては少し敵対的です（主な欠点はマイクロソフトにありますが）。

@jenshnielsen ：

conda-forgeによってパッケージ化されたビルドでは、blas / lapack実装を（openblas / mkl / blis / netlibから）切り替えることができます。MKLである必要はありません。

h-vetinari 2020年11月03日

👍1

人々は2004年にPythonを使うべきではありません、多分代わりにWSLを使うでしょうか？

これは、ほとんどのユーザーにとってデフォルトの操作モードではありません。

可能であれば、Windowsホイールに古いucrtを含めても問題ありませんが、他のプロジェクトについてはどうでしょうか。

他のプロジェクトは私たちの責任ではありません。

以前のWindowsバージョンに戻る簡単な方法はありますか？

新規インストールまたはディスクスペースのクリーンアップを行った場合、それを行うことはほとんど不可能になります。

ここで@bashtageに大体同意します。インポートが失敗し、それを修正するための合理的な推奨事項がない場合、ユーザーにとっては少し敵対的です（主な欠点はマイクロソフトにありますが）。

同意する。これを修正しないと、多くのユーザーを失う可能性があります。

hameerabbasi 2020年11月03日

可能であれば、Windowsホイールに古いucrtを含めても問題ありませんが、他のプロジェクトについてはどうでしょうか。

@charris 、これはWindows 10では役に立ちません。pythonまたはnumpyと一緒に別のucrtを展開すると、Windows 10に読み込まれることはありません。これは古いバージョンのWindows（Windows 7、8、8.1）にのみ適用されます。

carlkl 2020年11月03日

@carlkl
condaパッケージのpythonは、実際にはDLL検索パスの解決に介入します（これは、変更されていないため、おそらくWindows 10では機能しないと言う理由です）。これは、condaがucrtbase.dll提供する理由でもあるAFAICTです。 @jenshnielsenが書いているように、 ucrtbase.dll 。

h-vetinari 2020年11月03日

@ h-vetinari、ユニバーサルCRT展開は明確に述べています：

_ローカル展開には、次の2つの制限に注意する必要があります。
Windows 10では、アプリケーションにユニバーサルCRTのアプリケーションローカルコピーが含まれている場合でも、システムディレクトリのユニバーサルCRTが常に使用されます。ユニバーサルCRTはWindows10のコアオペレーティングシステムコンポーネントであるため、ローカルコピーが新しい場合でも同様です。

ところで：私はそれを自分でテストしました。 Windows10で展開された利用可能なUCRT以外の別のUCRTをロードする方法はありません。

carlkl 2020年11月03日

また、修正をリリースすることは合理的だと思います

これは、PR gh-17547を追加することを意味すると思いますか？

mattip 2020年11月03日

@carlklのポイントの証明：

bashtage 2020年11月03日

MS自体によって引き起こされるこのバグは、 Heisenbugと呼ばれる必要があります。原因を特定するのはコストがかかり、困難でした。Windows2004UCRT fmodは、特定の状況下でFPUレジスタを失敗した状態のままにします。これにより、後でFPUを再度使用するときに、数値計算エラーが発生する可能性があります。厳密にテストしない限り、計算エラーは通常、ユーザーコードに表示されません。これは、重大な数値エラーが長期間検出されないままであることを意味する場合があります。それはほとんど悪化することはありません。

carlkl 2020年11月03日

👍2

これは、PR gh-17547を追加することを意味すると思いますか？

すみません、間違ったことを書きました。

私が提案している唯一の変更は、NumPyがインポート時に発生した例外でより多くの情報を提供することです。これは、ユーザーがWindows 2004 / H2で、仕事/学校/趣味を続けることができる環境を取得する方法を示唆しています。

WSL
conda / enthought
1.19.3
ソースからビルド

[この順序は、ソリューションの品質に関する私の好みです]

この問題、またはより深い説明を提供する少しクリーンな問題にリンクすることも理にかなっていると思います。この2番目のリンクは、githubの問題ではなく、ドキュメント内のいくつかのリリースノートへのリンクである可能性もあります。

bashtage 2020年11月03日

conda-forgeによってパッケージ化されたビルドでは、blas / lapack実装を（openblas / mkl / blis / netlibから）切り替えることができます。MKLである必要はありません。

@ h-vetinari conda-forge + OpenBLASビルドは2004 / H2でテストに合格しますか？

OpenBlas 0.3.12をチェックして、コーダフォージで出荷しました。それでは、これはコンテナをクラッシュさせますか？

bashtage 2020年11月03日

OpenBLAS-0.3.12のEMMS命令でFPU状態を修復する方法を使用すると、もちろんnumpyテストとscipyテストをクリーンにするのに役立ちますが、 fmod(0,x)を呼び出すと述べたように後で（OpenBLASとは異なるパッケージで）呼び出されるCPythonとFPUの命令も発生する可能性があります。この場合、問題は他の場所にのみ移されます。

最善の策は、MSにバグのある動作にパッチを適用させることです。多分スティーブダワーは助けることができますか？

これは、アグナー・フォグやブルース・ドーソンにとっても興味深い話かもしれません。つまり、彼のブログでこの関連記事を参照してください。
古いものはすべて再び新しくなり、コンパイラのバグ

carlkl 2020年11月03日

👍1

おそらくOpenBlas0.3.12のバグです。 PrivateBytes列に注意してください。

私は24個の論理CPUを持っているので、これはおそらくデフォルトで24個のBLASスレッドになります。

これは、conda-forgeのNumPy1.19.2を搭載したOpenBLAS0.3.12です。

$env:OPENBLAS_NUM_THREADS=1を設定すると、劇的な削減になります

そして$env:OPENBLAS_NUM_THREADS=4スレッドで：

bashtage 2020年11月03日

@bashtage ：OpenBLAS xianyi / OpenBLAS＃2970でOpenBLAS 0.3.12について引き続き説明できますか？

mattip 2020年11月03日

@mattip conda + OpenBLASが信頼できる代替手段であるかどうかを判断しようとしていました。これらの結果を見て、1.19.3が解決するものは何も解決しないと思います。

bashtage 2020年11月03日

@bashtage ： @carlklのポイントの証明：

condaパッケージのPythonはWindowsの標準DLL解決を積極的に回避しているため、Windowsツールがどれだけの証拠になるかはわかりません。たとえば、 C:\Windows\System32古いlibcrypto.dllでこの問題が発生しました。たとえば、 //github.com/conda-forge/staged-recipes/pull/11452を参照してcryptographyテストスイートでのテストの失敗によってのみ検出され、 CONDA_DLL_SEARCH_MODIFICATION_ENABLE使用して、condaが提供するopensslの使用を強制することができました。

@bashtage ：@ h-vetinari conda-forge + OpenBLASビルドは2004 / H2でテストに合格しますか？

パッケージをビルドしているCIは、おそらくそのような現在のバージョンではなく、自分でビルドするのに少し時間がかかりました。私は現在2004年のマシンで実行していますが、これは-非常にポジティブな-結果**です。

= 10487 passed, 492 skipped, 19 xfailed, 1 xpassed, 227 warnings in 529.08s (0:08:49) =

@bashtage ：

conda-forgeには、固定のopenblasバージョンは付属していません。blasバージョンは「ホットスワップ」（たとえば、openblas、mkl、blis間）することもできるため、バージョンは大したものではありません。ただし、通常は最新のパッケージバージョンを使用します。クラッシュがコンテナ内で再現されるかどうかを確認できません。

@bashtage :: @ mattip私はconda + OpenBLASが信頼できる代替手段であるかどうかを判断しようとしていました。これらの結果を見て、1.19.3が解決するものは何も解決しないと思います。

xianyi / OpenBLAS＃2970でさらに説明されているように、メモリの増加はopenblas0.3.12の変更によるものでした。これまでのところ、conda-forgeは私にとって信頼できる代替手段のようです。少なくとも、エラーの影響を直接受けることはありません。

** https://github.com/conda-forge/numpy-feedstockの現在のマスターを使用しました。これはまだ1.19.2であり、openblas0.3.12と組み合わせています。興味があれば、 https：//github.com/conda-forge/numpy-feedstock/pull/210 + openblas0.3.12を試すこともでき

h-vetinari 2020年11月04日

幸いなことに、MSはVSフォーラムに戻り、2021年1月末までに修正が行われる可能性があることを示唆しました。この更新を考えると、唯一の問題は、エラーメッセージの更新に価値があるかどうかだと思います。バグのある機能が検出されました。

condaパッケージのPythonはWindowsの標準DLL解決を積極的に回避しているため、Windowsツールがどれだけの証拠になるかはわかりません。たとえば、 C:\Windows\System32古いlibcrypto.dllでこの問題が発生しました。たとえば、 conda-forge / staged-recipes＃11452を参照してください。簡単に言うと、古いシステムライブラリは、 cryptographyテストスイートでのテストの失敗によってのみ検出され、 CONDA_DLL_SEARCH_MODIFICATION_ENABLE使用して、condaが提供するopensslの使用を強制することができました。

conda create -n cf -c conda-forge python numpy pytest hypothesis blas=*=openblas openblas=0.3.9 -y
conda activate cf
python -c "import numpy as np;np.test('full')"

出力

C:\Anaconda\envs\cf\lib\site-packages\numpy\linalg\linalg.py:94: LinAlgError
---------------------------------------------------------------------- Captured stdout call ----------------------------------------------------------------------
 ** On entry to DGEBAL parameter number  3 had an illegal value
 ** On entry to DGEHRD parameter number  2 had an illegal value
 ** On entry to DORGHR DORGQR parameter number  2 had an illegal value
 ** On entry to DHSEQR parameter number  4 had an illegal value

これは、古いOpenBLASを使用すると、現在のucrtDLLのバグのある関数が使用されていることを示しています。

condaforgeのopenblas = 0.3.12のみがテストに合格しますが、これはNumPy1.19.3で出荷されたものと同じです。

bashtage 2020年11月04日

👍2

武装解除されたOpenBLAS-0.3.12でコンパイルされた新しいnumpyリリースに反対するものは何ですか？ numpyに使用されるOpenBLASのコンパイル時のバッファサイズが減少し、スレッド数が減少する可能性があります。これにより、OpenBLASのメモリ消費量が削減され、Dockerテストケースだけでなく、設備の整っていないユーザーにも役立つはずです。
窓ボックス。

carlkl 2020年11月06日

これは、Python内部のhttps://tinyurl.com/y3dm3h86バグレポートからのものです。まず、今のところWindowsで動作するバージョン（1.19.3）を提供していただきありがとうございます。

Linuxでは1.19.3が機能せず、Windowsでは1.19.4が機能しないことを理解しています（バグはありますが）。

Windows用のpypi1.19.3、および他のすべてのプラットフォーム用の1.19.4で最新バージョンを作成することは可能でしょうか？つまり、 https：//files.pythonhosted.org/packages/33/26/c448c5203823d744b7e71b81c2b6dcbcd4bff972897ce989b437ee836b2b/numpy-1.19.4-cp36-cp36m-win_amd64.whl （および対応する3.7 / 3.8 / 3.9 amd）を削除するだけです

luciansmith 2020年11月14日

👀1

@luciansmithソースが1.19.4で利用可能である限り、追加のフラグが渡されない限り、pipはこのバージョンを使用しようとします。ほとんどのユーザーは、問題を知っている場合にのみ追加のフラグを渡すと思いますが、1.19.3を固定するだけで済みます。

LinuxではOpenBLAS0.3.9を使用し、Windowsでは0.3.12を使用する1.19.5を使用することをお勧めしますが、これが可能かどうかはわかりません。

bashtage 2020年11月14日

👀1 👍1

Numpy: Windows 10を2004に更新した後、polyfitおよびeig回帰テストが失敗する

最も参考になるコメント

全てのコメント171件

関連する問題