Numpy: فشلت اختبارات انحدار polyfit و eig بعد تحديث Windows 10 إلى 2004

تحرير: من الواضح أنك تستخدم النقطة ، لقد حصلت أيضًا على نتيجة غريبة على Windows AMD64 في الماضي القريب مع مكتبات الجبر الخطية وتحليلات القيمة الذاتية (في سياق اختبار التشغيل لنماذج الحالة).

إذا كان لديك الوقت ، فحاول استخدام Python و Pip 32 بت ومعرفة ما إذا كنت تواجه نفس المشكلات؟ لم أتمكن من رؤيتها على نوافذ 32 بت لكنها كانت قابلة للتكرار على نوافذ 64 بت.

إذا استخدمت conda ، الذي يشحن MKL ، فلن أواجه الأخطاء.

تحرير: أراها أيضًا عند استخدام NumPy 1.18.5 على Windows AMD64.

تفشل الاختبارات بعد آخر تحديث لنظام التشغيل Windows 10

هل فشلت الاختبارات قبل التحديث؟

لا charris ، قبل التحديث ، تمر مجموعة الاختبار فقط.

speixoto هل تعرف التحديث الذي تم

التحديث 1809 (10.0.17763) لم يتسبب في فشل اختبار bashtage

لم يكن عام 1909 يسبب أي شيء كذلك. لقد بدأ فقط في عام 2004.

لست مقتنعًا بنسبة 100٪ أنه عام 2004 أو ما بعده. أعتقد أن عام 2004 نجح.

FWIW لا يمكنني إعادة إنتاج هذه الأعطال على CI (Azure أو appveyor) ولكني أفعل ذلك محليًا على جهازين هما AMD64 وتحديثهما في عام 2004.

هل حاول أي منكما معرفة ما إذا كان لديك برنامج Python 32 بت؟

يبدو أنه تم الإبلاغ عن عدد من المشكلات مقابل تحديث 2004. ربما ينبغي الإبلاغ عن هذا أيضا؟

لقد قمت للتو بتشغيل ما يلي على التثبيت الجديد لعامي 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 في مصحح أخطاء ، لاحظت أن الاستدعاء الأول للدالة غالبًا ما يعود بنتيجة غير صحيحة ، ولكن الاتصال مرة أخرى ينتج عنه النتيجة الصحيحة (التي تظل صحيحة إذا تم استدعاؤها بشكل متكرر). لست متأكدًا مما إذا كانت هذه معلومات مفيدة لتخمين سبب.

هل الإصدارات السابقة من NumPy بها مشكلات أيضًا؟ أفترض أنك تقوم بتشغيل 1.19.0.

باستخدام النقطة + 1.18.4 و scipy 1.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

عندما أركض باستخدام 1.18.5 + MKL ، لا أحصل على أخطاء. من الصعب تحديد ما إذا كان هذا من المحتمل أن يكون خطأ OpenBLAS أو خطأ في Windows. ربما هذا الأخير ، ولكن سيكون من الصعب حقًا الوصول إليه والتشخيص يتجاوز قدراتي على تصحيح الأخطاء على المستوى المنخفض.

على نفس الجهاز المادي ، عندما أقوم بتشغيل Ubuntu باستخدام حزم pip ، لا أرى أي أخطاء.

هذا هو أغرب سلوك. فشل في المكالمة الأولى ، يعمل في الثانية واللاحقة. أحد السلوكيات الأخرى التي يصعب فهمها هو أنني إذا أجريت اختبار الفشل بمعزل عن غيره من الأخطاء.

تحديث نهائي واحد: إذا قمت باختبار استخدام بناء مصدر لـ NumPy دون تحسين BLAS ، ما زلت أرى أخطاء بالرغم من أنها ليست مجموعة متطابقة.

ربما يستحق الأمر ping مع مطوري OpenBLAS. هل يحدث ذلك مع float32 بقدر ما يحدث مع float64؟

عند تشغيل اختبار كامل من نمباي 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...

أعتقد أنه إذا قمت بإجراء الاختبار حصريًا ، فيجب أن يجتاز الاختبار إذا كنت أتذكر بشكل صحيح من إجراء اختبار ping للأشياء ، وهذا يعني المزيد من السلوك الغريب.

لقد تقدمت إلى Microsoft بالطريقة الوحيدة التي أعرف كيف:

https://aka.ms/AA8xe7q

النشر في حال وجد الآخرون ذلك من خلال البحث:

يجب على مستخدمي Windows استخدام Conda / MKL إذا كان ذلك في عام 2004 حتى يتم حل هذه المشكلة

هذا مثال صغير على إعادة الإنتاج:

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
دورغر
DHSEQR

يبدو الأمر أشبه بمشكلة OpenBlas (أو شيء ما بين 2004 و OpenBLAS). هنا ملخصي:

NumPy فقط python -c "import numpy;numpy.test('full')"

• لا يوجد BLAS مُحسَّن: تمرير ممتلئ
• OpenBLAS: فشل كامل
• MKL: تمرير ممتلئ

statsmodels اختبار pytest statsmodels

• Pip NumPy و SciPy: فشل متعلق بـ SVD و QR ذات الصلة
• MKL NumPy و SciPy: مرر
• لا يوجد نظام BLAS مُحسَّن: فشل ، ولكن أقل من ذلك كله يتضمن إجراءات scipy.linalg ، والتي تستخدم OpenBLAS.
• لا يوجد BLAS محسن ، لا يوجد SciPY linalg: Pass

سيكون من الجيد معرفة ما الذي تغير في عام 2004. ربما نحتاج إلى علم مختلف عند تجميع / ربط المكتبة؟

_If_ هو خطأ OpenBLAS ، فمن غير المحتمل أن يكونوا قد رأوه لأن أيًا من CI المستندة إلى Windows لا تستخدم الإصدار 19041 (المعروف أيضًا باسم Windows 10 2004) أو أحدث.

فقط للتوضيح ، صحيح أن أياً من هذه التقارير لا يتضمن WSL؟

لا. كل ذلك مع إما python.exe المقدم من Conda أو قدم python.org python.exe

هل يفشل الاختبار إذا تم تحديد متغير البيئة OPENBLAS_CORETYPE=Haswell أو OPENBLAS_CORETYPE=NEHALEM بشكل صريح؟

لقد جربت Atom و SandyBridge و Haswell و Prescott و Nehalem ، كل ذلك بنتائج متطابقة.

أغرب شيء هو أنك إذا ركضت

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 .

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)

الملاحظة النهائية ، التحويل إلى np.complex128 يزيد أيضًا ، بينما التحويل إلى np.float32 أو np.complex64 يعمل كلاهما بدون مشكلة.

تم تجميع أجزاء Python من الكود بأعداد صحيحة طويلة ولكن OpenBLAS بني بدون INTERFACE64 = 1 في أجزاء Fortran (LAPACK)؟
(لا يزال هذا لا يفسر سبب فشل الاتصال الأول ولكن أي نجاح لاحق ، ولا سبب نجاحه قبل التحديث 19041)

يمكن لمستخدمي Windows 10 التصويت على هذه المشكلة في مركز ملاحظات Microsoft.

https://aka.ms/AA8xe7q

بناءً على طلب bashtage ، قمت

يؤدي التحويل إلى np.complex128 أيضًا إلى رفع ، بينما يعمل التحويل إلى np.float32 أو np.complex64 بدون مشكلة.

رسالة التحذير الأولى (التي لا يبدو أنها تظهر عند النجاح) "عند إدخال معلمة DGEBAL رقم 3 لها قيمة غير قانونية" ناتجة عن هذا الشرط https://github.com/xianyi/OpenBLAS/blob/ce3651516f12079f3ca2418aa85b9ad571c3a391/lapack -netlib / SRC / dgebal.f # L336 والذي قد يكون ناتجًا عن أي عدد من الحسابات السابقة التي تذهب إلى NaN.

بالتلاعب بخطوات repro ، وجدت أن إجراء التعديل كـ 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 الداخلية أين يمكن أن يحدث ذلك.

يذكرني نوع من الخلل القديم الذي رأيناه مع mingw على WIndows ، حيث لم يتم توريث تكوين سجل النقطة العائمة بواسطة مؤشرات ترابط العاملين ، مما أدى إلى عدم تدفق العوالق إلى الصفر وإفساد الحسابات اللاحقة في بعض الأحيان.
لست متأكدًا مما إذا كان هذا مناسبًا بأي شكل من الأشكال لنظام Windows الحالي على الأجهزة الحالية ولكن قد يكون من المثير للاهتمام معرفة ما إذا كان لديك
تم إنشاء OpenBLAS باستخدام CONSISTENT_FPCSR = 1 (أو إذا كانت إضافة خيار البناء هذا يساعد).

mattip هل تعرف ما إذا كان

يبدو أنه كذلك ، للأسف:

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

حسنًا ، على الأقل هذا بعيدًا عن الطريق إذن. بدا الاتصال بعيدًا إلى حد ما على أي حال.

مرحبا! لقد واجهت مشكلة مماثلة لبعض الوقت الآن وتشير جميع اختباراتي إلى شيء مريب بين Windows 10 (2004) و OpenBlas. عادةً ما أقوم بتشغيل برامجي على 3 أجهزة كمبيوتر (محطتا عمل Windows 10 وجهاز كمبيوتر محمول قديم يعمل بنظام Windows 7). بدأت نصوص Python النصية في التصرف مع الأخطاء المتعلقة بتقارب linalg و svd () في وقت قريب من الوقت الذي قمت فيه بترقية محطتي العمل إلى الإصدار 2004 من Windows 10. لقد واجهت أيضًا أعطالًا في المرة الأولى التي قمت فيها بتشغيل البرنامج النصي ، ولكن في معظم الأحيان عملت في المحاولة الثانية (تشغيل دفاتر Jupyter). جهاز الكمبيوتر المحمول القديم استمر في تشغيل نفس البرامج دون أخطاء! لديّ miniconda و python 3.6 وجميع الحزم مثبتة باستخدام pip (البيئة هي نفسها تمامًا في الأجهزة الثلاثة).
لقد قمت اليوم بإزالة النقطة الافتراضية numpy (1.19.0) وقمت بتثبيت الإصدار numpy + mkl (numpy-1.19.1 + mkl-cp36-cp36m-win_amd64.whl) من https://www.lfd.uci.edu/ ~ gohlke / pythonlibs /. حتى الآن ، اختفت الأخطاء المتعلقة بتقارب linalg و svd (). إذا وجدت شيئًا آخر ، فسأعود إلى هنا وأبلغ عنه.

داريو

من الغريب أن يتم إنشاء OpenBLAS dll بواسطة إصدار VC9 من lib.exe؟ هذا هو الإصدار الذي تم استخدامه مع Python 2.7. قد لا يكون الأمر مهمًا ، لكنه يبدو غريبًا نظرًا لأن VC9 لا يُستخدم في أي مكان.

ستكون الخطوة التالية لشخص ما (ربما أنا) هي بناء NumPy master باستخدام OpenBLAS أحادي السلسلة ( USE_THREAD=0 ) لمعرفة ما إذا كان هذا سيؤدي إلى حل المشكلات.

لقد جربت بعض التجارب ولكن دون جدوى:

• تعطيل المواضيع USE_THREADS=0
• ILP64 INTERFACE64=1 <- Segfault في اختبار NumPy مع انتهاك الوصول

هل يمكنك تشغيل اختبار LAPACK باستخدام إعداد Win10 هذا؟ لقد قمت مؤخرًا بإصلاح بناء cmake لإنتاجه ، ربما يوفر بعض الأدلة دون أي تدخل في 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%)

على الرغم من أنني أرى الكثير من الخطوط مثل

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

لذلك لست متأكدًا مما إذا كانت جديرة بالثقة.

يبدو أن غالبية الاختبارات معيبة ، لكن الاختبارات الباقية لا تشوبها شائبة ... هذا أكثر تطرفًا قليلاً مما كنت أتوقع.
(يعد كل من COMPLEX و COMPLEX16 متطلبًا بعض الشيء من حيث حجم المكدس ، لذلك من المرجح أن تكون هناك حالات فشل مع إعدادات نظام التشغيل الافتراضية ، لكن REAL و DOUBLE سيظهران عادةً حوالي 1200000 اختبار. هذا جعلني أتساءل عما إذا كانت MS قد غيرت شيئًا مكتوبًا في المكدس الافتراضي حد أو تخطيط رغم)

بعض الخلفية. يتم إنشاء كل شيء باستخدام 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)

أعتقد حقًا أن المشكلة تكمن في التسليم بين NumPy و OpenBLAS. لا أستطيع أن أتخيل كيف يمكن أن يحدث هذا السلوك بخلاف ذلك حيث تكون المكالمة الأولى خطأ ، ولكن المكالمة الثانية واللاحقة كلها جيدة. كيف يمكن حلها (أو حتى تشخيص دقيق للمشكلة العميقة) على الرغم من ...؟

إلغاء منصة MS والعيش في سعادة دائمة؟ إذا فشلت في اختبارات الثغرة ، فإن مشكلة التسليم تكمن بين Fortran (= جزء LAPACK من OpenBLAS) و C ، أو Fortran و "أي شيء آخر".

سأكون فضوليًا إذا كان من الممكن إنشاء Numpy باستخدام OpenBLAS باستخدام icc
و ifort لذلك تحقق مما إذا كانت المشكلة قائمة. هذا طلب كبير بالرغم من ذلك.

في الأربعاء ، 12 أغسطس ، 2020 ، الساعة 19:04 ، كتب Martin Kroeker [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
.

من المحتمل أن يكون كافياً لبناء OpenBLAS مع مترجمي إنتل (على الرغم من أن هذا يبدو مشكلة بما يكفي على الأقل مع VS مما ظهر مؤخرًا ، وليس لدي ترخيص صالح لـ ifc / ifort في الوقت الحالي.

مشكلة محتملة ذات صلة:

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

يجب على مستخدمي Windows استخدام Conda / MKL إذا كان ذلك في عام 2004 حتى يتم حل هذه المشكلة

bashtage شكرا على اقتراحك.
في حالتي ، لدي بعض الخطأ عند استخدام sqlite باستخدام pandasql بعد تطبيق إصدار Conda من numpy.

لكن ليس لدي أي مشكلة عند استخدام هذا الإصدار من numpy + mkl .

bashtage يبدو أن هناك

لمعلوماتك: مشكلة SciPy ذات الصلة: https://github.com/scipy/scipy/issues/12747

يوجد تقرير يفيد بأن إصدار Windows 17763.1397 (11 أغسطس) يعمل على إصلاح المشكلة ، راجع # 17082.

يوجد تقرير يفيد بأن إصدار Windows 17763.1397 (11 أغسطس) يعمل على إصلاح المشكلة ، راجع # 17082.

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

الإصدار 17763.1397 مخصص فقط لنظام التشغيل Windows 10 ، الإصدار 1809 (ينطبق على: Windows 10 ، الإصدار 1809 ، جميع الإصدارات ، إصدار خادم Windows 1809 ، Windows Server 2019 ، جميع الإصدارات).
لا توجد مشاكل في هذه الحالة لنظام التشغيل windows 10 ، الإصدار 1809.

هذا هو إصدار التحديث الأخير من windows 10 ، الإصدار 2004.
https://support.microsoft.com/en-us/help/4566782
11 أغسطس 2020 - KB4566782 (إصدار نظام التشغيل 19041.450).

ما زلت أواجه نفس المشكلة على Windows 10 ، الإصدار 2004

نفس الإخفاقات في 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)

يمكنني إعادة إنتاج الإخفاقات (الجزئية) في اختبار lapack-lapack لـ OpenBLAS - والتي تؤثر فقط على اختبارات EIG (القيمة الذاتية) ، والتي من المعروف أنها تحتوي على بعض متطلبات التكديس العالية بشكل غير عادي. هناك يحدث SIGSEGV في __chkstk_ms_ والذي يتم إدخاله حتى قبل main (). مضاعفة القيم الافتراضية "للحجم المحجوز للمكدس" و "حجم الالتزام المكدس" للملف التنفيذي المعني باستخدام الأداة المساعدة peflags (على سبيل المثال peflags -x4194304 -X4194304 EIG/xeigtsts.exe ) تجعل البرامج تعمل بشكل طبيعي ، مما يشير إلى أن تفاعل C / Fortran وتمرير الوسيطة على هذا النحو هو لا مشكلة. لم أحاول بعد تطبيق هذا على الحالة الفارغة (لست متأكدًا حتى من إعداد peflag لضبطه هناك - python.exe؟) ولكن يبدو أن OpenBLAS نفسه يعمل بشكل طبيعي عند إنشائه باستخدام إصدار msys2 mingw64 من مجلس التعاون الخليجي 9.1.0 في 19041.450 المعروف أيضًا باسم 2004

@ martin-frbg التي تبدو وكأنها تقدم.

انزلقت في حفرة أرنب في محاولة للحصول على جميع التبعيات المثبتة لبناء numpy على Windows / MSYS2 لذلك لا مزيد من التقدم.

@ martin-frbg ، يمكن تثبيت الحزمة numpy المستندة إلى Msys2 مع pacman. تتوفر نصوص وتصحيحات بناء Msys2 هنا: https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-python-numpy و https://github.com/msys2/MINGW-packages/tree / master / mingw-w64-openblas.

في اجتماع الفرز الأخير ، ظهر هذا كأولوية عالية نسبيًا ، وأنا و hameerabbasi مستعدون للمساعدة. ماذا نستطيع ان نفعل؟

bashtage هل يمكنك محاولة تكبير حجم المكدس باستخدام editbin /STACK:3145728 python.exe

هل هناك طريقة يمكننا بها محاولة بناء NumPy باستخدام إصدارات OpenBLAS للمكتبات بدلاً من تلك التي نبنيها؟ ربما تكون بناياتنا معطلة قليلاً.

قد يكون من الممكن استبدال libopenblas.dll في الإصدار الخاص بك بواحد تم إنشاؤه من الفرع الحالي develop أو إصدار أقدم مثل 0.3.8 أو 0.3.9 لمعرفة ما إذا كان لذلك أي تأثير؟ (لا يعني ذلك أن لدي أي التزام محدد في الوقت الحالي يمكن أن يكون له أي تأثير على هذا). لسوء الحظ ، ما زلت أواجه أخطاء في التثبيت حتى مع حزم msys2 ، ولا يمكنني حاليًا إجراء الاختبارات على ما يبدو بسبب self.ld_version الذي لا يُرجع شيئًا في فحص الإصدار.

شكر. أحاول تحديث النوافذ الخاصة بي لبناء عام 2004 ، دعنا نرى ما إذا كنت أنتهي قبل نهاية الأسبوع

أيضًا ، "مثال إعادة الإنتاج الصغير" الخاص بـ bashtage من https://github.com/numpy/numpy/issues/16744#issuecomment -655430682 لا يثير أي خطأ في إعداد msys2 الخاص بي. (بقدر ما أستطيع أن أقول ، فإن libopenblas الخاصة بهم في mingw64 / usr / lib عبارة عن 0.3.10 خيط واحد تم تصميمه لـ Haswell)

@ martin-frbg هل ti ممكن لبناء OpenBLAS باستخدام MSVC؟

MSVC عادي؟ يمكن تنفيذه ولكنه يعطي مكتبة محسّنة بشكل سيئ لأن MSVC لا يدعم نواة التجميع - عمليًا كما لو كنت قد بنيت OpenBLAS لـ TARGET = عام.

أيضًا ، "مثال إعادة الإنتاج الصغير" الخاص بـ bashtage من # 16744 (تعليق) لا يثير أي خطأ في إعداد msys2 الخاص بي. (بقدر ما أستطيع أن أقول ، فإن libopenblas الخاصة بهم في mingw64 / usr / lib عبارة عن 0.3.10 خيط واحد تم تصميمه لـ Haswell)

أنا متأكد تمامًا من أنه شيء يتعلق بالواجهة بين NumPy و OpenBLAS. لا يحتوي الإصدار 32 بت من NumPy أيضًا على هذه المشكلة. يبدو أن الأفكار من الأشخاص الذين تحدثت معهم من Microsoft والتي من المحتمل أن تكون مشكلة مزامنة مؤشر ترابط هي الأكثر منطقية. يمكن أن يشرح كيفية وجود القيمة الخاطئة في المكالمة الأولى ثم تصحيحها في المكالمات اللاحقة.

انزلقت في حفرة أرنب في محاولة للحصول على جميع التبعيات المثبتة لبناء numpy على Windows / MSYS2 لذلك لا مزيد من التقدم.

إنه ألم. لقد قمت بذلك ولكن أتمتة ذلك لتجربة بعض التجارب كان يستغرق وقتًا طويلاً. يتطلب أساسًا نسخ الخطوات من https://github.com/MacPython/openblas-libs للحصول على ملفات .a ، ثم نسخ الخطوات من https://github.com/numpy/numpy/blob/master/ azure-steps-windows.yml لبناء NumPy. إنه صعب بشكل خاص لأن بعض الأجزاء تريد MSYS2 القياسي والبعض الآخر يحتاج إلى أن تختفي ، لذلك ينتهي بك الأمر بتثبيت وإلغاء تثبيت معظم دول مجلس التعاون الخليجي في كل مرة تريد إجراء تجربة.

أسهل طريقة للحصول على DLL هي فتح حساب appveyor ، ثم استنساخ https://github.com/MacPython/openblas-libs. في نهاية التصميم الخاص بك ، هناك قطعة أثرية يمكنك العثور عليها من موقع الويب لتنزيلها والتي تحتوي على dll (وملف a.). ومع ذلك ، يعد هذا بطيئًا ، حيث يستغرق إنشاء جميع الإصدارات الثلاثة 3 ساعات.

بالنظر إلى https://github.com/MacPython/openblas-libs ، يبدو أن OpenBLAS تم إنشاؤه INTERFACE64=1 . ليس هذا هو الحال بالنسبة ل Msys2 بناء OpenBLAS و numpy.

carlkl لا تتعلق هذه المشكلة ببناء Msys2 لـ NumPy أو OpenBLAS. يتعلق الأمر ببناء Win32 / AMD64 الذي يستخدم Msys2 المقدم gfortran لتجميع مصادر fortran ، ولكن بعد ذلك يقوم بإنشاء Win32 DLL من المكتبة المترجمة باستخدام MS's lib.exe.

bashtage لقد ذكرت هذا ، لأنه تم الإبلاغ https://github.com/numpy/numpy/issues/16744#issuecomment -689785607 ، أن segfault لا يمكن إعادة إنتاجها داخل msys2. وأعتقد أن بيئة msys2 المذكورة تحتوي على حزم openblas و numpy الثنائية المقدمة من msys2.

ليس لدي أي فكرة ، إذا تم تجميع النوافذ 64 بت numpy بعلم مماثل مع MSVC أم لا.

راجع للشغل: لا يمكنني العثور على العلم -fdefault-integer-8 في مستودع scipy.
لست متأكدًا مما إذا كان الرمز المترجم باستخدام -fdefault-integer-8 متوافق مع ABI مع الكود المترجم بدون هذه العلامة.

جانب آخر جاء في ذهني: ربما يجب دمج -fdefault-integer-8 مع -mcmodel=large .

تحرير: تذكر: يحتوي Windows64 على نموذج ذاكرة LLP64 ، وليس ILP64.
يعني LLP64: طويل: 32 بت ، المؤشر: 64 بت

إذن ، ما هو حجم الأعداد الصحيحة التي يبنيها numpy الذي يواجه مشكلة Win10-2004 التي تستخدم؟ كان لديه تطابق أفضل مع ما تم تصميم OpenBLAS من أجله ، ولكن IIRC هذا الموضوع ظهر مسبقًا في هذا الموضوع بالفعل (ومن المحتمل أن يؤدي عدم التطابق إلى كسر أكثر وضوحًا بغض النظر عن مستوى Windows patchlevel)

يمكن إنشاء Openblas على الأقل بثلاثة متغيرات باستخدام https://github.com/MacPython/openblas-libs (انظر appveyor.yml):

• 32 بت
• 64 بت
• 64 بت مع INTEGER64

ولكن إذا لم يكن لديك أي فكرة عما يتم استخدامه لـ 64 بت numpy يبني على windows.

_ ومن المحتمل أن يؤدي عدم التطابق إلى كسر أكثر وضوحًا بغض النظر عن مستوى التصحيح لنظام التشغيل Windows_

-fdefault-integer-8 ينطبق فقط على الجزء الخاص بـ Fortran من Lapack. إنه لا يغير نموذج الذاكرة الأساسي (LLP64) ، لذلك لست متأكدًا مما إذا كان يجب أن نتوقع مشاكل خارج أجزاء Fortran Lapack.

حسنًا ،

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.

تم إنشاء جميع ثنائيات Numpy الموجودة على pypi.org باستخدام openblas عدد صحيح 32 بت. https://github.com/MacPython/numpy-wheels/blob/v1.19.x/azure/windows.yml

للحصول على تفاصيل عملية البناء gfortran مقابل MSVC ، انظر هنا . لا يشارك Microsoft lib.exe في إنتاج مكتبة الارتباط الديناميكي المفتوحة (DLL) ، إنها سلسلة أدوات mingw كلها. يستخدم Numpy الملف openblas.a ، ويقوم بإنشاء DLL باستخدام gfortran. https://github.com/numpy/numpy/blob/74712a53df240f1661fbced15ae984888fd9afa6/numpy/distutils/fcompiler/gnu.py#L442 تُستخدم أدوات MSVC لإنتاج ملف .lib من ملف .def ورمز Numpy C المترجم مع MSVC باستخدام ملف .lib هذا إلى DLL المُنتج بواسطة gfortran.

أحد الاحتمالات النظرية التي قد تسوء هو إذا كان هناك نوع من عدم تطابق نسخة mingw بين mingw التي أنتجت الأداة openblas.a الثابتة ، ونسخة mingw المستخدمة عند بناء numpy. ومع ذلك ، لست متأكدًا مما إذا كان هذا ممكنًا يمكن أن يسبب مشاكل.

choco install -y mingw --forcex86 --force --version=5.3.0 المستخدم في windows.yml قديم. لماذا لا تستخدم 7.3.0 أو 8.1.0 ؟ يمكنني تذكر المشكلات التي واجهتها مع دول مجلس التعاون الخليجي 5.x منذ عامين أو ثلاثة أعوام.

choco install -y mingw --forcex86 --force --version = 5.3.0 المستخدم في windows.yml يبدو أنه قديم

هذا من أجل بناء windows 32 بت فقط ، لذلك ربما لا يتعلق بهذه المشكلة.

تم إنشاء جميع الإصدارات الأخرى ( Python36-64bit-full ، Python37-64bit-full ) بدون NPY_USE_BLAS_ILP64.

نفس الأخطاء في Python 3.6 و 3.8.

بقيت فكرة واحدة (أنا أحفر في الظلام):

يتم الآن تجميع 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://gcc.gnu.org/legacy-ml/fortran/2019-05/msg00181.html

لم يطبق Numpy هذا العلم على جزءه الصغير من التقطيع. أعلم أنه تم تجميع numpy باستخدام MSVC. لذلك أتوقع مشاكل مع scipy بدلاً من numpy ، لذلك قد تكون هذه رحلة خاطئة مرة أخرى.

تم إنشاء جميع ثنائيات Numpy الموجودة على pypi.org باستخدام openblas عدد صحيح 32 بت. https://github.com/MacPython/numpy-wheels/blob/v1.19.x/azure/windows.yml

لماذا تختلف تكوينات البناء المستخدمة في الاختبار عن تلك المستخدمة في الإصدار؟ هذا يبدو وكأنه خطر.

هل يمكننا إضافة القطع الأثرية إلى تصميمات Azure؟ هذا من شأنه أن يجعل من الأسهل بكثير الحصول على عجلات للاختبار. قلقي الوحيد هنا هو أن حد الأداة المجانية هو IIRC صغير جدًا ، 1 غيغابايت ، ولا أعرف ماذا يحدث عندما تضغط عليه (سيكون FIFO جيدًا ، ولكن قد يفعل أشياء أخرى بما في ذلك الخطأ).

لماذا تختلف تكوينات البناء المستخدمة في الاختبار عن تلك المستخدمة في الإصدار؟

نحن نختبر جميع إصدارات python المدعومة في Windows بدون NPY_USE_BLAS_ILP64 ، ونختبر python 3.8 باستخدام NPY_USE_BLAS_ILP64 أيضًا ، راجع https://github.com/numpy/numpy/blob/v1.19.2/azure -pipelines.yml # L195. لذا فإن الإصدارات الأسبوعية صحيحة في استخدام openblas عدد صحيح 32 بت.

هل يمكننا إضافة القطع الأثرية إلى تصميمات Azure؟

ربما يكون من السهل تجربتها ومعرفة حدودها إذا كانت أخطاء. ومع ذلك ، تهدف العجلات الأسبوعية إلى إعادة إنشاء هياكل الاختبار بأمانة. يجب التعامل مع أي تناقضات على أنها أخطاء وإصلاحها.

ربما يكون من السهل تجربتها ومعرفة حدودها إذا كانت أخطاء. ومع ذلك ، تهدف العجلات الأسبوعية إلى إعادة إنشاء هياكل الاختبار بأمانة. يجب التعامل مع أي تناقضات على أنها أخطاء وإصلاحها.

كنت أفكر أنه سيكون من الأسهل تجربة العلاقات العامة في الريبو الرئيسي والاستيلاء على الأداة لاختبارها في عام 2004.

من المنطقي.

يمكنك تشغيل خطوط أنابيب Azure في الريبو bashtage / numpy

مزيد من المعلومات: المكالمة الأولى التي فشلت هي لأن DNRM2 داخل OpenBLAS تُرجع 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؟

تعتبر العملية mod بالغة الأهمية ، وبدونها لا تطبع الاستدعاء لـ eig هذا الخطأ.

هل يؤدي إنشاء نفس المصفوفة يدويًا إلى حدوث الخطأ بشكل متكرر؟

هذا الرمز لا يؤدي إلى الفشل:

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

هل يمكن أن يترك mod سجلاً في حالة غير محددة؟ لم أتحقق من nrm2.S مرة أخرى ، لكنني أعتقد أنه كان لدينا بضع سنوات من التجميع XORing سجل مع نفسه لمسحه ، والذي قد يفشل في NaN.

بالنسبة لأولئك الذين يتابعون ذلك ، ينتهي الأمر بـ float64 % باستدعاء npy_divmod لكل قيمة.

... وهو في السطر الأول يستدعي npy_fmod() ، وهو fmod () . هذه بعض التغييرات التي حاولت. يعني "خطأ" أنني تلقيت رسالة "قيمة غير قانونية" من OpenBLAS عند تشغيل الرمز الذي يستدعي a % 17; np.linalg.eig(a)
كود | النتيجة
--- | -
mod = npy_fmod@c@(a, b); (الكود الأصلي) | خطأ
mod = 100; //npy_fmod@c@(a, b); | لا خطأ
mod = npy_fmod@c@(a, b); mod = 100.0; | خطأ

لذلك يبدو أن fmod من MSVC يفعل شيئًا يربك OpenBLAS.

هذا مثير للاهتمام وغريب.

هل يمكنك استخدام إصدار ساذج (غير مرفق مع النظام الأساسي) من fmod لمعرفة ما إذا كان هذا قد تم إصلاحه؟

أو فقط فرض HAVE_MODF إلى 0 .

لا أعتقد أن لدينا نسخة ساذجة من fmod ، أليس كذلك؟

أرى أن هناك ماكرو HAVE_MODF ، ولكن إلى أين يقود هذا المسار ؟

يبدو أنه يتراجع إلى الإصدار المزدوج في حالة فقد الطفو والمزدوج الطويل. النسخة المزدوجة إلزامية لبناء numpy. من المحتمل أن يتجنب undef الدوال المضمنة للمترجم ، ISTR التي كانت مشكلة على windows منذ فترة طويلة.

أردت "إثبات" أن المشكلة تكمن في تطبيق fmod ، والذي يأتي من ucrtbase.dll . لذلك كتبت القليل من العمل البديل الذي يستخدم ctypes لسحب الوظيفة من ملف dll واستخدامها مباشرة في استدعاء fmod . الاختبارات لا تزال تفشل. ثم قمت بالتبديل إلى إصدار أقدم من ucrtbase.dll (فقط لوظيفة fmod ). الاختبارات تمر. فتحت موضوعًا في منتدى الاستوديو المرئي . إذا كان أي شخص يعرف طريقة أفضل للوصول إلى Microsoft فسيكون ذلك رائعًا.

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

ماذا لو أضفت بعض الكود بعد استدعاء fmod ، بحيث لا يحتوي ST(0) على nan؟ أو ضبطه على نان صناعيا؟
هل تضع اصطلاحات الاستدعاء بعض القيود على الطريقة التي من المفترض أن تتصرف بها هذه السجلات؟

أردت "إثبات" أن المشكلة تكمن في تطبيق fmod ، والذي يأتي من ucrtbase.dll . لذلك كتبت القليل من العمل البديل الذي يستخدم ctypes لسحب الوظيفة من ملف dll واستخدامها مباشرة في استدعاء fmod . الاختبارات لا تزال تفشل. ثم قمت بالتبديل إلى إصدار أقدم من ucrtbase.dll (فقط لوظيفة fmod ). الاختبارات تمر. فتحت موضوعًا في منتدى الاستوديو المرئي . إذا كان أي شخص يعرف طريقة أفضل للوصول إلى Microsoft فسيكون ذلك رائعًا.

كحد أدنى ، يمكن لأي شخص لديه حساب azure ، والذي ربما يكون العديد من الأشخاص هنا ، التصويت عليه. سأتواصل مع بعض جهات الاتصال التي أجريتها عندما ظهرت هذه المشكلة في الأصل ممن يعملون في Azure ML لمعرفة ما إذا كان بإمكانهم فعل أي شيء.

كحد أدنى ، يمكن لأي شخص لديه حساب azure ، والذي ربما يكون العديد من الأشخاص هنا ، التصويت عليه.

شكرا للنصيحة ، التصويت الايجابي!

لا أعتقد أن لدينا نسخة ساذجة من fmod ، أليس كذلك؟

لا ، إنها وظيفة صعبة تتطلبها مواصفات IEEE-754 للحصول على سلوك معين. كما أنها بطيئة جدًا ، والتي ربما تكون مرتبطة بالمواصفات.

يتم تنفيذ العمل الشاق لـ fmod بواسطة إنشاء fprem x87 ، حتى في متغير VS2019 - راجع جوهر mattip (السطر الأخير) https://gist.github.com/mattip / d9e1f3f88ce77b9fde6a285d585c738e. ( fprem1 هو المتغير remainder بالمناسبة.)

يجب توخي الحذر عند الاستخدام مع سجلات MMX أو SSE - كما هو موضح هنا: https://stackoverflow.com/questions/48332763/where-does-the-xmm-instruction-divsd-store-the-remainder.

تتوفر بعض التطبيقات البديلة كما هو موضح في https://github.com/xianyi/OpenBLAS/issues/2709#issuecomment -702634696. ومع ذلك: كل هذه تحتاج إلى دول مجلس التعاون الخليجي (mingw-w64) من أجل التجميع. لا يقوم OpenLIBM بالتجميع باستخدام MSVC AFAIK. ورمز المجمع المضمن غير مسموح به مع MSVC. من حيث المبدأ ، يمكن للمرء أن يبني (mingw-w64) ويستخدم (MSVC) مكتبة مساعد fmod أثناء البناء غير المتراكم.

ماذا لو أضفت بعض الكود بعد استدعاء fmod ، بحيث لا يحتوي ST (0) على nan؟ أو ضبطه على نان صناعيا؟ هل تضع اصطلاحات الاستدعاء بعض القيود على الطريقة التي من المفترض أن تتصرف بها هذه السجلات؟

أعتقد أنه يمكننا إضافة جزء صغير من التجميع لمسح السجلات قبل الاتصال بـ OpenBLAS على النوافذ. حاولت القيام بذلك في إعداد اختبار صغير ولكن تجميع masm my foo ضعيف. حاولت كتابة إجراء يستدعي fldz عدة مرات ، عند استخدامه أحصل على استثناء. مساعدة؟

.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 ، لقد قمت بإنشاء ملف مجمّع لوظيفة fmod 64 بت التي تنشئ مقطع text: مطابقًا كما هو موجود في الوظيفة fmod المقابلة من mingw-w64 (64 بت). لا توجد فكرة عما إذا كان هذا يعمل كبديل لوظيفة عربات التي تجرها الدواب ، ولكن على الأقل يجب على المرء تجربتها. يمكن إضافة ملف 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 (استخدم متغير 64 بت من 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

تضمين التغريدة سأكون أكثر سعادة مع قطعة من المجمّع تعيد تعيين سجلات ST (N) التي يمكننا استخدامها على x86_64 قبل استدعاء وظائف OpenBLAS. ظهرت هذه المشكلة اليوم بسبب تغيير في fmod ، وغدًا قد تكون وظيفة مختلفة. لست متأكدًا من أن الوظائف مطلوبة لإعادة تعيين تسجيلات ST(N) عند الإرجاع. إذا لم يكن هناك مثل هذا المطلب ، فإن fmod ليس عربات التي تجرها الدواب في الواقع والتغيير في النوافذ كشف عن فشل في OpenBLAS في إعادة تعيين السجلات قبل استخدامها ، يجب علينا إما مساعدتهم في إصلاحها أو حلها.

حاولت إعادة تعيين السجلات باستخدام fldz في التعليق أعلاه لكن برنامج الاختبار الخاص بي لا يعمل.

mattip ، إن https://stackoverflow.com/questions/19892215/free-the-x87-fpu-stack-ia32/33575875

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

أعتقد أنه يمكننا أيضًا استدعاء fninit في بداية OpenBLAS nrm2.S (بعد ماكرو PROFCODE) للتحقق من هذه النظرية

قليلا للاهتمام من
الواجهة الثنائية لتطبيق النظام الخامسملحق معالج معمارية AMD64مسودة الإصدار 0.99.6

_يتم حفظ بتات التحكم في سجل MXCSR (يتم حفظها عبر المكالمات) ، بينما يتم حفظ بتات الحالة بواسطة المتصل (غير محفوظة).

_ يتم حفظ سجل كلمة الحالة x87 بواسطة المتصل ، بينما يتم حفظ كلمة التحكم x87.

_ جميع سجلات x87 محفوظة بواسطة المتصل ، لذلك قد تستخدم callees التي تستخدم سجلات MMX تعليمات femms الأسرع.

مختلف تمامًا عن اصطلاح استدعاء Windows 64 بت.

@ martin-frbg ، fninit أمر خطير: The FPU control word is set to 037FH (round to nearest, all exceptions masked, 64-bit precision). X87 لم تكن الدقة الموسعة كما تريد في جميع الحالات ، خاصة على Windows.

لا أريد هذا لنسخة إصدار ، فقط لاختبار سريع. ما زلت غير مقتنع تمامًا بأن OpenBLAS يجب أن ينظف بطريقة ما "قبل" نفسه ، لكن لا يمكنني العثور على أي وثائق واضحة حول سلوك Windows من خلال x87 fpu القديم. لاحظت أن Agner Fog لديه مستند حول اصطلاحات الاتصال على http://www.agner.org/optimize/calling_conventions.pdf (تبدأ مناقشة معالجة Win64 لسجلات FP في الصفحة 13 ولكنها تركز على التوافر الأساسي والسلوك عبر مفاتيح التبديل).

راجع 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). إذا قمت بذلك ، حظا سعيدا. أو بعبارة أخرى: المستدعي مسؤول عن عدم الأذى.

حسنًا ، يبدو أن هذا يصف سلوك المترجم MSVC على وجه التحديد ، بينما أعتقد أننا في نظام بيئي mingw؟

لا ، يتم تجميع Numpy (Pypi) باستخدام MSVC (Visual Studio 2019) على نظام Windows. بالنسبة لـ OpenBLAS ، يتم استخدام mingw-w64 (بسبب أجزاء فورتران). كما تم تجميع أجزاء Scipy Fortran باستخدام mingw-w64. ومع ذلك ، فإن CPython وامتداداته الثنائية تعتمد بشكل كبير على المعايير التي وضعتها MSVC.

راجع للشغل: كان هذا هو سبب تطوير https://github.com/mingwpy والذي يتم بثه مرة أخرى في الحياة مرة أخرى. (المكونات وقح)

جزء آخر:

يستخدم mingw-w64 (تقريبًا) نفس اصطلاحات الاستدعاء مثل MSVC. الاختلافات الملحوظة الوحيدة هي محاذاة مكدس مختلفة على x86 (32 بت) - ذات الصلة بـ SIMD و vectorcall غير المدعوم.

مثير للإعجاب. x86 لا يتأثر. فقط AMD64.

في الأحد 4 أكتوبر 2020 الساعة 22:19 كتب carlkl [email protected] :

جزء آخر:

يستخدم mingw-w64 (تقريبًا) نفس اصطلاحات الاستدعاء مثل MSVC. الوحيد
الاختلافات الملحوظة هي محاذاة مكدس مختلفة على x86 (32 بت) -
ذات الصلة بـ SIMD والمكالمة الموجهة غير المدعومة.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/numpy/numpy/issues/16744#issuecomment-703317784 ، أو
إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/ABKTSRMFHWZVLDYDFGBM6YDSJDRGTANCNFSM4OP5IXNQ
.

MSVC 32bit لم يتبرأ من fpu ربما؟ سأقوم فقط باستبدال مؤقت لـ fpu-using nrm2.S إما عن طريق nrm2_see2.S (إذا كان قابلاً للتطبيق ، لسوء الحظ ، هناك عدد من إجراءات التجميع غير المستخدمة ولكنها مميتة تطفو في قاعدة الكود) أو إصدار C العادي لنظام التشغيل == ويندوز إذن. (يجب أن تكون المشكلة الأخرى التي تمت مناقشتها هنا شيئًا آخر ، حيث أعتقد أن جميع إجراءات التجميع الأقدم الأخرى لـ x86_64 هي SSE2 على الأقل)

mattip ، ربما تكون المكالمة إلى _fpreset بعد divmod كافية لإعادة التعيين من حالة FPU الفاسدة؟

ربما مكالمة إلى _fpreset

كلا ، فهو لا يعيد ضبط سجلات ST(N) ، ولا يصلح الاختبارات الفاشلة.

هل قمت بتجربة _fninit ؟ يجب أن يؤدي هذا إلى إعادة تعيين مكدس FPU. أو ffree أو fstp بدلاً من fldz كما هو مذكور في https://stackoverflow.com/questions/19892215/free-the-x87-fpu-stack-ia32/33575875 ؟

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

سأحاول لحسن الحظ أوامر المجمع ، لكن المشروع التجريبي في التعليق أعلاه يتعطل. يحتاج شخص ما إلى تصحيح الكود الخاص بي لجعله يعمل (في الواقع ، يبدو fninit مرشحًا جيدًا) ، ثم يمكنني إرسال تعليمات المجمع لإعادة ضبط السجلات في NumPy قبل الاتصال بـ OpenBLAS.

شيء من هذا القبيل؟

.code
reset_fpu proc
    finit
    fldz
reset_fpu endp
end

finit ist wait بالإضافة إلى fninit . لست متأكدًا من الحاجة إلى fldz بعد fninit .

كما قلت في التعليق ، هناك شيء مفقود لجعل الاتصال برمز التجميع المترجم يعمل بشكل صحيح. هذا إلى حد كبير ما كان لدي في ذلك التعليق. تعطل الرمز مع exited with code -2147483645 . يرجى إلقاء نظرة على الكود الكامل ومعرفة ما إذا كان يمكنك جعله يعمل.

يمكنني تجربته (غدا). ومع ذلك ، قد تكون هذه المقتطفات مفيدة:

https://www.website.masmforum.com/tutorials/fptute/fpuchap4.htm
(واحد من أكثر المواقع قراءة حول هذه المواضيع التي وجدتها)

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. 

كما أفهم ، يمكن لـ fldz segfault إذا كان st (7) قيد الاستخدام ، لذلك:

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

آسف أنا لا أوضح نفسي. لا تكمن المشكلة المباشرة في أي مكالمات المجمّع يجب إجراؤها. تكمن المشكلة الفورية في كيفية إنشاء إجراء قابل للاستدعاء بشكل صحيح بطريقة يمكننا استخدامها ، وإثبات ذلك في ملفين ( *.asm و main.c / main.cpp ) المشروع الذي يجمع ويدير. بمجرد أن نحصل على ذلك ، يمكنني الاستمرار في استكشاف المكالمات المختلفة وكيف تؤثر على OpenBLAS.

@ ماتيب ، أفهم. سأحاول بالتأكيد ، لكن هذا قد يستغرق وقته.

لدي انطباع بأن السلوك السيئ لـ fmod في UCRT يجب أن يتم معالجته بواسطة OpenBLAS: https://github.com/xianyi/OpenBLAS/pull/2882 وليس بواسطة numpy لأن numpy لا يستخدم FPU على WIN64. وبالطبع يجب على MS إصلاح هذه المشكلة باستخدام تصحيح Windows.
سيكون التصحيح numpy في هذه الحالة هو ضمان استخدام إصدار OpenBLAS أثناء إنشاء ليس أقدم من إصدار OpenBLAS القادم.

matti يوجد فحص سلامة في numpy/__init__.py . هل هناك اختبار بسيط وموثوق يمكننا إضافته لاكتشاف هذه المشكلة؟

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

mattip ، شكرًا لك على المقتطف. لكنني سأحتاج إلى بعض الوقت للوصول إلى سطح مكتب حيث سأتمكن من إجراء هذا النوع من الاختبارات. في الوقت الحالي ، أعمل معظم الوقت باستخدام جهاز كمبيوتر محمول مع الحد الأدنى من بيئة البرمجة حيث لا يمكنني تثبيت أي شيء تقريبًا.

لقد دمجنا تحديثًا لـ OpenBLAS v0.3.12 ونسخة محلية باستخدام هذا الإصدار + تحديث windows 2004 يجتاز مجموعة الاختبار.

ترك هذا مفتوحًا حتى يتم تحديث Windows.

هل تم تصنيع عجلات ما قبل الإصدار باستخدام OpenBLAS الجديد؟ يسعدني إجراء بعض الاختبارات الإضافية مع المشاريع النهائية التي كانت تعاني من هذا الخطأ.

عجلات Windows 3.9 ما قبل الإصدار مفقودة حاليًا بسبب وجود أخطاء اختبار (تم إصلاحها الآن). سيتم استخدام المكتبة الثابتة في 1.19.3 التي تصدر اليوم أو غدًا.

يتيح الخيار /MT الربط الثابت على Windows. قد يكون من الممكن الربط بشكل ثابت مع libucrt.lib باستخدام إصدار 1909 من Microsoft SDK. قد يكون هذا بمثابة حل بديل لخلل ucrtbase.dll في عامي 2004 و 20H2. سيجعل العجلات أكبر ، وهذا جانب سلبي.

ليس لدي أي فكرة عما إذا كانت مشكلة MT هذه لا تزال سارية ، ولكن ينبغي النظر فيها.

أعتقد أنه إذا كانت NumPy هي الوحدة الوحيدة التي يتم إنشاؤها باستخدام MT ، فقد تكون كذلك
حسنا. بالطبع ، قد يكون الأمر كذلك إذا كان NumPy هو MT ثم أي شيء
سيحتاج المصب أيضًا إلى MT ، وبالتالي ستكون هذه مشكلة.

في الإثنين 2 نوفمبر 2020 ، الساعة 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
.

أي حلول موصى بها لهذه المشكلة؟ وضعي هو أنني على جهاز تم تحديثه إلى تحديث 2004 ، ولدي برنامج سطح مكتب يستخدم pip لتثبيت numpy / scipy / pandas وما إلى ذلك. تتأثر جميع هذه البرامج بهذه المشكلة الناتجة عن تحديث Microsoft.

سيكون موضع تقدير أي توصيات ، لأن استخدام conda لتثبيت numpy ليس خيارًا للبرنامج الذي أعمل عليه.

إذا لم تكن بحاجة إلى عامل إرساء ، فيمكنك تثبيت 1.19.3. يجتاز جميع الاختبارات على أنظمة Windows الخاصة بي.

شكر. 1.19.3 يعمل بالنقطة على القضية.

يؤدي الارتباط الموجود في اكتشاف BLAS السيئ إلى نشر الكثير من المشاركات المزعجة على موقع MS. آمل ألا ينتهي الأمر بالتفجير.

أفترض أن هناك بديلًا آخر وهو استخدام fmod لجهة خارجية على Win64.

أتساءل ماذا سيكون الرد إذا كان NumPy يعاني من خلل غير ثابت بهذه الخطورة لمدة أربعة أشهر بعد الإصدار ، خاصة إذا لم نقدم تعليمات واضحة للمستخدمين للرجوع إلى الإصدار السابق. يمكن للمستخدمين التثبيت بسهولة على 1.19.3 ، لكن هذا لن يحل المشكلة ، بل سينقلها فقط إلى حزمة أخرى تستخدم السجلات بعد أن يتم العبث بها: ربما scipy ، وربما tensorflow.

فكرة أخرى لحل بديل: معرفة ما إذا كانت هناك أي وظيفة أخرى في ucrt تستخدم FPU وتترك حالتها في حالة جيدة. إذا كان هناك واحد ، فيمكننا تسميته بعد fmod. سيكون لهذا ميزة على حل التجميع الذي كتبه mattip لأنه لن يحتاج إلى أي ملفات خاصة أو عملية بناء.

لا أعتقد أننا يجب أن نستثمر المزيد من الجهد لحل هذه المشكلة. سيستغرق أي عمل إضافي نقوم به للتخفيف من المشكلة وقتًا ثمينًا للمطور ويقلل الضغط على Microsoft لإصلاح ذلك. أيضًا ، كما هو مذكور أعلاه ، فإن أي رمز في مشاريع أخرى تستدعي fmod و / أو يستخدم المسجلات قد يواجه هذه المشكلة دون اتصال بـ NumPy.

لا أعتقد أننا يجب أن نستثمر المزيد من الجهد لحل هذه المشكلة. سيستغرق أي عمل إضافي نقوم به للتخفيف من المشكلة وقتًا ثمينًا للمطور ويقلل الضغط على Microsoft لإصلاح ذلك. أيضًا ، كما هو مذكور أعلاه ، فإن أي رمز في مشاريع أخرى تستدعي fmod و / أو يستخدم المسجلات قد يواجه هذه المشكلة دون اتصال بـ NumPy.

بعد رؤية رد الفعل على رسالة الخطأ ، من الواضح أنه ليس مفيدًا للغاية. يجب ، على سبيل المثال ، أن يقترح على مستخدمي Windows الذين يرغبون في استخدام أحدث ميزات NumPy استخدام التوزيع الذي يأتي مع MKL بدلاً من عجلة الأنابيب. يجب أن يتضمن أيضًا ارتباطًا لهذا الموضوع.

بينما من الواضح أن هذه مسؤولية MS للإصلاح ، إلا أن التسبب في الألم للمستخدمين للإشارة إلى خطأ شخص آخر نادرًا ما يكون طريقة جيدة لأي مشروع للحفاظ على حسن النية.

bashtage لست متأكدًا تمامًا مما

لست متأكدًا تمامًا مما تقصده بشأن التسبب في الألم.

فشل استيراد NumPy بشكل مذهل ولا يوجد حل بديل متوفر. سيكون من المفيد لمعظم المستخدمين أن تكون قائمة الحلول المعروفة مرئية بوضوح:

(أ) استخدام توزيع قائم على MKL مثل Conda أو En Thinkt Deployment Manager والذي يتجنب ذلك ولكن في كود الجبر الخطي
(ب) ارجع إلى NumPy 1.19.3 الذي يأتي مع إصدار OpenBLAS محمي من الخطأ. قد لا يكون هذا الخيار مناسبًا للمستخدمين الذين يعملون في الحاويات.
(ج) البناء من المصدر. سيشتمل هذا الخيار على BLAS منخفض الأداء ، ولكنه قد يكون مناسبًا في البيئات التي لا يُسمح فيها بالتوزيع من قِبل طرف ثالث ويتم استخدام الحاويات أو يلزم وجود ميزة حديثة أو إصلاح أخطاء في NumPy.

لا أعتقد أنه من الخطأ لفت الانتباه إلى خطأ fmod ، ولكن بعد ذلك يرسل المستخدمين إلى هذا المنتدى كما لو كان هناك بعض الحلول في انتظارهم.

يمكننا إزالة الرابط وجعل المستخدمين يهبطون هنا بدلاً من ذلك ، ولكن يجب أن نحذر المستخدمين من أنه عند تشغيلهم في عام 2004 ، لا يمكن الوثوق بالنتائج ، وإذا كنت لا تثق في نتائج الحساب ، فيجب عليك تجنب الحساب على هذا النظام الأساسي.

هذا ليس خيارا. يحتاج المستخدمون فقط إلى تجنب NumPy + OpenBLAS (مثل 0.3.12). لا يحتاجون إلى تجنب NumPy + Windows (2004/20H2 (هناك الآن إصداران تم إصدارهما متأثران)).

التوزيع القائم على MKL

كان هناك تقرير عن مشاكل مع MKL أيضًا.

ارجع إلى NumPy 1.19.3

لكن هذا لن يحل المشاكل المحتملة الأخرى الناتجة عن استخدام fmod. المشكلة هي أنه لا توجد طريقة للتأكد من صحة النتائج.

يجب ألا يستخدم الناس بايثون في عام 2004 ، ربما يستخدمون WSL بدلاً من ذلك؟ سأكون موافقًا أيضًا على تضمين ucrt أقدم مع عجلات النوافذ إذا كان ذلك ممكنًا ، ولكن ماذا عن المشاريع الأخرى؟ هل هناك طريقة سهلة للعودة إلى إصدارات Windows السابقة؟

كان هناك تقرير عن مشاكل مع MKL أيضًا.

ليس لدى NumPy اختبار يفشل في MKL. يبدو من الصعب افتراض وجود مشكلة في حالة عدم الإبلاغ عن أي إخفاقات. لا يظهر خطأ fmod في BLAS الخاص بـ MKL (على الأرجح لأنه لا يستخدم FPU).

لكن هذا لن يحل المشاكل المحتملة الأخرى الناتجة عن استخدام fmod. المشكلة هي أنه لا توجد طريقة للتأكد من صحة النتائج.

لا ، ولكنه أيضًا لن يصلح مشكلات أمان Windows أو العديد من الأخطاء الأخرى. القضية هنا خاصة جدا

1. fmod جيد لأنه ينتج عنه نتائج صحيحة
2. يجب أن يكون لديك كود مكتوب في المجمع لمواجهة هذه المشكلة لأن مترجم النظام لن ينتج كود x87.

يقترح هذان الاثنان لي أن المشكلة صعبة للغاية للوصول إلى جميع الرموز تقريبًا. فقط أعلى كود أداء مثل OpenBLAS أو مكتبات FFT التي تحتوي على نواة مكتوبة بخط اليد أو MKL من المحتمل أن تقوم بتشغيل # 2.

أعتقد أيضًا أنه من المعقول إصدار الإصلاح لأنه إذا عمل OpenBLAS 0.3.12 كما هو متوقع ، فسيتم إصدار NumPy ولن يتم طرح هذه المشكلة للمستخدمين أبدًا.

يجب ألا يستخدم الناس بايثون في عام 2004 ، ربما يستخدمون WSL بدلاً من ذلك؟ سأكون موافقًا أيضًا على تضمين ucrt أقدم مع عجلات النوافذ إذا كان ذلك ممكنًا ، ولكن ماذا عن المشاريع الأخرى؟ هل هناك طريقة سهلة للعودة إلى إصدارات Windows السابقة؟

أظن أن هذا ليس خيارًا للعديد من المستخدمين حقًا: مستخدمو الشركات على سطح مكتب المؤسسة ، أو الطلاب المبتدئين (الذين يجب أن يستخدموا conda) ، أو أي شخص اشترى كمبيوترًا محمولًا مع 2004 أو 20H2 ولا يمكنه الرجوع إلى إصدار أقدم.

لاحظ أنه ليس فقط Condas numpy مرتبطًا بـ MLK ، بل إنه يشحن بالفعل نسخته الخاصة من ucrtbase.dll التي تبدو نسخة أقدم (10.0.17134.12)

أتفق إلى حد كبير مع bashtage هنا ،

jenshnielsen : لاحظ أنه ليس فقط أن Condas numpy مرتبطة ضد MLK [...]

تسمح البنيات التي تم حزمها بواسطة conda-forge بتبديل تنفيذ blas / lapack (من openblas / mkl / blis / netlib) ، لا يجب أن تكون MKL.

يجب ألا يستخدم الناس بايثون في عام 2004 ، ربما يستخدمون WSL بدلاً من ذلك؟

ليس هذا هو الوضع الافتراضي للعمليات لمعظم المستخدمين.

سأكون موافقًا أيضًا على تضمين ucrt أقدم مع عجلات النوافذ إذا كان ذلك ممكنًا ، ولكن ماذا عن المشاريع الأخرى؟

مشاريع أخرى ليست مسؤوليتنا.

هل هناك طريقة سهلة للعودة إلى إصدارات Windows السابقة؟

إذا أجريت تثبيتًا جديدًا أو قمت بتنظيف مساحة القرص لديك ، فسيصبح من المستحيل تقريبًا القيام بذلك.

أتفق إلى حد كبير مع bashtage هنا ،

أنا موافق. قد ينتهي بنا الأمر بفقدان الكثير من المستخدمين إذا لم نصلح ذلك.

سأكون موافقًا أيضًا على تضمين ucrt أقدم مع عجلات النوافذ إذا كان ذلك ممكنًا ، ولكن ماذا عن المشاريع الأخرى؟

charris ، لن يساعد هذا في Windows 10. إذا قمت بنشر ملف ucrt مختلف إلى جانب python أو numpy ، فلن يتم تحميله مطلقًا على Windows 10. هذه الطريقة تنطبق فقط على إصدارات Windows الأقدم (Windows 7 ، 8 ، 8.1).

تضمين التغريدة
الثعبان المعبأة كوندا فعلا يتدخل نفسها في قرار مسار البحث DLL (الذي - دون تغيير - من المفترض أن تكون السبب أقول لكم ما في وسعها العمل على ويندوز 10 أبدا)، وهذا هو AFAICT أيضا السبب كوندا _does_ توفير ucrtbase.dll ، كما كتب jenshnielsen .

@ h-vetinari ، يوضح نشر Universal CRT بوضوح ما يلي:

_هناك نوعان من القيود على النشر المحلي يجب أن تكون على دراية بما يلي:
في نظام التشغيل Windows 10 ، يتم دائمًا استخدام Universal CRT في دليل النظام ، حتى إذا تضمن أحد التطبيقات نسخة محلية للتطبيق من Universal CRT. هذا صحيح حتى عندما تكون النسخة المحلية أحدث ، لأن Universal CRT هو أحد مكونات نظام التشغيل الأساسي على Windows 10._

راجع للشغل: اختبرت ذلك بنفسي. لا توجد طريقة لتحميل UCRT آخر من UCRT المتاح المنتشر مع Windows 10.

أعتقد أيضًا أنه من المعقول إصدار الإصلاح

من هذا أعتقد أنك تقصد إضافة PR gh-17547؟

دليل على نقطة carlkl :

يجب تسمية هذا الخطأ الناجم عن مرض التصلب العصبي المتعدد نفسه باسم

من هذا أعتقد أنك تقصد إضافة PR gh-17547 ؟

آسف ، لقد كتبت الشيء الخطأ.

التغيير الوحيد الذي أقترحه هو أن NumPy يوفر مزيدًا من المعلومات في الاستثناء الذي أثير عند الاستيراد والذي يقترح طرقًا يمكن للمستخدم من خلالها الحصول على بيئة على Windows 2004 / H2 تسمح له بمتابعة وظيفته / مدرسته / هوايته.

1. WSL
2. كوندا / تحمس
3. 1.19.3
4. بناء من المصدر

[هذا الترتيب هو المفضل لدي فيما يتعلق بجودة الحل]

أعتقد أنه سيكون من المنطقي أيضًا ربط هذه المشكلة ، أو بمشكلة أكثر وضوحًا توفر شرحًا أعمق. يمكن أن يكون هذا الرابط الثاني أيضًا لبعض ملاحظات الإصدار في المستندات ، وليس مشكلة جيثب.

تسمح البنيات التي تم حزمها بواسطة conda-forge بتبديل تنفيذ blas / lapack (من openblas / mkl / blis / netlib) ، لا يجب أن تكون MKL.

@ h-vetinari هل يبني Conda-forge + OpenBLAS اختبارات النجاح في 2004 / H2؟

لقد قمت للتو بفحص السفن OpenBlas 0.3.12. هل هذا تحطم الحاويات بعد ذلك؟

من المفترض أن يساعد استخدام طريقة شفاء حالة FPU مع التعليمات EMMS في OpenBLAS-0.3.12 بالطبع في تنظيف الاختبارات المعقدة والخادعة ، ولكن كما ذكر charris استدعاء fmod(0,x) in يمكن أن تحدث تعليمات CPython ثم FPU التي تم استدعاؤها لاحقًا (في حزمة مختلفة عن OpenBLAS) أيضًا. في هذه الحالة يتم نقل المشكلة فقط إلى مكان آخر.

أفضل رهان هو إجبار MS على تصحيح سلوك عربات التي تجرها الدواب. ربما يمكن أن يساعد ستيف داور؟

يمكن أن تكون هذه أيضًا قصة مثيرة للاهتمام لـ Agner Fog أو ربما Bruce Dawson: انظر أي هذه القصة ذات الصلة في مدونته:
كل شيء قديم جديد مرة أخرى ، وخطأ في المترجم

ربما الخطأ في OpenBlas 0.3.12. لاحظ عمود وحدات البايت الخاصة:

من المحتمل أن يكون هذا افتراضيًا على 24 مؤشر ترابط BLAS لأن لدي 24 وحدة معالجة مركزية منطقية.

هذا هو OpenBLAS 0.3.12 مع NumPy 1.19.2 من conda-Forge.

تعيين $env:OPENBLAS_NUM_THREADS=1 يؤدي إلى انخفاض كبير

ومع مواضيع $env:OPENBLAS_NUM_THREADS=4 :

bashtage : هل يمكنك الاستمرار في مناقشة OpenBLAS 0.3.12 في OpenBLAS xianyi / OpenBLAS # 2970؟

mattip كنت أحاول تحديد ما إذا كان conda + OpenBLAS بديلاً موثوقًا به. لا أعتقد أنه يحل أي شيء يحله 1.19.3 بعد رؤية هذه النتائج.

bashtage : إثبات نقطة carlkl :

نظرًا لأن python المعبأ بنظام conda يتحايل بنشاط على دقة DLL القياسية لـ windows ، فأنا لست متأكدًا من مقدار الإثبات الذي ستكون عليه أداة Windows. لقد واجهت هذه المشكلة على سبيل المثال مع libcrypto.dll في C:\Windows\System32 ، راجع على سبيل المثال https://github.com/conda-forge/staged-recipes/pull/11452. باختصار ، لم يتم انتقاء مكتبة النظام القديمة إلا بفشل اختبار في مجموعة الاختبار cryptography ، وبعد ذلك - باستخدام CONDA_DLL_SEARCH_MODIFICATION_ENABLE - يمكن فرض استخدام openssl المقدم من conda.

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 : لقد راجعت للتو سفن OpenBlas وكوندا فورج 0.3.12. هل هذا تحطم الحاويات بعد ذلك؟

لا يتم شحن conda-forge مع أي إصدار openblas ثابت - يمكن حتى أن يتم "hotswapped" إصدار blas (على سبيل المثال بين openblas و mkl و blis) ، وبالتالي فإن الإصدار ليس كبيرًا. بشكل عام ، على الرغم من أنه سيستخدم أحدث إصدار معبأ. لا يمكنني التحقق مما إذا كان العطل يتكرر أم لا داخل الحاويات.

bashtage :: mattip كنت أحاول تحديد ما إذا كان conda + OpenBLAS بديلاً موثوقًا به. لا أعتقد أنه يحل أي شيء يحله 1.19.3 بعد رؤية هذه النتائج.

كانت زيادة الذاكرة بسبب تغيير في openblas 0.3.12 ، كما تمت مناقشته بمزيد من التفصيل في xianyi / OpenBLAS # 2970. حتى الآن ، تبدو Conda-Forge بديلاً موثوقًا به - على الأقل لا تتأثر مباشرة بالخطأ.

** لقد استخدمت المعلم الحالي لـ https://github.com/conda-forge/numpy-feedstock ، والذي لا يزال على 1.19.2 ، إلى جانب openblas 0.3.12. يمكنني أيضًا تجربة https://github.com/conda-forge/numpy-feedstock/pull/210 + openblas 0.3.12 ، إذا كان الأشخاص مهتمين.

في الأخبار السارة ، عادت MS إلى منتدى VS واقترحت أن الإصلاح قد ينتهي بحلول نهاية يناير 2021. بالنظر إلى هذا التحديث ، أعتقد أن السؤال الوحيد هو ما إذا كانت هناك أي قيمة في تحديث رسالة الخطأ التي تظهر عند تم الكشف عن وظيفة عربات التي تجرها الدواب.

نظرًا لأن python المعبأ بنظام conda يتحايل بنشاط على دقة DLL القياسية لـ windows ، فأنا لست متأكدًا من مقدار الإثبات الذي ستكون عليه أداة Windows. لقد واجهت هذه المشكلة على سبيل المثال مع libcrypto.dll في C:\Windows\System32 ، انظر على سبيل المثال conda-forge / staged-recipes # 11452 . باختصار ، لم يتم انتقاء مكتبة النظام القديمة إلا بفشل اختبار في مجموعة الاختبار cryptography ، وبعد ذلك - باستخدام CONDA_DLL_SEARCH_MODIFICATION_ENABLE - يمكن فرض استخدام openssl المقدم من conda.

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 القديم ، يتم استخدام وظيفة عربات التي تجرها الدواب من مكتبة ucrt DLL الحالية.

فقط openblas = 0.3.12 من conda forge ستجتاز الاختبارات ، لكن هذا هو نفسه الذي تم شحنه في NumPy 1.19.3.

ما الذي يتحدث ضد إصدار جديد تم تجميعه باستخدام OpenBLAS-0.3.12 غير نشط؟ تقليل التخزين المؤقت وربما تقليل عدد الخيوط في وقت التحويل البرمجي لـ OpenBLAS المستخدم في numpy. هذا من شأنه أن يقلل من استهلاك الذاكرة لـ OpenBLAS ويجب أن يساعد ليس فقط في اختبار Docker ولكن أيضًا المستخدمين الأقل تجهيزًا
مربعات النوافذ.

هنا من https://tinyurl.com/y3dm3h86 تقرير الخطأ من داخل Python. أولاً ، شكرًا لك على توفير إصدار يعمل على Windows حاليًا (1.19.3).

أفهم أن 1.19.3 لا يعمل على Linux وأن 1.19.4 لا يعمل على Windows (بينما يحتوي على الخطأ).

هل سيكون من الممكن عمل أحدث إصدار على pypi 1.19.3 لنظام التشغيل Windows و 1.19.4 لجميع الأنظمة الأساسية الأخرى؟ بمعنى آخر ، ما عليك سوى حذف https://files.pythonhosted.org/packages/33/26/c448c5203823d744b7e71b81c2b6dcbcd4bff972897ce989b437ee836b2b/numpy-1.19.4-cp36-cp36m-win_amd64.whl (بالكامل) الى الان؟

luciansmith طالما كان المصدر متاحًا لـ 1.19.4 نقطة ، فستحاول استخدام هذا الإصدار ما لم يتم تمرير إشارات إضافية. أعتقد أن معظم المستخدمين سيمررون إشارات إضافية فقط إذا عرفوا المشكلة ، ولكن بعد ذلك يمكنهم فقط تثبيت 1.19.3.

أفضل أن يكون لدي 1.19.5 يستخدم OpenBLAS 0.3.9 على Linux و 0.3.12 على Windows ، لكني لا أعرف ما إذا كان هذا ممكنًا.