Numpy: Uji regresi polyfit dan eig gagal setelah pembaruan Windows 10 ke 2004

Sunting: Anda jelas menggunakan pip. Saya juga memiliki hasil yang aneh pada Windows AMD64 di masa lalu dengan perpustakaan aljabar linier dan dekomposisi nilai eigen (dalam konteks menjalankan tes untuk statsmodels).

Jika Anda punya waktu, coba gunakan Python 32 bit dan pip dan lihat apakah Anda mendapatkan masalah yang sama? Saya tidak dapat melihatnya di jendela 32-bit tetapi dapat diulang di jendela 64-bit.

Jika saya menggunakan conda, yang mengirimkan MKL, saya tidak mengalami error.

Sunting: Saya juga melihatnya saat menggunakan NumPy 1.18.5 pada Windows AMD64.

tes gagal setelah pembaruan Windows 10 terbaru

Apakah tes gagal sebelum pembaruan?

Tidak @charris , sebelum update test suite berlalu begitu saja.

@speixoto Tahukah Anda pembaruan mana yang secara khusus? Saya tertarik untuk melihat apakah ini menyelesaikan masalah saya dengan roda yang dipasang dengan pip.

Pembaruan 1809 (10.0.17763) tidak menyebabkan tes yang gagal @bashtage

1909 juga tidak menyebabkan apa-apa. Ini baru mulai terjadi pada tahun 2004.

Saya tidak 100% yakin ini tahun 2004 atau setelahnya. Saya pikir 2004 berhasil.

FWIW Saya tidak dapat mereproduksi kerusakan ini pada CI (Azure atau appveyor) tetapi saya melakukannya secara lokal pada 2 mesin yang merupakan AMD64 dan diperbarui pada tahun 2004.

Sudahkah salah satu dari Anda mencoba untuk melihat apakah Anda mendapatkannya pada Python 32-bit?

Tampaknya ada sejumlah masalah yang dilaporkan terhadap pemutakhiran 2004. Mungkin ini harus dilaporkan juga?

Saya baru saja menjalankan yang berikut ini pada penginstalan baru tahun 1909 dan 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

Pada 1909 tidak ada kegagalan. Pada tahun 2004, 30 kegagalan semua terkait dengan fungsi aljabar linier.

Ketika saya menjalankan tes pada tahun 2004 di debugger, saya perhatikan bahwa panggilan pertama ke suatu fungsi sering kali memberikan hasil yang salah, tetapi memanggil lagi menghasilkan hasil yang benar (yang tetap benar jika dipanggil berulang kali). Tidak yakin apakah ini informasi yang berguna untuk menebak penyebabnya.

Apakah versi NumPy sebelumnya juga mengalami masalah? Saya berasumsi Anda menjalankan 1.19.0.

Menggunakan pip + 1.18.4, dan scipy 1.4.1, saya mendapatkan serangkaian kesalahan yang sama.

Ini sangat umum:

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

Ketika saya menjalankan menggunakan 1.18.5 + MKL saya tidak mendapatkan error. Sulit untuk mengatakan apakah ini kemungkinan bug OpenBLAS atau bug Windows. Mungkin yang terakhir, tetapi akan sangat sulit untuk dijangkau dan mendiagnosis berada di luar kemampuan saya untuk debugging tingkat rendah.

Pada mesin fisik yang sama, ketika saya menjalankan Ubuntu menggunakan paket pip, saya tidak melihat kesalahan apa pun.

Ini adalah perilaku yang paling aneh. Gagal pada panggilan pertama, bekerja pada panggilan kedua dan berikutnya. Satu lagi perilaku yang sulit dipahami adalah jika saya menjalankan pengujian yang gagal secara terpisah daripada saya tidak melihat kesalahannya.

Satu pembaruan terakhir: jika saya menguji menggunakan build sumber NumPy tanpa BLAS yang dioptimalkan, saya masih melihat kesalahan meskipun itu bukan set yang identik.

Mungkin layak untuk melakukan ping ke OpenBLAS devs. Apakah itu terjadi dengan float32 sesering float64?

Ketika saya menjalankan tes penuh NumPy 1.19.0, python -c "import numpy;numpy.test('full')" Saya melihat kesalahan yang sama seperti di atas:

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

Saya pikir jika Anda hanya menjalankan tes secara eksklusif itu harus lulus jika saya ingat dengan benar dari ping hal-hal di sekitar sehingga itu berarti perilaku yang lebih aneh.

Saya telah mengajukan ke Microsoft satu-satunya cara yang saya tahu caranya:

https://aka.ms/AA8xe7q

Posting jika orang lain menemukan ini melalui pencarian:

Pengguna Windows harus menggunakan Conda / MKL jika pada tahun 2004 hingga masalah ini teratasi

Berikut adalah contoh reproduksi kecil:

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)

Menghasilkan

 ** 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

Apakah LAPACK dihitung dari 0 atau 1? Semua nilai ilegal tampaknya adalah bilangan bulat:
DGEBAL
DGEHRD
DORGHR
DHSEQR

Ini terlihat lebih seperti masalah OpenBlas (atau sesuatu antara 2004 dan OpenBLAS). Ini ringkasan saya:

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

• Tidak ada BLAS yang dioptimalkan: Lulus penuh
• OpenBLAS: Gagal penuh
• MKL: Lulus penuh

statsmodels menguji pytest statsmodels

• Pip NumPy dan SciPy: Gagal terkait dengan kode terkait SVD dan QR
• MKL NumPy dan SciPy: Lulus
• Tidak ada BLAS yang dioptimalkan: Gagal , tetapi lebih sedikit yang melibatkan rutinitas scipy.linalg , yang menggunakan OpenBLAS.
• Tidak ada BLAS yang dioptimalkan, tidak ada linalg SciPY: Lulus

Alangkah baiknya mempelajari apa yang berubah pada tahun 2004. Mungkin kita memerlukan flag yang berbeda saat mengkompilasi / menghubungkan perpustakaan?

_Jika_ ini adalah bug OpenBLAS, kemungkinan besar mereka tidak akan melihatnya karena tidak ada CI berbasis Windows yang menggunakan build 19041 (alias Windows 10 2004) atau yang lebih baru.

Hanya untuk memperjelas, apakah benar tidak ada laporan ini yang melibatkan WSL?

Tidak. Semua dengan python.exe atau python.org disediakan python.exe

Apakah pengujian gagal jika variabel lingkungan OPENBLAS_CORETYPE=Haswell atau OPENBLAS_CORETYPE=NEHALEM disetel secara jelas?

Saya mencoba Atom, SandyBridge, Haswell, Prescott dan Nehalem, semuanya dengan hasil yang sama.

Hal yang paling aneh adalah jika Anda lari

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)

panggilan kedua (dan selanjutnya) ke eig berhasil.

SciPy memiliki kesalahan serupa di

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) 

yang menimbulkan

 ** 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)

Catatan terakhir, mengubah menjadi np.complex128 juga akan meningkat, sementara mengonversi menjadi np.float32 atau np.complex64 keduanya bekerja tanpa masalah.

Bagian kode Python dikompilasi dengan bilangan bulat panjang tetapi OpenBLAS dibangun tanpa INTERFACE64 = 1 di bagian fortran (LAPACK)?
(Ini masih tidak akan menjelaskan mengapa panggilan pertama gagal tetapi sukses berikutnya, atau mengapa itu bekerja sebelum pembaruan 19041)

Pengguna Windows 10 dapat meningkatkan masalah ini di Hub Umpan Balik Microsoft.

https://aka.ms/AA8xe7q

Atas permintaan @bashtage , saya telah menggali kode sedikit, dan dugaan saya adalah bahwa beberapa aspek status floating point sekarang berbeda saat masuk. Itu tampaknya dikonfirmasi oleh ini:

mengonversi ke np.complex128 juga memunculkan, sementara mengonversi ke np.float32 atau np.complex64 keduanya bekerja tanpa masalah.

Pesan peringatan pertama (yang sepertinya tidak muncul saat berhasil) "Saat masuk ke parameter DGEBAL nomor 3 memiliki nilai ilegal" disebabkan oleh kondisi ini https://github.com/xianyi/OpenBLAS/blob/ce3651516f12079f3ca2418aa85b9ad571c3a391/lapack -netlib / SRC / dgebal.f # L336 yang dapat disebabkan oleh sejumlah kalkulasi sebelumnya yang masuk ke NaN.

Bermain-main dengan langkah-langkah repro, saya menemukan bahwa melakukan mod sebagai float32 "memperbaikinya":

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)

Jadi tebakan saya adalah ada sesuatu di jalur kode itu yang mengatur ulang status dengan benar, meskipun saya tidak yakin apa itu. Mudah-mudahan seseorang yang lebih akrab dengan bagian dalam numpy mungkin tahu di mana hal itu bisa terjadi.

Jenis mengingatkan saya pada bug lama yang kami lihat dengan mingw di Windows, di mana konfigurasi register floating point tidak diwarisi oleh utas pekerja, yang menyebabkan denormals tidak menjadi nol dan terkadang mengacaukan perhitungan selanjutnya.
Tidak yakin apakah ini relevan dengan Windows saat ini pada perangkat keras saat ini, tetapi mungkin menarik untuk mengetahui apakah file
Build OpenBLAS diselesaikan dengan CONSISTENT_FPCSR = 1 (atau jika menambahkan opsi build itu membantu).

@ Mattip Apakah Anda tahu jika CONSISTENT_FPCSR = 1 dalam build OpenBLAS?

Sepertinya begitu, sayangnya:

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

Yah, setidaknya ini sudah keluar dari jalan. koneksi tampaknya cukup jauh.

Hai! Saya telah mengalami masalah serupa untuk beberapa waktu sekarang dan semua pengujian saya menunjukkan sesuatu yang mencurigakan antara windows 10 (2004) dan OpenBlas. Saya biasanya menjalankan program saya di 3 PC (2 workstation Windows 10 dan laptop Windows 7 yang lebih lama). Skrip python saya mulai berperilaku buruk dengan kesalahan terkait dengan konvergensi linalg dan svd () sekitar waktu saya mengupgrade 2 workstation saya ke versi 2004 Windows 10. Saya juga mengalami crash saat pertama kali menjalankan skrip, tetapi sebagian besar waktu itu bekerja pada percobaan kedua (menjalankan notebook Jupyter). Rig laptop lama terus menjalankan program yang sama tanpa kesalahan! Saya memiliki miniconda, python 3.6 dan semua paket diinstal menggunakan pip (env persis sama di 3 mesin).
Hari ini saya menghapus instalasi numpy pip default (1.19.0) dan menginstal versi numpy + mkl (numpy-1.19.1 + mkl-cp36-cp36m-win_amd64.whl) dari https://www.lfd.uci.edu/ ~ gohlke / pythonlibs /. Sejauh ini, kesalahan yang terkait dengan konvergensi linalg dan svd () menghilang. Jika saya menemukan sesuatu yang lain, saya akan kembali ke sini dan melaporkannya.

Dário

Aneh bahwa dll OpenBLAS dibuat oleh lib.exe versi VC9? Ini adalah versi yang digunakan dengan Python 2.7. Ini mungkin tidak masalah, tetapi terasa aneh mengingat VC9 tidak digunakan di mana pun.

Langkah selanjutnya bagi seseorang (mungkin saya) adalah membuat master NumPy dengan OpenBLAS utas tunggal ( USE_THREAD=0 ) untuk melihat apakah ini memperbaiki masalah.

Saya telah mencoba beberapa eksperimen tetapi tidak berhasil:

• Nonaktifkan utas USE_THREADS=0
• ILP64 INTERFACE64=1 <- Segfault dalam pengujian NumPy dengan pelanggaran akses

Bisakah Anda menjalankan testsuite LAPACK dengan pengaturan Win10 itu? Saya baru-baru ini memperbaiki build cmake untuk memproduksinya, mungkin itu memberikan beberapa petunjuk tanpa melibatkan numpy.

                        -->   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%)

Meskipun saya melihat banyak garis suka

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

jadi saya tidak yakin apakah ini dapat dipercaya.

Sepertinya sebagian besar tes segfault, tapi tes yang bertahan sempurna ... ini sedikit lebih ekstrim dari yang saya harapkan.
(COMPLEX dan COMPLEX16 agak menuntut dalam hal ukuran tumpukan, jadi kegagalan lebih mungkin terjadi dengan pengaturan OS default, tetapi REAL dan DOUBLE biasanya akan menampilkan sekitar 1200000 pengujian yang dijalankan. Ini membuat saya bertanya-tanya apakah MS mengubah sesuatu dengan tumpukan default batas atau tata letak)

Beberapa latar belakang. Semuanya sedang dibangun dengan gcc.exe / gfortran.exe. Ini digunakan untuk menghasilkan file .a, yang kemudian dikemas menjadi DLL. Secara khusus:

$ 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)

Saya benar-benar berpikir masalahnya ada di handoff antara NumPy dan OpenBLAS. Saya tidak bisa membayangkan bagaimana lagi perilaku ini dapat terjadi ketika panggilan pertama adalah kesalahan, tetapi panggilan kedua dan berikutnya semuanya baik-baik saja. Bagaimana mengatasinya (atau TBH bahkan secara akurat mendiagnosis masalah yang dalam) ...?

Hapus platform MS dan hidup bahagia selamanya? Jika gagal tes lapack masalah handoff terletak antara Fortran (= LAPACK bagian dari OpenBLAS) dan C, atau Fortran dan "apa pun".

Saya akan penasaran apakah mungkin untuk membangun Numpy dengan OpenBLAS menggunakan icc
dan ifort jadi lihat apakah masalah terus berlanjut. Itu pertanyaan besar.

Pada Rabu, 12 Agustus 2020, 19:04 Martin Kroeker [email protected] menulis:

Hapus platform MS dan hidup bahagia selamanya? Jika gagal,
tes lapack masalah handoff terletak di antara Fortran (= LAPACK bagian dari
OpenBLAS) dan C, atau Fortran dan "apa pun".

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/numpy/numpy/issues/16744#issuecomment-673026759 , atau
berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ABKTSRLSHZ2XWF4OE7J3QO3SALKSJANCNFSM4OP5IXNQ
.

Mungkin akan cukup untuk hanya membangun OpenBLAS dengan kompiler Intel (meskipun tampaknya cukup bermasalah setidaknya dengan VS dari apa yang muncul baru-baru ini, dan saya tidak memiliki lisensi yang valid untuk ifc / ifort saat ini.

Kemungkinan masalah terkait:

https://developercommunity.visualstudio.com/content/problem/1095521/link-error-in-in-rust-test-binary.html

Pengguna Windows harus menggunakan Conda / MKL jika pada tahun 2004 hingga masalah ini teratasi

@bashtage Terima kasih atas saran Anda.
Dalam kasus saya, saya mendapat beberapa kesalahan ketika saya menggunakan sqlite menggunakan oleh pandasql setelah menerapkan versi Conda numpy.

tetapi saya tidak mendapat masalah saat menggunakan versi numpy + mkl ini .

@bashtage tampaknya ada

FYI: masalah SciPy terkait: https://github.com/scipy/scipy/issues/12747

Ada laporan bahwa Windows build 17763.1397 (Aug 11) memperbaiki masalah, lihat # 17082.

Ada laporan bahwa Windows build 17763.1397 (Aug 11) memperbaiki masalah, lihat # 17082.

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

Build 17763.1397 hanya untuk Windows 10, versi 1809 (Berlaku untuk: Windows 10, versi 1809, semua edisiWindows Server versi 1809Windows Server 2019, semua edisi).
Tidak ada masalah dalam hal ini untuk windows 10, versi 1809.

Ini baru-baru ini memperbarui versi windows 10, versi 2004.
https://support.microsoft.com/en-us/help/4566782
11 Agustus 2020 — KB4566782 (OS Build 19041.450).

Saya masih memiliki masalah yang sama di Windows 10, Versi 2004

Kegagalan yang sama pada 19042.487 (ini adalah cabang 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)

Saya dapat mereproduksi kegagalan (parsial) dalam tes lapack OpenBLAS - hanya memengaruhi tes EIG (nilai eigen), yang diketahui memiliki beberapa persyaratan ukuran tumpukan yang sangat tinggi. Di sana SIGSEGV terjadi di __chkstk_ms_ yang dimasukkan bahkan sebelum main (). Menggandakan nilai default "stack reserved size" dan "stack commit size" dari masing-masing yang dapat dieksekusi dengan utilitas peflags (mis. peflags -x4194304 -X4194304 EIG/xeigtsts.exe ) membuat program bekerja secara normal, menunjukkan bahwa interaksi C / Fortran dan argumen yang lewat seperti itu tidak bermasalah. Saya belum mencoba menerapkan ini ke kasus numpy (bahkan tidak yakin pengaturan peflag siapa yang harus menyesuaikan di sana - python.exe?) Tetapi OpenBLAS sendiri tampaknya berfungsi normal ketika dibangun dengan versi msys2 mingw64 dari gcc 9.1.0 pada 19041.450 aka 2004

@ martin-frbg Sepertinya kemajuan.

Pergi ke lubang kelinci mencoba menginstal semua dependensi untuk membangun numpy pada Windows / MSYS2 sehingga tidak ada kemajuan lebih lanjut.

@ martin-frbg, paket numpy berbasis Msys2 dapat diinstal dengan pacman. Skrip dan patch build Msys2 tersedia di sini: https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-python-numpy dan https://github.com/msys2/MINGW-packages/tree / master / mingw-w64-openblas.

Dalam pertemuan triase terbaru, hal ini muncul sebagai prioritas yang relatif tinggi, dan @hameerabbasi dan saya bersedia membantu. Apa yang bisa kita lakukan?

@bashtage dapatkah Anda mencoba membuat tumpukan lebih besar dengan editbin /STACK:3145728 python.exe

Adakah cara agar kami dapat mencoba membangun NumPy dengan rilis pustaka OpenBLAS daripada yang kami buat? Mungkin bangunan kami sedikit meleset.

Mungkin akan dimungkinkan untuk mengganti libopenblas.dll dalam build Anda dengan yang dibuat dari cabang develop atau rilis yang lebih lama seperti 0.3.8 atau 0.3.9 untuk melihat apakah itu berpengaruh? (Bukannya saya memiliki komitmen khusus dalam pikiran saya sekarang yang mungkin ada hubungannya dengan ini). Sayangnya saya masih mengalami kesalahan penginstalan bahkan dengan paket msys2, saat ini tidak dapat menjalankan tes karena self.ld_version tidak mengembalikan apa-apa dalam pemeriksaan versi.

Terima kasih. Saya mencoba memperbarui windows saya untuk membangun 2004, mari kita lihat apakah saya selesai sebelum akhir pekan

Selain itu, "contoh reproduksi kecil" bashtage dari https://github.com/numpy/numpy/issues/16744#issuecomment -655430682 tidak memunculkan kesalahan apa pun dalam penyiapan msys2 saya. (Sejauh yang saya tahu, libopenblas mereka di mingw64 / usr / lib adalah 0.3.10 utas tunggal yang dibuat untuk Haswell)

@ martin-frbg Apakah mungkin untuk membangun OpenBLAS menggunakan MSVC?

MSVC biasa? Dapat dilakukan tetapi memberikan pustaka yang tidak dioptimalkan dengan baik karena MSVC tidak mendukung kernel perakitan - praktis sama seperti jika Anda membuat OpenBLAS untuk TARGET = GENERIC.

Juga, "contoh kecil mereproduksi" bashtage dari

Saya cukup yakin itu ada hubungannya dengan antarmuka antara NumPy dan OpenBLAS. Build 32-bit dari NumPy juga tidak mengalami masalah ini. Ide dari orang-orang Microsoft yang saya ajak bicara bahwa ini kemungkinan adalah masalah sinkronisasi utas yang tampaknya paling masuk akal. Ini bisa menjelaskan bagaimana nilai yang salah muncul di panggilan pertama dan kemudian memperbaikinya di panggilan berikutnya.

Pergi ke lubang kelinci mencoba menginstal semua dependensi untuk membangun numpy pada Windows / MSYS2 sehingga tidak ada kemajuan lebih lanjut.

Ini menyakitkan. Saya telah melakukannya tetapi mengotomatiskannya untuk mencoba beberapa eksperimen membutuhkan waktu lama. Ini pada dasarnya membutuhkan penyalinan langkah-langkah dari https://github.com/MacPython/openblas-libs untuk mendapatkan file .a, dan kemudian menyalin langkah-langkah dari https://github.com/numpy/numpy/blob/master/ azure-steps-windows.yml untuk membangun NumPy. Ini sangat sulit karena beberapa bagian menginginkan MSYS2 standar dan yang lainnya perlu dihapus, jadi Anda akhirnya menginstal dan menghapus sebagian besar gcc setiap kali Anda ingin melakukan percobaan.

Cara termudah untuk mendapatkan DLL build adalah dengan membuka akun appveyor, lalu mengkloning https://github.com/MacPython/openblas-libs. Di akhir pembuatan, ada artefak yang dapat Anda temukan dari situs web untuk diunduh yang memiliki dll (dan file .a). Namun ini lambat, membutuhkan waktu 3 jam untuk membangun ketiga versi tersebut.

Melihat https://github.com/MacPython/openblas-libs , OpenBLAS tampaknya dibangun dengan INTERFACE64=1 . Ini bukan kasus untuk Msys2 membangun OpenBLAS dan numpy.

@carlkl Masalah ini bukan tentang build Msys2 dari NumPy atau OpenBLAS. Ini tentang build Win32 / AMD64 yang menggunakan gfortran yang disediakan Msys2 untuk mengkompilasi sumber fortran, tetapi kemudian membangun Win32 DLL dari pustaka yang dikompilasi menggunakan MS lib.exe.

@bashtage Saya menyebutkan ini, karena telah dilaporkan https://github.com/numpy/numpy/issues/16744#issuecomment -689785607, bahwa segfault tidak dapat direproduksi dalam msys2. Dan saya kira lingkungan msys2 yang disebutkan yang disebutkan berisi paket biner yang disediakan msys2 openblas dan numpy.

Saya tidak tahu, apakah windows 64bit numpy dikompilasi dengan flag yang mirip dengan MSVC atau tidak.

BTW: Saya tidak dapat menemukan bendera -fdefault-integer-8 di gudang scipy.
Saya tidak yakin apakah kode yang dikompilasi dengan -fdefault-integer-8 kompatibel dengan ABI dengan kode yang dikompilasi tanpa flag ini.

Aspek lain muncul di benak saya: mungkin -fdefault-integer-8 harus digabungkan dengan -mcmodel=large .

EDIT: Ingat: Windows64 memiliki model memori LLP64, bukan ILP64.
LLP64 artinya: panjang: 32bit, penunjuk: 64bit

Jadi, bilangan bulat ukuran apa yang digunakan oleh numpy build yang mengalami masalah Win10-2004? Itu lebih cocok untuk apa OpenBLAS dibuat, tetapi IIRC topik ini sudah muncul sebelumnya di utas ini (dan ketidakcocokan mungkin akan menyebabkan kerusakan yang lebih jelas terlepas dari tingkat tambalan Windows)

Setidaknya Openblas dapat dibangun dalam tiga varian dengan https://github.com/MacPython/openblas-libs (lihat appveyor.yml):

• 32 bit
• 64 bit
• 64 bit dengan INTEGER64

tetapi jika tidak tahu apa yang digunakan untuk 64bit yang numpy dibangun di windows.

_dan ketidakcocokan mungkin akan menyebabkan kerusakan yang lebih jelas terlepas dari patchlevel Windows_

-fdefault-integer-8 hanya berlaku untuk bagian fortran Lapack. Itu tidak mengubah model memori yang mendasari (LLP64), jadi saya tidak yakin apakah kita harus mengharapkan masalah di luar bagian Fortran Lapack.

hmm,

https://github.com/numpy/numpy/blob/60a21a35210725520077f13200498e2bf3198029/azure-pipelines.yml mengatakan

- 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_'
semua versi lainnya ( Python36-64bit-full , Python37-64bit-full ) dibuat tanpa NPY_USE_BLAS_ILP64.

Binari Numpy di pypi.org semuanya dibangun dengan openblas integer 32-bit. https://github.com/MacPython/numpy-wheels/blob/v1.19.x/azure/windows.yml

Untuk detail proses build gfortran vs. MSVC, lihat di sini . Microsoft lib.exe tidak terlibat dalam memproduksi DLL openblas, semuanya mingw toolchain. Numpy menggunakan file openblas.a , dan membuat DLL menggunakan gfortran. https://github.com/numpy/numpy/blob/74712a53df240f1661fbced15ae984888fd9afa6/numpy/distutils/fcompiler/gnu.py#L442 Alat MSVC digunakan untuk menghasilkan file .lib dari file .def, dan kode Numpy C yang dikompilasi dengan MSVC ditautkan menggunakan file .lib itu ke DLL yang diproduksi gfortran.

Satu kemungkinan teoritis yang mungkin salah adalah jika ada semacam ketidakcocokan versi mingw antara mingw yang menghasilkan artefak openblas.a statis, dan versi mingw yang digunakan saat numpy dibuat. Namun, tidak yakin apakah ini mungkin bisa menimbulkan masalah.

choco install -y mingw --forcex86 --force --version=5.3.0 digunakan di windows.yml sepertinya sudah ketinggalan zaman. Mengapa tidak menggunakan 7.3.0 atau 8.1.0 ? Saya ingat masalah yang saya alami dengan gcc-5.x dua atau tiga tahun lalu.

choco install -y mingw --forcex86 --force --version = 5.3.0 digunakan di windows.yml tampaknya sudah usang

Itu hanya untuk build windows 32-bit, jadi mungkin tidak terkait dengan masalah ini.

semua versi lainnya ( Python36-64bit-full , Python37-64bit-full ) dibuat tanpa NPY_USE_BLAS_ILP64.

Kesalahan yang sama pada Python 3.6 dan 3.8.

Ada satu ide tersisa (saya menggali dalam kegelapan):

OpenBLAS sekarang dikompilasi dengan -fno-optimize-sibling-calls , lihat https://github.com/xianyi/OpenBLAS/issues/2154 , https://github.com/xianyi/OpenBLAS/pull/2157 dan https: // gcc .gnu.org / bugzilla / show_bug.cgi? id = 90329.
Edit: lihat juga: https://gcc.gnu.org/legacy-ml/fortran/2019-05/msg00181.html

Numpy tidak menerapkan flag ini ke bagian distutil gfortrannya. Saya tahu bahwa numpy dikompilasi dengan MSVC. Oleh karena itu saya akan mengharapkan masalah dengan scipy bukan dengan numpy, jadi ini bisa menjadi perjalanan yang salah lagi.

Binari Numpy di pypi.org semuanya dibangun dengan openblas integer 32-bit. https://github.com/MacPython/numpy-wheels/blob/v1.19.x/azure/windows.yml

Mengapa konfigurasi build yang digunakan dalam pengujian berbeda dari yang digunakan dalam rilis? Ini terdengar seperti sebuah resiko.

Bisakah kita menambahkan artefak ke bangunan Azure? Ini akan membuatnya lebih mudah untuk mendapatkan roda untuk pengujian. Satu-satunya kekhawatiran saya di sini adalah bahwa batas artefak gratis IIRC cukup kecil, 1GB, dan saya tidak tahu apa yang terjadi ketika Anda menekannya (FIFO akan bagus, tetapi mungkin melakukan hal-hal lain termasuk kesalahan).

Mengapa konfigurasi build yang digunakan dalam pengujian berbeda dari yang digunakan dalam rilis?

Kami menguji semua versi python yang didukung di windows tanpa NPY_USE_BLAS_ILP64 , dan menguji python 3.8 dengan NPY_USE_BLAS_ILP64 juga, lihat https://github.com/numpy/numpy/blob/v1.19.2/azure -pipelines.yml # L195. Jadi, build mingguan benar dalam menggunakan openblas integer 32-bit.

Bisakah kita menambahkan artefak ke bangunan Azure?

Mungkin mudah untuk mencobanya dan mencari tahu tentang batasan jika ada kesalahan. Namun roda mingguan dimaksudkan untuk menciptakan ulang pengujian dengan setia. Setiap perbedaan harus diperlakukan sebagai kesalahan dan diperbaiki.

Mungkin mudah untuk mencobanya dan mencari tahu tentang batasan jika ada kesalahan. Namun roda mingguan dimaksudkan untuk menciptakan ulang pengujian dengan setia. Setiap perbedaan harus diperlakukan sebagai kesalahan dan diperbaiki.

Saya berpikir bahwa akan lebih mudah untuk bereksperimen dalam PR ke repo utama dan mengambil artefak untuk diuji pada tahun 2004.

Masuk akal.

Anda dapat mengaktifkan pipeline Azure di repo bashtage / numpy Anda

Sedikit lebih banyak informasi: panggilan pertama yang gagal adalah karena DNRM2 di dalam OpenBLAS mengembalikan NAN. Bagi saya, ini berulang: setiap panggilan ke

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

mencetak ** On entry to DGEBAL parameter number 3 had an illegal value , yang merupakan cara lain untuk mengatakan " DNRM2 dikembalikan NAN". Operasi mod sangat penting, tanpa panggilan ke eig tidak akan mencetak kesalahan ini.

Bagaimana bisa ada interaksi antara mod ufunc dan panggilan ke OpenBLAS?

Operasi mod sangat penting, tanpa panggilan ke eig tidak akan mencetak kesalahan ini.

Apakah membangun larik yang sama persis ini secara manual berulang kali memicu kesalahan?

Kode ini tidak memicu kegagalan:

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

Bisakah mod meninggalkan register dalam keadaan tidak ditentukan? Saya belum memeriksa nrm2.S lagi, tetapi saya pikir kami memiliki beberapa masalah tahun yang lalu dari perakitan XORing register dengan sendirinya untuk menghapusnya, yang akan gagal di NaN.

Bagi mereka yang mengikuti, float64 % akhirnya memanggil npy_divmod untuk setiap nilai.

... yang pada baris pertama memanggil npy_fmod() , yang merupakan fmod () . Berikut beberapa perubahan yang saya coba. "Error" berarti saya mendapatkan pesan "nilai ilegal" dari OpenBLAS saat menjalankan kode yang memanggil a % 17; np.linalg.eig(a)
kode | hasil
--- | ---
mod = npy_fmod@c@(a, b); (kode asli) | Kesalahan
mod = 100; //npy_fmod@c@(a, b); | Tidak ada kesalahan
mod = npy_fmod@c@(a, b); mod = 100.0; | Kesalahan

Jadi sepertinya fmod dari MSVC melakukan sesuatu yang membingungkan OpenBLAS.

Itu menarik, dan aneh.

Dapatkah Anda menggunakan versi fmod yang naif (tidak disediakan platform) untuk melihat apakah itu memperbaikinya?

Atau cukup paksa HAVE_MODF menjadi 0 .

Saya rasa kita tidak memiliki versi fmod yang naif, bukan?

Saya melihat ada makro HAVE_MODF, tetapi ke mana tujuan jalur ini ?

Sepertinya itu jatuh kembali ke versi ganda jika pelampung dan ganda panjang hilang. Versi ganda wajib untuk membangun numpy. Undef mungkin untuk menghindari fungsi sebaris kompilator, ISTR yang merupakan masalah pada windows lama.

Saya ingin "membuktikan" bahwa masalahnya adalah implementasi fmod , yang berasal dari ucrtbase.dll . Jadi saya menulis sedikit solusi yang menggunakan ctypes untuk menarik fungsi keluar dari dll dan menggunakannya secara langsung untuk memanggil fmod . Tes masih gagal. Kemudian saya beralih ke versi yang lebih lama dari ucrtbase.dll (hanya untuk fungsi fmod ). Tes lulus. Saya membuka utas di forum studio visual . Jika ada yang tahu cara yang lebih baik untuk menjangkau microsoft itu akan sangat bagus.

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)
 {

Bagaimana jika Anda menambahkan beberapa kode setelah panggilan fmod, sehingga ST(0) tidak berisi nan? Atau atur ke nan sintetis?
Apakah konvensi panggilan menempatkan beberapa batasan tentang bagaimana register ini seharusnya berperilaku?

Saya ingin "membuktikan" bahwa masalahnya adalah implementasi fmod , yang berasal dari ucrtbase.dll . Jadi saya menulis sedikit solusi yang menggunakan ctypes untuk menarik fungsi keluar dari dll dan menggunakannya secara langsung untuk memanggil fmod . Tes masih gagal. Kemudian saya beralih ke versi yang lebih lama dari ucrtbase.dll (hanya untuk fungsi fmod ). Tes lulus. Saya membuka utas di forum studio visual . Jika ada yang tahu cara yang lebih baik untuk menjangkau microsoft itu akan sangat bagus.

Minimal siapa pun dengan akun biru, yang mungkin banyak orang di sini, dapat memberi suara positif. Saya akan menghubungi beberapa kontak yang saya buat ketika masalah ini awalnya muncul yang bekerja di Azure ML untuk melihat apakah mereka dapat melakukan sesuatu.

Minimal siapa pun dengan akun biru, yang mungkin banyak orang di sini, dapat memberi suara positif.

Terima kasih atas tipnya, suara positif!

Saya rasa kita tidak memiliki versi fmod yang naif, bukan?

Tidak. Ini adalah fungsi rumit yang dibutuhkan oleh spesifikasi IEEE-754 untuk memiliki perilaku tertentu. Ini juga sangat lambat, yang mungkin terkait dengan spesifikasi.

Kerja keras fmod dilakukan oleh instruksi fprem x87, bahkan dalam varian VS2019 - lihat inti @mattip (baris terakhir) https://gist.github.com/mattip / d9e1f3f88ce77b9fde6a285d585c738e. ( fprem1 adalah remainder varian btw.)

Perhatian harus diberikan saat digunakan bersama dengan register MMX atau SSE - seperti yang dijelaskan di sini: https://stackoverflow.com/questions/48332763/where-does-the-xmm-instruction-divsd-store-the-remainder.

Ada beberapa implementasi alternatif yang tersedia seperti yang dijelaskan di https://github.com/xianyi/OpenBLAS/issues/2709#issuecomment -702634696. Namun: semua ini membutuhkan gcc (mingw-w64) untuk kompilasi. OpenLIBM tidak dapat dikompilasi dengan MSVC AFAIK. Dan kode assembler sebaris tidak diperbolehkan dengan MSVC. Pada prinsipnya, seseorang dapat membangun (mingw-w64) dan menggunakan (MSVC) pustaka fmod helper selama numpy build.

Bagaimana jika Anda menambahkan beberapa kode setelah panggilan fmod, sehingga ST (0) tidak mengandung nan? Atau atur ke nan sintetis? Apakah konvensi panggilan menempatkan beberapa batasan tentang bagaimana register ini seharusnya berperilaku?

Saya kira kita bisa menambahkan sedikit perakitan untuk membersihkan register sebelum memanggil OpenBLAS di windows. Saya mencoba melakukan ini dalam set-up pengujian kecil tetapi foo perakitan masm saya lemah. Saya mencoba menulis prosedur yang hanya memanggil fldz beberapa kali, ketika menggunakannya saya mendapatkan pengecualian. Tolong?

.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;
}

@ mattip , saya membuat file assembler untuk fungsi text: identik seperti yang ditemukan dalam fungsi fmod dari mingw-w64 (64-bit). Tidak tahu apakah ini berfungsi sebagai pengganti fungsi fmod buggy, tetapi setidaknya seseorang harus mencobanya. Berkas obj yang dihasilkan dapat ditambahkan ke npymath.lib.

fmod.asm: (64-bit)

.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

perintah masm: ml64.exe /c fmod.asm membuat fmod.obj (gunakan varian 64-bit dari ml64.exe)

``

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 terima kasih. Saya akan lebih senang dengan bagian assembler yang me-reset register ST (N) yang bisa kita gunakan pada x86_64 sebelum memanggil fungsi OpenBLAS. Hari ini masalah ini muncul karena adanya perubahan pada fmod , besok mungkin fungsi yang berbeda. Saya tidak yakin apakah ada fungsi yang diperlukan untuk menyetel ulang register ST(N) saat kembali. Jika tidak ada persyaratan seperti itu, fmod sebenarnya bukan buggy dan perubahan di windows menunjukkan kegagalan OpenBLAS untuk mengatur ulang register sebelum menggunakannya sehingga kami harus membantu mereka memperbaiki atau mengatasinya.

Saya mencoba mengatur ulang register menggunakan fldz di komentar di atas tetapi program pengujian saya tidak berfungsi.

@ Mattip , pengetahuan assembler saya juga kurang lebih mendasar. Namun, Anda mungkin menemukan jawaban yang mungkin di utas SO ini: https://stackoverflow.com/questions/19892215/free-the-x87-fpu-stack-ia32/33575875

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

Kira kita juga bisa memanggil fninit pada awal OpenBLAS nrm2.S (setelah makro PROFCODE) untuk memeriksa teori itu

Sedikit menarik dari
Antarmuka Biner Aplikasi Sistem VTambahan Prosesor Arsitektur AMD64Versi Draf 0.99.6

_Bit kontrol dari register MXCSR disimpan callee (dipertahankan di seluruh panggilan), sedangkan bit status disimpan penelepon (tidak disimpan) ._

_ Register kata status x87 disimpan oleh penelepon, sedangkan kata kontrol x87 disimpan dengan panggilan ._

_Semua register x87 disimpan oleh pemanggil, jadi pengguna yang menggunakan register MMX dapat menggunakan instruksi femms yang lebih cepat._

Cukup berbeda dibandingkan dengan konvensi panggilan 64-bit Windows.

@ martin-frbg, fninit berbahaya: The FPU control word is set to 037FH (round to nearest, all exceptions masked, 64-bit precision). X87 presisi yang diperluas tidak Anda inginkan dalam semua kasus, terutama pada Windows.

Saya tidak ingin ini untuk versi rilis, hanya untuk tes cepat. Masih belum cukup yakin bahwa OpenBLAS entah bagaimana harus membersihkan "sebelum" itu sendiri, tetapi saya tidak dapat menemukan dokumentasi yang jelas tentang perilaku Windows dengan fpu x87 warisan. Saya perhatikan Agner Fog memiliki dokumen tentang konvensi panggilan di http://www.agner.org/optimize/calling_conventions.pdf (diskusi tentang penanganan register FP Win64 dimulai pada halaman 13 tetapi berkonsentrasi pada ketersediaan dasar dan perilaku di seluruh sakelar konteks).

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

Saya kira ini berarti: jangan gunakan instruksi x87 (Win64). Jika Anda melakukannya, semoga berhasil. Atau dengan kata lain: callee bertanggung jawab untuk tidak mencelakakan.

Hm itu sepertinya menggambarkan perilaku compiler MSVC secara spesifik, sedangkan saya _think_ kita berada di ekosistem mingw?

Tidak, Numpy (Pypi) dikompilasi dengan MSVC (Visual Studio 2019) di Windows. Untuk OpenBLAS mingw-w64 digunakan (karena bagian Fortran). Juga bagian Scipy Fortran dikompilasi dengan mingw-w64. Namun, CPython dan ekstensi binernya sangat didasarkan pada standar yang ditetapkan oleh MSVC.

BTW: inilah alasan pengembangan https://github.com/mingwpy yang saat ini dihembuskan kembali ke kehidupan kembali. (steker tidak tahu malu)

Sedikit lagi:

mingw-w64 menggunakan (hampir) konvensi pemanggilan yang sama dengan MSVC. Satu-satunya perbedaan penting adalah perataan tumpukan yang berbeda pada x86 (32-bit) - relevan untuk SIMD dan vectorcall tidak didukung.

Menarik. x86 tidak terpengaruh. Hanya AMD64.

Pada Sun, 4 Okt 2020, 22:19 carlkl [email protected] menulis:

Sedikit lagi:

mingw-w64 menggunakan (hampir) konvensi pemanggilan yang sama dengan MSVC. Satu-satunya
perbedaan penting adalah perataan tumpukan yang berbeda pada x86 (32-bit) -
relevan untuk SIMD dan vectorcall yang tidak didukung.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/numpy/numpy/issues/16744#issuecomment-703317784 , atau
berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ABKTSRMFHWZVLDYDFGBM6YDSJDRGTANCNFSM4OP5IXNQ
.

MSVC 32bit mungkin tidak menolak fpu? Saya hanya akan melakukan penggantian sementara dari nrm2.S yang menggunakan fpu oleh nrm2_see2.S (jika layak, sayangnya ada sejumlah rutinitas perakitan yang tidak terpakai tetapi mematikan yang beredar di basis kode) atau versi C biasa untuk OS == Windows kemudian. (Masalah lain yang dibahas di sini haruslah sesuatu yang lain, karena saya pikir semua rutinitas perakitan lama lainnya untuk x86_64 setidaknya adalah SSE2)

@ Mattip , mungkin panggilan ke _fpreset setelah divmod cukup untuk menyetel ulang dari status FPU yang kacau?

mungkin panggilan ke _fpreset

Tidak, ini tidak mengatur ulang register ST(N) , juga tidak memperbaiki tes yang gagal.

Apakah Anda mencoba _fninit ? Ini harus mengatur ulang tumpukan FPU. Atau ffree atau fstp bukan fldz seperti yang disebutkan di https://stackoverflow.com/questions/19892215/free-the-x87-fpu-stack-ia32/33575875 ?

lihat https://developercommunity.visualstudio.com/content/problem/1208774/fpu-exception-in-fmod0-x-in-windows-10-version-200.html

Saya akan dengan senang hati mencoba perintah assembler, tetapi proyek uji di komentar di atas macet. Seseorang perlu memperbaiki kode saya untuk membuatnya berfungsi (memang, fninit sepertinya kandidat yang baik) kemudian saya dapat mengeluarkan instruksi assembler untuk mengatur ulang register di NumPy sebelum memanggil ke OpenBLAS.

Sesuatu seperti ini?

.code
reset_fpu proc
    finit
    fldz
reset_fpu endp
end

finit ist wait ditambah fninit . Saya tidak yakin, bahwa fldz dibutuhkan setelah fninit .

Seperti yang saya katakan di komentar, ada sesuatu yang hilang untuk membuat panggilan ke kode assembly yang dikompilasi berfungsi dengan benar. Ini cukup banyak yang saya miliki dalam komentar itu. Kode macet dengan exited with code -2147483645 . Silakan lihat kode lengkapnya dan lihat apakah Anda dapat membuatnya berfungsi.

Saya bisa mencobanya (besok). Namun, semoga cuplikan ini bermanfaat:

https://www.website.masmforum.com/tutorials/fptute/fpuchap4.htm
(salah satu situs yang paling dapat dibaca tentang topik ini yang saya temukan)

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. 

Seperti yang saya pahami fldz dapat segfault jika st (7) digunakan, oleh karena itu:

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. 

Anda dapat mencoba:

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

Maaf saya tidak menjelaskan dengan jelas. Masalah langsungnya bukanlah pada panggilan assembler yang mana . Masalah langsungnya adalah bagaimana membuat prosedur callable dengan benar sedemikian rupa sehingga kita dapat menggunakannya, dan untuk menunjukkannya dalam dua file ( *.asm dan main.c / main.cpp ) proyek yang mengompilasi dan menjalankan. Setelah kami memilikinya, saya dapat terus mengeksplorasi panggilan yang berbeda dan bagaimana pengaruhnya terhadap OpenBLAS.

@ mattip , saya mengerti. Saya pasti akan mencobanya, tetapi ini mungkin membutuhkan waktu.

Saya mendapat kesan bahwa _tempory_ perilaku buruk fmod di UCRT harus _healed_ oleh OpenBLAS: https://github.com/xianyi/OpenBLAS/pull/2882 dan bukan oleh numpy karena numpy tidak menggunakan FPU di WIN64. Dan tentu saja MS harus memperbaiki masalah ini dengan tambalan Windows.
Patch numpy dalam kasus ini akan memastikan penggunaan versi OpenBLAS selama build tidak lebih lama dari rilis OpenBLAS mendatang.

@matti Ada pemeriksaan kewarasan di numpy/__init__.py . Apakah ada pengujian sederhana dan andal yang dapat kami tambahkan untuk mendeteksi masalah ini?

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

@ mattip , terima kasih atas cuplikannya. Tetapi saya perlu waktu untuk mendapatkan akses ke desktop tempat saya dapat melakukan tes semacam ini. Saat ini saya bekerja sebagian besar waktu dengan laptop dengan lingkungan pemrograman minimal di mana saya hampir tidak dapat menginstal apa pun.

Kami telah menggabungkan pembaruan ke OpenBLAS v0.3.12 dan versi lokal menggunakan versi + pembaruan windows 2004 melewati rangkaian pengujian.

Membiarkan ini terbuka sampai pembaruan Windows.

Apakah roda pra-rilis telah dibuat dengan OpenBLAS baru? Senang melakukan beberapa pengujian lebih lanjut dengan proyek hilir yang mengalami bug ini.

Roda pra-rilis Windows 3.9 saat ini hilang karena ada kesalahan uji (sekarang sudah diperbaiki). Perpustakaan tetap akan digunakan di 1.19.3 yang keluar hari ini atau besok.

Opsi /MT memungkinkan penautan statis di Windows. Dimungkinkan untuk menautkan secara statis ke libucrt.lib menggunakan versi Microsoft SDK 1909. Ini dapat bertindak sebagai solusi untuk bug ucrtbase.dll pada tahun 2004 dan 20H2. Itu akan membuat roda lebih besar, yang merupakan sisi negatifnya.

Saya tidak tahu apakah masalah / MT ini masih berlaku, tetapi harus dipertimbangkan.

Saya pikir jika NumPy adalah satu-satunya modul yang dibangun dengan MT maka itu mungkin saja
BAIK. Tentu saja, bisa jadi jika NumPy adalah MT maka apapun
hilir juga perlu menjadi MT, jadi ini akan menjadi masalah.

Pada hari Senin, 2 Nov 2020, 19:37 carlkl [email protected] menulis:

Saya tidak tahu apakah ini / masalah MT
https://stevedower.id.au/blog/building-for-python-3-5-part-two masih
valid, tetapi harus dipertimbangkan.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/numpy/numpy/issues/16744#issuecomment-720682011 , atau
berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ABKTSRJIVAQLECK4E2EVSSDSN4C65ANCNFSM4OP5IXNQ
.

Adakah solusi yang disarankan untuk masalah ini? Situasi saya adalah bahwa saya menggunakan mesin yang diperbarui ke pembaruan 2004, dan memiliki perangkat lunak desktop yang menggunakan pip untuk menginstal numpy / scipy / pandas dll. Semua perangkat lunak ini dipengaruhi oleh masalah ini yang disebabkan oleh pembaruan Microsoft.

Setiap rekomendasi akan dihargai, karena menggunakan conda untuk menginstal numpy bukanlah pilihan untuk perangkat lunak yang saya kerjakan.

Jika Anda tidak membutuhkan buruh pelabuhan, Anda bisa memasang pin 1.19.3. Ini melewati semua tes pada sistem Windows saya.

Terima kasih. 1.19.3 bekerja dengan pip tentang masalah ini.

Tautan dalam deteksi BLAS yang buruk mendorong banyak posting berisik di situs MS. Saya harap ini tidak berakhir meledak.

Saya kira alternatif lain adalah menggunakan fmod pihak ke-3 di Win64.

Saya ingin tahu bagaimana tanggapannya jika NumPy memiliki bug yang tidak diperbaiki yang serius selama empat bulan setelah rilis, terutama jika kami tidak memberikan instruksi yang jelas bagi pengguna untuk menurunkan versi ke versi sebelumnya. Pengguna dapat dengan mudah menyematkan ke 1.19.3, tetapi itu tidak akan menyelesaikan masalah, itu hanya akan memindahkannya ke paket lain yang menggunakan register setelah mereka mengacaukannya: mungkin scipy, mungkin tensorflow.

Ide lain untuk solusi: Lihat apakah ada fungsi lain di ucrt yang menggunakan FPU dan biarkan statusnya dalam kondisi baik. Jika ada, kita bisa menyebutnya setelah fmod. Ini akan memiliki keuntungan dibandingkan solusi perakitan yang ditulis @mattip karena tidak memerlukan file khusus atau proses pembuatan.

Saya tidak berpikir kita harus menginvestasikan lebih banyak upaya untuk mengatasi masalah ini. Setiap pekerjaan tambahan yang kami lakukan untuk mengurangi masalah akan menyita waktu pengembang yang berharga dan mengurangi tekanan pada Microsoft untuk memperbaikinya. Juga, seperti yang disebutkan di atas, kode apa pun dalam proyek lain yang memanggil fmod dan / atau menggunakan register dapat mengalami masalah ini tanpa koneksi ke NumPy.

Saya tidak berpikir kita harus menginvestasikan lebih banyak upaya untuk mengatasi masalah ini. Setiap pekerjaan tambahan yang kami lakukan untuk mengurangi masalah akan menyita waktu pengembang yang berharga dan mengurangi tekanan pada Microsoft untuk memperbaikinya. Juga, seperti yang disebutkan di atas, kode apa pun dalam proyek lain yang memanggil fmod dan / atau menggunakan register dapat mengalami masalah ini tanpa koneksi ke NumPy.

Setelah melihat reaksi terhadap pesan kesalahan itu jelas tidak terlalu membantu. Ini harus, misalnya, menyarankan pengguna Windows yang ingin menggunakan fitur NumPy terbaru harus menggunakan distribusi yang disertakan dengan MKL daripada roda pip. Ini juga harus menyertakan tautan ke utas ini.

Meskipun ini jelas merupakan tanggung jawab MS untuk memperbaikinya, menyebabkan rasa sakit bagi pengguna untuk menunjukkan kesalahan orang lain jarang merupakan cara yang baik untuk proyek apa pun untuk mempertahankan niat baik.

@bashtage Tidak begitu yakin apa yang Anda maksud tentang menyebabkan rasa sakit. Kami dapat menghapus tautan dan meminta pengguna mendarat di sini, tetapi kami harus memperingatkan pengguna bahwa ketika dijalankan pada tahun 2004, hasilnya tidak dapat dipercaya, dan jika Anda tidak dapat mempercayai hasil penghitungan, Anda harus menghindari penghitungan pada platform itu.

Tidak begitu yakin apa yang Anda maksud dengan menyebabkan rasa sakit.

Impor NumPy gagal secara spektakuler dan tidak ada solusi yang disediakan. Akan sangat membantu bagi sebagian besar pengguna jika daftar solusi yang diketahui terlihat jelas:

(a) Menggunakan distribusi berbasis MKL seperti conda atau Enthought Deployment Manager yang menghindari ini, tetapi dalam kode aljabar linier
(b) Kembalikan ke NumPy 1.19.3 yang disertakan dengan versi OpenBLAS yang dilindungi dari bug. Opsi ini mungkin tidak cocok untuk pengguna yang menjalankan di kontainer.
(c) Membangun dari sumber. Opsi ini akan memiliki BLAS berkinerja rendah, tetapi mungkin cocok di lingkungan di mana distribusi pihak ketiga tidak diizinkan dan kontainer digunakan atau fitur terbaru atau perbaikan bug di NumPy diperlukan.

Saya rasa tidak salah untuk memperhatikan bug fmod, tetapi kemudian mengirim pengguna ke forum itu seolah-olah ada solusi yang menunggu mereka.

Kami dapat menghapus tautan dan meminta pengguna mendarat di sini, tetapi kami harus memperingatkan pengguna bahwa ketika dijalankan pada tahun 2004, hasilnya tidak dapat dipercaya, dan jika Anda tidak dapat mempercayai hasil penghitungan, Anda harus menghindari penghitungan pada platform itu.

Ini bukanlah pilihan. Pengguna hanya perlu menghindari NumPy + OpenBLAS (contoh 0.3.12). Mereka tidak perlu menghindari NumPy + Windows (2004 / 20H2 (sekarang ada 2 versi rilis yang terpengaruh)).

Distribusi berbasis MKL

Ada laporan masalah dengan MKL juga.

Kembali ke NumPy 1.19.3

Tapi itu tidak akan memperbaiki masalah potensial lain yang diakibatkan oleh penggunaan fmod. Masalahnya adalah tidak ada cara untuk memastikan bahwa hasilnya benar.

Orang-orang seharusnya tidak menggunakan Python pada tahun 2004, mungkin menggunakan WSL sebagai gantinya? Saya juga akan baik-baik saja dengan memasukkan ucrt yang lebih tua dengan roda jendela jika itu memungkinkan, tetapi bagaimana dengan proyek lain? Apakah ada cara mudah untuk kembali ke versi windows sebelumnya?

Ada laporan masalah dengan MKL juga.

NumPy tidak memiliki pengujian yang gagal di MKL. Tampaknya sulit untuk menganggap ada masalah jika tidak ada laporan kegagalan. Bug fmod tidak memanifestasikan dirinya di BLAS MKL (mungkin karena tidak menggunakan FPU).

Tapi itu tidak akan memperbaiki masalah potensial lain yang diakibatkan oleh penggunaan fmod. Masalahnya adalah tidak ada cara untuk memastikan bahwa hasilnya benar.

Tidak, tetapi itu juga tidak akan memperbaiki masalah keamanan Windows, atau banyak bug lainnya. Masalahnya di sini sangat khusus.

1. fmod baik-baik saja karena menghasilkan hasil yang benar
2. Anda perlu memiliki kode yang ditulis di assembler untuk menghadapi masalah ini karena compiler sistem tidak akan menghasilkan kode x87.

Keduanya menunjukkan kepada saya bahwa masalahnya sangat menantang untuk menjangkau hampir semua kode. Hanya kode kinerja tertinggi seperti OpenBLAS, pustaka FFT yang berisi kernel tulisan tangan, atau MKL yang cenderung memicu # 2.

Saya juga berpikir masuk akal untuk merilis perbaikan karena jika OpenBLAS 0.3.12 bekerja seperti yang diharapkan maka NumPy akan dirilis dan masalah ini tidak akan pernah diangkat ke pengguna.

Orang-orang seharusnya tidak menggunakan Python pada tahun 2004, mungkin menggunakan WSL sebagai gantinya? Saya juga akan baik-baik saja dengan memasukkan ucrt yang lebih tua dengan roda jendela jika itu memungkinkan, tetapi bagaimana dengan proyek lain? Apakah ada cara mudah untuk kembali ke versi windows sebelumnya?

Saya curiga bagi banyak pengguna ini sebenarnya bukan pilihan bagi banyak pengguna: pengguna korporat di desktop perusahaan, siswa pemula (yang harus menggunakan conda), atau siapa saja yang membeli laptop dengan 2004 atau 20H2 yang tidak dapat menurunkan versi.

Perhatikan bahwa Condas numpy tidak hanya ditautkan ke MLK, tetapi juga sudah mengirimkan versinya sendiri ucrtbase.dll yang appers menjadi versi yang lebih lama (10.0.17134.12)

Sangat setuju dengan @bashtage di sini, impor yang gagal tanpa rekomendasi yang masuk akal untuk memperbaikinya agak memusuhi pengguna (meskipun kesalahan utama ada pada microsoft).

@jenshnielsen : Perhatikan bahwa

Build yang dikemas oleh conda-forge memungkinkan pengalihan implementasi blas / lapack (dari openblas / mkl / blis / netlib), tidak _have_ menjadi MKL.

Orang-orang seharusnya tidak menggunakan Python pada tahun 2004, mungkin menggunakan WSL sebagai gantinya?

Itu bukan mode operasi default untuk sebagian besar pengguna.

Saya juga akan baik-baik saja dengan memasukkan ucrt yang lebih tua dengan roda jendela jika itu memungkinkan, tetapi bagaimana dengan proyek lain?

Proyek lain bukan tanggung jawab kami.

Apakah ada cara mudah untuk kembali ke versi windows sebelumnya?

Jika Anda melakukan instalasi baru atau membersihkan ruang disk Anda, hampir tidak mungkin untuk melakukannya.

Sangat setuju dengan @bashtage di sini, impor yang gagal tanpa rekomendasi yang masuk akal untuk memperbaikinya agak memusuhi pengguna (meskipun kesalahan utama ada pada microsoft).

Saya setuju. Kami mungkin akan kehilangan banyak pengguna jika kami tidak memperbaikinya.

Saya juga akan baik-baik saja dengan memasukkan ucrt yang lebih tua dengan roda jendela jika itu memungkinkan, tetapi bagaimana dengan proyek lain?

@charris , ini tidak akan membantu di Windows 10. Jika Anda menggunakan ucrt yang berbeda bersama dengan python atau numpy, itu tidak akan

@kartun_anak
Python yang dikemas dengan konda benar-benar menyisipkan dirinya ke dalam resolusi jalur pencarian DLL (yang - tidak berubah - mungkin akan menjadi alasan mengapa Anda mengatakan itu tidak akan pernah bisa berfungsi pada Windows 10), dan ini AFAICT juga alasan mengapa conda _does_ memberikan ucrtbase.dll , seperti yang ditulis @jenshnielsen .

@ h-vetinari, penerapan CRT Universal dengan jelas menyatakan:

_Ada dua batasan tentang penerapan lokal yang harus diperhatikan:
Pada Windows 10, CRT Universal di direktori sistem selalu digunakan, meskipun aplikasi menyertakan salinan lokal aplikasi CRT Universal. Itu benar bahkan ketika salinan lokal lebih baru, karena CRT Universal adalah komponen sistem operasi inti pada Windows 10._

BTW: Saya mengujinya sendiri. Tidak ada cara untuk memuat UCRT lain selain UCRT yang tersedia yang disebarkan dengan Windows 10.

Saya juga berpikir masuk akal untuk merilis perbaikan

dengan ini saya pikir Anda bermaksud menambahkan PR gh-17547?

Bukti poin @carlkl :

Bug ini, yang disebabkan oleh MS itu sendiri, harus disebut Heisenbug . Itu mahal dan sulit untuk menemukan penyebabnya: Windows 2004 UCRT fmod membuat register FPU dalam keadaan gagal dalam keadaan tertentu. Hal ini dapat menyebabkan kesalahan kalkulasi numerik nantinya saat menggunakan FPU lagi. Kesalahan perhitungan biasanya tidak muncul dalam kode pengguna jika tidak diuji secara ketat. Ini dapat berarti bahwa kesalahan numerik yang signifikan tetap tidak terdeteksi untuk waktu yang lama. Hampir tidak bisa lebih buruk.

dengan ini saya pikir Anda bermaksud menambahkan PR gh-17547 ?

Maaf, saya menulis hal yang salah.

Satu-satunya perubahan yang saya sarankan adalah bahwa NumPy memberikan lebih banyak informasi dalam pengecualian yang dimunculkan pada impor yang menyarankan cara agar pengguna bisa mendapatkan lingkungan di Windows 2004 / H2 yang memungkinkan mereka melanjutkan pekerjaan / sekolah / hobi mereka.

1. WSL
2. conda / entought
3. 1.19.3
4. Bangun dari sumber

[Pemesanan ini adalah preferensi saya terkait kualitas solusi]

Saya rasa masuk akal juga untuk menautkan ke masalah ini, atau ke masalah yang sedikit lebih bersih yang memberikan penjelasan lebih dalam. Tautan kedua ini juga bisa menjadi ke beberapa catatan rilis di dokumen, daripada masalah github.

Build yang dikemas oleh conda-forge memungkinkan pengalihan implementasi blas / lapack (dari openblas / mkl / blis / netlib), tidak _have_ menjadi MKL.

@ h-vetinari Apakah conda-forge + OpenBLAS membangun tes lulus pada 2004 / H2?

Saya baru saja memeriksa dan memalsukan pengiriman OpenBlas 0.3.12. Apakah ini crash container?

Menggunakan metode pemulihan status FPU dengan instruksi EMMS di OpenBLAS-0.3.12 tentu saja akan membantu untuk mendapatkan tes numpy dan scipy bersih, tetapi seperti yang @charris nyatakan memanggil fmod(0,x) in CPython dan kemudian instruksi FPU dipanggil kemudian (dalam paket yang berbeda dari OpenBLAS) bisa terjadi juga. Dalam hal ini masalahnya hanya dialihkan ke tempat lain.

Taruhan terbaik memang memaksa MS untuk menambal perilaku buggy ini. Mungkin Steve Dower bisa membantu?

Ini bisa juga cerita yang menarik untuk Agner Fog atau mungkin Bruce Dawson: Lihat cerita terkait ini di blognya:
Everything Old is New Again, dan Compiler Bug

Mungkin bug di OpenBlas 0.3.12. Perhatikan kolom Private Bytes:

Ini mungkin default ke 24 utas BLAS karena saya memiliki 24 CPU logis.

Ini adalah OpenBLAS 0.3.12 dengan NumPy 1.19.2 dari conda-forge.

Menyetel $env:OPENBLAS_NUM_THREADS=1 menghasilkan pengurangan yang dramatis

Dan dengan utas $env:OPENBLAS_NUM_THREADS=4 :

@bashtage : dapatkah Anda melanjutkan diskusi OpenBLAS 0.3.12 di OpenBLAS xianyi / OpenBLAS # 2970?

@ Mattip Saya mencoba untuk menentukan apakah conda + OpenBLAS adalah alternatif yang kredibel. Saya tidak berpikir itu menyelesaikan apa pun yang 1.19.3 pecahkan setelah melihat hasil ini.

@bashtage : Bukti poin @carlkl :

Karena python yang dikemas dengan konda secara aktif menghindari resolusi DLL standar windows, saya tidak yakin berapa banyak bukti alat windows akan menjadi. Saya mengalami masalah ini misalnya dengan libcrypto.dll sudah ketinggalan zaman di C:\Windows\System32 , lihat misalnya https://github.com/conda-forge/staged-recipes/pull/11452. Singkatnya, pustaka sistem yang sudah ketinggalan zaman hanya diambil oleh kegagalan pengujian dalam rangkaian pengujian cryptography , dan kemudian - menggunakan CONDA_DLL_SEARCH_MODIFICATION_ENABLE - penggunaan opensl yang disediakan conda dapat dipaksakan.

@bashtage : @ h-vetinari Apakah conda-forge + OpenBLAS membangun tes lulus pada 2004 / H2?

CI yang membangun paket mungkin tidak pada versi saat ini, dan saya butuh sedikit untuk membangunnya sendiri. Saat ini saya menjalankan mesin tahun 2004, dan ini adalah - hasil yang sangat positif **:

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

@bashtage : Saya baru saja memeriksa dan memalsukan kapal OpenBlas 0.3.12. Apakah ini crash container?

conda-forge tidak dikirimkan dengan versi openblas tetap - versi blas bahkan dapat "hotswapped" (misalnya antara openblas, mkl, blis), jadi versinya bukan masalah besar. Namun secara umum, ini akan menggunakan versi paket terbaru. Saya tidak dapat memverifikasi apakah crash mereproduksi atau tidak di dalam kontainer.

@bashtage :: @mattip Saya mencoba untuk menentukan apakah conda + OpenBLAS adalah alternatif yang kredibel. Saya tidak berpikir itu menyelesaikan apa pun yang 1.19.3 pecahkan setelah melihat hasil ini.

Peningkatan memori disebabkan oleh perubahan pada openblas 0.3.12, sebagaimana dibahas lebih lanjut di xianyi / OpenBLAS # 2970. Sejauh ini, conda-forge tampaknya merupakan alternatif yang kredibel bagi saya - setidaknya tidak terpengaruh secara langsung oleh kesalahan tersebut.

** Saya menggunakan master https://github.com/conda-forge/numpy-feedstock saat ini , yang masih di 1.19.2, ditambah dengan openblas 0.3.12. Saya juga dapat mencoba https://github.com/conda-forge/numpy-feedstock/pull/210 + openblas 0.3.12, jika orang tertarik.

Kabar baiknya, MS kembali ke forum VS dan menyarankan agar perbaikan dapat dilakukan pada akhir Jan 2021. Mengingat pembaruan ini, saya pikir satu-satunya pertanyaan adalah apakah ada nilai dalam memperbarui pesan kesalahan yang muncul saat fungsi buggy terdeteksi.

Karena python yang dikemas dengan konda secara aktif menghindari resolusi DLL standar windows, saya tidak yakin berapa banyak bukti alat windows akan menjadi. Saya mengalami masalah ini misalnya dengan libcrypto.dll sudah ketinggalan zaman di C:\Windows\System32 , lihat contoh conda-forge / staged-recipes # 11452 . Singkatnya, pustaka sistem yang sudah ketinggalan zaman hanya diambil oleh kegagalan pengujian dalam rangkaian pengujian cryptography , dan kemudian - menggunakan CONDA_DLL_SEARCH_MODIFICATION_ENABLE - penggunaan opensl yang disediakan conda dapat dipaksakan.

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')"

keluaran

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

Ini menunjukkan bahwa ketika OpenBLAS lama digunakan, fungsi buggy dari ucrt DLL sedang digunakan.

Hanya openblas = 0.3.12 dari conda forge yang akan lulus tes, tetapi ini sama dengan yang dikirimkan di NumPy 1.19.3.

Apa yang menentang rilis numpy baru yang dikompilasi dengan OpenBLAS-0.3.12 yang dilucuti? Mengurangi Buffer dan mungkin mengurangi jumlah utas pada waktu kompilasi OpenBLAS yang digunakan untuk numpy. Ini akan mengurangi konsumsi memori OpenBLAS dan akan membantu tidak hanya dalam testcase Docker tetapi juga pengguna dengan perlengkapan yang kurang baik
kotak jendela.

Di sini dari https://tinyurl.com/y3dm3h86 laporan bug dari dalam Python. Pertama, terima kasih telah menyediakan versi yang berfungsi di Windows untuk saat ini (1.19.3).

Saya memahami bahwa 1.19.3 tidak berfungsi di Linux dan 1.19.4 tidak berfungsi di Windows (meskipun terdapat bug).

Apakah mungkin membuat versi terbaru pada pypi 1.19.3 untuk Windows, dan 1.19.4 untuk semua platform lainnya? Dengan kata lain, cukup hapus https://files.pythonhosted.org/packages/33/26/c448c5203823d744b7e71b81c2b6dcbcd4bff972897ce989b437ee836b2b/numpy-1.19.4-cp36-cp36m-win_amd64.whl / 3,8 yang sesuai untuk sekarang?

@luciansmith Selama sumber tersedia untuk 1.19.4 pip akan mencoba dan menggunakan versi ini kecuali bendera tambahan dilewatkan. Saya pikir sebagian besar pengguna hanya akan memberikan tanda tambahan jika mereka mengetahui masalahnya, tetapi kemudian mereka dapat memasang pin 1.19.3.

Preferensi saya adalah memiliki 1.19.5 yang menggunakan OpenBLAS 0.3.9 di Linux dan 0.3.12 di Windows, tetapi saya tidak tahu apakah ini memungkinkan.