वास्तविक प्रकारांची अवास्तव वैशिष्ट्ये किंवा REAL सह सावधगिरी बाळगा

प्रकाशनानंतर लेख PostgreSQL मधील टायपिंगच्या वैशिष्ट्यांबद्दल, अगदी पहिली टिप्पणी वास्तविक संख्यांसह कार्य करण्याच्या अडचणींबद्दल होती. ते REAL प्रकार किती वेळा वापरतात हे पाहण्यासाठी मी माझ्याकडे उपलब्ध असलेल्या SQL क्वेरीच्या कोडवर झटपट नजर टाकण्याचे ठरवले. असे दिसून आले की ते बर्‍याचदा वापरले जाते आणि विकासकांना नेहमीच त्यामागील धोके समजत नाहीत. आणि हे असूनही इंटरनेटवर आणि हॅब्रेवर संगणक मेमरीमध्ये वास्तविक संख्या संचयित करण्याच्या वैशिष्ट्यांबद्दल आणि त्यांच्याबरोबर कार्य करण्याबद्दल बरेच चांगले लेख आहेत. म्हणून, या लेखात मी अशी वैशिष्ट्ये 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*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) म्हणून दिसते. परिणामी, संगणक मेमरीमधील या संख्येचे अंतिम मूल्य बिट खोलीवर अवलंबून बदलू शकते.

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

चला आमची दशांश संख्या 0.1 REAL आणि Double PRECISION अशा दोन्ही प्रकारांमध्ये पॅक करू. घातांकाचे चिन्ह आणि मूल्य सारखेच असल्याने, आम्ही मंटिसावर लक्ष केंद्रित करू (मी मुद्दाम घातांकाची मूल्ये आणि शून्य वास्तविक मूल्ये संग्रहित करण्याची गैर-स्पष्ट वैशिष्ट्ये वगळतो, कारण ते समजून घेण्यास गुंतागुंत करतात आणि सारापासून लक्ष विचलित करतात. समस्येबद्दल, स्वारस्य असल्यास, IEEE 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 पर्यंत पूर्ण केली जाते. प्रकार दुहेरी अचूकतेमध्ये बदलून, आम्हाला हे दृश्य आता दिसत नाही:

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

इतकंच. असे दिसून आले की तेथे कोणतेही चमत्कार नाहीत. परंतु वर्णन केलेली प्रत्येक गोष्ट आपल्याला वास्तविक प्रकाराची खरोखर किती आवश्यकता आहे याचा विचार करण्याचे एक चांगले कारण आहे. कदाचित त्याच्या वापराचा सर्वात मोठा फायदा म्हणजे अचूकतेच्या ज्ञात नुकसानासह गणनाची गती. परंतु या प्रकारच्या वारंवार वापराचे समर्थन करणारी ही सार्वत्रिक परिस्थिती असेल का? विचार करू नका.

स्त्रोत: www.habr.com