বাস্তব প্রকারের অবাস্তব বৈশিষ্ট্য, বা বাস্তবের সাথে সতর্ক থাকুন

প্রকাশের পর প্রবন্ধ PostgreSQL-এ টাইপ করার বৈশিষ্ট্য সম্পর্কে, প্রথম মন্তব্যটি ছিল বাস্তব সংখ্যার সাথে কাজ করার অসুবিধা সম্পর্কে। তারা কত ঘন ঘন বাস্তব টাইপ ব্যবহার করে তা দেখতে আমি আমার কাছে উপলব্ধ এসকিউএল কোয়েরির কোডটি দ্রুত দেখার সিদ্ধান্ত নিয়েছি। দেখা যাচ্ছে যে এটি প্রায়শই ব্যবহৃত হয় এবং বিকাশকারীরা সর্বদা এর পিছনের বিপদগুলি বোঝেন না। কম্পিউটার মেমরিতে প্রকৃত সংখ্যা সংরক্ষণের বৈশিষ্ট্য এবং সেগুলির সাথে কাজ করার বিষয়ে ইন্টারনেটে এবং হ্যাব্রেতে প্রচুর ভাল নিবন্ধ থাকা সত্ত্বেও এটি। অতএব, এই নিবন্ধে আমি পোস্টগ্রেএসকিউএল-এ এই জাতীয় বৈশিষ্ট্যগুলি প্রয়োগ করার চেষ্টা করব, এবং তাদের সাথে সম্পর্কিত সমস্যাগুলি দ্রুত দেখার চেষ্টা করব, যাতে এসকিউএল কোয়েরি বিকাশকারীদের এগুলি এড়ানো সহজ হয়।

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 строка)

আর দেখা গেল আরও ৩টি! এটাই, ডাটাবেস শেষ পর্যন্ত কীভাবে গণনা করতে হয় তা ভুলে গেছে! নাকি আমরা কিছু ভুল বুঝছি? আসুন এটা বের করা যাক।

প্রথমত, এর উপাদান মনে রাখা যাক. আপনি জানেন যে, যেকোনো দশমিক সংখ্যাকে দশের ক্ষমতায় প্রসারিত করা যেতে পারে। সুতরাং, 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 মান দেখুন)। আমরা কি পাব? উপরের লাইনে আমি REAL টাইপের জন্য "ম্যান্টিসা" দেব (সর্বশেষের প্রতিনিধিত্বযোগ্য সংখ্যায় 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