विषय 71 / 91· सॉफ़्टवेयर इंजीनियरिंग और डिजिटल डिलीवरी
मुद्रा-सुरक्षित लागत संकलन
बहुत-सी मौद्रिक मदों — मासिक चालान, प्रति-स्थान लागत, बहु-वर्षीय बजट प्रभाव आँकड़े — को सामान्य बाइनरी फ़्लोटिंग-पॉइंट संख्याओं (f64) से जोड़ना छोटी-छोटी निरूपण त्रुटियाँ जमा करता है, क्योंकि अधिकांश दशमलव भिन्न (जैसे $1,234.56) बाइनरी फ़्लोटिंग-पॉइंट में ठीक-ठीक निरूपित नहीं हो सकते। हर त्रुटि छोटी होती है, पर सैकड़ों या हज़ारों मदों को वर्षों में जोड़ने वाला बड़ा मॉडल एक सेंट के अंश से भटक सकता है — और भटकाव जोड़ने के क्रम पर निर्भर करता है, इसलिए दोहराने योग्य नहीं। यथार्थ दशमलव अंकगणित (या पूर्णांक न्यूनतम इकाई) से किया गया मुद्रा संकलन ठीक-ठीक जुड़ता है, इस तरह कि लेखा प्रणालियाँ और द्वि-प्रविष्टि बहीखाता सेंट तक मिलना चाहिए।
यह क्यों महत्वपूर्ण है
यह एक भलीभाँति प्रलेखित और मूलभूत सॉफ़्टवेयर बग प्रकार है: Goldberg का 1991 का ACM Computing Surveys लेख "What Every Computer Scientist Should Know About Floating-Point Arithmetic" इस बात का मानक संदर्भ है कि बाइनरी फ़्लोटिंग-पॉइंट अधिकांश दशमलव राशियों को ठीक-ठीक क्यों निरूपित नहीं कर सकता और उनमें से बहुतों को जोड़ने से त्रुटि क्यों बढ़ती है। NHS के स्वास्थ्य-अर्थशास्त्र और वित्तीय मॉडल नियमित रूप से कई वर्ष और कई लागत श्रेणियाँ जोड़ते हैं — स्वामित्व की कुल लागत और बजट प्रभाव विश्लेषण दोनों वर्षों में कई f64 लागत मदें जोड़ते हैं। जब किसी मॉडल को सेंट तक मिलना हो — हाथ से कुल निकालने वाले ऑडिट को बिल्कुल वही संख्या मिलनी चाहिए — तब अंकगणित स्वयं यथार्थ दशमलव होना चाहिए, फ़्लोटिंग-पॉइंट नहीं।
गणित
सरल संकलन: कुल = Σ f64(मद_i) — क्रम-निर्भर भटकाव
मुद्रा-सुरक्षित संकलन: कुल = Σ Decimal(मद_i) — यथार्थ, दोहराने योग्य
प्रतिशत समायोजन लागू करना (जैसे आकस्मिकता):
समायोजित = कुल × गुणक — यथार्थ Decimal परिणाम, मुद्रा की न्यूनतम
इकाई घात से अधिक दशमलव स्थान हो सकते हैं
पूर्णांकित = पूर्णांकन(समायोजित, मुद्रा_घात, पूर्णांकन_नियम)
— पूर्णांकन नियम (half-up बनाम
half-even/बैंकर का पूर्णांकन) स्पष्ट रूप
से बताना चाहिए
दो-चरणीय अनुशासन पर ध्यान दें: यथार्थ Decimal को गुणक से गुणा करने पर मुद्रा के वास्तविक उपयोग से अधिक दशमलव स्थान आ सकते हैं (जैसे दो स्थान वाली संख्या को दो स्थान वाले गुणक से गुणा करने पर तीन दशमलव स्थान) — वह मध्यवर्ती परिशुद्धता अपने आप नहीं छँटती; केवल स्पष्ट पूर्णांकन चरण, बताए गए पूर्णांकन नियम के साथ, उसे मुद्रा की वास्तविक न्यूनतम इकाई घात तक लाता है।
हल किया गया उदाहरण
बारह एक-समान मासिक चालान, प्रत्येक $1,234.56, यथार्थ दशमलव अंकगणित से जोड़े गए: $1,234.56 × 12 = ठीक-ठीक $14,814.72, बनाम IEEE-754 द्विगुण परिशुद्धता में f64 स्थिरांक 1234.56 को बारह बार जोड़ना, जो जोड़ने के क्रम के अनुसार एक सेंट के अंश से भटक सकता है — एक वास्तविक और प्रलेखित बग प्रकार, यथार्थ दशमलव Money अंकगणित पर बने मॉडल के लिए कोई समस्या नहीं।
अब उस $14,814.72 कुल पर मानक 5% बजट प्रभाव आकस्मिकता (गुणक 1.05) लागू करें: $14,814.72 × 1.05 = $15,555.456 — तीन दशमलव स्थान, क्योंकि गुणन यथार्थ है और अपने आप मुद्रा के दो स्थानों तक पूर्णांकित नहीं होता। बैंकर के पूर्णांकन (half-even) से स्पष्ट रूप से 2 स्थानों तक पूर्णांकित करने पर ठीक-ठीक $15,555.46 मिलता है।
सॉफ़्टवेयर इंजीनियरिंग से संबंध
यह "वित्तीय सॉफ़्टवेयर Decimal का उपयोग करता है, float का नहीं" सिद्धांत के पीछे का सीधा मूलभूत पाठ है — इस रिपॉज़िटरी के स्वामित्व की कुल लागत और बजट प्रभाव विश्लेषण मॉड्यूलों से स्पष्ट रूप से जुड़ा, जो फ़िलहाल सामान्य फ़्लोटिंग-पॉइंट लागत जोड़ते हैं। शुद्धता का तर्क उन मॉडलों को तुरंत स्थानांतरित करने की माँग नहीं करता; यह ठीक-ठीक बताता है कि कब किसी प्रणाली को सेंट तक मिलना चाहिए और इसलिए अपने मुद्रा अंकगणित के लिए बाइनरी फ़्लोटिंग-पॉइंट का उपयोग नहीं करना चाहिए। एक कुल को (जोड़ने के बजाय) बिना एक सेंट खोए बाँटने की पूरक समस्या के लिए यथार्थ-सेंट लागत आवंटन देखें।
सामान्य गलतियाँ
- शृंखला के बीच में
floatमें रूपांतरण: गणना के बीच किसी मौद्रिक मान को फ़्लोटिंग-पॉइंट संख्या के रूप में निकालना (कुछMoneyलाइब्रेरी इस रूपांतरण विधि का नाम ही स्पष्ट चेतावनी के रूप में "lossy" रखती हैं) उस बिंदु के बाद की हर गणना के लिए यथार्थता की गारंटी चुपचाप छोड़ देता है। - "Decimal इतना धीमा है कि परवाह करें": यथार्थ दशमलव अंकगणित को अनावश्यक बोझ कहकर ख़ारिज करना, जबकि वित्तीय रिपोर्टिंग को शुद्धता और लेखा-परीक्षा योग्यता चाहिए, कच्ची थ्रूपुट नहीं।
- पूर्णांकन नियम बताए बिना आकस्मिकता प्रतिशत लागू करना: half-up बनाम half-even (बैंकर का पूर्णांकन) अंतिम सेंट बदल सकता है; पूर्णांकन परिपाटी स्वयं एक घोषित, लेखा-परीक्षा योग्य चुनाव होनी चाहिए — आकस्मिकता समायोजन और आशावाद पूर्वाग्रह पर HM Treasury Green Book मार्गदर्शन के लिए लागत-लाभ विश्लेषण देखें, उसी प्रकार की संख्याएँ जिन पर यह पूर्णांकन चरण लागू होता है।
स्रोत
- Fowler M. "Patterns of Enterprise Application Architecture." Addison-Wesley, 2002 —
Moneyपैटर्न। - Goldberg D. "What Every Computer Scientist Should Know About Floating-Point Arithmetic." ACM Computing Surveys, 1991.
- HM Treasury, The Green Book — बजट प्रभाव मॉडलन के लिए आशावाद पूर्वाग्रह और आकस्मिकता मार्गदर्शन. https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-government/the-green-book-2020