🤼 🤟🏼 🧑🏿‍🤝‍🧑🏾 जावास्क्रिप्ट: बिग होल पूरा क्यों 🎆 🍺 🛴

बहुत समय पहले, जावास्क्रिप्ट ने मनमाने ढंग से सटीक संख्याओं के साथ काम करने के लिए एक नया आदिम BigInt डेटा प्रकार का दावा किया । प्रेरणा और उपयोग के मामलों के बारे में आवश्यक न्यूनतम जानकारी पहले ही बताई गई है / अनुवादित है । और मैं टाइप कास्टिंग और अनपेक्षित TypeError में अतिरंजित स्थानीय "खोजकर्ता" पर थोड़ा अधिक ध्यान देना चाहूंगा। क्या हम डाँटेंगे या समझेंगे और क्षमा करेंगे (फिर से)?

स्पष्ट हो जाता है?

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

1 + {}; // '1[object Object]' 1 + [[0]]; // '10' 1 + new Date; // '1Fri Feb 08 2019 00:32:57 GMT+0300 (,  )' 1 - new Date; // -1549616425060 ...

हमें अचानक एक टाइपर्र मिलता है, दो समान रूप से जोड़ने की कोशिश कर रहा है:

 1 + 1n; // TypeError: Cannot mix BigInt and other types, use explicit conversions

और अगर निहित चीजों के पिछले अनुभव ने भाषा सीखने में कोई कमी नहीं की, तो ईसीएमए पाठ्यपुस्तक को तोड़ने और कुछ जावा में जाने का दूसरा मौका है।

इसके अलावा, भाषा डेवलपर्स को "ट्रोल" करना जारी रखती है:

 1n + '1'; // '11'

अरे हाँ, यूनरी + ऑपरेटर के बारे में मत भूलना:

 +1n; // TypeError: Cannot convert a BigInt value to a number Number(1n); // 1

संक्षेप में, हम संचालन में BigInt और संख्या को नहीं मिला सकते हैं। परिणामस्वरूप, "बड़े पूर्णांक" का उपयोग करने की अनुशंसा नहीं की जाती है यदि 2 ^ 53-1 ( MAX_SAFE_INTEGER ) हमारे उद्देश्यों के लिए पर्याप्त है।

मुख्य निर्णय

हां, यह इस नवाचार का मुख्य निर्णय था। यदि आप भूल जाते हैं कि यह जावास्क्रिप्ट है, तो सब कुछ बहुत तार्किक है: ये निहितार्थ रूपांतरण जानकारी के नुकसान में योगदान करते हैं।

जब हम विभिन्न संख्यात्मक प्रकार (बड़े पूर्णांक और फ्लोटिंग-पॉइंट संख्या) के दो मान जोड़ते हैं, तो परिणाम का गणितीय मान उनकी संभावित मानों की सीमा के बाहर हो सकता है। उदाहरण के लिए, अभिव्यक्ति का मान (2n ** 53n + 1n) + 0.5 इनमें से किसी भी प्रकार का सही प्रतिनिधित्व नहीं कर सकता है। यह अब पूर्णांक नहीं है, लेकिन एक वास्तविक संख्या है, लेकिन फ़्लोट 64 प्रारूप में इसकी सटीकता अब गारंटी नहीं है:

 2n ** 53n + 1n; // 9007199254740993n Number(2n ** 53n + 1n) + 0.5; // 9007199254740992

अधिकांश गतिशील भाषाओं में, जहां पूर्णांक और फ्लोट दोनों के प्रकारों का प्रतिनिधित्व किया जाता है, पूर्व को 1 के रूप में लिखा जाता है, और बाद को 1.0 के रूप में लिखा जाता है। इस प्रकार, ऑपरेंड में एक दशमलव विभाजक की उपस्थिति पर अंकगणितीय संचालन के दौरान, हम यह निष्कर्ष निकाल सकते हैं कि गणना में फ्लोट की सटीकता स्वीकार्य है। लेकिन जावास्क्रिप्ट उनमें से एक नहीं है, और 1 एक फ्लोट है! और इसका मतलब है कि कंप्यूटिंग 2 एन ** 53 एन + 1 फ्लोट 2 ^ 53 वापस आ जाएगी। जो, बदले में, BigInt की मुख्य कार्यक्षमता को तोड़ता है:

 2 ** 53 === 2 ** 53 + 1; // true

खैर, "संख्यात्मक टॉवर" के कार्यान्वयन के बारे में बात करने का कोई कारण नहीं है, क्योंकि आप मौजूदा संख्या को सामान्य संख्यात्मक डेटा प्रकार (उसी कारण के लिए) के रूप में लेने में सफल नहीं हुए हैं।

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

 Math.max(1n, 10n); // TypeError

आपको नंबर () या BigInt () का उपयोग करके स्पष्ट रूप से दो प्रकारों में से एक का चयन करना होगा।

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

बेशक, यह अन्य आदिम लोगों के साथ संख्यात्मक रूपांतरण पर लागू होता है:

 1 + true; // 2 1n + true; // TypeError 1 + null; // 1 1n + null; // TypeError

लेकिन निम्नलिखित (पहले से ही) निष्कर्ष काम करेगा, क्योंकि अपेक्षित परिणाम एक स्ट्रिंग है:

 1n + [0]; // '10' 1n + {}; // '1[object Object]' 1n + (_ => 1); // '1_ => 1'

एक और अपवाद संख्या और BigInt के बीच तुलना ऑपरेटरों (जैसे < , > और == ) के रूप में है। सटीकता का कोई नुकसान भी नहीं है, क्योंकि परिणाम एक बूलियन है।

यदि आप पिछले नए प्रतीक डेटा प्रकार को याद करते हैं, तो क्या TypeError अब इस तरह के कट्टरपंथी जोड़ की तरह नहीं लगता है?

 Symbol() + 1; // TypeError: Cannot convert a Symbol value to a number

और हाँ, लेकिन नहीं। वास्तव में, वैचारिक रूप से प्रतीक एक संख्या नहीं है, बल्कि एक संपूर्ण - बहुत अधिक है:

यह अत्यधिक संभावना नहीं है कि प्रतीक ऐसी स्थिति में आ जाएगा। हालांकि, यह बहुत संदेहास्पद है और यहां टाइप टाइप बहुत उपयुक्त है।
यह बहुत संभावना है और सामान्य है कि संचालन में "बड़ा पूरा" ऑपरेंड में से एक होगा जब वास्तव में कुछ भी गलत नहीं है।

असमी + ऑपरेटर asm.js के साथ एक संगतता समस्या के कारण एक अपवाद को फेंक देता है , जहां संख्या अपेक्षित है। यूनीरी प्लस बिगआईंट के साथ नंबर की तरह काम नहीं कर सकता है, क्योंकि इस मामले में पिछले asm.js कोड अस्पष्ट हो जाएगा।

वैकल्पिक प्रस्ताव

BigInt कार्यान्वयन के सापेक्ष सादगी और "सफाई" के बावजूद, एक्सल रौशमेयर नवाचार की कमी पर जोर देता है। अर्थात्, मौजूदा संख्या और आगामी के साथ इसकी केवल आंशिक पिछड़ी संगतता:

53-बिट इनट्स के लिए संख्याओं का उपयोग करें। यदि आपको अधिक बिट्स की आवश्यकता है तो इंटेगर का उपयोग करें

एक विकल्प के रूप में, उन्होंने निम्नलिखित का प्रस्ताव रखा ।

आइए नंबर को नए Int और Double के लिए सुपरस्क्रिप्ट बनाएं:

टाइपोफ 123.0 === 'संख्या' , और नंबर.डिस् डबल (123.0) === सच
टाइपोफ़ 123 === 'संख्या' , और नंबर.आईसइंट (123) === सच

Number.asInt () और Number.asDouble () रूपांतरणों के लिए नए कार्यों के साथ। और, ज़ाहिर है, ऑपरेटर ओवरलोडिंग और आवश्यक कलाकारों के साथ:

इंट × डबल = डबल (कास्ट)
डबल × इंट = डबल (कास्ट के साथ)
डबल × डबल = डबल
Int × Int = Int (विभाजन को छोड़कर सभी ऑपरेटर)

दिलचस्प है, सरलीकृत संस्करण में, यह वाक्य भाषा में नए प्रकार को जोड़े बिना (पहले) का प्रबंधन करता है। इसके बजाय, संख्या प्रकार की परिभाषा का विस्तार होता है: सभी संभावित 64-बिट डबल-सटीक संख्या (IEEE 754-2008) के अलावा, संख्या में अब सभी पूर्णांक शामिल हैं। नतीजतन, "गलत संख्या" 123.0 और "सटीक संख्या" 123 एकल संख्या प्रकार की अलग-अलग संख्याएं हैं।

यह बहुत परिचित और उचित लगता है। हालाँकि, यह मौजूदा संख्या का एक गंभीर अपग्रेड है, जो "वेब को तोड़ने" और इसके उपकरणों की अधिक संभावना है:

1 और 1.0 के बीच अंतर है, जो पहले नहीं था। मौजूदा कोड उन्हें परस्पर उपयोग करता है, जो अपग्रेड के बाद भ्रम की स्थिति पैदा कर सकता है (उन भाषाओं के विपरीत जहां यह अंतर शुरू में मौजूद था)।
एक प्रभाव है जब 1 === 1.0 (यह एक अपग्रेड माना जाता है), और उसी समय, Number.isDouble (1)! == Number.isDouble (1.0) : फिर से, यह ऐसा है।
समानता 2 "53" और 2 ^ 53 + 1 की "ख़ासियत" गायब हो जाती है, जो उस पर निर्भर कोड को तोड़ देगा।
Asm.js और अधिक के साथ एक ही संगतता मुद्दा।

इसलिए, अंत में, हमारे पास नए अलग डेटा प्रकार के रूप में एक समझौता समाधान है। यह केवल इस बात पर जोर देने के लायक है कि एक अन्य विकल्प पर भी विचार किया गया था और चर्चा की गई थी ।

जब आप दो कुर्सियों पर बैठते हैं

दरअसल, समिति की टिप्पणी शब्दों के साथ शुरू होती है:

उपयोगकर्ता अंतर्ज्ञान को बनाए रखने और परिशुद्धता को संरक्षित करने के बीच संतुलन का पता लगाएं

एक ओर, मैं आखिरकार भाषा में कुछ "सटीक" जोड़ना चाहता था। और दूसरी ओर, कई डेवलपर्स के लिए अपने पहले से ही परिचित व्यवहार को बनाए रखने के लिए।

यह सिर्फ इतना है कि आप इस "सटीक" को जोड़ने में सक्षम नहीं होंगे, क्योंकि आप इसे नहीं तोड़ सकते हैं: गणित, भाषा का एर्गोनॉमिक्स, asm.js, टाइप सिस्टम के आगे विस्तार की संभावना , उत्पादकता और, अंत में, वेब ही! और आप इसे एक ही समय में नहीं तोड़ सकते, जो एक ही ओर जाता है।

और आप उन भाषा उपयोगकर्ताओं के अंतर्ज्ञान को नहीं तोड़ सकते हैं, जो निश्चित रूप से, बहुत गर्म बहस में थे । सच है, यह काम किया?

जावास्क्रिप्ट: बिग होल पूरा क्यों

स्पष्ट हो जाता है?

मुख्य निर्णय

वैकल्पिक प्रस्ताव

जब आप दो कुर्सियों पर बैठते हैं

More articles: