Numpy: व्यर्थ RuntimeWarning clang- संकलित np.float32 द्वारा .__ mul__

numpy.float32('1.5').__mul__(x) साथ-साथ __add__ और __sub__ साथ एक ही चित्र।

इस प्रकार की त्रुटि सरणियों की विशिष्ट है जिसमें nan या infinity । np.array(x) वापसी क्या है?

@ एरिक-वेसर: यह array(x, dtype=object) , कोई चेतावनी नहीं देता है।

क्या np.multiply(np.float32('1.5'), x) एक ही चेतावनी देते हैं?

numpy.multiply(numpy.float32('1.5'), x) एक ही चेतावनी देता है।

type(x).__rmul__(numpy.float32('1.5'), x) बारे में क्या?

इसके अलावा, यदि आप warnings.filterwarnings('error') चला सकते हैं, तो आपको एक पूर्ण स्टैक ट्रेस मिलेगा

type(x).__rmul__(numpy.float32('1.5'), x)

TypeError: descriptor '__rmul__' requires a 'sage.structure.element.Element' object but received a 'numpy.float32'

x.__rmul__(numpy.float32('1.5')) बस ठीक से गुजरता है।

लगता है मैं भूल गया कि rmul काम करता है। मेरा मतलब type(x).__rmul__(x, numpy.float32('1.5')) , लेकिन मुझे लगता है कि x.__rmul__ रूप में एक ही काम करता है, जब तक x वास्तव में अजीब नहीं है

क्या यह भी असफल हो जाता है? np.multiply(np.array(1.5, dtype=object), x) ( filterwarnings साथ इस बार, कृपया)

type(x).__rmul__(x,numpy.float32('1.5')) बिना किसी चेतावनी के गुजरता है।

और, वैसे, warnings.filterwarnings('error') सेट करना मुझे कुछ भी दिलचस्प नहीं देता है,

---------------------------------------------------------------------------
RuntimeWarning                            Traceback (most recent call last)
<ipython-input-50-b3ece847d318> in <module>()

sage: np.multiply(np.array(1.5, dtype=object), x)
---------------------------------------------------------------------------
RuntimeWarning                            Traceback (most recent call last)
<ipython-input-52-706823a0b5a2> in <module>()
----> 1  np.multiply(np.array(RealNumber('1.5'), dtype=object), x)

RuntimeWarning: invalid value encountered in multiply

हम्म, ऋषि ने कुछ ऐसा किया जिसकी मुझे उम्मीद नहीं थी। float('1.5') साथ समान व्यवहार, मुझे लगता है?

ठीक है, तो यहाँ मुझे क्या लगता है:

• Ufunc में ऑब्जेक्ट लूप का उपयोग करके numpy का सही ढंग से उपयोग किया जाता है, जो PyNumber_Multiply कॉलिंग को समाप्त करता है
• sage , कुछ FPU में त्रुटि ध्वज (ऋषि में बग) स्थापित कर रहा है?
• numpy अपने सामान्य fpu फ्लैग चेक को ufunc (ऑब्जेक्ट लूप में बग?) से बाहर निकलने पर कर रहा है, और sage द्वारा उनकी त्रुटि को खोजने में

sage: float(1.5).__mul__(x)
NotImplemented
sage: np.float(1.5).__mul__(x)
NotImplemented
sage: np.float32(1.5).__mul__(x)
/usr/home/dima/Sage/sage/src/bin/sage-ipython:1: RuntimeWarning: invalid value encountered in multiply
  #!/usr/bin/env python
1.50000000000000*x
sage: np.float64(1.5).__mul__(x)
/usr/home/dima/Sage/sage/src/bin/sage-ipython:1: RuntimeWarning: invalid value encountered in multiply
  #!/usr/bin/env python
1.50000000000000*x

अनुकूलता कारणों से वर्थ नोटिंग np.float is float

np.float32(1.5).__mul__(x) रिटर्न NotImplemented क्यों नहीं है?

क्योंकि यह पता है कि यह ऑब्जेक्ट लूप के साथ np.multiply रूप में इसे संभाल सकता है, और फिर उस लूप के अंदर float * x साथ फिर से कोशिश करता है। दुर्भाग्य से, उस लूप के चारों ओर आवरण, ऋषि द्वारा निर्धारित FPU झंडे उठा रहा है।

यदि आप बारीकी से देखते हैं, तो आप पाएंगे कि x.__rmul__ अभी भी स्टैक में गहरा कहा जा रहा है

sage: np.float32(1.5)*x
/usr/home/dima/Sage/sage/src/bin/sage-ipython:1: RuntimeWarning: invalid value encountered in multiply
  #!/usr/bin/env python
1.50000000000000*x
sage: np.float128(1.5)*x
1.50000000000000*x
sage: np.float64(1.5)*x
/usr/home/dima/Sage/sage/src/bin/sage-ipython:1: RuntimeWarning: invalid value encountered in multiply
  #!/usr/bin/env python
1.50000000000000*x

तो ऐसा लगता है जैसे np.float128 ठीक है, लेकिन

sage: np.float128(1.5).__mul__(x)
/usr/home/dima/Sage/sage/src/bin/sage-ipython:1: RuntimeWarning: invalid value encountered in multiply
  #!/usr/bin/env python
1.50000000000000*x

यह अजीब है। एक कंपाइलर बग, शायद (जैसा कि हम इसे जीसीसी पर कभी नहीं देखते हैं), लेकिन किस जगह पर?

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

दुर्भाग्य से, numpy FPU झंडे के लिए स्पष्ट रूप से पूछने के लिए किसी भी तरह का खुलासा नहीं करता है - जो ऋषि के भीतर समस्या को सुलझाने के लिए बहुत उपयोगी होगा।

मुझे लगता है कि यह एक ही चेतावनी का कारण बनता है (ऐसा करने के लिए 1.12 की आवश्यकता है, मुझे लगता है)

mul = np.vectorize(x.__rmul__)
mul(float('1.5'))

काफी समान नहीं है, लेकिन करीब:

/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/numpy/lib/function_base.py:2652: RuntimeWarning: invalid value encountered in __rmul__ (vectorized)
  outputs = ufunc(*inputs)
array(1.50000000000000*x, dtype=object)

ठीक है, अच्छा है, यह इंगित करता है कि np.float32 या np.float64 साथ कुछ भी विशिष्ट नहीं है, यह यहां किकिंग चेतावनी उत्पन्न करने के लिए अधिक सामान्य संख्यात्मक तंत्र है।

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

हां, यह मेरे संदेह की पुष्टि करता है, और आपको डीबग करने का एक तरीका प्रदान करता है। यह कोड

def check_fpu(f):
    @functools.wraps(f)
    def wrapped(*args, **kwargs):
        excluded = list(range(len(args))) + list(kwargs.keys())
        fvec = np.vectorize(f, excluded=excluded)
        return fvec(*args, **kwargs)
    return wrapped

एक अजगर समारोह के लिए लागू, आप कोड के उस हिस्सा के भीतर चेतावनी को अलग करने की अनुमति देता है।

मेरा मतलब है, यह बहुत अजीब है कि यह सब हो रहा है; संकलक आमतौर पर आविष्कार नहीं करते हैं और फिर बिना किसी कारण के NaN को फेंक देते हैं।

यदि आप इसे नीचे ट्रैक करने का प्रयास कर रहे हैं, तो आपको संभवतः ऋषि में कोड को देखना चाहिए जो उन बहुपद के लिए गुणन को लागू करता है - यह संभावना है कि अजीब झंडा सेटिंग संभवतः हर समय हो रही है, और खौफनाक केवल उस दृश्य को शामिल करने के लिए है ।

वहाँ भी एक बहुत अच्छा तर्क है कि सुन्न भी वस्तु छोरों पर इन झंडे की जाँच करने की कोशिश नहीं करनी चाहिए। (या पूर्णांक उस मामले के लिए लूप करता है, लेकिन यह बहुत मुश्किल है क्योंकि जिस तरह से हम पूर्णांक ओवरफ़्लो की रिपोर्ट करते हैं वह थोड़े सकल है और fpu झंडे का उपयोग करता है।) यही एकमात्र चीज़ है जो मैं सोच सकता हूं कि यहां सुपीफी कर सकता है।

check_fpu() का एक टाइपो है, यह वहां fvec = np.vectorize(f, excluded=exclude) होना चाहिए।
और, हम python2 पर हैं: import functools32 as functools ।

functools.wraps को अजगर 3 की आवश्यकता नहीं है, है ना?

यदि setattr() p

AttributeError: 'method-wrapper' object has no attribute '__module__'

हाँ, मैं अनुमान लगा रहा हूँ कि यह जो भी बहु-सटीक पुस्तकालय है, जो RealField में गुणांक के लिए अंकगणित को कार्यान्वित कर रहा है जो FPU ध्वज को स्थापित कर रहा है। अंतर्निहित लाइब्रेरीज़ को अलग-अलग परिस्थितियों में एक ही संकलक के रूप में संकलित किया जाता है? या केवल अलग-अलग संकलक के साथ पुनर्निर्माण किया जा रहा है?

हाँ, मैं यह अनुमान लगा रहा हूँ कि रियलफ़ील्ड में गुणांक के लिए अंकगणित को लागू करने वाली जो भी बहु-सटीक लाइब्रेरी है

यह रिकॉर्ड के लिए MPFR है।

हम Sagemath को clang + gfortran (अधिकतर OSX और FreeBSD पर, प्लेटफ़ॉर्म जहां क्लैंग प्राथमिक कंपाइलर है) पर पोर्ट करने का प्रयास करते हैं, ताकि OSX पर इसे बनाना और चलाना आसान और तेज़ हो (FreeBSD एक समान वातावरण प्राप्त करने के लिए टूल के बिना अधिक है) OSX और Apple हार्डवेयर की परेशानी)।

मेरे द्वारा यहां बताई गई सभी तुलनाएं पूरी तरह से clang / clang +++ gfortran के साथ हैं जो gcc / g +++ gfortran के विपरीत है।

रैपर हमें यह बताने लगता है कि x.__rmul__ FPU का झंडा है

check_fpu(x.__rmul__)(np.float32('1.5'))

चेतावनी देता है, जबकि x.__rmul__(np.float32('1.5')) नहीं है।

वास्तव में - मेरी धारणा यह थी कि अजगर में x.__rmul__ लिखा गया था, और इसका स्रोत कोड यह पता लगाने के लिए लगाया जा सकता है कि कौन सा विशेष रूप से ध्वज सेट करता है

x.__rmul__ साइथन में है, लेकिन फिर भी यह जांच करने के लिए कोड का एक छोटा सा टुकड़ा है।

यदि चेतावनी को त्रुटि में बदलने का एक सरल तरीका होगा, तो आपको एक ट्रेसबैक मिलेगा (साइथॉन त्रुटियों के लिए ट्रेसबैक बनाता है लेकिन चेतावनियों के लिए नहीं)।

@jdemeyer IMHO की खस्ता चेतावनी कोड पथ में बहुत बाद में जारी की गई है, अर्थात यह FPU झंडे की स्पष्ट जांच का परिणाम है, न कि एक रुकावट सेट।

numpy इस चेतावनी को एक त्रुटि में बदलने के लिए एक इंटरफ़ेस प्रदान करता है, लेकिन आपको केवल इतना मिलता है कि आप मुख्य iPython दुभाषिया लूप में वापस आते हैं, बिना किसी बैकट्रेस के।

@jdemeyer Cythignals से sig_on() / sig_off() के बीच Cython कोड एक FPU ध्वज उठाए जाने पर एक अपवाद फेंक देंगे ? या यह ध्वज पर निर्भर करता है?

cysignals फेंक देंगे एक अपवाद SIGFPE है, जो कि FPU कॉन्फ़िगरेशन के आधार पर FPU ध्वज उठाए जाने पर हो सकता है। लेकिन डिफ़ॉल्ट रूप से यह नहीं होता है।

इसी तरह की चेतावनी: RuntimeWarning: invalid value encountered in greater है
np.float64(5)>e से आ रहा है। यहाँ e Sagemath निरंतर प्राकृतिक लघुगणक 2.71828 के आधार को निर्दिष्ट करता है ..., और इसलिए True का मूल्यांकन करने के तरीके पर इसे "परिवर्तित" (निश्चित रूप से, ई) जानता है "इसके संख्यात्मक सन्निकटन, यह e.n() ) एक संख्या है।
यह अनुमान RealField पहले ही ऊपर उल्लेखित है (इसलिए शायद यह चेतावनी निकट से संबंधित है)।

फिर, सवाल यह है: numpy np.float64(5)>e का मूल्यांकन करने के लिए क्या करता है?
या समकक्ष, एक ही चेतावनी np.float64(5).__gt__(e) से पॉप अप करती है, इसलिए कोई भी बस वहां से शुरू कर सकता है।

ध्यान दें कि type(e) sage.symbolic.constants_c.E ; यह मूल रूप से कुछ (लगभग) डमी क्लास है
सांपमठ की प्रतीकात्मक अभिव्यक्तियों को लपेटना ( SR )।

np.float64(5).__gt__(e.n()) या np.float64(5)>e.n() से कोई चेतावनी नहीं है।
यदि आप e pi (स्पष्ट pi.n()==3.1.415... साथ) को प्रतिस्थापित करते हैं, तो अनिवार्य रूप से समान (समान चेतावनी / कोई चेतावनी पैटर्न) होता है।
pi का प्रकार SR , अर्थात sage.symbolic.expression.Expression ।

यहाँ उत्तर एक ही है - सुन्न एक वस्तु लूप के साथ np.greater कॉल करता है। निचले स्तर पर, जो e.__lt__(5.0) कॉल करता है। लेकिन एक बार फिर, यह पहले और बाद में एफपीयू झंडे की जांच करता है, और नोटिस करता है कि कुछ एमिस है।

Ndarray अंकगणित / तार्किक ऑपरेटरों के अधिकांश ( - और divmod के अपवाद के साथ) ufuncs को सौंपते हैं। जब ऋषि वस्तुओं के साथ आह्वान किया जाता है, तो यह इन ufuncs के लिए O (ऑब्जेक्ट) लूप को कॉल करेगा। ये ऑब्जेक्ट लूप ऐरे के ऊपर लूप करेंगे (जो इस मामले में 0d है), तत्वों पर सामान्य पायथन ऑपरेटर को चलाते हैं, _बल्कि ऐसा करने पर FPU झंडे की जाँच करें।

इसलिए एक बार फिर ऋषि इन झंडों को स्थापित कर रहे हैं। शायद यह एक बग का संकेत है, शायद इसकी नहीं।

मुझे लगता है कि यहाँ एक अच्छा तर्क है कि इन मामलों के लिए सुन्न को fpu झंडे की जाँच नहीं करनी चाहिए। @njsmith , क्या आपको लगता है कि हमें ऑब्जेक्ट प्रकारों के लिए चेक को हटाने के साथ आगे बढ़ना चाहिए?

तथ्य की बात के रूप में, e.__lt__(5.0) एक प्रतीकात्मक अभिव्यक्ति है:

sage: type(e.__lt__(np.float32(5.0)))
<type 'sage.symbolic.expression.Expression'>
sage: e.__lt__(np.float32(5.0))
e < 5.0
sage: bool(e.__lt__(np.float32(5.0)))  # this is how it's evaluated
True

और इस प्रकार मुझे वास्तव में संदेह है कि इसे अंत में कहा जाता है, क्योंकि एक को True । इसके अलावा, ऊपर से आपके check_fpu रैपर इसे प्रिंट चेतावनी नहीं देते हैं, अर्थात निम्नलिखित सिर्फ काम करता है।

sage: check_fpu(e.__lt__)(np.float32(5.0))
e < 5.0

मैं किसी खास सी एक्सटेंशन का उपयोग कर के लिए नीचे Sagemath में हमारी समस्या पिन करने में सक्षम था fpectl पायथन मॉड्यूल (जो कुछ हद तक है, लेकिन नहीं पूरी तरह से, FreeBSD पर टूट)। एक बार इसे स्थापित करने में कामयाब होने के बाद यह वास्तव में बहुत जल्दी था।

IMHO fpectl इतना उपयोगी है कि इसे ठीक किया जाना चाहिए; शायद इसके बजाय, या np.seterr() बजाय सुन्न में उपयोग किया जाता है, क्योंकि यह कंपोनेंट घटकों पर बेहतर ग्रैन्युलैरिटी प्रदान करता है।

Fpectl के दृष्टिकोण और np.seterr के बीच का अंतर है:

np.seterr ufunc लूप चलाता है, और फिर यह देखने के लिए जांचता है कि क्या कोई झंडे सेट हैं।

fpectl इसे बनाने के लिए कुछ जादू करता है ताकि जब भी कोई ऑपरेशन होता है जिसमें से एक झंडे को सेट करने का कारण बनता है, तो हार्डवेयर एक बाधा उत्पन्न करता है, कर्नेल इसे एक SIGFPE में परिवर्तित कर देता है, जो प्रक्रिया को दिया जाता है, और यह स्थापित करता है SIGFPE हैंडलर कि longjmp s सीधे सिग्नल हैंडलर से बाहर त्रुटि हैंडलिंग कोड में।

fpectl दृष्टिकोण के कुछ डाउनसाइड हैं: (ए) यह विंडोज पर बिल्कुल भी काम नहीं करता है, (बी) यह कोड के लिए टूट जाता है जो आंतरिक रूप से इनमें से एक झंडे को अस्थायी रूप से सेट करने का कारण बनता है और फिर इसे साफ करता है (यह) कानूनी है और मुझे उम्मीद है कि लिबम के लोग ऐसा करते हैं), (c) longjmp अविश्वसनीय रूप से नाजुक है; मूल रूप से आप हर बार जब आप इसे करते हैं तो एक segfault को जोखिम में डालते हैं। यह निश्चित रूप से उपयोगकर्ता-परिभाषित ufuncs के लिए एक सामान्य समाधान नहीं हो सकता है।

यह सब देखते हुए, मुझे नहीं लगता कि सुन्न स्विच करने जा रहा है।

किसी भी मामले में, ऐसा लगता है कि मूल मुद्दा हल हो गया है, इसलिए इसे बंद करना - एक नया मुद्दा खोलने के लिए स्वतंत्र महसूस करें यदि आप seterr में बदलाव के लिए मामला बनाना चाहते हैं।

किसी भी मामले में, ऐसा लगता है कि मूल मुद्दा हल हो गया है

क्या हम सुनिश्चित हैं कि हम ऑब्जेक्ट लूप के लिए FPU झंडे की जाँच को अक्षम नहीं करना चाहते हैं? यह एक बहुत समझदार परिवर्तन के रूप में सुन्न करने के लिए प्रतीत होता है।

@ eric-wieser: ओह, यह एक दिलचस्प विचार है, हाँ। शायद यह उस :-) के लिए एक मुद्दा खोलने के लायक है। हालांकि "सही बात" बहुत जटिल है - आदर्श रूप से हमें ऑब्जेक्ट dtype (थिंक यूज़र dtypes) के लिए विशेष-आवरण नहीं होना चाहिए, और पूर्णांक लूप भी इसका उपयोग नहीं करना चाहिए (यह कुछ आर्किटेक्चर पर एक वास्तविक अनुकूलन हो सकता है जहां जाँच हो रही है / FPU झंडे साफ़ करना बेहद धीमा है), लेकिन पूर्णांक लूप्स को पूर्णांक त्रुटियों को स्पष्ट रूप से संकेत करने के लिए एक तरीका चाहिए, जो वे वर्तमान में स्पष्ट रूप से FPU झंडे स्थापित करके करते हैं, ... मुझे यकीन नहीं है कि यह एक ऐसा मामला है जहां आसान कम है फल बदल रहा है?

या क्या मुझे गलतफहमी हुई, और ऋषि ने केवल समस्या की पहचान की है, और वास्तव में इसे ठीक करने के लिए उन्हें अभी भी एक महत्वपूर्ण बदलाव की आवश्यकता है?

@njsmith : मुझे समझ नहीं आता कि आप यह क्यों कहते हैं कि यह विंडोज पर काम नहीं करेगा। (यह पूर्व C99 युग में सही होगा, हालांकि)। जैसे ही आपका C कंपाइलर C99- स्टैंडर्ड कंप्लेंट होता है, आधुनिक FPU-हैंडलिंग फंक्शन (fenv) उपलब्ध होते हैं। Fenv के अलावा सभी की जरूरत है setjmp / longjmp (फिर से, मानक सी सुविधा)।

मैं एक लिबम के बारे में सुनने के लिए उत्सुक हूं जो सामान्य ऑपरेशन के दौरान एफई अपवादों में से एक का कारण बनता है।
(जब तक इसे बग के रूप में वर्गीकृत नहीं किया जाता है)।

@ डिम्पेस : आपको SIGFPE समर्थन की भी आवश्यकता है, जो C99 में निर्दिष्ट नहीं है। (ठीक है, C99 का कहना है कि एक SIGFPE होना चाहिए, लेकिन यह डिवाइड-बाय-जीरो के लिए है - यह फ्लोटिंग पॉइंट अपवादों को हुक करने का कोई तरीका निर्दिष्ट नहीं करता है।) उन्होंने कहा, ऐसा लगता है कि मैं गलत तरीके से देखता हूं, और विंडोज। संकेतों का समर्थन नहीं करता है, MSVCRT संरचित अपवाद हैंडलिंग का उपयोग करके SIGFPE का अनुकरण करता है, और विशेष fp अपवादों के लिए इसे सक्षम करने के लिए गैर-मानक _control_fp फ़ंक्शन प्रदान करता है, इसलिए Windows समर्थन वास्तव में एक बाधा नहीं है। OTOH से कोई फर्क नहीं पड़ता कि longjmp निश्चित रूप से एक बहुत अच्छे कारण के बिना नहीं हो रहा है :-)

और एफडब्ल्यूआईडब्ल्यू, अगर एक एफएबीएम ने एक एफई अपवाद का कारण बना दिया और फिर इसे फिर से मंजूरी दे दी, तो मैं यह नहीं देख सकता कि वे इस बात पर विचार क्यों करेंगे। मुझे यकीन नहीं है कि इस तरह के किसी भी कार्यान्वयन मौजूद हैं, लेकिन यह प्रशंसनीय है, और अगर वे करते हैं तो जिस तरह से हमें पता चलेगा वह है b / c कोई हमें बताता है कि प्लेटफार्म X पर सुन्नता टूट गई है और केवल परिवर्तन को वापस करना होगा आपने सुझाव दिया।

क्या आप मेरी पिछली टिप्पणी के अंत में मेरे द्वारा पूछे गए प्रश्न का उत्तर दे सकते हैं?

@njsmith : यदि किसी libm (या किसी अन्य उपयोगकर्ता कोड) को FE अपवाद बनाने और उसे संसाधित करने की आवश्यकता है, तो वह अपना FE अपवाद हैंडलर सेट करेगा, पिछले एक को सहेज रहा है, और बाहर निकलने पर पिछले एक को पुनर्स्थापित कर रहा है।
तो यह एक समस्या नहीं है यदि अंतर्निहित कोड नियमों द्वारा खेल रहा है।

इसके लिए MS सपोर्ट के बारे में, वे Visual C (++) 2013 या उसके बाद fenv.h शिप करते हैं ।
यह विशेष रूप से सेटजम्प / लॉन्गजम्प के साथ उपयोगी होने के लिए है (यह वास्तव में हुड के तहत किया जाता है, एक बहुत चिंता नहीं करनी चाहिए, मुझे उम्मीद है)।

सुन्न के बारे में

• अगर आपको लगता है कि उपयोगकर्ता कोड एफपी झंडे के साथ तेज और ढीला खेल सकता है, तो इन चेतावनियों को वैकल्पिक होना चाहिए।
• अन्यथा, उन्हें मानक रखा जा सकता है, लेकिन कम से कम जिस जगह से वे आते हैं, उसके तल तक जाने का एक तरीका उनके लिए उपयोगी है; (बेहतर) fpectl बाद प्राप्त करने का एक त्वरित तरीका है। बाहरी उपकरणों का उपयोग करना (जैसे कि डिबगर्स आपको हर निर्देश के बाद कुछ को जांचने के लिए कोड को इंस्ट्रूमेंट करने की अनुमति देता है) कठिन, धीमा और अधिक त्रुटि-प्रवण है --- जैसे कि यह असामान्य नहीं है कि बग केवल एक अनुकूलित बाइनरी पर पॉप अप करता है, और जैसे ही आप इसे अच्छी तरह से डीबग करने योग्य बाइनरी पर खोजने का प्रयास करते हैं, दूर हो जाता है।
• किसी भी स्थिति में, रनटाइमटाइमिंग चीज़ को बंद करना संभव होना चाहिए।

ऋषि में इस मुद्दे के बारे में - अभी भी फिक्सिंग (उम्मीद है कि यह केवल एमपीएफआर में कुछ मुद्दों तक सीमित है)।

क्षमा करें, यह मंडलियों में जा रहा है और मुझे अन्य चीजों पर जाने की आवश्यकता है, इसलिए जब तक fenv / sigfpe मुद्दे पर कुछ नया नहीं आता है, यह इस विषय पर मेरा अंतिम संदेश होगा। (मुझे अभी भी दिलचस्पी है अगर ऋषि बग के लिए कुछ भी करने की ज़रूरत नहीं है)।

यदि किसी libm (या किसी अन्य उपयोगकर्ता कोड) को FE अपवाद बनाने और उसे संसाधित करने की आवश्यकता है, तो वह अपना FE अपवाद हैंडलर सेट करेगा, जो पिछले एक को सहेज रहा है,

आप जो प्रस्ताव कर रहे हैं वह एक ऐसा ऑपरेशन करना है जो आम तौर पर सिग्नल हैंडलर को आग नहीं देता है, और प्रोसेसर को गैर-मानक मोड में कॉन्फ़िगर करता है जहां यह सिग्नल हैंडलर को आग लगाता है। यह कोड इस ऑपरेशन को करने के लिए पूरी तरह से उचित है और उम्मीद करता है कि यह सिग्नल हैंडलर को बिल्कुल भी ट्रिगर नहीं करेगा।

इसके लिए MS सपोर्ट के बारे में, वे Visual C (++) 2013 या उसके बाद fenv.h शिप करते हैं।
यह विशेष रूप से setjmp / longjmp के साथ उपयोगी होने के लिए है

मैं यह पता नहीं लगा सकता कि आप यहाँ क्या बात कर रहे हैं। Afaict, fenv.h में मानक कार्यक्षमता केवल संख्यात्मक शैली की कार्यक्षमता को लागू करने के लिए उपयोगी है, और MS मानक पर चिपक जाता है। मुझे वहां कोई भी कार्य दिखाई नहीं देता है जिसका उपयोग सेटजम्प / लॉन्गजम्प के साथ किया जा सकता है।

उपयोगकर्ता कोड एफपी झंडे के साथ तेज और ढीले खेल सकते हैं, फिर इन चेतावनियों को वैकल्पिक होना चाहिए।

एक मध्यवर्ती गणना द्वारा निर्धारित ध्वज को सावधानीपूर्वक साफ़ करना उनके साथ तेज और ढीले खेलने का सटीक विपरीत है। इसके अलावा, चेतावनी वैकल्पिक हैं।

जिस स्थान से वे आते हैं, उसके तल तक जाने का एक तरीका उनके लिए महत्वपूर्ण है; (बेहतर) fpectl बाद प्राप्त करने का एक त्वरित तरीका है।

आप वस्तुतः इस तरह के मुद्दे पर बहस करने के लिए SIGFPE की जरूरत के लिए एक दशक की तरह पहले व्यक्ति हैं, और ऋषि बग टिप्पणियों पर फिर से देख रहे हैं, ऐसा लगता है कि आपको वास्तव में fpectl काम नहीं मिला? यह कोर डंप का कारण नहीं माना जाता है। (ऐसा लगता है कि cysignals fpectl कोड को ओवरराइड कर रहा है, इसलिए यह चलता भी नहीं है।)

यदि यह फिर से आता है, तो आपको SIGFPE को सक्षम करने के लिए एक C कॉल करने की आवश्यकता है, तो स्टैक ट्रेस प्राप्त करने के लिए डीबगर का उपयोग करें। स्टैक ट्रेस प्राप्त करने के लिए आपको डीबग बिल्ड की आवश्यकता नहीं है; तुम सब करने की जरूरत है प्रतीकों पट्टी नहीं है। और हे, अब हम जानते हैं कि यह मामला फिर से सामने आता है।

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

अंत में, यह पता चला है कि यह क्लैंग सी कंपाइलर में एक लंबे समय तक चलने वाले बग को उबालता है। मूल रूप से, double एक निश्चित सीमा में असाइनमेंट

unsigned long a;
double b;
...
a = b;

FE_INVALID उठाता है (और कभी-कभी FE_INEXACT ); btw यह फ्लोट डेटा के अन्य प्रकारों को भी प्रभावित कर रहा है। महान एमपीएफआर (एमपीएफआर को युगल को अपने मनमाने ढंग से सटीक फ़्लोट्स में कॉपी करना पड़ता है, निश्चित रूप से) लोगों ने ऋषि को इसे ठीक करते हुए एक वर्कअराउंड प्रदान किया।

संयोग से, एक से संबंधित और भी अधिक लंबे समय से (2010 के बाद से, एक दर्जन से अधिक के साथ बंद डुप्लिकेट) बजना बग 8100 का कहना है का उपयोग करने का बजना की कोई उम्मीद है कि वहाँ fenv.h बनाने के लिए fpectl ठीक से पल में काम कर । इस संबंध में क्लैंग पूरी तरह से C99- अनुरूप नहीं है, और इसके बारे में वास्तव में शर्मीली है।

निश्चित नहीं है कि numpy इसके बारे में कुछ भी करना चाहता है; शायद एक टिप्पणी कि RuntimeWarning केवल एक कंपाइलर बग के कारण हो सकता है ("क्लैंग बग 8100" का हवाला देते हुए, यह एक काफी प्रमुख उदाहरण है) सहायक हो सकता है।

बग 8100 प्रासंगिक नहीं है; C99 के लिए यह फ़्लोटिंग पॉइंट ऑप्टिमाइज़ेशन को अक्षम करने के लिए है, और मुख्यधारा के कंपाइलर उन का समर्थन नहीं करते हैं। numpy लगता है (ज्यादातर) वैसे भी काम :-)

बग 8100 की भावना यह है कि क्लेंग एफपी संचालन को सही ढंग से संकलित करने के बारे में परवाह नहीं करता है; हालांकि एक वकील असहमत हो सकता है। :-)

ठीक है, पहले से ही उल्लेख किया गया बग 17686 निश्चित रूप से प्रासंगिक है।