Reaali tõelised omadused, või olge ettevaatlikud REAL-i suhtes

Pärast avaldamist artikleid PostgreSQL-i tüübid on keerulised, ja esimene kommentaar käsitles pärisnumbritega töötamise raskusi. Otsustasin kiiresti üle vaadata koodi, mis mulle SQL-päringutena kätte on antud, et näha, kui sageli seal kasutatakse tüüpi REAL. Selgus, et seda kasutatakse üsna tihti, ja mitte alati ei mõista arendajad sellega seotud ohte. Ja see mald isegi vaatamata sellele, et internetis ja Habr's on piisavalt häid artikleid, mis käsitlevad reaalarvude salvestamise eripärasid masina mälus ja nende kasutamist. Seetõttu püüan selles artiklis rakendada neid eripärasid PostgreSQL-ile ning üritan kätega seletada seotud probleeme, et SQL-päringute arendajad saaksid neist kergemini mööda minna.

PostgreSQL dokumentatsioon sisaldab lühikest lauset: "Selliste vigade käitlemine ja nende levik arvutuste käigus on terve matemaatika ja arvutiteaduse valdkonna õppeaine, ja seda siin ei käsitleta" (samuti suunab see ettevaatlikult lugeja IEEE 754 standardi poole). Milliseid vigu siin silmas peetakse? Räägime neist järkjärgult ning varsti selgub, miks ma jälle kirjutamise kallale asusin.

Võtame näiteks lihtsa päringu:

********* PÄRING *********
SELECT 0.1::REAL;
**************************
float4
--------
    0.1
(1 rida)

Tulemuseks ei näe me midagi erilist – saame oodatud 0.1. Kuid nüüd võrdleme seda 0.1-ga:

********* PÄRING *********
SELECT 0.1::REAL = 0.1;
**************************
?column?
----------
f
(1 rida)

Ei ole võrdsed! Millised imed! Kuid see pole veel kõik. Keegi ütleb, et ma tean, et REAL halvas tehingudes käitub halvasti, aga ma hakkan sinna sisestama terveid numbreid, nendega on kindlasti kõik hästi. Okei, toome arvu 123 456 789 tüüpi REAL:

********* PÄRING *********
SELECT 123456789::REAL::INT;
**************************
   int4   
-----------
123456792
(1 rida)

Ja see tuli 3 võrra suurem! Kõik, andmebaas on täiesti lugema unustanud! Või ei saa me millestki aru? Läheme edasi.

Kuna alguseks meenutame teooriat. Nagu on teada, võib iga kümneline arv lagundada kümniste astmete summaks. Seega number 123.456 on võrdne 1*10² + 2*10¹ + 3*10⁰ + 4*10⁻¹ + 5*10⁻² + 6*10⁻³. Kuid arvuti töötab kahendvormis, seega tuleb need esitada kahendkalduvuste summana. Seetõttu esindatakse number 5.625 kahendvormis kui 101.101 ja on võrdne 1*2² + 0*2¹ + 1*2⁰ + 1*2⁻¹ + 0*2⁻² + 1*2⁻³. Ja kui positiivsed kahetiseste astmed annavad alati täisarve (1, 2, 4, 8, 16 jne), siis negatiivsete osas on see keerulisem (0.5, 0.25, 0.125, 0.0625 jne). Probleem seisneb selles, et kõiki kümnende murde ei saa esitada lõplike kahendmurdena. Näiteks meie kuulus 0.1 esindatakse kahendmurdena kui perioodiline väärtus 0.0(0011). Seega numbrite lõplik väärtus masinamuudatustes muutub sõltuvalt bittide arvust.

Nüüd on aeg meenutada, kuidas reaalarve salvestatakse arvuti mälus. Üldiselt koosneb reaalarv kolmest põhiosast - märgist, mantissist ja eksponentsist. Märgiks võib olla kas pluss või miinus, seega kulutab sellele üks bitt. Kuid mantissi ja eksponendi bittide arv määrab reaali tüüp. Näiteks REAL tüübi puhul on mantissi pikkus 23 bitti (üks bitt, mis on võrdne 1, lisatakse salaja mantissi ette, ja seetõttu on kokku 24), ning eksponents on 8 bitti. Kokku on see 32 bitti ehk 4 baiti. Tüüp DOUBLE PRECISION puhul on mantissi pikkus juba 52 bitti ja eksponents 11 bitti, kokku 64 bitti ehk 8 baiti. PostgreSQL ei toeta suuremat täpsust ujukomaarvude jaoks.

Pakkime nüüd meie kümnendilise arvu 0.1 mõlemasse tüüpi - REAL ja DOUBLE PRECISION. Kuna märk ja eksponendi väärtus on meil samad, keskendume mantissile (ma väldin teadlikult eksponendi salvestamise ja nullsete reaalarvude mitteilmsed omadused, kuna need raskendavad mõistmist ja segavad probleemi tuumast, kui huvitav - vaadake standardit IEEE 754). Mida me saame? Ülemises reas toon välja "mantissi" REAL tüübi jaoks (arvestades viimane bitt 1 ümardatakse lähimaks esitatavaks arvuks, vastasel juhul saame 0.099999...), ja alumises REAL tüübi jaoks DOUBLE PRECISION:

0.000110011001100110011001101
0.00011001100110011001100110011001100110011001100110011001

On selge, et need on kaks täiesti erinevat numbrit! Seetõttu, kui me esimese numbri võrreldes täiendame seda nullidega, on see seega suurem kui teine (arvesse võttes ümardamist – rõhutatud rasvases kirjas ühte). Just see seletab meie näidete mitmeti mõistetavust. Teises näites konverteeritakse selgelt määratud arv 0.1 tüüpi DOUBLE PRECISION, pärast mida võrreldakse seda tüüpi REAL numbriga. Mõlemad konverteeritakse ühte tüüpi ja saame täpselt seda, mida näeme ülalpool. Muudame päringut, et kõik omaks oma kohta:

********* PÄRING *********
SELECT 0.1::REAL > 0.1::DOUBLE PRECISION;
**************************
?column?
----------
t
(1 rida)

Ja tõepoolest, viies 0.1 kahekordselt REAL-iks ja DOUBLE PRECISION-iks, saame vastuse mõistatusele:

********* PÄRING *********
SELECT 0.1::REAL::DOUBLE PRECISION;
**************************

      float8       
-------------------
0.100000001490116
(1 rida)

Sama seletab ka kolmandat näidet eespool. Arv 123 456 789 on lihtsalt võimatu mahutada 24 bitti mantissasse (23 nähtavat + 1 mõistetud). Suurim täisarv, mis 24 bitis mahub, on 224-1 = 16 777 215. Seetõttu ümardatakse meie arv 123 456 789 lähimale esindatavale 123 456 792-le. Muutes tüübi DOUBLE PRECISION-iks, ei näe me enam sellist stsenaariumi:

********* PÄRING *********
SELECT 123456789::DOUBLE PRECISION::INT;
**************************
   int4   
-----------
123456789
(1 rida)

Ja ongi kõik. Selgub, et mingeid imesid pole. Kuid kõik see, mis on kirjas, on hea põhjus mõelda, kui tõeliselt on teil vaja tüüpi REAL. Tõenäoliselt on tema kasutamise suurim eelis arvutuste kiire teostamine vaatamata juba olemasolevale täpsuse kadumisele. Kuid kas on see universaalne stsenaarium, mis õigustab selle tüübi nii sagedast kasutamist? Ei, ma ei usu.

Allikas: habr.com