Numpy: 2004 में विंडोज 10 अपडेट के बाद पॉलीफिट और ईग रिग्रेशन परीक्षण विफल हो जाते हैं

संपादित करें: आप स्पष्ट रूप से पिप का उपयोग कर रहे हैं। हाल ही में रैखिक बीजगणित पुस्तकालयों और आइजनवेल्यू डीकंपोज़िशन (स्टैटस्मोडेल के लिए रनिंग टेस्ट के संदर्भ में) के साथ विंडोज एएमडी 64 पर भी एक अजीब परिणाम आया है।

यदि आपके पास समय है, तो 32 बिट पायथन और पाइप का उपयोग करने का प्रयास करें और देखें कि क्या आपको समान मुद्दे मिलते हैं? मैं उन्हें 32-बिट विंडो पर नहीं देख सकता था लेकिन वे 64-बिट विंडो पर दोहराए जा सकते थे।

अगर मैं MKL का उपयोग करता हूं, तो मेरे पास त्रुटियाँ नहीं हैं।

संपादित करें: मैं भी विंडोज AMD64 पर NumPy 1.18.5 का उपयोग करते समय उन्हें देखता हूं।

नवीनतम Windows 10 अद्यतन के बाद परीक्षण विफल हो जाते हैं

क्या अद्यतन से पहले परीक्षण विफल हो रहे थे?

नहीं @charris , अद्यतन से पहले परीक्षण सूट बस गुजरता है।

@speixoto क्या आप जानते हैं कि यह विशेष रूप से कौन सा अपडेट है? मुझे यह देखने में दिलचस्पी होगी कि क्या यह पाइप-स्थापित पहियों के साथ मेरे मुद्दे को हल करता है।

अपडेट 1809 (10.0.17763) कोई भी असफल परीक्षण @bashtage नहीं कर रहा था

1909 भी कुछ भी पैदा नहीं कर रहा था। यह केवल 2004 के साथ होने लगा।

मैं 100% आश्वस्त नहीं हूँ कि यह 2004 या उसके बाद का है। मुझे लगता है कि 2004 ने काम किया।

FWIW मैं CI (Azure या appveyor) पर इन दुर्घटनाओं को पुन: उत्पन्न नहीं कर सकता, लेकिन मैं इसे स्थानीय रूप से 2 मशीनों पर करता हूं जो AMD64 दोनों हैं और 2004 को अपडेट करते हैं।

क्या आपने या तो यह देखने की कोशिश की है कि क्या आप उन्हें 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, और स्कैपी 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 का उपयोग करता हूं तो मुझे कोई त्रुटि नहीं मिलती है। यह कहना मुश्किल है कि क्या यह संभावना है कि ओपनब्लस बग या विंडोज बग। संभवतः उत्तरार्द्ध, लेकिन इसे प्राप्त करना वास्तव में कठिन होगा और निदान करना निम्न-स्तरीय डिबगिंग के लिए मेरी क्षमताओं से परे है।

उसी भौतिक मशीन पर, जब मैं उबंटू में रन करता हूं तो पाइप पैकेज का उपयोग करके मुझे कोई त्रुटि नहीं दिखाई देती है।

यह सबसे अजीब व्यवहार है। पहली कॉल पर विफल रहता है, दूसरे और बाद में काम करता है। व्यवहार को समझने में एक और मुश्किल यह है कि अगर मैं त्रुटि को नहीं देखता तो मैं अलगाव में फेल हो जाता हूं।

एक अंतिम अद्यतन: यदि मैं अनुकूलित BLAS के बिना NumPy के स्रोत निर्माण का उपयोग करके परीक्षण करता हूं तो मुझे अभी भी त्रुटियां दिखाई देती हैं, हालांकि वे एक समान सेट नहीं हैं।

शायद OpenBLAS देवों को पिंग करने लायक। क्या यह फ्लोट 32 के साथ अक्सर फ्लोट 64 के साथ होता है?

जब मैं NumPy 1.19.0, python -c "import numpy;numpy.test('full')" का पूर्ण परीक्षण चलाता हूं तो मुझे ऊपर की तरह त्रुटियां दिखाई देती हैं:

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

मुझे लगता है कि अगर आप केवल विशेष रूप से परीक्षण चलाते हैं तो यह पास होना चाहिए अगर मुझे सही तरीके से चीजों को पिंग करने से याद है ताकि इसका अर्थ और भी अजीब व्यवहार हो।

मैंने Microsoft के साथ एक ही तरीका दायर किया है जो मुझे पता है कि कैसे:

https://aka.ms/AA8xe7q

दूसरों को खोज के माध्यम से खोजने के मामले में पोस्टिंग:

यदि इसका हल नहीं किया जाता है, तो विंडोज उपयोगकर्ताओं को कॉनडा / एमकेएल का उपयोग 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
DORGHR
DHSEQR

यह एक OpenBlas मुद्दा (या 2004 और OpenBLAS के बीच कुछ) की तरह लग रहा है। यहाँ मेरा सारांश है:

NumPy केवल python -c "import numpy;numpy.test('full')"

• कोई अनुकूलित BLAS नहीं: पूरा पास
• OpenBLAS: असफल पूर्ण
• MKL: पूरा पास

स्टैटमॉडल परीक्षण pytest statsmodels

• Pip NumPy और SciPy: SVD और QR संबंधित कोड से संबंधित विफलता
• MKL NumPy और SciPy: पास
• कोई अनुकूलित BLAS नहीं: विफल , लेकिन कम है कि सभी में scipy.linalg रूटीन शामिल हैं, जो OpenBLAS का उपयोग करते हैं।
• कोई अनुकूलित BLAS, कोई विज्ञान नहीं linalg: पास

यह जानना अच्छा होगा कि 2004 में क्या बदल गया। लाइब्रेरी को संकलित / लिंक करते समय शायद हमें एक अलग ध्वज की आवश्यकता होगी?

_If_ यह एक OpenBLAS बग है, यह संभावना नहीं है कि उन्होंने इसे देखा होगा क्योंकि विंडोज-आधारित सीआई में से कोई भी 19041 (उर्फ विंडोज 10 2004) या बाद के बिल्ड का उपयोग नहीं कर रहा है।

बस स्पष्ट होने के लिए, यह सच है कि इनमें से किसी भी रिपोर्ट में डब्ल्यूएसएल शामिल नहीं है?

नहीं, सभी के साथ कोंडा-प्रदान python.exe या python.org ने python.exe

क्या परीक्षण विफल हो जाता है यदि पर्यावरण चर OPENBLAS_CORETYPE=Haswell या OPENBLAS_CORETYPE=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 बिना किसी समस्या के कार्य में परिवर्तित होता है।

कोड के पायथन भागों को लंबे पूर्णांकों के साथ संकलित किया गया है, लेकिन फोर्ट्रान (लैपैक) भागों में INTERFACE64 = 1 के बिना बनाया गया OpenBLAS?
(यह अभी भी यह स्पष्ट नहीं करेगा कि पहली कॉल विफल क्यों होती है लेकिन बाद में कोई भी सफल होता है, और न ही यह 19041 से पहले क्यों काम किया)

विंडोज 10 उपयोगकर्ता माइक्रोसॉफ्ट के फीडबैक हब में इस मुद्दे को बढ़ा सकते हैं।

https://aka.ms/AA8xe7q

@Bashtage के अनुरोध पर, मैंने कोड को थोड़ा खोदा है, और मेरा अनुमान है कि फ्लोटिंग पॉइंट स्टेट का कुछ पहलू अब प्रवेश पर अलग है। इससे इसकी पुष्टि होती प्रतीत होगी:

np.complex128 में कनवर्ट करना भी बढ़ जाता है, जबकि np.float32 या np.complex64 में कनवर्ट करना दोनों समस्या के बिना काम करते हैं।

पहला चेतावनी संदेश (जो सफल होने पर प्रकट नहीं होता है) "DGEBAL पैरामीटर संख्या 3 के प्रवेश पर एक गैरकानूनी मूल्य था" इस शर्त के कारण होता है https://github.com/xianyi/OpenBLAS/blob/ce36515ff12079f3ca2418aa85b9ad571c3a391/lapackack -नेटलिब / एसआरसी / dgebal.f # L336 जो NaN में जाने वाले किसी भी पूर्व गणना के कारण हो सकता है।

रेप्रो चरणों के साथ खेलते हुए, मैंने पाया कि फ्लोट 32 के रूप में मॉड करना "इसे" ठीक करता है:

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)

तो मेरा अनुमान है कि उस कोड पथ में कुछ है जो राज्य को ठीक से रीसेट कर रहा है, हालांकि मुझे यकीन नहीं है कि यह क्या है। उम्मीद है कि कोई और अधिक सुन्न के आंतरिक लोगों से परिचित हो सकता है, जहां यह हो सकता है।

एक पुराने बग की याद दिलाता है जिसे हमने वाइंडोव्स पर मिंगव के साथ देखा था, जहां फ्लोटिंग पॉइंट रजिस्टर कॉन्फ़िगरेशन वर्कर थ्रेड्स द्वारा विरासत में नहीं मिला था, जिसके कारण डीनोर्मल शून्य से फ्लश नहीं हो रहे थे और बाद की गणनाओं को गड़बड़ कर रहे थे।
सुनिश्चित नहीं है कि यह किसी भी तरह से वर्तमान हार्डवेयर पर वर्तमान विंडोज के लिए प्रासंगिक है लेकिन यह जानना दिलचस्प हो सकता है कि क्या आपका
OpenBLAS बिल्ड CONSISTENT_FPCSR = 1 के साथ किया गया था (या यदि वह निर्माण विकल्प जोड़ने में मदद करता है)।

@mattip क्या आप जानते हैं कि

जैसा दिखता है, दुर्भाग्य से:

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

खैर, कम से कम यह तब से बाहर है। कनेक्शन वैसे भी काफी दूरस्थ लग रहा था।

नमस्ते! मैं कुछ समय से इसी तरह की समस्या का सामना कर रहा हूं और मेरे सभी परीक्षण विंडोज़ 10 (2004) और ओपनब्लैस के बीच कुछ गड़बड़ करने के लिए इंगित करते हैं। मैं आमतौर पर 3 पीसी (2 विंडोज 10 वर्कस्टेशन और एक पुराने विंडोज 7 लैपटॉप) पर अपने कार्यक्रम चलाता हूं। मेरी python स्क्रिप्ट ने linalg और svd () से संबंधित त्रुटियों के साथ दुर्व्यवहार करना शुरू कर दिया, जब मैंने अपने 2 वर्कस्टेशन को विंडोज 2004 के संस्करण 10 में अपग्रेड किया। मैंने भी स्क्रिप्ट चलाने के लिए पहली बार क्रैश का अनुभव किया, लेकिन ज्यादातर बार दूसरी कोशिश में काम किया (जुपिटर नोटबुक चलाने)। पुराने लैपटॉप रिग त्रुटियों के बिना एक ही कार्यक्रम चलाते रहे! मेरे पास मिनिकोंडा, पायथन 3.6 है और सभी पैकेज पाइप का उपयोग करके स्थापित किए गए हैं (3 मशीनों पर एनवी बिल्कुल वैसा ही है)।
आज मैं पिप डिफ़ॉल्ट 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 lib.exe के VC9 संस्करण द्वारा बनाया जा रहा है? यह वह संस्करण है जिसका उपयोग पायथन 2.7 के साथ किया गया था। यह बात नहीं हो सकती है, लेकिन यह अजीब लगता है कि VC9 का कहीं भी उपयोग नहीं किया गया है।

किसी के लिए अगला कदम (शायद मेरे लिए) एक सिंगल-थ्रेडेड ओपनबीएएलएस ( USE_THREAD=0 ) के साथ NumPy मास्टर का निर्माण होगा ताकि यह देखा जा सके कि क्या यह समस्याओं को ठीक करता है।

मैंने बिना किसी सफलता के कुछ प्रयोग किए हैं:

• धागे को USE_THREADS=0 अक्षम करें
• ILP64 INTERFACE64=1 <- एक्सेस उल्लंघन के साथ NumPy के परीक्षण में सिगफॉल्ट

क्या आप उस Win10 सेटअप के साथ LAPACK टेस्टसुइट चला सकते हैं? मैंने हाल ही में इसे बनाने के लिए cmake बिल्ड को ठीक किया था, हो सकता है कि यह बिना किसी सुन्न के कुछ सुराग प्रदान करता हो।

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

इसलिए मुझे यकीन नहीं है कि ये भरोसेमंद हैं।

ऐसा लगता है कि परीक्षण के बहुमत segfaulting हैं, लेकिन जीवित लोग निर्दोष हैं ... यह मेरी अपेक्षा से थोड़ा अधिक चरम पर है।
(COMPLEX और COMPLEX16 स्टैक आकार के मामले में थोड़ी बहुत मांग कर रहे हैं, इसलिए विफलताओं में डिफ़ॉल्ट OS सेटिंग्स के साथ बहुत अधिक संभावना है, लेकिन 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)

मैं वास्तव में यह सोचता हूं कि यह अंक न्यूपे और ओपनबीएलएएस के बीच की स्थिति में है। मैं सोच भी नहीं सकता कि यह व्यवहार कैसे हो सकता है जहां पहली कॉल एक त्रुटि है, लेकिन दूसरी और बाद में सभी ठीक हैं। हालांकि इसे कैसे हल किया जाए (या टीबीएच ने भी गहरे मुद्दे का सटीक निदान किया है) हालांकि ...?

MS प्लेटफ़ॉर्म को समाप्त करें और कभी खुशी से रहें? यदि यह लैपैक परीक्षणों में विफल रहता है तो हैंडऑफ़ की समस्या फोरट्रान (= ओपनब्लस का हिस्सा) और सी, या फोरट्रान और "कुछ और" के बीच है।

मुझे उत्सुकता होगी अगर आईसीक्यू का उपयोग करके ओपनबीएलएएस के साथ नेम्पी का निर्माण संभव है
और ifort तो देखें कि क्या समस्या बनी रहती है। हालांकि यह एक बड़ा सवाल है।

बुध पर, 12 अगस्त, 2020, 19:04 मार्टिन क्रोकेर सूचनाएं @github.com ने लिखा:

MS प्लेटफ़ॉर्म को समाप्त करें और कभी खुशी से रहें? यदि यह विफल रहता है
लैपैक टेस्ट की हैंडऑफ़ समस्या फोरट्रान (= LAPACK भाग) के बीच है
OpenBLAS) और सी, या फोरट्रान और "कुछ और"।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/16744#issuecomment-6730262699 , या
सदस्यता समाप्त
https://github.com/notifications/unsubscribe-auth/ABKTSRLSHZ2XWF4OE7J3QO3SALKSJANCNFSM4OP5IXNQ
।

शायद इंटेल कंपाइलर्स के साथ ओपनब्लस बनाने के लिए पर्याप्त होगा (हालांकि यह हाल ही में सामने आए वीएस के साथ कम से कम समस्याग्रस्त लगता है, और मेरे पास फिलहाल ifc / ifort के लिए वैध लाइसेंस नहीं है।

संभावित संबंधित समस्या:

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

यदि इसका हल नहीं किया जाता है, तो विंडोज उपयोगकर्ताओं को कॉनडा / एमकेएल का उपयोग 2004 तक करना चाहिए

@bashtage आपके सुझाव के लिए धन्यवाद।
मेरे मामले में, मुझे कुछ त्रुटि मिली है जब मैं अंकुश के कोनडा संस्करण को लागू करने के बाद पंडासक्कल द्वारा साइक्लाइट का उपयोग कर रहा हूं।

लेकिन मुझे कोई समस्या नहीं हुई है जब मैं numpy + mkl के इस संस्करण का उपयोग करता

@bashtage ऐसा लगता है कि उस जंग लिंक मुद्दे के लिए एक नया MSVC

FYI करें: संबंधित SciPy समस्या: https://github.com/scipy/scipy/issues/12747

एक रिपोर्ट है कि विंडोज बिल्ड 17763.1397 (अगस्त 11) समस्या को ठीक करता है, # 17082 देखें।

एक रिपोर्ट है कि विंडोज बिल्ड 17763.1397 (अगस्त 11) समस्या को ठीक करता है, # 17082 देखें।

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

बिल्ड 17763.1397 केवल विंडोज 10, संस्करण 1809 के लिए है (इस पर लागू होता है: विंडोज 10, संस्करण 1809, सभी संस्करण विंडोज सर्वर संस्करण 1809 विंडोज सर्वर 2019, सभी संस्करण)।
विंडोज़ 10, संस्करण 1809 के लिए इस मामले में कोई समस्या नहीं है।

यह हाल ही में विंडोज़ 10, 2004 के संस्करण का अपडेट संस्करण है।
https://support.microsoft.com/en-us/help/4566782
11 अगस्त, 2020- KB4566782 (ओएस बिल्ड 19041.450)।

मेरे पास अभी भी विंडोज 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)

मैं OpenBLAS के लैपैक-परीक्षण में (आंशिक) विफलताओं को पुन: उत्पन्न कर सकता हूं - केवल EIG (eigenvalue) परीक्षणों को प्रभावित कर रहा है, जो कि कुछ असामान्य रूप से उच्च स्टैकाइज़ आवश्यकताओं के लिए जाने जाते हैं। वहां SIGSEGV __chkstk_ms_ में होता है जो मुख्य () से पहले भी दर्ज किया जाता है। डिफ़ॉल्ट "स्टैक आरक्षित आकार" और "स्टैक कमेट साइज़" संबंधित निष्पादन के मूल्यों को peflags उपयोगिता के साथ संबंधित (जैसे peflags -x4194304 -X4194304 EIG/xeigtsts.exe ) कार्यक्रमों को सामान्य रूप से काम करता है, यह सुझाव देता है कि सी / फोरट्रान इंटरैक्शन और तर्क इस तरह से गुजर रहा है। समस्याग्रस्त नहीं है। मैंने अभी तक इसे खौफनाक मामले में लागू करने की कोशिश नहीं की है (यह सुनिश्चित करने के लिए भी कि जिसका पेफ्लग सेटिंग वहां समायोजित करने के लिए नहीं है - pththon.exe?) लेकिन OpenBLAS खुद को सामान्य रूप से कार्य करता प्रतीत होता है, जब 19041.450 उर्फ ​​पर gcc 9.1.0 के msys2 mingw64 संस्करण के साथ बनाया गया था 2004

@ मार्टिन-फ़्रॉग जो प्रगति की तरह दिखता है।

विंडोज / MSYS2 पर संख्यात्मक निर्माण के लिए स्थापित सभी निर्भरताओं को प्राप्त करने की कोशिश कर रहा एक खरगोश छेद नीचे चला गया ताकि आगे कोई प्रगति न हो।

@ मार्टिन-एफआरजीबी, एमएसवाई 2 आधारित खस्ता पैकेज को पैक्मैन के साथ स्थापित किया जा सकता है। Msys2 बिल्ड स्क्रिप्ट और पैच यहां उपलब्ध हैं: https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-python-numpy और https://github.com/msys2.MINGW-packages/tree / मास्टर / MinGW-W64-openblas।

एक नवीनतम त्रिभुज बैठक में यह एक अपेक्षाकृत उच्च प्राथमिकता के रूप में सामने आया, और @hameerabbasi और मैं मदद करने के लिए तैयार हैं। हम क्या कर सकते है?

@bashtage आप editbin /STACK:3145728 python.exe साथ स्टैक को बड़ा बनाने का प्रयास कर सकता है

क्या कोई तरीका है जिससे हम अपने द्वारा बनाए गए पुस्तकालयों के OpenBLAS के रिलीज के साथ NumPy बनाने की कोशिश कर सकते हैं? शायद हमारे निर्माण थोड़ा दूर हैं।

यह संभव है कि आपके बिल्ड में 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 सेटअप में कोई त्रुटि नहीं होती है। (जहाँ तक मैं बता सकता हूँ, mingw64 / usr / lib में उनका लिबोपेंब्लास एक सिंगल-थ्रेडेड 0.3.10 हैसवेल के लिए बनाया गया है)

@ martin-frbg क्या MSVC का उपयोग करके OpenBLAS का निर्माण संभव है?

सादा MSVC? उल्लेखनीय है, लेकिन एक खराब रूप से अनुकूलित पुस्तकालय देता है क्योंकि MSVC असेंबली गुठली का समर्थन नहीं करता है - व्यावहारिक रूप से उसी तरह जैसे कि आपने TARGET = GENERIC के लिए OpenBLAS का निर्माण किया।

इसके अलावा, # 16744 (टिप्पणी) से बैशेट का "छोटा पुनरुत्पादन उदाहरण" मेरे msys2 सेटअप में कोई त्रुटि नहीं बढ़ाता है। (जहाँ तक मैं बता सकता हूँ, mingw64 / usr / lib में उनका लिबोपेंब्लास एक सिंगल-थ्रेडेड 0.3.10 हैसवेल के लिए बनाया गया है)

मुझे पूरा यकीन है कि यह NumPy और OpenBLAS के बीच के इंटरफेस के साथ कुछ करना है। NumPy के 32-बिट बिल्ड में भी यह समस्या नहीं है। मैंने जिन Microsoft लोगों से बात की, उनके विचार से यह संभव है कि थ्रेड सिंक्रोनाइज़ेशन समस्या सबसे अधिक प्रशंसनीय हो। यह समझा सकता है कि पहले कॉल में गलत मूल्य कैसे मौजूद है और फिर बाद की कॉल में सही है।

विंडोज / MSYS2 पर संख्यात्मक निर्माण के लिए स्थापित सभी निर्भरताओं को प्राप्त करने की कोशिश कर रहा एक खरगोश छेद नीचे चला गया ताकि आगे कोई प्रगति न हो।

यह एक पीड़ा है। मैंने इसे किया है, लेकिन कुछ प्रयोग करने के लिए इसे स्वचालित करने में काफी समय लग रहा था। इसे मूल रूप से .a फ़ाइलें प्राप्त करने के लिए https://github.com/MacPython/openblas-libbl- से चरणों की प्रतिलिपि बनाने की आवश्यकता होती है, और फिर https://github.com/numpy/numpy/nlob/master/ से चरणों की प्रतिलिपि बनाई जाती है। NumPy बनाने के लिए

DLL बिल्ड प्राप्त करने का सबसे आसान तरीका है, एक ऐपिवर खाता खोलना, और फिर https://github.com/MacPython/openblas-libs को क्लोन करना

Https://github.com/MacPython/openblas-libs को देखते हुए, OpenBLAS INTERFACE64=1 । यह Msys2 बिल्ड OpenBLAS और numpy के मामले में नहीं है।

@carlkl यह समस्या NumPy या OpenBLAS के Msys2 बिल्ड के बारे में नहीं है। यह Win32 / AMD64 बिल्ड के बारे में है जो Msys2 का उपयोग करता है जो फोरट्रान स्रोतों को संकलित करने के लिए गफ़रान प्रदान करता है, लेकिन फिर MS के lib.exe का उपयोग करके संकलित लाइब्रेरी से Win32 DLL बनाता है।

@bashtage मैंने इसका उल्लेख किया, क्योंकि यह बताया गया था कि https://github.com/numpy/numpy/issues/16744#issuecomment -689785607, कि msys2 के बाद segfault दोबारा नहीं बनाया जा सकता। और मुझे लगता है कि उल्लेख किया गया msys2 पर्यावरण में उल्लेख किया गया है कि msys2 में ओपनब्लस और संख्यात्मक बाइनरी पैकेज दिए गए हैं।

मुझे कोई अंदाजा नहीं है, अगर 64 बिट के खंभे को एमएसवीसी के समान ध्वज के साथ संकलित किया गया है या नहीं।

BTW: मैं झंडा रिपॉजिटरी में झंडा -fdefault-integer-8 नहीं पा सकता।
मुझे यकीन नहीं है कि अगर कोड -fdefault-integer-8 के साथ संकलित किया गया है तो ABI इस ध्वज के बिना संकलित कोड के साथ संगत है।

एक और पहलू मेरे दिमाग में आता है: शायद -fdefault-integer-8 को -mcmodel=large के साथ जोड़ दिया जाए।

EDIT: याद रखें: Windows64 में LLP64 मेमोरी मॉडल है, ILP64 नहीं।
LLP64 का अर्थ है: लंबा: 32 बिट, पॉइंटर: 64 बिट

तो, Win10-2004 समस्या का उपयोग करने वाले सुपीरियर बिल्ड किस आकार के पूर्णांक का उपयोग करता है? यह बेहतर मैच था कि ओपनबीएलएएस के लिए क्या बनाया गया था, लेकिन IIRC यह विषय पहले से ही इस धागे में पहले आया था (और एक बेमेल शायद विंडोज पैचलेवल के बावजूद अधिक स्पष्ट टूटना पैदा करेगा)

Https://github.com/MacPython/openblas-libs (appveyor.yml देखें) के साथ कम से कम ओपनब्लास को तीन वेरिएंट में बनाया जा सकता है:

• 32 बिट
• 64 बिट
• INTEGER64 के साथ 64 बिट

लेकिन अगर कोई विचार नहीं है कि विंडोज़ पर सुन्न 64 बिट के लिए क्या उपयोग किया जाता है।

_ और एक बेमेल शायद अधिक स्पष्ट टूटने के लिए नेतृत्व करेंगे भले ही विंडोज पैचलेवेल_

-fdefault-integer-8 केवल लैपैक के फोरट्रान भाग पर लागू होता है। यह अंतर्निहित मेमोरी मॉडल (LLP64) को नहीं बदलता है, इसलिए मुझे यकीन नहीं है कि अगर हमें फोरट्रान लैपैक भागों के बाहर की समस्याओं की उम्मीद करनी चाहिए।

हम्म,

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 के बिना निर्मित हैं।

Pypi.org पर Numpy binaries सभी 32-बिट पूर्णांक ओपनब्लस के साथ निर्मित हैं। https://github.com/MacPython/numpy-wheels/blob/v1.19.x/azure/windows.yml

निर्माण प्रक्रिया के लिए ग्राट्रान बनाम MSVC विवरण, यहां देखें। Microsoft lib.exe Openblas DLL के उत्पादन में शामिल नहीं है, यह सभी मिंगव टूलकिन है। Numpy openblas.a फ़ाइल का उपयोग करता है, और gfortran का उपयोग करके DLL बनाता है। । है कि .lib फ़ाइल का उपयोग करके gfortran-उत्पादित DLL से जुड़ा हुआ है।

एक सैद्धांतिक संभावना जो गलत हो सकती है वह यह है कि मिंगव के बीच किसी प्रकार का मिंगव संस्करण बेमेल है जो स्टैटिक ओपनब्लास.ए आर्टिफ़िकेशन का निर्माण करता है, और मिंगव वर्जन का उपयोग तब किया जाता है जब सुपीह बनाया जाता है। हालांकि, निश्चित नहीं है कि क्या यह संभव है कि यह समस्या पैदा कर सकता है।

choco install -y mingw --forcex86 --force --version=5.3.0 उपयोग windows.yml पुराना प्रतीत होता है। 7.3.0 या 8.1.0 उपयोग क्यों न करें? मैं उन समस्याओं को याद कर सकता हूं जो मैंने दो-तीन साल पहले gcc-5.x के साथ की थीं।

choco install -y mingw --forcex86 --force --version = 5.3.0 windows.yml में उपयोग किया जाता है जो पुराना प्रतीत होता है

यह 32-बिट विंडोज़ के लिए ही निर्मित है, इसलिए शायद इस मुद्दे से संबंधित नहीं है।

अन्य सभी संस्करण ( Python36-64bit-full , Python37-64bit-full ) NPY_USE_BLAS_ILP64 के बिना बनाए गए हैं।

पायथन 3.6 और 3.8 पर समान त्रुटियां।

एक विचार बचा है (मैं अंधेरे में खोद रहा हूँ):

OpenBLAS अब -fno-optimize-sibling-calls साथ संकलित किया गया है, https://github.com/xianyi/OpenBLAS/issues/2154 , https://github.com/xianyi/OpenBLAS/pull/2n7 और https: // gcc देखें .gnu.org / बगजिला / show_bug.cgi? id = 90,329।
संपादित करें: यह भी देखें: https://gcc.gnu.org/legacy-ml/fortran/2019-05/msg00181.html

Numpy ने इस झंडे को अपने गड़बड़ी वाले हिस्से में नहीं लगाया। मुझे पता है कि MSVC के साथ संकरी संकलित है। इसलिए मैं सुन्न के साथ घबराहट के साथ समस्याओं की उम्मीद करता हूं, इसलिए यह फिर से एक गलत यात्रा हो सकती है।

Pypi.org पर Numpy binaries सभी 32-बिट पूर्णांक ओपनब्लस के साथ निर्मित हैं। https://github.com/MacPython/numpy-wheels/blob/v1.19.x/azure/windows.yml

रिलीज़ में उपयोग किए गए से अलग परीक्षण में बिल्ड कॉन्फ़िगरेशन का उपयोग क्यों किया जाता है? यह एक जोखिम जैसा लगता है।

क्या हम एज़्योर बिल्ड की कलाकृतियों को जोड़ सकते हैं? इससे परीक्षण के लिए पहियों को प्राप्त करना बहुत सरल हो जाएगा। यहाँ मेरी एकमात्र चिंता यह है कि मुक्त विरूपण साक्ष्य सीमा बहुत छोटी IIRC, 1GB है, और मुझे नहीं पता कि जब आप इसे मारते हैं तो क्या होता है (FIFO अच्छा होगा, लेकिन त्रुटि सहित अन्य चीजें कर सकते हैं)।

रिलीज़ में उपयोग किए गए से अलग परीक्षण में बिल्ड कॉन्फ़िगरेशन का उपयोग क्यों किया जाता है?

हम सभी समर्थित पायथन संस्करणों को NPY_USE_BLAS_ILP64 बिना विंडोज़ में परीक्षण करते हैं, और NPY_USE_BLAS_ILP64 साथ अजगर 3.8 का परीक्षण करते हैं, https://github.com/numpy/numpy/blob/b1.19.2/azure देखें -pipelines.yml # L195। इसलिए 32-बिट पूर्णांक ओपनब्लस का उपयोग करने में साप्ताहिक बिल्ड सही हैं।

क्या हम एज़्योर बिल्ड की कलाकृतियों को जोड़ सकते हैं?

शायद इसे आज़माने में आसानी हो और अगर यह त्रुटी हो तो सीमा के बारे में पता करें। हालाँकि साप्ताहिक पहिये का उद्देश्य परीक्षण निर्माणों को ईमानदारी से बनाना है। किसी भी विसंगतियों को त्रुटियों और निश्चित के रूप में माना जाना चाहिए।

शायद इसे आज़माने में आसानी हो और अगर यह त्रुटी हो तो सीमा के बारे में पता करें। हालाँकि साप्ताहिक पहिये का उद्देश्य परीक्षण निर्माणों को ईमानदारी से बनाना है। किसी भी विसंगतियों को त्रुटियों और निश्चित के रूप में माना जाना चाहिए।

मैं सोच रहा था कि 2004 में परीक्षण करने के लिए मुख्य रेपो के लिए पीआर में प्रयोग करना और कलाकृतियों को पकड़ना आसान होगा।

समझ में आता है।

आप अपने रेपो बैश्टेज / सुपी में एज़्योर पाइपलाइनों को चालू कर सकते हैं

थोड़ी अधिक जानकारी: पहला कॉल जो विफल रहता है, क्योंकि OpenBLAS के अंदर DNRM2 एक NAN देता है। मेरे लिए, यह दोहराने योग्य है: हर कॉल

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

** On entry to DGEBAL parameter number 3 had an illegal value प्रिंट करता है, जो " DNRM2 वापस नान" कहने का एक और तरीका है। 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 पर विफल होंगे।

साथ आने वालों के लिए, प्रत्येक मूल्य के लिए npy_divmod मंगाने पर % समाप्त होता है।

... जो, पहली पंक्ति में npy_fmod() कॉल करता है , जो a % 17; np.linalg.eig(a) कॉल करने वाले कोड को चलाते समय OpenBLAS से "अवैध मान" संदेश मिलता है
कोड | परिणाम
--- | ---
mod = npy_fmod@c@(a, b); (मूल कोड) | त्रुटि
mod = 100; //npy_fmod@c@(a, b); | कोई त्रुटि नहीं
mod = npy_fmod@c@(a, b); mod = 100.0; | त्रुटि

तो ऐसा लगता है कि MSVC से fmod कुछ ऐसा कर रहा है जो OpenBLAS को भ्रमित करता है।

यह दिलचस्प है, और अजीब है।

क्या आप यह तय करने के लिए fmod के एक भोले (प्लेटफ़ॉर्म आपूर्ति नहीं) संस्करण का उपयोग कर सकते हैं?

या सिर्फ HAVE_MODF से 0 लिए मजबूर करें।

मुझे नहीं लगता कि हमारे पास fmod का एक भोला संस्करण है, क्या हम?

मैं देख रहा हूँ कि एक HAVE_MODF मैक्रो है, लेकिन यह पथ कहाँ जाता है?

Iike लगता है कि यह डबल संस्करण में वापस आता है यदि फ्लोट और लंबे डबल गायब हैं। सुन्न बनाने के लिए डबल संस्करण अनिवार्य है। अपरिभाषित संभवतः संकलक इनलाइन फ़ंक्शंस, ISTR से बचने के लिए है जो कि विंडोज़ पर बहुत पहले एक समस्या थी।

मैं "साबित" करना चाहता था कि समस्या fmod कार्यान्वयन है, जो ucrtbase.dll से आती है। इसलिए मैंने एक छोटा सा काम लिखा, जो ctypes का उपयोग फ़ंक्शन को dll से बाहर निकालने के लिए करता है और इसका उपयोग सीधे fmod कॉल करने के लिए करता है। परीक्षण अभी भी विफल। फिर मैंने ucrtbase.dll (केवल fmod फ़ंक्शन के लिए) के पुराने संस्करण पर स्विच किया। टेस्ट पास करते हैं। मैंने दृश्य स्टूडियो मंच पर एक

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) में नैनो न हो? या इसे नैन सिंथैटिक तरीके से सेट करें?
क्या कॉलिंग कन्वेंशन कुछ बाधाओं को डालते हैं कि इन रजिस्टरों को कैसे व्यवहार करना चाहिए?

मैं "साबित" करना चाहता था कि समस्या fmod कार्यान्वयन है, जो ucrtbase.dll से आती है। इसलिए मैंने एक छोटा सा काम लिखा, जो ctypes का उपयोग फ़ंक्शन को dll से बाहर निकालने के लिए करता है और इसका उपयोग सीधे fmod कॉल करने के लिए करता है। परीक्षण अभी भी विफल। फिर मैंने ucrtbase.dll (केवल fmod फ़ंक्शन के लिए) के पुराने संस्करण पर स्विच किया। टेस्ट पास करते हैं। मैंने दृश्य स्टूडियो मंच पर एक

कम से कम किसी के पास एक एज़्योर खाता है, जो शायद यहाँ बहुत से लोग हैं, इसे बढ़ा सकते हैं। मैं इस मुद्दे पर मूल रूप से दिखाई देने वाले एज़ुर एमएल में काम करने वाले कुछ संपर्कों को देख सकता हूं कि क्या वे कुछ भी कर सकते हैं।

कम से कम किसी के पास एक एज़्योर खाता है, जो शायद यहाँ बहुत से लोग हैं, इसे बढ़ा सकते हैं।

टिप के लिए धन्यवाद, उत्कीर्ण!

मुझे नहीं लगता कि हमारे पास fmod का एक भोला संस्करण है, क्या हम?

नहीं। यह एक मुश्किल काम है जो IEEE-754 कल्पना द्वारा कुछ व्यवहार करने के लिए आवश्यक है। यह भी बहुत धीमा है, जो शायद कल्पना से संबंधित है।

fmod की कड़ी मेहनत fprem x87 इंस्ट्रक्शन द्वारा की जाती है, यहां तक ​​कि VS2019 संस्करण में भी - देखें @mattip की https: //gist.github-mattip / d9e1f3f88ce77b9fde6a285d585c738e। ( fprem1 remainder वेरिएंट btw है।)

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 में वर्णित कुछ वैकल्पिक कार्यान्वयन उपलब्ध हैं। हालाँकि: संकलन के लिए इन सभी को gcc (mingw-w64) की आवश्यकता है। OpenLIBM MSVC AFAIK के साथ संकलन नहीं करता है। और इनलाइन असेंबलर कोड को MSVC के साथ अनुमति नहीं है। सिद्धांत रूप में, एक (mingw-w64) और निर्माण (MSVC) का उपयोग कर सकता है, जो सुपीरियर बिल्ड के दौरान एक fmod सहायक पुस्तकालय का निर्माण करता है।

क्या होगा यदि आप fmod कॉल के बाद कुछ कोड जोड़ते हैं, ताकि ST (0) में नैनो न हो? या इसे नैन सिंथैटिक तरीके से सेट करें? क्या कॉलिंग कन्वेंशन कुछ बाधाओं को डालते हैं कि इन रजिस्टरों को कैसे व्यवहार करना चाहिए?

मुझे लगता है कि हम खिड़कियों पर OpenBLAS में कॉल करने से पहले रजिस्टर को साफ करने के लिए विधानसभा का एक छोटा सा टुकड़ा जोड़ सकते हैं। मैंने थोड़ा परीक्षण सेट-अप में ऐसा करने की कोशिश की, लेकिन मेरी मस्त असेंबली फू कमजोर है। मैंने एक ऐसी प्रक्रिया लिखने की कोशिश की, जिसमें केवल 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 , मैंने 64-बिट fmod फ़ंक्शन के लिए एक असेंबलर फ़ाइल बनाई जो समान text: सेगमेंट बनाता है जैसा कि mingw-w64 (64-बिट) से संबंधित fmod फ़ंक्शन में मिलता है। कोई विचार नहीं है अगर यह छोटी गाड़ी fmod फ़ंक्शन के प्रतिस्थापन के रूप में काम करता है, लेकिन कम से कम इसे एक कोशिश देना चाहिए। परिणामी obj-file को npymath.lib में जोड़ा जा सकता है।

fmod.asm: (64-बिट)

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

masm कमांड: ml64.exe /c fmod.asm fmod.obj बनाता है (ml64.exe का 64-बिट संस्करण का उपयोग करें)

``

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

@carlkl धन्यवाद। मैं असेंबलर के एक टुकड़े के साथ खुश रहूंगा जो एसटी (एन) को रीसेट करता है जो कि हम ओबीएलएएलएस कार्यों को कॉल करने से पहले x86_64 पर उपयोग कर सकते हैं। आज fmod में बदलाव के कारण यह समस्या खड़ी हो गई, कल यह एक अलग कार्य हो सकता है। मुझे यकीन नहीं है कि रिटर्न पर ST(N) रजिस्टरों को रीसेट करने के लिए फ़ंक्शन आवश्यक हैं। अगर ऐसी कोई आवश्यकता नहीं है, तो fmod वास्तव में छोटी गाड़ी नहीं है और खिड़कियों में बदलाव ने उन्हें उपयोग करने से पहले रजिस्टरों को रीसेट करने के लिए OpenBLAS में एक असफलता उजागर की कि हमें या तो उन्हें ठीक करने में मदद करनी चाहिए या इसके आसपास काम करना चाहिए।

मैंने ऊपर टिप्पणी में fldz का उपयोग करके रजिस्टरों को रीसेट करने की कोशिश की, लेकिन मेरा परीक्षण कार्यक्रम काम नहीं करता है।

@ मैमटिप , मेरे https://stackoverflow.com/questions/19892215/free-the-x87-fpu-stack-ia32/33575875

Https://docs.microsoft.com/de-de/cpp/build/x64-calling-conference?view=vs-2019 :

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

अनुमान करें कि हम उस सिद्धांत की जाँच के लिए OpenBLAS nrm2.S (PROFCODE मैक्रो के बाद) की शुरुआत में fninit भी कॉल कर सकते हैं

से दिलचस्प सा
सिस्टम वी एप्लीकेशन बाइनरी इंटरफ़ेसAMD64 आर्किटेक्चर प्रोसेसर सप्लीमेंटड्राफ्ट संस्करण 0.99.6

_ MXCSR रजिस्टर के कंट्रोल बिट्स कैली-सेव (कॉल के दौरान संरक्षित) होते हैं, जबकि स्टेटस बिट्स कॉलर-सेव (संरक्षित नहीं) होते हैं ।_

_ X87 स्थिति शब्द रजिस्टर कॉलर-सहेजा गया है, जबकि x87 नियंत्रण शब्द कैली-सेव है ।_

_ सभी x87 रजिस्टरों को कॉलर-सेव किया जाता है, इसलिए MMX रजिस्टरों का उपयोग करने वाले कैलेज़ तेज़ महिला निर्देश का उपयोग कर सकते हैं ।_

विंडोज 64-बिट कॉलिंग कन्वेंशन की तुलना में काफी अलग है।

@ martin-frbg, fninit खतरनाक है: The FPU control word is set to 037FH (round to nearest, all exceptions masked, 64-bit precision). X87 विस्तारित परिशुद्धता क्या आप सभी मामलों में नहीं चाहते हैं, विशेष रूप से विंडोज पर।

मैं इसे रिलीज़ संस्करण के लिए नहीं चाहता, बस एक त्वरित परीक्षण के लिए। अभी भी काफी आश्वस्त नहीं हैं कि ओपनबीएलएएस को किसी तरह "सफाई" से पहले "स्वयं" करना चाहिए, लेकिन मुझे विंडोज व्यवहार पर कोई स्पष्ट दस्तावेज नहीं मिल सकता है। मैंने देखा कि Agner Fog के पास http://www.agner.org/optimize/calling_conventions.pdf पर सम्मेलनों को बुलाने के बारे में एक दस्तावेज़ है (FP रजिस्टरों के Win64 से निपटने की चर्चा पृष्ठ 13 पर शुरू होती है, लेकिन संपूर्ण उपलब्धता के दौरान बुनियादी उपलब्धता और व्यवहार पर ध्यान केंद्रित करती है)।

Https://github.com/numpy/numpy/issues/16744#issuecomment -703555555 देखें:

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

मुझे लगता है कि इसका मतलब है: x87 निर्देशों (Win64) का उपयोग न करें। यदि आप करते हैं, तो सौभाग्य। या दूसरे शब्दों में: नुकसान न आने के लिए कैली जिम्मेदार है।

एचएम जो MSVC संकलक के व्यवहार का विशेष रूप से वर्णन करता प्रतीत होता है, जबकि I _think_ हम एक मिंग इकोसिस्टम में हैं?

नहीं, Numpy (Pypi) को विंडोज पर MSVC (विजुअल स्टूडियो 2019) के साथ संकलित किया गया है। OpenBLAS के लिए mingw-w64 (फोरट्रान भागों के कारण) का उपयोग किया जाता है। इसके अलावा स्किप फोरट्रान भागों को मिंगव-डब्ल्यू 64 के साथ संकलित किया गया है। हालाँकि, CPython और यह बाइनरी एक्सटेंशन MSVC द्वारा निर्धारित मानकों पर आधारित है।

BTW: यह https://github.com/mingwpy के विकास का कारण था जो वर्तमान में फिर से जीवन में वापस सांस ले रहा है। (बेशर्म प्लग)

एक और बिट:

mingw-w64 MSVC के रूप में एक ही बुला सम्मेलनों का उपयोग करता है (लगभग)। केवल उल्लेखनीय अंतर x86 (32-बिट) पर अलग-अलग स्टैक संरेखण हैं - SIMD के लिए प्रासंगिक और संयुक्त राष्ट्र समर्थित vectorcall ।

दिलचस्प। x86 प्रभावित नहीं है। केवल AMD64।

सूर्य पर, 4 अक्टूबर, 2020, 22:19 carlkl सूचनाएं @github.com ने लिखा:

एक और बिट:

mingw-w64 MSVC के रूप में एक ही बुला सम्मेलनों का उपयोग करता है (लगभग)। केवल
उल्लेखनीय अंतर x86 (32-बिट) पर अलग-अलग स्टैक संरेखण हैं -
SIMD और संयुक्त राष्ट्र समर्थित वेक्टरकॉल के लिए प्रासंगिक है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/16744#issuecomment-7033171784 , या
सदस्यता समाप्त
https://github.com/notifications/unsubscribe-auth/ABKTSRMFHWZVLDYDFGBM6YDSJDRGTANCNFSM4OP5IXNQ
।

MSVC 32 बिट शायद fpu को अस्वीकार नहीं किया है? मैं बस nrm2_see2.S द्वारा fpu का उपयोग करते हुए nrm2.S का स्टॉपगैप रिप्लेसमेंट करूँगा (यदि इसका व्यवहार्य है, तो दुर्भाग्य से अप्रयुक्त लेकिन घातक असेंबली रूटीन की संख्या कोडबेस में या ओएस के लिए सादे सी संस्करण के आसपास तैर रही है) == विंडोज तो। (यहां चर्चा की गई दूसरी समस्या कुछ और है, लेकिन जैसा कि मुझे लगता है कि x86_64 के लिए अन्य सभी पुराने विधानसभा रूट एसएसई 2 हैं)

@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 एक अच्छे उम्मीदवार की तरह लगता है) तो मैं OpenBLAS में कॉल करने से पहले NumPy में रजिस्टरों को रीसेट करने के लिए कोडांतरक निर्देशों का उत्सर्जन कर सकता हूं।

कुछ इस तरह?

.code
reset_fpu proc
    finit
    fldz
reset_fpu endp
end

finit ist wait plus 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 सेगफॉल्ट कर सकता है यदि सेंट (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 ) प्रोजेक्ट जो संकलित करता है और चलाता है। एक बार हमारे पास ऐसा हो, मैं अलग-अलग कॉलों का पता लगाना जारी रख सकता हूं और वे ओपब्लस को कैसे प्रभावित करते हैं।

@ मट्टीप , मैं समझता हूं। मैं इसे जरूर आजमाऊंगा, लेकिन इसमें समय लग सकता है।

मुझे यह आभास हुआ कि UCRT में fmod का _tempory_ खराब व्यवहार _ Open_AS द्वारा _healed_ होना चाहिए: https://github.com/xianyi/OpenBLAS/pull/2882 और सुपी द्वारा नहीं, Win64 पर FPU का उपयोग नहीं करता है। और निश्चित रूप से एमएस को इस मुद्दे को विंडोज पैच के साथ ठीक करना चाहिए।
इस मामले में सुन्न पैच एक ओपनबीएलएएस संस्करण का उपयोग सुनिश्चित करने के दौरान होगा, जो आगामी ओपनबीएलएएस रिलीज से पुरानी नहीं है।

@ मत्ती numpy/__init__.py में एक पवित्रता की जाँच है। क्या इस समस्या का पता लगाने के लिए हम एक सरल और विश्वसनीय परीक्षण जोड़ सकते हैं?

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

@ मट्टीप , स्निपेट के लिए धन्यवाद। लेकिन मुझे डेस्कटॉप पर पहुंच प्राप्त करने के लिए कुछ समय की आवश्यकता होगी जहां मैं इस तरह के परीक्षण कर सकूंगा। अभी मैं कम से कम प्रोग्रामिंग वातावरण के साथ एक लैपटॉप के साथ अधिकांश समय काम कर रहा हूं जहां मैं लगभग कुछ भी स्थापित नहीं कर सकता।

हमने OpenBLAS v0.3.12 में एक अद्यतन को मर्ज कर दिया है और उस संस्करण का उपयोग करके एक स्थानीय बिल्ड + विंडोज़ अपडेट 2004 टेस्ट सूट पास करता है।

विंडोज अपडेट होने तक इसे खुला छोड़ दें।

क्या प्री-रिलीज़ पहियों को नए ओपनबीएलएएस के साथ बनाया गया है? डाउनस्ट्रीम परियोजनाओं के साथ कुछ और परीक्षण करने में खुशी है जो इस बग का अनुभव कर रहे थे।

विंडोज 3.9 पूर्व-रिलीज़ पहिये वर्तमान में गायब हैं क्योंकि परीक्षण त्रुटियां थीं (अब तय हो गई हैं)। आज या कल आने वाले 1.19.3 में तय पुस्तकालय का उपयोग किया जाएगा।

/MT विकल्प विंडोज पर स्टेटिक लिंकिंग को सक्षम करता है। Microsoft SDK के 1909 संस्करण का उपयोग करके libucrt.lib के विरुद्ध स्टेटिक रूप से लिंक करना संभव हो सकता है। यह 2004 और 20H2 में ucrtbase.dll बग के लिए एक समाधान के रूप में कार्य कर सकता है। यह पहियों को बड़ा बनाता है, जो एक नकारात्मक पहलू है।

मुझे नहीं पता कि यह / एमटी समस्या अभी भी वैध है, लेकिन इस पर विचार किया जाना चाहिए।

मुझे लगता है कि अगर NumPy एकमात्र मॉड्यूल है जो MT के साथ बनाता है तो यह हो सकता है
ठीक। बेशक, यह मामला हो सकता है कि अगर NumPy MT है तो कोई भी
डाउनस्ट्रीम को भी एमटी होने की आवश्यकता होगी, और इसलिए यह एक समस्या होगी।

सोम, 2 नवंबर, 2020 को, 19:37 carlkl सूचनाएं @github.com ने लिखा:

मुझे नहीं पता कि यह / एमटी समस्या है
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 के अपडेट के लिए अपडेट की गई मशीन पर हूं, और इसमें डेस्कटॉप सॉफ्टवेयर है जो पाइप का उपयोग करने के लिए संख्यात्मक / स्कैपी / पांडा आदि स्थापित करता है। यह सभी सॉफ़्टवेयर Microsoft के अपडेट के कारण होने वाली इस समस्या से प्रभावित हैं।

किसी भी सिफारिश की सराहना की जाएगी, क्योंकि numpy स्थापित करने के लिए conda का उपयोग करना उस सॉफ़्टवेयर के लिए कोई विकल्प नहीं है जिस पर मैं काम कर रहा हूं।

यदि आपको डॉकटर की आवश्यकता नहीं है तो आप 1.19.3 पिन कर सकते हैं। यह मेरे विंडोज सिस्टम पर सभी परीक्षणों को पास करता है।

धन्यवाद। 1.19.3 मुद्दे पर पाइप के साथ काम करता है।

खराब BLAS का पता लगाने की कड़ी, MS की साइट पर बहुत सारे शोर वाले पोस्ट चला रही है। मुझे आशा है कि यह अंत तक फूंक नहीं होगा।

मुझे लगता है कि एक और विकल्प Win64 पर एक 3 पार्टी fmod का उपयोग करने के लिए है।

मुझे आश्चर्य है कि अगर एक रिलीज के बाद चार महीनों के लिए नुम्पी बग को इस गंभीर समस्या से मुक्त किया गया तो क्या प्रतिक्रिया होगी, खासकर अगर हमने उपयोगकर्ताओं को पिछले संस्करण को डाउनग्रेड करने के लिए स्पष्ट निर्देश नहीं दिए हैं। उपयोगकर्ता आसानी से 1.19.3 पर पिन कर सकते हैं, लेकिन यह समस्या को हल नहीं करेगा, यह केवल एक और पैकेज में ले जाएगा जो रजिस्टरों का उपयोग करने के बाद उन्हें गड़बड़ कर दिया गया है: शायद डांट, शायद टेंसरफ़्लो।

वर्कअराउंड के लिए एक और विचार: देखें कि क्या ucrt में कोई अन्य फ़ंक्शन है जो FPU का उपयोग करता है और एक अच्छी स्थिति में अपना राज्य छोड़ देता है। अगर वहाँ एक है, हम fmod के बाद यह कह सकते हैं। इससे विधानसभा के कामकाज पर फायदा होगा @mattip ने लिखा क्योंकि इसे किसी विशेष फाइल या निर्माण प्रक्रिया की आवश्यकता नहीं होगी।

मुझे नहीं लगता कि हमें इस समस्या के आसपास काम करने में अधिक प्रयास करना चाहिए। समस्या को कम करने के लिए हम जो भी अतिरिक्त काम करेंगे, वह मूल्यवान डेवलपर समय लेगा और इसे ठीक करने के लिए Microsoft पर दबाव कम करेगा। इसके अलावा, जैसा कि ऊपर बताया गया है, अन्य परियोजनाओं में कोई भी कोड जो fmod और / या रजिस्टरों का उपयोग करता है, वह इस समस्या को NumPy से कोई संबंध नहीं रखता है।

मुझे नहीं लगता कि हमें इस समस्या के आसपास काम करने में अधिक प्रयास करना चाहिए। समस्या को कम करने के लिए हम जो भी अतिरिक्त काम करेंगे, वह मूल्यवान डेवलपर समय लेगा और इसे ठीक करने के लिए Microsoft पर दबाव कम करेगा। इसके अलावा, जैसा कि ऊपर बताया गया है, अन्य परियोजनाओं में कोई भी कोड जो fmod और / या रजिस्टरों का उपयोग करता है, वह इस समस्या को NumPy से कोई संबंध नहीं रखता है।

त्रुटि संदेश की प्रतिक्रिया देखने के बाद यह स्पष्ट रूप से बहुत उपयोगी नहीं है। उदाहरण के लिए, विंडोज उपयोगकर्ताओं को सुझाव देना चाहिए कि जो नवीनतम न्यूमपी सुविधाओं का उपयोग करना चाहते हैं, उन्हें पाइप पहिया के बजाय एमकेएल के साथ जहाजों के वितरण का उपयोग करना चाहिए। इसमें इस धागे का लिंक भी शामिल होना चाहिए।

हालांकि, यह स्पष्ट रूप से एमएस की जिम्मेदारी है, जिससे उपयोगकर्ताओं को किसी और की गलती को इंगित करने के लिए दर्द होता है, शायद ही कभी किसी भी परियोजनाओं के लिए अच्छी इच्छाशक्ति बनाए रखने का एक अच्छा तरीका है।

@bashtage काफी निश्चित नहीं है कि आप दर्द पैदा करने के बारे में क्या सोचते हैं। हम लिंक को हटा सकते हैं और उपयोगकर्ताओं के बजाय यहां लैंड कर सकते हैं, लेकिन हमें उपयोगकर्ताओं को चेतावनी देनी चाहिए कि जब वे 2004 में चलते हैं तो परिणामों पर भरोसा नहीं किया जा सकता है, और यदि आप एक गणना के परिणामों पर भरोसा नहीं कर सकते हैं तो आपको उस प्लेटफॉर्म पर गणना से बचना चाहिए।

बहुत निश्चित नहीं है कि आप दर्द पैदा करने के बारे में क्या सोचते हैं।

NumPy का आयात शानदार रूप से विफल हो जाता है और कोई समाधान प्रदान नहीं किया जाता है। अधिकांश उपयोगकर्ताओं के लिए यह सबसे उपयोगी होगा यदि ज्ञात वर्कअराउंड की सूची स्पष्ट रूप से दिखाई दे रही थी:

(ए) एमकेएल-आधारित वितरण का उपयोग करना जैसे कि कोंडा या उत्साहित तैनाती प्रबंधक जो इसे से बचता है लेकिन रैखिक बीजगणित कोड में
(b) NumPy 1.19.3 पर वापस जाएं जो OpenBLAS के एक संस्करण के साथ जहाज है जो बग से सुरक्षित है। यह विकल्प उन उपयोगकर्ताओं के लिए उपयुक्त नहीं हो सकता है जो कंटेनर में चल रहे हैं।
(c) स्रोत से निर्माण। इस विकल्प में कम-प्रदर्शन करने वाला BLAS होगा, लेकिन ऐसे वातावरण में उपयुक्त हो सकता है जहां तृतीय-पक्ष वितरण की अनुमति नहीं है और या तो कंटेनर का उपयोग किया जाता है या हाल ही में एक सुविधा या NumPy में बग फिक्स की आवश्यकता है।

मुझे नहीं लगता कि fmod बग पर ध्यान देना गलत है, लेकिन फिर यह उपयोगकर्ताओं को उस मंच पर भेजता है जैसे कि कोई समाधान उनके लिए इंतजार कर रहा है।

हम लिंक को हटा सकते हैं और उपयोगकर्ताओं के बजाय यहां लैंड कर सकते हैं, लेकिन हमें उपयोगकर्ताओं को चेतावनी देनी चाहिए कि जब वे 2004 में चलते हैं तो परिणामों पर भरोसा नहीं किया जा सकता है, और यदि आप एक गणना के परिणामों पर भरोसा नहीं कर सकते हैं तो आपको उस प्लेटफॉर्म पर गणना से बचना चाहिए।

यह एक विकल्प नहीं है। उपयोगकर्ताओं को केवल NumPy + OpenBLAS (पूर्व 0.3.12) से बचने की आवश्यकता है। उन्हें NumPy + Windows (2004 / 20H2 (अब 2 जारी किए गए संस्करण प्रभावित हैं) से बचने की आवश्यकता नहीं है)।

एमकेएल-आधारित वितरण

साथ ही एमकेएल के साथ समस्याओं की रिपोर्ट थी।

NumPy 1.19.3 पर वापस लौटें

लेकिन यह fmod के उपयोग से उत्पन्न अन्य संभावित समस्याओं को ठीक नहीं करेगा। समस्या यह है कि यह सुनिश्चित करने का कोई तरीका नहीं है कि परिणाम सही हों।

फोल्क्स 2004 में अजगर का उपयोग नहीं करना चाहिए, शायद इसके बजाय WSL का उपयोग करें? मैं भी एक पुराने ucrt के साथ खिड़कियों के पहियों के साथ ठीक हो जाएगा अगर यह संभव था, लेकिन अन्य परियोजनाओं के बारे में क्या? क्या पहले के विंडोज़ संस्करणों में वापस जाने का एक आसान तरीका है?

साथ ही एमकेएल के साथ समस्याओं की रिपोर्ट थी।

NumPy में एक परीक्षण नहीं है जो MKL पर विफल रहता है। ऐसा लगता है कि वहाँ कोई समस्या नहीं है जब वहाँ कोई विफलता रिपोर्ट कर रहे हैं मुश्किल है। Fmod बग एमकेएल के BLAS में प्रकट नहीं होता है (संभवतः क्योंकि यह FPU का उपयोग नहीं करता है)।

लेकिन यह fmod के उपयोग से उत्पन्न अन्य संभावित समस्याओं को ठीक नहीं करेगा। समस्या यह है कि यह सुनिश्चित करने का कोई तरीका नहीं है कि परिणाम सही हों।

नहीं, लेकिन यह विंडोज सुरक्षा समस्याओं को भी ठीक नहीं करेगा, या कई अन्य बग। यहाँ मुद्दा बहुत विशेष है।

1. fmod ठीक है जो सही परिणाम उत्पन्न करता है
2. सिस्टम कंपाइलर x87 कोड का उत्पादन नहीं करेगा क्योंकि आपको इस समस्या का सामना करने के लिए कोडांतरक में कोड लिखा होना चाहिए।

ये दोनों मुझे सुझाव देते हैं कि लगभग सभी कोड तक पहुंचने के लिए समस्या बहुत चुनौतीपूर्ण है। केवल OpenBLAS, FFT पुस्तकालयों जैसे हाथ से लिखित गुठली, या MKL जैसे उच्चतम प्रदर्शन कोड # 2 को ट्रिगर करने की संभावना है।

मुझे यह भी लगता है कि यह तय करना वाजिब है कि जब से ओपनबीएएसए 0.3.12 ने उम्मीद के मुताबिक काम किया है, तब नूपी रिलीज होगी और यह मुद्दा कभी भी यूजर्स के सामने नहीं आएगा।

फोल्क्स 2004 में अजगर का उपयोग नहीं करना चाहिए, शायद इसके बजाय WSL का उपयोग करें? मैं भी एक पुराने ucrt के साथ खिड़कियों के पहियों के साथ ठीक हो जाएगा अगर यह संभव था, लेकिन अन्य परियोजनाओं के बारे में क्या? क्या पहले के विंडोज़ संस्करणों में वापस जाने का एक आसान तरीका है?

मुझे कई उपयोगकर्ताओं के लिए संदेह है कि यह वास्तव में कई उपयोगकर्ताओं के लिए एक विकल्प नहीं है: एंटरप्राइज़ डेस्कटॉप पर कॉर्पोरेट उपयोगकर्ता, नौसिखिया छात्र (जो कोंडा का उपयोग करना चाहिए), या कोई भी जो 2004 या 20 एच 2 के साथ एक लैपटॉप खरीदा था, जो डाउनग्रेड नहीं कर सकता है।

ध्यान दें कि न केवल कॉन्डास को खसरा पैक MLK के साथ जोड़ा गया है, यह पहले से ही ucrtbase.dll अपने संस्करण को शिप करता है जो कि पुराने वर्जन के लिए अपीयर किया जाता है (10.0.17134.12)

यहाँ @Bashtage के साथ काफी हद तक सहमत

@jenshnielsen : ध्यान दें कि MLK के खिलाफ न केवल कोंडा खसरा पैक से जुड़ा है [...]

Conda-forge द्वारा पैक किए गए बिल्ड, blas / lapack कार्यान्वयन (ओपनब्लस / mkl / blis / netlib के बाहर) को स्विच करने की अनुमति देते हैं, यह _have_ को MKL नहीं बनाता है।

फोल्क्स 2004 में अजगर का उपयोग नहीं करना चाहिए, शायद इसके बजाय WSL का उपयोग करें?

यह अधिकांश उपयोगकर्ताओं के लिए संचालन का डिफ़ॉल्ट मोड नहीं है।

मैं भी एक पुराने ucrt के साथ खिड़कियों के पहियों के साथ ठीक हो जाएगा अगर यह संभव था, लेकिन अन्य परियोजनाओं के बारे में क्या?

अन्य परियोजनाएं हमारी जिम्मेदारी नहीं हैं।

क्या पहले के विंडोज़ संस्करणों में वापस जाने का एक आसान तरीका है?

यदि आपने अपने डिस्क स्थान को एक ताजा स्थापित या साफ किया है, तो ऐसा करना लगभग असंभव हो जाता है।

यहाँ @Bashtage के साथ काफी हद तक सहमत

मैं सहमत हूँ। यदि हम इसे ठीक नहीं करते हैं तो हम बहुत से उपयोगकर्ताओं को खो सकते हैं।

मैं भी एक पुराने ucrt के साथ खिड़कियों के पहियों के साथ ठीक हो जाएगा अगर यह संभव था, लेकिन अन्य परियोजनाओं के बारे में क्या?

@charris , यह विंडोज 10 पर मदद नहीं करेगा। यदि आप अजगर या सुन्न के साथ एक अलग ucrt तैनात करते हैं, तो इसे विंडोज 10 पर कभी लोड

@carlkl
Conda पैक अजगर वास्तव में interjects DLL खोज पथ संकल्प में ही (- अपरिवर्तित - जो संभवतः कारण तुम क्यों कहते हैं कि यह Windows 10 पर काम कभी नहीं कर सकते हैं हो सकता है), और इस AFAICT भी कारण है कि conda _does_ प्रदान करना है एक ucrtbase.dll , जैसा कि @jenshnielsen लिखते हैं।

@ h-vetinari, यूनिवर्सल CRT तैनाती में स्पष्ट रूप से कहा गया है:

_ स्थानीय तैनाती पर दो प्रतिबंध हैं जिनसे अवगत होना:
विंडोज 10 पर, सिस्टम डायरेक्टरी में यूनिवर्सल CRT का उपयोग हमेशा किया जाता है, भले ही किसी एप्लिकेशन में यूनिवर्सल CRT की एप्लिकेशन-लोकल कॉपी शामिल हो। यह तब भी सच है जब स्थानीय प्रति नया है, क्योंकि यूनिवर्सल सीआरटी विंडोज 10._ पर एक कोर ऑपरेटिंग सिस्टम घटक है

BTW: मैं इसे खुद का परीक्षण किया। विंडोज 10 के साथ उपलब्ध यूसीआरटी की तुलना में किसी अन्य यूसीआरटी को लोड करने का कोई तरीका नहीं है।

मुझे यह भी लगता है कि यह तय करना उचित है

इसके द्वारा मुझे लगता है कि आप PR gh-17547 जोड़ रहे हैं?

@Carlkl की बात का प्रमाण:

एमएस के कारण होने वाले इस बग को एक हाइजेनबग कहा जाना चाहिए। इसका कारण ढूंढना महंगा और कठिन था: विंडोज 2004 यूसीआरटी एफएमडी कुछ परिस्थितियों में एफपीयू रजिस्टर्ड बॉटस्टेड अवस्था में छोड़ देता है। यह एफपीयू का फिर से उपयोग करते समय बहुत बाद में संख्यात्मक गणना त्रुटियों को जन्म दे सकता है। गणना की त्रुटियां आमतौर पर उपयोगकर्ता कोड में पॉप अप नहीं होती हैं यदि कठोरता से परीक्षण नहीं किया गया है। इसका मतलब यह हो सकता है कि महत्वपूर्ण संख्यात्मक त्रुटियां लंबे समय तक अनिर्धारित रहती हैं। यह शायद ही बदतर हो सकता है।

इसके द्वारा मुझे लगता है कि आप PR gh-17547 जोड़ रहे हैं?

क्षमा करें, मैंने गलत बात लिखी है।

एकमात्र बदलाव जो मैं सुझाव दे रहा हूं, वह यह है कि NumPy आयात पर उठाए गए अपवाद में अधिक जानकारी प्रदान करता है जो यह बताता है कि उपयोगकर्ता को 2004 / H2 पर एक ऐसा वातावरण मिल सकता है जो उन्हें अपनी नौकरी / स्कूल / शौक के साथ मिलेगा।

1. WSL
2. conda / enthought
3. 1.19.3
4. स्रोत से बनाएँ

[यह आदेश समाधान की गुणवत्ता के अनुसार मेरी प्राथमिकता है]

मुझे लगता है कि यह इस मुद्दे से जुड़ने के लिए, या एक ऐसे मुद्दे से भी जुड़ा होगा जो थोड़ा साफ है जो एक गहन व्याख्या प्रदान करता है। यह दूसरा लिंक भी एक github मुद्दे के बजाय डॉक्स में कुछ रिलीज़ नोट्स के लिए हो सकता है।

Conda-forge द्वारा पैक किए गए बिल्ड, blas / lapack कार्यान्वयन (ओपनब्लस / mkl / blis / netlib के बाहर) को स्विच करने की अनुमति देते हैं, यह _have_ को MKL नहीं बनाता है।

@ h-vetinari Do conda-forge + OpenBLAS 2004 / H2 पर पास परीक्षण बनाता है?

मैंने अभी-अभी जाँच की और कोडा-फोर्ज के जहाज OpenBlas 0.3.12। क्या यह क्रैश कंटेनर है?

ओपनबीएएस-0.3.12 में EMMS निर्देश के साथ FPU राज्य की चिकित्सा पद्धति का उपयोग करते हुए, निश्चित रूप से सुन्न और चुस्त परीक्षणों को साफ करने में मदद करनी चाहिए, लेकिन जैसा कि @charris ने fmod(0,x) कॉल करने की बात कही है CPython और फिर FPU निर्देश बाद में (OpenBLAS की तुलना में एक अलग पैकेज में) कहा जा सकता है। इस मामले में समस्या केवल अन्यत्र स्थानांतरित कर दी जाती है।

सबसे अच्छा दांव वास्तव में एमएस को मजबूर कर रहा है कि वे छोटी गाड़ी के व्यवहार को थपथपाएं। शायद स्टीव डावर मदद कर सकते हैं?

यह एग्नर फॉग या शायद ब्रूस डॉसन के लिए एक दिलचस्प कहानी भी हो सकती है: देखिए उनके ब्लॉग में इस संबंधित कहानी:
सब कुछ पुराना है फिर से, और एक कंपाइलर बग

शायद OpenBlas 0.3.12 में बग। निजी बाइट्स कॉलम पर ध्यान दें:

यह संभवतः 24 BLAS थ्रेड के लिए डिफॉल्ट करता है क्योंकि मेरे पास 24 लॉजिकल सीपीयू हैं।

यह OpenBLAS 0.3.12 है जिसमें कोंपा-फोर्ज की संख्या 1.19.2 है।

एक नाटकीय कमी के लिए $env:OPENBLAS_NUM_THREADS=1 स्थापना करता है

और $env:OPENBLAS_NUM_THREADS=4 धागे के साथ:

@ नोट : क्या आप OpenBLAS xianyi / OpenBLAS # 2970 में OpenBLAS 0.3.12 पर चर्चा जारी रख सकते हैं?

@ मैमटिप मैं यह निर्धारित करने की कोशिश कर रहा था कि क्या कोंडा + ओपनबीएलएएस एक विश्वसनीय विकल्प था। मुझे नहीं लगता कि यह कुछ भी है कि 1.19.3 हल इन परिणामों को देखा है हल करती है।

@ बेसशूट : @ ओंकारलोक बिंदु का प्रमाण:

चूंकि कोंडा-पैक किए गए अजगर सक्रिय रूप से विंडोज़ मानक डीएलएल रिज़ॉल्यूशन को दरकिनार करते हैं, मुझे यकीन नहीं है कि विंडोज़ टूल कितना प्रमाण होने वाला है। मैंने इस मुद्दे को पुराने libcrypto.dll C:\Windows\System32 उदाहरण के साथ सामना किया है, उदाहरण के लिए https://github.com/conda-forge/staged-recipes/pull/11452 देखें। लंबी कहानी संक्षेप में, पुरानी प्रणाली लाइब्रेरी को cryptography परीक्षण सूट में एक परीक्षण विफलता द्वारा उठाया गया था, और फिर - CONDA_DLL_SEARCH_MODIFICATION_ENABLE का उपयोग करते हुए - कोंडा द्वारा प्रदान किए गए ओपनसेल का उपयोग करने के लिए मजबूर किया जा सकता है।

@bashtage : @ h-vetinari Do conda-forge + OpenBLAS 2004 / H2 पर पास परीक्षण बनाता है?

CI जो संकुल का निर्माण कर रहा है वह संभवतः इस तरह के वर्तमान संस्करण पर नहीं है, और इसे स्वयं बनाने में मुझे थोड़ा समय लगा। मैं वर्तमान में 2004 मशीन पर चल रहा हूं, और यह है - बहुत सकारात्मक - परिणाम **:

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

@बैशेट : मैंने अभी-अभी चेक किया और कोंडा फोर्ज के जहाज ओपेनबालास 0.3.12। क्या यह क्रैश कंटेनर है?

कोंडा-फोर्ज किसी भी निर्धारित ओपनब्लास संस्करण के साथ जहाज नहीं करता है - ब्लास संस्करण को "हॉटस्वैप्ड" भी किया जा सकता है (जैसे ओपनब्लास, एमकेएल, ब्लिस के बीच), इसलिए संस्करण एक बड़ा हिस्सा नहीं है। आम तौर पर हालांकि, यह नवीनतम पैक संस्करण का उपयोग करेगा। मैं पुष्टि नहीं कर सकता कि दुर्घटना कंटेनर में पुन: उत्पन्न होती है या नहीं।

@bashtage :: @mattip मैं यह निर्धारित करने की कोशिश कर रहा था कि क्या conda + OpenBLAS एक विश्वसनीय विकल्प था। मुझे नहीं लगता कि यह कुछ भी है कि 1.19.3 हल इन परिणामों को देखा है हल करती है।

स्मृति वृद्धि ओपनब्लैस 0.3.12 में बदलाव के कारण हुई, जैसा कि आगे जियान्यी / ओपनब्लस # 2970 में चर्चा की गई थी। अब तक, कोंडा-फोर्ज मुझे एक विश्वसनीय विकल्प लगता है - कम से कम यह सीधे त्रुटि से प्रभावित नहीं होता है।

** मैंने https://github.com/conda-forge/numpy-feedstock के वर्तमान मास्टर का उपयोग किया, जो अभी भी 1.19.2 पर है, जो ओपनब्लस 0.3.12 के साथ मिलकर है। अगर लोगों की दिलचस्पी है तो मैं https://github.com/conda-forge/numpy-feedstock/pull/210 + openblas 0.3.12 भी आज़मा सकता हूं।

अच्छी खबर में, एमएस वीएस फोरम पर वापस आ गया और सुझाव दिया कि जनवरी 2021 के अंत तक एक फिक्स आउट किया जा सकता है। इस अपडेट को देखते हुए, मुझे लगता है कि एकमात्र सवाल यह है कि क्या त्रुटि संदेश को अपडेट करने में कोई मूल्य है जो जब उठाया जाता है छोटी गाड़ी समारोह का पता चला है।

चूंकि कोंडा-पैक किए गए अजगर सक्रिय रूप से विंडोज़ मानक डीएलएल रिज़ॉल्यूशन को दरकिनार करते हैं, मुझे यकीन नहीं है कि विंडोज़ टूल कितना प्रमाण होने वाला है। मैंने इस मुद्दे को पुराने libcrypto.dll C:\Windows\System32 उदाहरण के साथ सामना किया है, उदाहरण के लिए conda-forge / staged-recipes # 11452 देखें। लंबी कहानी संक्षेप में, पुरानी प्रणाली लाइब्रेरी को cryptography परीक्षण सूट में एक परीक्षण विफलता द्वारा उठाया गया था, और फिर - CONDA_DLL_SEARCH_MODIFICATION_ENABLE का उपयोग करते हुए - कोंडा द्वारा प्रदान किए गए ओपनसेल का उपयोग करने के लिए मजबूर किया जा सकता है।

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 से छोटी गाड़ी फ़ंक्शन का उपयोग किया जा रहा है।

कोंडा फोर्ज से केवल ओपनब्लास = 0.3.12 परीक्षण पास करेगा, लेकिन यह वही है जो न्यूमपी 1.19.3 में भेज दिया गया है।

एक निरस्त्र OpenBLAS-0.3.12 के साथ संकलित एक नई संख्यात्मक रिलीज के खिलाफ क्या बोलता है? सुपीरियर के लिए उपयोग किए जाने वाले OpenBLAS के संकलन के समय ब्रेडर्स को कम करना और संभवतः थ्रेड्स की संख्या कम हो जाना। इससे OpenBLAS की मेमोरी की खपत कम होनी चाहिए और न केवल डॉकटर टेस्टकेस में बल्कि कम अच्छी तरह से सुसज्जित उपयोगकर्ताओं के साथ मदद करनी चाहिए
खिड़कियों के बक्से।

यहाँ पर https://tinyurl.com/y3dm3h86 बग रिपोर्ट पायथन के अंदर से। सबसे पहले, एक संस्करण प्रदान करने के लिए धन्यवाद जो अब (1.19.3) विंडोज पर काम करता है।

मैं समझता हूं कि 1.19.3 लिनक्स पर काम नहीं करता है और 1.19.4 विंडोज पर काम नहीं करता है (जबकि इसमें बग है)।

क्या विंडोज के लिए पेपी 1.19.3 और अन्य सभी प्लेटफार्मों के लिए 1.19.4 पर नवीनतम संस्करण बनाना संभव होगा? दूसरे शब्दों में, बस https://files.pythonhosteded.org/packages/33/26/c448c5203823237d744b7e71b81c2b6dcbcd4bff972897ce937b437ee836b2b/numpy-1.19.4-cp36-cp36-m_m6/m_m/m/6/6/6/6/6/6/6/6/6/6/5446&vs&hl=hi&vs=&hl=hi&vs=&hl=hi&hl=hi/m_m6&hl=hi/m/6/6/ इस तरह से इसे हटाएं। अभी के लिए?

@luciansmith जब तक स्रोत 1.19.4 के लिए उपलब्ध है, तब तक पाइप इस संस्करण का उपयोग करने की कोशिश करेगा और जब तक कि अतिरिक्त झंडे पास न हों। मुझे लगता है कि अधिकांश उपयोगकर्ता केवल अतिरिक्त झंडे पास करेंगे यदि उन्हें समस्या पता थी, लेकिन तब वे केवल 1.19.3 पिन कर सकते थे।

मेरी प्राथमिकता 1.19.5 होगी जो लिनक्स पर OpenBLAS 0.3.9 और विंडोज पर 0.3.12 का उपयोग करती है, लेकिन मुझे नहीं पता कि यह संभव है या नहीं।