ليه 0.1 + 0.2 مش بيساوي 0.3 للمبتدئ: خطأ الفاصلة العائمة وحلّه

النوع اللي بتتخزّن فيه الأرقام العشرية في أغلب اللغات اسمه double precision floating point، وبياخد 64 خانة (bit) في الذاكرة. الـ 64 خانة دول متقسّمين بالظبط زي ما في الرسم ده:

• خانة واحدة للإشارة (sign): بتحدّد الرقم موجب ولا سالب.
• 11 خانة للأس (exponent): بتحدّد حجم الرقم، يعني قوة الاتنين المضروب فيها.
• 52 خانة للمانتيسا (mantissa): بتحمل الأرقام المعنوية نفسها، وهي دي بالظبط مكمن المشكلة.

الرقم بيتخزّن بالصيغة دي: القيمة تساوي الإشارة مضروبة في 1.المانتيسا مضروبة في 2 أس (الأس ناقص 1023). المهم في الكلام ده إن المانتيسا فيها 52 خانة وبس. يعني عند الكمبيوتر مساحة ثابتة ومحدودة جدًا للأرقام المعنوية، وده بيدّيك دقة في حدود 15 إلى 17 رقم عشري معنوي لا أكتر.

وبما إن تمثيل 0.1 الثنائي لا نهائي، اللي بيحصل إن الكمبيوتر بياخد أقرب 52 خانة، يرمي الباقي، ويقرّب. النتيجة إن القيمة اللي بتتخزّن فعلًا أول ما تكتب 0.1 مش 0.1 بالظبط، هي:

نفس الكلام بيحصل مع 0.2. كل واحد فيهم فيه خطأ تقريب ضئيل جدًا في حدود 10 أس سالب 17. ولما تجمعهم، الخطأين بيتجمّعوا، والناتج بيتقرّب لأقرب قيمة ممكنة، واللي بتظهر على الشاشة بالشكل 0.30000000000000004. الزيادة دي مقدارها تقريبًا 0.0000000000000000555 — رقم تافه فعلًا، بس موجود وبيكسر المقارنة.

جرّبها بنفسك: الكود اللي بيكشف الحكاية

الكود ده تقدر تنسخه وتجرّبه فورًا في console المتصفح:

ونفس التجربة في Python بتدّي نفس الناتج بالظبط، لأن الاتنين بيشتغلوا على معيار IEEE 754 نفسه:

لاحظ المثال الأخير: لما تجمع 0.1 عشر مرات المفروض يطلع 1.0، بس بيطلع 0.9999999999999999. ده معناه إن الخطأ مش بيحصل مرة واحدة، هو بيتراكم مع كل عملية.

القاعدة الذهبية اللي تطلع بيها من هنا: ممنوع تستخدم == في مقارنة رقمين عشريين. قارن دايمًا بفرق أصغر من هامش صغير (epsilon).

سيناريو من الواقع: لما القرشين الغلط يكسروا الفاتورة

الكلام ده يفضل نظري لحد ما يلمس الفلوس. تخيّل متجر إلكتروني عربي بياخد 8,000 طلب في اليوم، وكل طلب بيجمع سعر المنتج زائد الشحن. لو الحسابات دي ماشية بنوع float:

الناتج المفروض يكون 24.98، بس طلع 24.979999999999997. دلوقتي تخيّل النظام بيقارن total === expectedTotal قبل ما يأكّد الدفع — المقارنة هتفشل، والطلب السليم هيتعلّق. على 8,000 طلب في اليوم، حتى لو 2% بس وقعوا في الفخ ده، يبقى 160 طلب متعطّل يوميًا وفريق دعم بيلاحق مشكلة وهمية. والأسوأ من كده: لو الأخطاء الصغيرة بتتجمّع في تقرير مالي شهري على ملايين العمليات، الإجمالي ممكن يخرج بفرق محسوس فعلًا، مش 10 أس سالب 17.

الحل: 3 طرق، وكل واحدة ليها تمنها

1. خزّن الفلوس كأرقام صحيحة (بالقرش بدل الجنيه). بدل ما تخزّن 19.99، خزّن 1999 قرش. كل الحسابات تبقى على أرقام صحيحة، والأرقام الصحيحة مفيهاش أي خطأ تقريب أصلًا. بتكسب: دقة كاملة 100% وسرعة عالية. بتخسر: لازم تفتكر تقسم على 100 وقت العرض بس، وتضرب في 100 وقت الإدخال. ده الحل الأخف، وهو اللي بتعتمد عليه أنظمة دفع كبيرة زي Stripe فعلًا.

2. استخدم نوع Decimal مخصّص. Python فيها decimal.Decimal، وقواعد البيانات فيها نوع DECIMAL أو NUMERIC، وJavaScript ليها مكتبات زي decimal.js. الأنواع دي بتحسب بالنظام العشري نفسه فمفيش تقريب ثنائي. بتكسب: دقة عشرية كاملة وكود واضح. بتخسر: أبطأ بشكل ملحوظ — العمليات على Decimal ممكن تكون أبطأ من float بعشرات المرات — وبتاخد ذاكرة أكتر. وانتبه لفخ مهم: لازم تبني الـ Decimal من نص زي Decimal("0.1") مش من رقم float، وإلا هتورّث نفس الخطأ من أول سطر.

3. قرّب في اللحظة الصح. دوال زي toFixed(2) في JavaScript أو round(x, 2) في Python بتقرّب الرقم لخانتين. بتكسب: أرخص حل وأسهله. بتخسر: ده مجرد بلاستر — بيخبّي المشكلة وقت العرض بس، ومش بيمنع تراكم الأخطاء جوّه الحسابات نفسها. وأكتر من كده، التقريب نفسه ممكن يتأثر بالمشكلة: في Python round(2.675, 2) بيطلع 2.67 مش 2.68، لأن 2.675 نفسها متخزّنة أقل شوية من قيمتها. فاستخدم التقريب للعرض على الشاشة فقط، وممنوع تمامًا تعتمد عليه في المقارنات أو في القيم اللي بتتخزّن في الداتابيز.

متى ما تشغّلش بالك بالموضوع ده أصلًا

المقال ده ممكن يخوّفك من float بدون داعي، فخلّينا نوضّح الصورة. النوع float سريع جدًا ومدعوم من المعالج نفسه على مستوى العتاد، وهو الاختيار الصح في أغلب الشغل. خطأه في حدود 10 أس سالب 16، وده رقم تافه مالوش أي تأثير عملي في:

• الرسوميات والألعاب وحسابات الفيزياء والإحداثيات.
• تعلّم الآلة والإحصاء وقراءات الحسّاسات.
• أي قيمة بتتعرض في النهاية كرسمة أو نسبة تقريبية.

الفرضية هنا واضحة: المشكلة دي بتهمّ في تلات حالات بس — الفلوس، والمقارنات اللي محتاجة تساوي مظبوط بالظبط، وتراكم الأخطاء على ملايين العمليات. لو شغلك مش واحد من التلاتة دول، سيبك من Decimal واستخدم float وانت مرتاح، لأن استخدام Decimal في غير محلّه بيبطّأ برنامجك من غير أي فايدة.

الخطوة التالية

دلوقتي حالًا، افتح أي ملف في مشروعك بيتعامل مع فلوس. دوّر على أي متغير بيشيل مبلغ ونوعه float أو number أو double — ده علامة حمرا. ابدأ بأخطر نقطة: حساب الإجمالي، وأي مقارنة فيها == على مبلغ. حوّل التخزين يبقى بالقرش كعدد صحيح، أو لو الإطار اللي بتشتغل بيه بيدعم Decimal استخدمه. لو عملت ده في كل مكان بيمسّ الفلوس، تبقى قفلت الباب على فئة كاملة من الـ bugs الصامتة اللي بتظهر بعد شهور.

المصادر

• معيار IEEE 754-2019 الرسمي للحساب ذي الفاصلة العائمة (IEEE Standard for Floating-Point Arithmetic) — المرجع اللي بيحدّد بنية الـ 64 خانة وقواعد التقريب.
• David Goldberg، «What Every Computer Scientist Should Know About Floating-Point Arithmetic»، منشورة في ACM Computing Surveys سنة 1991 — المرجع الكلاسيكي لفهم أخطاء التقريب.
• توثيق Python الرسمي، «Floating-Point Arithmetic: Issues and Limitations» على الرابط docs.python.org/3/tutorial/floatingpoint.html — ومنه القيمة المخزّنة الدقيقة للكسر 0.1.
• MDN Web Docs، صفحة Number.EPSILON — الطريقة الموصى بيها لمقارنة الأرقام العشرية في JavaScript.
• الموقع المرجعي 0.30000000000000004.com اللي بيعرض نفس الناتج عبر أكتر من 100 لغة برمجة.