क्यों (inf + 0j) * 1 inf + nanj का मूल्यांकन करता है?


97
>>> (float('inf')+0j)*1
(inf+nanj)

क्यों? यह मेरे कोड में एक बुरा बग का कारण बना।

1गुणक पहचान क्यों नहीं दे रहा है (inf + 0j)?


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

1
ओह, और यदि आप इन मूर्खताओं को निराशाजनक पाते हैं और अपने कंप्यूटर को पंच करना चाहते हैं, तो आपको मेरी सहानुभूति है
user541686

2
@ मेहरदाद एक बार जब आप उन गैर परिमित तत्वों को जोड़ते हैं तो यह एक क्षेत्र बनना बंद हो जाता है। वास्तव में, जैसा कि एक बहुसांस्कृतिक तटस्थ नहीं है, यह परिभाषा द्वारा क्षेत्र नहीं हो सकता है।
पॉल पैंजर

@PaPPanzer: हाँ, मुझे लगता है कि उन्होंने बाद में उन तत्वों को हिला दिया।
user541686

1
फ़्लोटिंग पॉइंट नंबर (भले ही आप अनन्तता और NaN को छोड़ दें) एक फ़ील्ड नहीं है। अधिकांश पहचान जो खेतों के लिए होती हैं वे फ्लोटिंग पॉइंट नंबरों के लिए नहीं होती हैं।
14

जवाबों:


95

1पहले एक जटिल संख्या में बदल जाती है, 1 + 0jहै, जो तब एक पर ले जाया जाता inf * 0गुणा, एक में जिसके परिणामस्वरूप nan

(inf + 0j) * 1
(inf + 0j) * (1 + 0j)
inf * 1  + inf * 0j  + 0j * 1 + 0j * 0j
#          ^ this is where it comes from
inf  + nan j  + 0j - 0
inf  + nan j

8
प्रश्न का उत्तर देने के लिए "क्यों ...?", शायद सबसे महत्वपूर्ण कदम पहला है, जहां 1डाली जाती है 1 + 0j
वारेन वीकेसर

5
ध्यान दें कि C99 निर्दिष्ट करता है कि वास्तविक फ़्लोटिंग-पॉइंट प्रकारों को एक जटिल प्रकार (ड्राफ्ट मानक के खंड 6.3.1.8) द्वारा गुणा करने पर जटिल को बढ़ावा नहीं दिया जाता है, और जहाँ तक मुझे पता है कि यह C ++ के std :: complex का सच है। यह आंशिक रूप से प्रदर्शन कारणों से हो सकता है लेकिन यह अनावश्यक NaN से भी बचता है।
बेर्ग सिप

NumPy में @benrg, array([inf+0j])*1का मूल्यांकन भी करता है array([inf+nanj])। यह मानते हुए कि वास्तविक गुणा C / C ++ कोड में कहीं होता है, तो क्या इसका मतलब यह होगा कि उन्होंने CPComthon व्यवहार का अनुकरण करने के लिए कस्टम कोड लिखा, बजाय _Complex या std :: complex का उपयोग किए?
मार्निक्स 22'19

1
@marnix यह उससे कहीं अधिक शामिल है। numpyएक केंद्रीय वर्ग ufuncहै जहाँ से लगभग हर ऑपरेटर और फ़ंक्शन व्युत्पन्न होता है। ufuncप्रसारण प्रबंधन का ध्यान रखता है कि सभी ट्रिकी एडमिन को व्यवस्थित करता है जो सरणियों के साथ काम करना इतना सुविधाजनक बनाता है। अधिक सटीक रूप से एक विशिष्ट ऑपरेटर और सामान्य मशीनरी के बीच श्रम का विभाजन यह है कि विशिष्ट ऑपरेटर इनपुट और आउटपुट तत्व के प्रत्येक संयोजन के लिए "अंतरतम छोरों" का एक सेट लागू करता है जिसे वह संभालना चाहता है। सामान्य मशीनरी किसी भी बाहरी छोरों की देखभाल करती है और सबसे अच्छा मैच अंतरतम लूप का चयन करती है ...
पॉल पैंजर

1
... आवश्यकतानुसार किसी भी प्रकार के मिलान को बढ़ावा नहीं देना। हम इस पैदावार के typesलिए विशेषता के माध्यम से प्रदान की गई आंतरिक छोरों की सूची तक पहुंच सकते हैं हम देख सकते हैं कि लगभग कोई मिश्रित प्रकार नहीं हैं, विशेष रूप से, कोई भी मिश्रण जटिल के साथ फ्लोट नहीं करता है । np.multiply['??->?', 'bb->b', 'BB->B', 'hh->h', 'HH->H', 'ii->i', 'II->I', 'll->l', 'LL->L', 'qq->q', 'QQ->Q', 'ee->e', 'ff->f', 'dd->d', 'gg->g', 'FF->F', 'DD->D', 'GG->G', 'mq->m', 'qm->m', 'md->m', 'dm->m', 'OO->O']"efdg""FDG"
पॉल पैंजर

32

यंत्रवत्, स्वीकृत उत्तर, निश्चित रूप से, सही है, लेकिन मैं तर्क दूंगा कि एक गहरा ansswer दिया जा सकता है।

सबसे पहले, यह प्रश्न को स्पष्ट करने के लिए उपयोगी है क्योंकि @PeterCordes एक टिप्पणी में करता है: "क्या जटिल संख्याओं के लिए एक गुणक पहचान है जो inf + 0j पर काम करती है?" या दूसरे शब्दों में, ओपी को जटिल गुणा के कंप्यूटर कार्यान्वयन में कमजोरी दिखाई देती है या क्या वैचारिक रूप से कुछ गलत हैinf+0j

संक्षिप्त जवाब:

ध्रुवीय निर्देशांक का उपयोग करके हम जटिल गुणन को स्केलिंग और रोटेशन के रूप में देख सकते हैं। एक अनंत "भुजा" को 0 डिग्री तक घुमाते हुए भी एक से गुणा करने की स्थिति में हम उसके सिरे को परिमित परिशुद्धता के साथ रखने की अपेक्षा नहीं कर सकते। इसलिए वास्तव में, मौलिक रूप से कुछ सही नहीं है inf+0j, अर्थात्, जैसे ही हम अनंत पर होते हैं एक परिमित ऑफसेट अर्थहीन हो जाता है।

लंबा जवाब:

पृष्ठभूमि: "बड़ी बात" जिसके चारों ओर यह सवाल घूमता है वह संख्याओं की एक प्रणाली का विस्तार करने का मामला है (वास्तविक या जटिल संख्याएं सोचें)। एक कारण हो सकता है कि कोई ऐसा करना चाहे जो अनन्तता की कुछ अवधारणा को जोड़ दे, या "गणित" करने के लिए, यदि कोई गणितज्ञ होता है। अन्य कारण भी हैं, ( https://en.wikipedia.org/wiki/Galois_theory , https://en.wikipedia.org/wiki/Non-standard_analysis ), लेकिन हम यहाँ उन लोगों में रुचि नहीं रखते हैं।

एक बिंदु जमाव

इस तरह के विस्तार के बारे में मुश्किल सा यह है कि हम चाहते हैं कि ये नए नंबर मौजूदा अंकगणित में फिट हों। सबसे सरल तरीका अनंत में एक तत्व को जोड़ना है ( https://en.wikipedia.org/wiki/Alexandroff_extension ) और इसे शून्य से विभाजित शून्य के बराबर कुछ भी बनाते हैं। यह वास्तविक ( https://en.wikipedia.org/wiki/Projectively_extended_real_line ) और जटिल संख्या ( https://en.wikipedia.org/wiki/Riemann_sphere ) के लिए काम करता है ।

अन्य एक्सटेंशन ...

जबकि एक बिंदु कॉम्पैक्टिफ़िकेशन सरल और गणितीय रूप से ध्वनि है, "मल्टीफ़ोर" एक्सटेंशन जिसमें कई infinties शामिल हैं, की मांग की गई है। वास्तविक फ्लोटिंग पॉइंट नंबरों के लिए IEEE 754 मानक में + inf और -inf ( https://en.wikipedia.org/wiki/Extended_real_number_line ) है। प्राकृतिक और सीधा लगता है, लेकिन पहले से ही हमें हुप्स के माध्यम से कूदने और https://en.wikipedia.org/wiki/Sign_zero जैसे सामान का आविष्कार करने के लिए मजबूर करता है।-0

... जटिल विमान में

जटिल विमान के अधिक-से-एक-inf एक्सटेंशन के बारे में क्या?

कंप्यूटर में, जटिल संख्याओं को आम तौर पर दो fp वास्तविक को एक साथ चिपकाकर और एक को काल्पनिक भाग के लिए लागू किया जाता है। यह पूरी तरह से ठीक है जब तक सब कुछ परिमित है। हालाँकि, हालाँकि, जैसा कि शिशुओं को माना जाता है कि चीजें मुश्किल हो जाती हैं।

कॉम्प्लेक्स प्लेन में एक प्राकृतिक घूर्णी समरूपता होती है, जो पूरी तरह से ई ^ फीज द्वारा पूरे विमान को गुणा करने के रूप में कॉम्प्लेक्स अंकगणित के साथ संबंध रखती है 0। यह चारों ओर फी रेडियन रोटेशन के समान है ।

वह एनेक्स जी चीज

अब, चीजों को सरल रखने के लिए, जटिल fp केवल अंतर्निहित वास्तविक संख्या कार्यान्वयन के एक्सटेंशन (+/- inf, nan आदि) का उपयोग करता है। यह विकल्प इतना स्वाभाविक लग सकता है कि इसे एक विकल्प के रूप में भी नहीं माना जाता है, लेकिन आइए देखें कि इसका क्या अर्थ है। कॉम्प्लेक्स प्लेन के इस विस्तार का एक सरल दृश्य इस तरह दिखता है (I = infinite, f = finite, 0 = 0)

I IIIIIIIII I
             
I fffffffff I
I fffffffff I
I fffffffff I
I fffffffff I
I ffff0ffff I
I fffffffff I
I fffffffff I
I fffffffff I
I fffffffff I
             
I IIIIIIIII I

लेकिन चूंकि एक सच्चा जटिल विमान वह है जो जटिल गुणा का सम्मान करता है, इसलिए एक अधिक जानकारीपूर्ण प्रक्षेपण होगा

     III    
 I         I  
    fffff    
   fffffff   
  fffffffff  
I fffffffff I
I ffff0ffff I
I fffffffff I
  fffffffff  
   fffffff   
    fffff    
 I         I 
     III    

इस प्रक्षेपण में हम अनन्तताओं का "असमान वितरण" देखते हैं जो न केवल बदसूरत है, बल्कि ओपी की तरह की समस्याओं का मूल भी है: अधिकांश अनन्तताएं (उन रूपों में से (+/- inf, finite) और (परिमित, + / -inf) को चार प्रमुख दिशाओं में एक साथ लंप किया जाता है, अन्य सभी दिशाओं को केवल चार शिशुओं (+/- inf, + -inf) द्वारा दर्शाया जाता है। यह एक आश्चर्य के रूप में नहीं आना चाहिए कि इस ज्यामिति में जटिल गुणन एक दुःस्वप्न है। ।

C99 ऐनक का अनुलग्नक G इसे कैसे infऔर nanअंतःक्रियात्मक रूप से infट्रम्प्स करता है, नियमों को झुकने सहित, इसे काम करने के लिए अपनी पूरी कोशिश करता है nan। ओपी की समस्या को वास्तविक रूप से बढ़ावा देने और जटिल रूप से एक प्रस्तावित काल्पनिक काल्पनिक प्रकार से दूर नहीं किया गया है, लेकिन वास्तविक 1 के जटिल 1 से अलग व्यवहार करता है और मुझे समाधान के रूप में हड़ताल नहीं करता है। बता दें, अनुलग्नक जी पूरी तरह से निर्दिष्ट करने से रोकता है कि दो शिशुओं का उत्पाद क्या होना चाहिए।

क्या हम बेहतर कर सकते हैं?

शिशुओं की बेहतर ज्यामिति का चयन करके इन समस्याओं को ठीक करने की कोशिश करना ललचाता है। विस्तारित वास्तविक रेखा के अनुरूप हम प्रत्येक दिशा के लिए एक अनन्तता जोड़ सकते हैं। यह निर्माण प्रक्षेप्य तल के समान है लेकिन विपरीत दिशाओं में एक साथ नहीं चलता है। Infinities को ध्रुवीय निर्देशांक inf xe ^ {2 ओमेगा pi i} में दर्शाया जाएगा, परिभाषित करने वाले उत्पाद सीधे होंगे। विशेष रूप से, ओपी की समस्या को स्वाभाविक रूप से हल किया जाएगा।

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

बचाव के लिए रीमैन

इन सब के मद्देनजर शायद अच्छा पुराना एक बिंदु कॉम्पैक्टिफिकेशन सबसे सुरक्षित चीज है। हो सकता है कि एनेक्स जी के लेखकों को एक ऐसा कार्य करते समय महसूस हुआ हो, जो एक cprojसाथ सभी शिशुओं को लुभाता हो।


यहाँ एक संबंधित प्रश्न है जिसका उत्तर मैं विषय की तुलना में अधिक सक्षम लोगों द्वारा देता हूँ।


5
हाँ, क्योंकि nan != nan। मैं समझता हूं कि यह उत्तर आधा-मजाक है, लेकिन मैं यह देखने में विफल हूं कि यह ओपी के लिए सहायक क्यों है जिस तरह से लिखा गया है।
cmaster - मोनिका

यह देखते हुए कि प्रश्न निकाय में कोड वास्तव में उपयोग नहीं किया गया था ==(और उन्हें दूसरे उत्तर को स्वीकार किया गया था), ऐसा लगता है कि यह सिर्फ एक समस्या थी कि ओपी ने शीर्षक कैसे व्यक्त किया। मैंने उस असंगतता को ठीक करने के लिए शीर्षक पुन: तैयार किया। (इस उत्तर के पहले भाग पर जानबूझकर हमला करना क्योंकि मैं @cmaster से सहमत हूं: यह वही नहीं है जिसके बारे में यह सवाल पूछ रहा था)।
पीटर कॉर्ड्स

3
@PeterCordes जो कि परेशान होंगे क्योंकि ध्रुवीय निर्देशांक का उपयोग करके हम स्केलिंग और रोटेशन के रूप में जटिल गुणा देख सकते हैं। एक अनंत "भुजा" को 0 डिग्री तक घुमाते हुए भी एक से गुणा करने के मामले में हम इसकी टिप को परिमित परिशुद्धता के साथ रखने की उम्मीद नहीं कर सकते हैं। यह मेरे विचार में स्वीकृत एक से अधिक गहन व्याख्या है, और नान में एको के साथ भी! = नैन नियम।
पॉल पैंजर

3
C99 निर्दिष्ट करता है कि वास्तविक फ़्लोटिंग-पॉइंट प्रकारों को एक जटिल प्रकार (ड्राफ्ट मानक के खंड 6.3.1.8) द्वारा गुणा करने पर जटिल को बढ़ावा नहीं दिया जाता है, और जहाँ तक मुझे पता है कि यह C ++ के std :: complex का सच है। इसका मतलब यह है कि 1 उन भाषाओं में उन प्रकारों के लिए एक गुणात्मक पहचान है। अजगर को भी ऐसा ही करना चाहिए। मैं इसके वर्तमान व्यवहार को केवल बग कहूंगा।
बेर्ग

2
@PaPPanzer: मैं नहीं, लेकिन मूल अवधारणा यह होगी कि एक शून्य (जिसे मैं Z कहूंगा) हमेशा x + Z = x और x * Z = Z, और 1 / Z = NaN, एक (सकारात्मक) को बनाए रखेगा। infinitesimal) 1 / P = + INF, एक (ऋणात्मक infinitesimal) 1 / N = -INF को बनाए रखेगा, और (अहस्ताक्षरित infinitesimal) 1 / U = NaN निकलेगा। सामान्य तौर पर, xx तब तक U होगा जब तक x एक वास्तविक पूर्णांक नहीं है, जिस स्थिति में यह Z पैदा करेगा।
सुपरकाट

6

यह एक कार्यान्वयन विवरण है कि सीपीथॉन में जटिल गुणन कैसे लागू किया जाता है। अन्य भाषाओं (जैसे C या C ++) के विपरीत, CPython कुछ हद तक सरल दृष्टिकोण लेता है:

  1. ints / floats को गुणा में जटिल संख्या में बढ़ावा दिया जाता है
  2. सरल स्कूल-सूत्र का उपयोग किया जाता है , जो अनंत संख्या में शामिल होते ही वांछित / अपेक्षित परिणाम प्रदान नहीं करता है:
Py_complex
_Py_c_prod(Py_complex a, Py_complex b)
{
    Py_complex r;
    r.real = a.real*b.real - a.imag*b.imag;
    r.imag = a.real*b.imag + a.imag*b.real;
    return r;
}

उपरोक्त कोड के साथ एक समस्याग्रस्त मामला होगा:

(0.0+1.0*j)*(inf+inf*j) = (0.0*inf-1*inf)+(0.0*inf+1.0*inf)j
                        =  nan + nan*j

हालांकि, एक -inf + inf*jपरिणाम के रूप में करना चाहते हैं ।

इस संबंध में अन्य भाषाएं बहुत आगे नहीं हैं: जटिल संख्या गुणा लंबे समय तक सी मानक का हिस्सा नहीं था, केवल परिशिष्ट जी के रूप में सी 99 में शामिल है, जो बताता है कि जटिल गुणन कैसे किया जाना चाहिए - और यह उतना सरल नहीं है ऊपर स्कूल सूत्र! C ++ मानक निर्दिष्ट नहीं करता है कि जटिल गुणन कैसे काम करना चाहिए, इस प्रकार अधिकांश संकलक कार्यान्वयन C-कार्यान्वयन पर वापस आ रहे हैं, जो कि C99 अनुरूप (gcc, clang) या नहीं (MSVC) हो सकता है।

उपरोक्त "समस्याग्रस्त" उदाहरण के लिए, C99- अनुरूप कार्यान्वयन (जो स्कूल सूत्र से अधिक जटिल हैं ) अपेक्षित परिणाम देगा ( लाइव देखें )

(0.0+1.0*j)*(inf+inf*j) = -inf + inf*j 

C99 मानक के साथ भी, सभी इनपुट के लिए एक अस्पष्ट परिणाम परिभाषित नहीं किया गया है और यह C99 के अनुरूप संस्करणों के लिए भी भिन्न हो सकता है।

C99 में floatपदोन्नत नहीं होने का एक अन्य दुष्प्रभाव यह complexहै कि इसके inf+0.0jसाथ गुणा करने 1.0या 1.0+0.0jइसके विभिन्न परिणाम हो सकते हैं (यहाँ देखें लाइव):

  • (inf+0.0j)*1.0 = inf+0.0j
  • (inf+0.0j)*(1.0+0.0j) = inf-nanj, काल्पनिक हिस्सा होने -nanऔर नहीं nan(CPython के लिए के रूप में) है क्योंकि सभी शांत Nans बराबर (देखें हैं एक भूमिका यहाँ खेलते हैं, यह नहीं है कि यह ), यहां तक कि उनमें से कुछ साइन-बिट निर्धारित (और इस तरह के रूप में मुद्रित "-", देखना यह ) और कुछ नहीं।

जो कम से कम प्रति-सहज है।


मेरी कुंजी इससे दूर है: "सरल" जटिल संख्या गुणा (या विभाजन) के बारे में कुछ भी सरल नहीं है और भाषाओं या यहां तक ​​कि संकलक के बीच स्विच करते समय किसी को सूक्ष्म कीड़े / मतभेदों के लिए खुद को बांधना चाहिए।


मुझे पता है कि बहुत सारे नैन बिट पैटर्न हैं। हालांकि साइन बिट बात पता नहीं था। लेकिन मेरा तात्पर्य यह था कि नान किस तरह नान से अलग है? या मुझे यह कहना चाहिए कि नैन से अधिक भिन्न है नैन?
पॉल पैंजर

@PaPPanzer यह केवल एक कार्यान्वयन विवरण है कि कैसे printfऔर इसी तरह के दोहरे के साथ काम करता है: वे साइन-बिट को देखने के लिए तय करते हैं कि क्या "-" मुद्रित होना चाहिए या नहीं (कोई फर्क नहीं पड़ता कि यह नान है या नहीं)। तो आप सही हैं, जवाब के इस हिस्से को जल्द ही ठीक करने में "नान" और "-नन" के बीच कोई सार्थक अंतर नहीं है।
EAD

आह अच्छा। एक मो के लिए चिंता थी कि मुझे लगा कि मुझे पता था कि fp के बारे में सब कुछ वास्तव में सही नहीं था ...
पॉल पैंजर

कष्टप्रद होने के लिए क्षमा करें, लेकिन क्या आपको यकीन है कि "कोई काल्पनिक 1.0 नहीं है, अर्थात 1.0j जो गुणन के संबंध में 0.0 + 1.0j के समान नहीं है।" सही है? यह अनुलग्नक G एक विशुद्ध काल्पनिक प्रकार (G.2) निर्दिष्ट करता है और यह भी बताता है कि इसे कैसे गुणा किया जाना चाहिए आदि (G.5.1)
पॉल पैंजर

@PaPPanzer नहीं, मुद्दों को इंगित करने के लिए धन्यवाद! जैसा कि सी ++ - कोडर, मैं ज्यादातर सी + + के माध्यम से सी + + मानक देखता हूं - यह मेरे दिमाग को फिसल गया, कि सी यहां एक कदम आगे है - आप सही स्पष्ट हैं, एक बार फिर से।
ead

3

पायथन से मजेदार परिभाषा। यदि हम इसे एक पेन और पेपर के साथ हल कर रहे हैं, तो मैं कहूंगा कि अपेक्षित परिणाम expected: (inf + 0j)जैसा कि आपने बताया, क्योंकि हम जानते हैं कि हमारा मतलब 1है(float('inf')+0j)*1 =should= ('inf'+0j) :

लेकिन ऐसा नहीं है जैसा कि आप देख सकते हैं ... जब हम इसे चलाते हैं तो हमें मिलता है:

>>> Complex( float('inf') , 0j ) * 1
result: (inf + nanj)

अजगर यह समझता है *1एक जटिल संख्या और नहीं के आदर्श के रूप में 1तो यह रूप में व्याख्या *(1+0j)और त्रुटि दिखाई देती है जब हम करने की कोशिश inf * 0j = nanjके रूप मेंinf*0 हल नहीं किया जा सकता है।

आप वास्तव में क्या करना चाहते हैं (1 को मान लेना 1 है):

याद रखें कि यदि z = x + iyवास्तविक भाग x और काल्पनिक भाग y के साथ एक जटिल संख्या है, के zरूप में परिभाषित किया गया है z* = x − iy, और निरपेक्ष मान, जिसे जटिल रूप में भी norm of zपरिभाषित किया गया है:

यहां छवि विवरण दर्ज करें

मान लिया जाए 1कि 1हम कुछ करना चाहते हैं:

>>> c_num = complex(float('inf'),0)
>>> value = 1
>>> realPart=(c_num.real)*value
>>> imagPart=(c_num.imag)*value
>>> complex(realPart,imagPart)
result: (inf+0j)

बहुत सहज नहीं है मुझे पता है ... लेकिन कभी-कभी कोडिंग भाषाओं को एक अलग तरीके से परिभाषित किया जाता है जो हम अपने दिन के दिनों में उपयोग करते हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.