რეალური ტიპების არარეალური მახასიათებლები, ან ფრთხილად იყავით REAL-თან

РџРѕСЃР »Рм РїСГР ± Р» РёРєє ° С † РёРё მუხლი PostgreSQL-ში აკრეფის მახასიათებლების შესახებ, პირველივე კომენტარი ეხებოდა რეალურ ციფრებთან მუშაობის სირთულეებს. გადავწყვიტე სწრაფად გადამეხედა ჩემთვის ხელმისაწვდომი SQL მოთხოვნების კოდს, რათა გამეგო, რამდენად ხშირად იყენებენ ისინი REAL ტიპს. გამოდის, რომ ის საკმაოდ ხშირად გამოიყენება და დეველოპერებს ყოველთვის არ ესმით მის უკან არსებული საფრთხეები. და ეს იმისდა მიუხედავად, რომ ინტერნეტში და ჰაბრეზე საკმაოდ ბევრი კარგი სტატიაა კომპიუტერის მეხსიერებაში რეალური რიცხვების შენახვის მახასიათებლებისა და მათთან მუშაობის შესახებ. ამიტომ, ამ სტატიაში შევეცდები გამოვიყენო ასეთი ფუნქციები 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 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.1 ბინარული წილადის სახით ჩნდება როგორც პერიოდული მნიშვნელობა 0.0(0011). შესაბამისად, ამ რიცხვის საბოლოო მნიშვნელობა კომპიუტერის მეხსიერებაში შეიცვლება ბიტის სიღრმის მიხედვით.

ახლა დროა გავიხსენოთ, როგორ ინახება რეალური რიცხვები კომპიუტერის მეხსიერებაში. ზოგადად რომ ვთქვათ, რეალური რიცხვი შედგება სამი ძირითადი ნაწილისაგან - ნიშანი, მანტისა და ექსპონენტი. ნიშანი შეიძლება იყოს პლუსი ან მინუსი, ამიტომ მას ერთი ბიტი აქვს გამოყოფილი. მაგრამ მანტისას და მაჩვენებლის ბიტების რაოდენობა განისაზღვრება რეალური ტიპის მიხედვით. ასე რომ, REAL ტიპისთვის, მანტისას სიგრძეა 23 ბიტი (ერთი ბიტი 1-ის ტოლი ემატება მანტისას დასაწყისში და შედეგი არის 24), ხოლო მაჩვენებელი არის 8 ბიტი. სულ არის 32 ბიტი, ანუ 4 ბაიტი. ხოლო DOUBLE PRECISION ტიპისთვის მანტისას სიგრძე იქნება 52 ბიტი, ხოლო მაჩვენებელი იქნება 11 ბიტი, სულ 64 ბიტი, ანუ 8 ბაიტი. PostgreSQL არ უჭერს მხარს მცურავი წერტილის რიცხვების უფრო მაღალ სიზუსტეს.

მოდით შეფუთოთ ჩვენი ათობითი რიცხვი 0.1 როგორც REAL, ასევე DOUBLE PRECISION ტიპებად. ვინაიდან მაჩვენებლის ნიშანი და მნიშვნელობა იგივეა, ჩვენ ყურადღებას გავამახვილებთ მანტისაზე (მე განზრახ გამოვტოვებ ექსპონენტის მნიშვნელობების და ნულოვანი რეალური მნიშვნელობების შენახვის არა აშკარა მახასიათებლებს, რადგან ისინი ართულებენ გაგებას და ყურადღებას აშორებენ არსს. პრობლემის შესახებ, დაინტერესების შემთხვევაში, იხილეთ IEEE 754 სტანდარტი). რას მივიღებთ? ზედა სტრიქონში მივცემ „მანტისას“ REAL ტიპისთვის (ბოლო ბიტის დამრგვალების 1-ით უახლოეს წარმომადგენლობით რიცხვამდე, წინააღმდეგ შემთხვევაში ეს იქნება 0.099999...), ხოლო ქვედა სტრიქონში - ორმაგი სიზუსტის ტიპი:

0.000110011001100110011001101
0.00011001100110011001100110011001100110011001100110011001

ცხადია, ეს ორი სრულიად განსხვავებული რიცხვია! ამიტომ, შედარებისას, პირველი რიცხვი შეივსება ნულებით და, შესაბამისად, იქნება მეორეზე მეტი (დამრგვალების გათვალისწინებით - თამამად მონიშნული). ეს ხსნის გაურკვევლობას ჩვენი მაგალითებიდან. მეორე მაგალითში, ცალსახად მითითებული რიცხვი 0.1 გადაცემულია DOUBLE PRECISION ტიპისთვის და შემდეგ შედარებულია REAL ტიპის რიცხვთან. ორივე დაყვანილია იმავე ტიპზე და გვაქვს ზუსტად ის, რასაც ზემოთ ვხედავთ. მოდით შევცვალოთ მოთხოვნა ისე, რომ ყველაფერი თავის ადგილზე მოხვდეს:

********* ЗАПРОС *********
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-მდე. ტიპის DOUBLE PRECISION-ზე შეცვლით, ჩვენ ვეღარ ვხედავთ ამ სცენარს:

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

Სულ ეს არის. გამოდის, რომ სასწაულები არ არის. მაგრამ ყველაფერი აღწერილი არის კარგი მიზეზი, ვიფიქროთ იმაზე, თუ რამდენად გჭირდებათ რეალურად ტიპი. მისი გამოყენების ალბათ ყველაზე დიდი უპირატესობა არის გამოთვლების სიჩქარე ცნობილი სიზუსტის დაკარგვით. მაგრამ იქნება ეს უნივერსალური სცენარი, რომელიც გაამართლებს ამ ტიპის ხშირ გამოყენებას? არ იფიქრო.

წყარო: www.habr.com