संख्या 1e9999 क्यों है ... (31 9 एस) आर में समस्याएं पैदा करता है?

Question

1e9999999999999999999999999999999 में आर में प्रवेश करते समय, आर लटकता है और जवाब नहीं देगा - इसे समाप्त करने की आवश्यकता है।

ऐसा लगता है कि यह 3 अलग-अलग कंप्यूटर, ओएस (विंडोज 7 और उबंटू) में होता है। यह रुस्टूडियो, आरजीईई और आरस्क्रिप्ट में होता है।

यहाँ और अधिक आसानी से संख्या उत्पन्न करने के लिए कुछ कोड है:

boom <- paste(c("1e", rep(9, 31)), collapse="") 
eval(parse(text=boom)) 

अब स्पष्ट रूप से यह एक व्यावहारिक समस्या नहीं है। मुझे इस परिमाण की संख्या का उपयोग करने की आवश्यकता नहीं है। यह जिज्ञासा का सिर्फ एक सवाल है।

मजे की बात है, अगर आप 1e9999999999999999999999999999998 या 1e10000000000000000000000000000000 (जोड़ सकते हैं या बिजली से एक घटाना) प्रयास करने पर आपको Inf और 0 क्रमशः मिलता है। यह संख्या स्पष्ट रूप से किसी प्रकार की सीमा है, लेकिन यहां और क्यों के बीच?

मैं माना जाता है कि यह हो सकता है:

• एक चल बिन्दु समस्या है, लेकिन मैं वे 1.7977e308 पर बाहर अधिकतम लगता है, लंबे समय से प्रश्न में नंबर से पहले।
• 32-बिट पूर्णांक वाले एक समस्या, लेकिन 2^32 42 9 4 9 672 9 6 है, जो प्रश्न में संख्या से बहुत छोटा है।
• वास्तव में अजीब। यह मेरा प्रमुख सिद्धांत है।

संपादित करें: नवीनतम रूप से 2015-09-15 तक, यह अब आर को लटका देता है। उन्होंने इसे पैच किया होगा।

Answer 1

यह पार्सर में एक चरम मामले की तरह दिखता है। XeY प्रारूप को R Language Definition में वर्णित किया गया है और वर्तमान में स्वीकृत प्रारूपों पर अद्यतित जानकारी के लिए ?NumericConstants पर अंक दिया गया है।

समस्या यह प्रतीत होती है कि पार्सर एक्सपोनेंट को कैसे संभालता है।सांख्यिक निरंतर NumericValue (लाइन main/gram.c की 4361) है, जो कहता है mkFloat (लाइन main/gram.c की 4124) है, जो कहता है R_atof (लाइन main/util.c 1584 की) है, जो कहता है R_strtod4 (लाइन main/util.c की 1461) द्वारा नियंत्रित किया जाता। (सभी संशोधन 60052. के रूप में)

लाइन main/utils.c के 1464 शो expnint रूप में घोषित किया है और यह लाइन 1551 में अतिप्रवाह जाएगा अगर प्रतिपादक बहुत बड़ी है। हस्ताक्षरित पूर्णांक ओवरफ़्लो अपरिभाषित व्यवहार का कारण बनता है।

उदाहरण के लिए, नीचे दिए गए कोड मूल्यों एक्स्पोनेंट्स < 308 या तो और घातांक के लिए Inf के लिए पैदा करता है> 308.

const <- paste0("1e",2^(1:31)-2) 
for(n in const) print(eval(parse(text=n))) 

आप घातांक के लिए अपरिभाषित व्यवहार देख सकते हैं> 2^31 (आर एक प्रतिपादक के लिए लटकी हुई है = 2^31):

const <- paste0("1e",2^(31:61)+1) 
for(n in const) print(eval(parse(text=n))) 

मुझे शक है क्योंकि आर केवल के बीच के बारे में 2 ई-308 के लिए 2 ई + 308 (?double देखें) और इस संख्या है संख्यात्मक मान स्टोर कर सकते हैं इस आर-कोर से कोई ध्यान मिल जाएगा जिस तरह से उससे परे।

Answer 2

आर कभी-कभी bignums का उपयोग कर सकता है। शायद 1e9999999999999999999999999999999 कुछ थ्रेसहोल्ड है, या शायद पार्सिंग रूटीन में एक्सपोनेंट पढ़ने के लिए सीमित बफर है। आपका अवलोकन एक्सपोनेंट के लिए 32 char (null-terminated) बफर के साथ संगत होगा।

मैं उन प्रश्नों या मेलिंग सूची पर आर पर विशिष्ट प्रश्न पूछूंगा, जो कि दोस्ताना होने की अफवाह है।

वैकल्पिक रूप से, आर मुफ्त सॉफ्टवेयर है, तो आप इसके स्रोत कोड की जांच कर सकते हैं।

Answer 3

यह दिलचस्प है, लेकिन मुझे लगता है कि आर बहुत बड़ी एक्स्पोनेंट्स है पार्स संख्या के साथ प्रणालीगत समस्या है:

> 1e10000000000000000000000000000000 
[1] 0 
> 1e1000000000000000000000000000000 
[1] Inf 
> 1e100000000000000000000 
[1] Inf 
> 1e10000000000000000000 
[1] 0 
> 1e1000 
[1] Inf 
> 1e100 
[1] 1e+100 

वहाँ हम चले, अंत में कुछ उचित। इस आउटपुट के अनुसार और जोशुआ उलरिच की टिप्पणी नीचे दी गई है, आर लगभग 2e308 तक संख्याओं का प्रतिनिधित्व करने और + 2 * 10^9 तक एक्सपोनेंट के साथ पार्सिंग संख्याओं का समर्थन करने का समर्थन करता है, लेकिन यह उनका प्रतिनिधित्व नहीं कर सकता है। इसके बाद, ओवरफ्लो के कारण जाहिर तौर पर अनिश्चित व्यवहार होता है।