🥇वास्तविक प्रकारका अवास्तविक सुविधाहरू, वा वास्तविकसँग सावधान रहनुहोस्

प्रकाशन पछि लेख PostgreSQL मा टाइप गर्ने सुविधाहरूको बारेमा, पहिलो टिप्पणी वास्तविक संख्याहरूसँग काम गर्ने कठिनाइहरूको बारेमा थियो। मैले मलाई उपलब्ध SQL प्रश्नहरूको कोडमा द्रुत रूपमा हेर्ने निर्णय गरें कि उनीहरूले कति पटक वास्तविक प्रकार प्रयोग गर्छन् भनेर हेर्नको लागि। यो जान्छ कि यो धेरै पटक प्रयोग गरिन्छ, र विकासकर्ताहरूले सधैं यसको पछाडि खतराहरू बुझ्दैनन्। र यो तथ्यको बावजुद इन्टरनेट र Habré मा कम्प्यूटर मेमोरीमा वास्तविक संख्याहरू भण्डारण गर्ने सुविधाहरू र तिनीहरूसँग काम गर्ने बारे धेरै राम्रा लेखहरू छन्। त्यसकारण, यस लेखमा म PostgreSQL मा त्यस्ता सुविधाहरू लागू गर्ने प्रयास गर्नेछु, र तिनीहरूसँग सम्बन्धित समस्याहरूलाई द्रुत रूपमा हेर्ने प्रयास गर्नेछु, ताकि SQL क्वेरी विकासकर्ताहरूलाई तिनीहरूबाट बच्न सजिलो हुनेछ।

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

उदाहरणका लागि एउटा साधारण अनुरोध गरौं:

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

नतिजाको रूपमा, हामीले केहि विशेष देख्ने छैनौं - हामी अपेक्षित 0.1 प्राप्त गर्नेछौं। तर अब यसलाई ०.१ मा तुलना गरौं:

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

बराबर छैन! कस्तो चमत्कार! तर अगाडि, थप। कसैले भन्नेछ, मलाई थाहा छ कि REAL ले अंशहरूसँग नराम्रो व्यवहार गर्छ, त्यसैले म त्यहाँ पूर्ण संख्याहरू प्रविष्ट गर्नेछु, र तिनीहरूसँग सबै कुरा निश्चित रूपमा ठीक हुनेछ। ठीक छ, 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, आदि)। समस्या त्यही हो प्रत्येक दशमलवलाई सीमित बाइनरी अंशको रूपमा प्रतिनिधित्व गर्न सकिँदैन। यसरी, बाइनरी अंशको रूपमा हाम्रो कुख्यात 0.1 आवधिक मान 0.0(0011) को रूपमा देखा पर्दछ। फलस्वरूप, कम्प्यूटर मेमोरीमा यो संख्याको अन्तिम मान बिट गहिराइको आधारमा भिन्न हुनेछ।

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

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

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 बिट मा mantissa फिट गर्न असम्भव छ (२३ स्पष्ट + १ निहित)। 23 बिटहरूमा फिट हुन सक्ने अधिकतम पूर्णांक 1-24 = 224 हो। त्यसैले, हाम्रो नम्बर 1 लाई निकटतम प्रतिनिधित्व 16 मा राउन्ड गरिएको छ। प्रकारलाई डबल PRECISION मा परिवर्तन गरेर, हामी अब यो परिदृश्य देख्दैनौं:

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

यति नै। त्यहाँ कुनै चमत्कार छैन बाहिर जान्छ। तर वर्णन गरिएको सबै कुरा तपाईलाई वास्तविक प्रकारको कति आवश्यक छ भन्ने बारे सोच्ने राम्रो कारण हो। सायद यसको प्रयोगको सबैभन्दा ठूलो फाइदा सटीकता को ज्ञात हानि संग गणना को गति हो। तर के यो एक सार्वभौमिक परिदृश्य हुनेछ जसले यस प्रकारको बारम्बार प्रयोगलाई औचित्य दिन्छ? सोच्नु हुन्न।

स्रोत: www.habr.com

वास्तविक प्रकारका अवास्तविक सुविधाहरू, वा REAL सँग सावधान रहनुहोस्

एक टिप्पणी थप्न Отменить ответ