वास्तविक प्रकारों की अवास्तविक विशेषताएं, या वास्तविक से सावधान रहें

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

PostgreSQL दस्तावेज़ में संक्षेप में कहा गया है: "ऐसी त्रुटियों का प्रबंधन और गणना के दौरान उनका प्रसार गणित और कंप्यूटर विज्ञान की पूरी शाखा का विषय है, और इसे यहां कवर नहीं किया गया है" (बुद्धिमानी से पाठक को IEEE 754 मानक का संदर्भ देते हुए)। यहाँ किस प्रकार की त्रुटियों का आशय है? आइए उन पर क्रम से चर्चा करें, और यह जल्द ही स्पष्ट हो जाएगा कि मैंने फिर से कलम क्यों उठाया।

आइए उदाहरण के लिए एक साधारण अनुरोध लें:

********* ЗАПРОС *********
SELECT 0.1::REAL;
**************************
float4
--------
    0.1
(1 строка)

परिणामस्वरूप, हमें कुछ खास नहीं दिखेगा - हमें अपेक्षित 0.1 मिलेगा। लेकिन अब आइए इसकी तुलना 0.1 से करें:

********* ЗАПРОС *********
SELECT 0.1::REAL = 0.1;
**************************
?column?
----------
f
(1 строка)

सम नही! क्या चमत्कार! लेकिन आगे, और भी। कोई कहेगा, मुझे पता है कि REAL भिन्नों के साथ बुरा व्यवहार करता है, इसलिए मैं वहां पूर्णांक दर्ज करूंगा, और उनके साथ सब कुछ निश्चित रूप से ठीक हो जाएगा। ठीक है, आइए संख्या 123 को वास्तविक में डालें:

********* ЗАПРОС *********
SELECT 123456789::REAL::INT;
**************************
   int4   
-----------
123456792
(1 строка)

और यह 3 और निकला! बस, डेटाबेस आख़िरकार गिनती करना भूल गया है! या हम कुछ गलत समझ रहे हैं? आइए इसका पता लगाएं।

सबसे पहले, आइए मैटरियल को याद करें। जैसा कि आप जानते हैं, किसी भी दशमलव संख्या को दस की घातों में विस्तारित किया जा सकता है। तो, संख्या 123.456 1*102 + 2*101 + 3*100 + 4*10-1 + 5*10-2 + ​​6*10-3 के बराबर होगी। लेकिन कंप्यूटर संख्याओं को बाइनरी रूप में संचालित करता है, इसलिए उन्हें दो की घातों में विस्तार के रूप में प्रदर्शित करना पड़ता है। इसलिए, बाइनरी में संख्या 5.625 को 101.101 के रूप में दर्शाया गया है और यह 1*22 + 0*21 + 1*20 + 1*2-1 + 0*2-2 + 1*2-3 के बराबर होगी। और यदि दो की सकारात्मक घातें हमेशा पूर्ण दशमलव संख्याएँ (1, 2, 4, 8, 16, आदि) देती हैं, तो नकारात्मक घातों के साथ सब कुछ अधिक जटिल है (0.5, 0.25, 0.125, 0,0625, आदि)। समस्या यह है कि प्रत्येक दशमलव को एक परिमित बाइनरी अंश के रूप में प्रदर्शित नहीं किया जा सकता है. इस प्रकार, बाइनरी अंश के रूप में हमारा कुख्यात 0.1 आवधिक मान 0.0(0011) के रूप में प्रकट होता है। परिणामस्वरूप, कंप्यूटर मेमोरी में इस संख्या का अंतिम मान बिट गहराई के आधार पर अलग-अलग होगा।

अब यह याद रखने का समय है कि कंप्यूटर मेमोरी में वास्तविक संख्याएँ कैसे संग्रहीत की जाती हैं। सामान्यतया, एक वास्तविक संख्या में तीन मुख्य भाग होते हैं - चिह्न, मंटिसा और घातांक। चिह्न प्लस या माइनस हो सकता है, इसलिए इसके लिए एक बिट आवंटित किया गया है। लेकिन मंटिसा और एक्सपोनेंट के बिट्स की संख्या वास्तविक प्रकार से निर्धारित होती है। तो, वास्तविक प्रकार के लिए, मंटिसा की लंबाई 23 बिट है (1 के बराबर एक बिट को मंटिसा की शुरुआत में जोड़ा जाता है, और परिणाम 24 है), और घातांक 8 बिट है। कुल 32 बिट्स या 4 बाइट्स हैं। और डबल प्रिसिजन प्रकार के लिए, मंटिसा की लंबाई 52 बिट्स होगी, और घातांक 11 बिट्स होगा, कुल 64 बिट्स या 8 बाइट्स के लिए। PostgreSQL फ़्लोटिंग पॉइंट नंबरों के लिए उच्च परिशुद्धता का समर्थन नहीं करता है।

आइए अपनी दशमलव संख्या 0.1 को वास्तविक और दोहरे परिशुद्धता दोनों प्रकारों में पैक करें। चूँकि घातांक का चिन्ह और मान समान हैं, हम मंटिसा पर ध्यान केंद्रित करेंगे (मैं जानबूझकर घातांक और शून्य वास्तविक मूल्यों के मूल्यों को संग्रहीत करने की गैर-स्पष्ट विशेषताओं को छोड़ देता हूँ, क्योंकि वे समझने को जटिल बनाते हैं और सार से ध्यान भटकाते हैं समस्या के बारे में, यदि रुचि हो, तो आईईईई 754 मानक देखें)। हमें क्या मिलेगा? शीर्ष पंक्ति में मैं वास्तविक प्रकार के लिए "मेंटिसा" दूंगा (निकटतम प्रतिनिधित्व योग्य संख्या के लिए अंतिम बिट को 1 से पूर्णांकित करने को ध्यान में रखते हुए, अन्यथा यह 0.099999 होगा...), और निचली पंक्ति में - के लिए दोहरी परिशुद्धता प्रकार:

0.000110011001100110011001101
0.00011001100110011001100110011001100110011001100110011001

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

********* ЗАПРОС *********
SELECT 0.1::REAL > 0.1::DOUBLE PRECISION;
**************************
?column?
----------
t
(1 строка)

और वास्तव में, संख्या 0.1 को वास्तविक और दोहरी परिशुद्धता में दोहराने से, हमें पहेली का उत्तर मिलता है:

********* ЗАПРОС *********
SELECT 0.1::REAL::DOUBLE PRECISION;
**************************

      float8       
-------------------
0.100000001490116
(1 строка)

यह उपरोक्त तीसरे उदाहरण की भी व्याख्या करता है। संख्या 123 सरल है मंटिसा को 24 बिट्स में फिट करना असंभव है (23 स्पष्ट + 1 निहित)। अधिकतम पूर्णांक जो 24 बिट्स में फिट हो सकता है वह 224-1 = 16 है। इसलिए, हमारी संख्या 777 को निकटतम प्रतिनिधित्व योग्य 215 तक पूर्णांकित किया गया है। प्रकार को डबल प्रिसिजन में बदलने से, हम अब इस परिदृश्य को नहीं देखते हैं:

********* ЗАПРОС *********
SELECT 123456789::DOUBLE PRECISION::INT;
**************************
   int4   
-----------
123456789
(1 строка)

बस इतना ही। इससे पता चलता है कि कोई चमत्कार नहीं है। लेकिन वर्णित हर चीज़ यह सोचने का एक अच्छा कारण है कि आपको वास्तव में वास्तविक प्रकार की कितनी आवश्यकता है। शायद इसके उपयोग का सबसे बड़ा लाभ सटीकता की ज्ञात हानि के साथ गणना की गति है। लेकिन क्या यह एक सार्वभौमिक परिदृश्य होगा जो इस प्रकार के लगातार उपयोग को उचित ठहराएगा? सोचो मत.

स्रोत: www.habr.com