વાસ્તવિક પ્રકારના અવાસ્તવિક લક્ષણો, અથવા વાસ્તવિક સાથે સાવચેત રહો

પ્રકાશન પછી લેખ PostgreSQL માં ટાઈપ કરવાની વિશેષતાઓ વિશે, પ્રથમ ટિપ્પણી વાસ્તવિક સંખ્યાઓ સાથે કામ કરવાની મુશ્કેલીઓ વિશે હતી. તેઓ REAL પ્રકારનો કેટલી વાર ઉપયોગ કરે છે તે જોવા માટે મેં મારી પાસે ઉપલબ્ધ SQL ક્વેરીઝના કોડ પર એક ઝડપી દેખાવ કરવાનું નક્કી કર્યું. તે તારણ આપે છે કે તેનો ઉપયોગ ઘણી વાર થાય છે, અને વિકાસકર્તાઓ હંમેશા તેની પાછળના જોખમોને સમજી શકતા નથી. અને આ એ હકીકત હોવા છતાં કે ઇન્ટરનેટ અને હેબ્રે પર કમ્પ્યુટર મેમરીમાં વાસ્તવિક સંખ્યાઓ સંગ્રહિત કરવાની સુવિધાઓ વિશે અને તેમની સાથે કામ કરવા વિશે ઘણા સારા લેખો છે. તેથી, આ લેખમાં હું આવી સુવિધાઓને PostgreSQL પર લાગુ કરવાનો પ્રયાસ કરીશ, અને તેમની સાથે સંકળાયેલી મુશ્કેલીઓ પર ઝડપથી નજર કરવાનો પ્રયાસ કરીશ, જેથી SQL ક્વેરી ડેવલપર્સ માટે તેમને ટાળવાનું સરળ બને.

પોસ્ટગ્રેએસક્યુએલ દસ્તાવેજીકરણ સંક્ષિપ્તમાં જણાવે છે: "ગણતર દરમિયાન આવી ભૂલોનું સંચાલન અને તેમના પ્રચાર એ ગણિત અને કમ્પ્યુટર વિજ્ઞાનની સમગ્ર શાખાનો વિષય છે, અને તે અહીં આવરી લેવામાં આવતું નથી" (જ્યારે વાચકને 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 ને REAL માં કાસ્ટ કરીએ:

********* ЗАПРОС *********
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 ને વાસ્તવિક અને ડબલ ચોકસાઈ બંને પ્રકારોમાં પેક કરીએ. ઘાતાંકની નિશાની અને મૂલ્ય સમાન હોવાથી, અમે મેન્ટિસા પર ધ્યાન કેન્દ્રિત કરીશું (હું ઇરાદાપૂર્વક ઘાતાંકના મૂલ્યો અને શૂન્ય વાસ્તવિક મૂલ્યોને સંગ્રહિત કરવાના બિન-સ્પષ્ટ લક્ષણોને છોડી દઉં છું, કારણ કે તેઓ સમજણને જટિલ બનાવે છે અને સારથી વિચલિત કરે છે. સમસ્યા માટે, જો રસ હોય, તો 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 છે. તેથી, અમારી સંખ્યા 777 નજીકના પ્રતિનિધિત્વ કરી શકાય તેવા 215 પર ગોળાકાર છે. પ્રકારને ડબલ પ્રિસિશનમાં બદલીને, અમે હવે આ દૃશ્ય જોઈ શકતા નથી:

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

બસ એટલું જ. તે તારણ આપે છે કે ત્યાં કોઈ ચમત્કારો નથી. પરંતુ વર્ણવેલ દરેક વસ્તુ એ વિચારવાનું એક સારું કારણ છે કે તમને ખરેખર વાસ્તવિક પ્રકારની કેટલી જરૂર છે. કદાચ તેના ઉપયોગનો સૌથી મોટો ફાયદો એ છે કે ચોકસાઈના જાણીતા નુકશાન સાથે ગણતરીઓની ઝડપ. પરંતુ શું આ એક સાર્વત્રિક દૃશ્ય હશે જે આ પ્રકારના વારંવાર ઉપયોગને યોગ્ય ઠેરવશે? વિચારશો નહીં.

સોર્સ: www.habr.com