विषय 70 / 91· सॉफ़्टवेयर इंजीनियरिंग और डिजिटल डिलीवरी

यथार्थ-सेंट लागत आवंटन

एक कुल राशि — साझा अनुदान, अवसंरचना चालान, बजट प्रभाव आँकड़ा — को सरल प्रतिशत अंकगणित से कई प्राप्तकर्ताओं में बाँटने पर अक्सर ऐसे हिस्से निकलते हैं जो जोड़ने पर मूल कुल के बराबर नहीं होते। यथार्थ-सेंट आवंटन उपाय है: एक पूर्णांक/दशमलव विधि जो मुद्रा की न्यूनतम इकाई (सेंट) में काम करती है और गारंटी देती है कि हिस्से ठीक-ठीक कुल के बराबर जुड़ेंगे, विभाजन चाहे जितना असमान हो। हर सॉफ़्टवेयर इंजीनियर जिसे बाँटे गए कुल को सेंट तक मिलाना है — वेतन-सूची, अनुदान भुगतान, साझा सेवा शुल्क — को यह पैटर्न चाहिए, फ़्लोटिंग-पॉइंट प्रतिशत नहीं।

यह क्यों महत्वपूर्ण है

यह एंटरप्राइज़ सॉफ़्टवेयर इंजीनियरिंग का एक नामित मूलभूत पैटर्न है: Martin Fowler की Patterns of Enterprise Application Architecture (2002) Money और Allocate को प्रलेखित करती है ठीक इसलिए कि "$100 को तीन में बाँटना" ऐसी समस्या है जिसे सरल कोड हमेशा ग़लत करता है, और चुपचाप ग़लत करता है — त्रुटि तब सामने आती है जब कोई बही मिलाता है और पाता है कि हिस्से कुल से एक सेंट कम (या ज़्यादा) हैं। स्वास्थ्य-अर्थशास्त्र और NHS वित्तीय कार्य में यह सैद्धांतिक नहीं है: बजट प्रभाव आँकड़ा स्थान, वर्ष या ट्रस्ट के अनुसार बाँटा जाता है; साझा अवसंरचना और लाइसेंस लागत कर्मचारी संख्या या गतिविधि अनुपात के आधार पर विभागों में वितरित होती है। इनमें से हर बँटवारा ठीक-ठीक मिलना चाहिए, क्योंकि जो वित्त निदेशक ऐसे हिस्से पाता है जो कुल के बराबर नहीं जुड़ते, वह पूरे मॉडल पर भरोसा खो देगा।

गणित

सरल विधि (दोषपूर्ण):
  हिस्सा_i = पूर्णांकन(कुल × अनुपात_i / Σ अनुपात)     — प्रत्येक हिस्से को अलग-अलग पूर्णांकित करता है

यथार्थ विधि (सबसे बड़ा शेष / "largest remainder allocation"):
  1. आधार_i = फ़र्श(कुल_न्यूनतम_इकाई में × अनुपात_i / Σ अनुपात)   — केवल पूर्ण न्यूनतम इकाइयाँ (सेंट)
  2. शेष = कुल_न्यूनतम_इकाई में − Σ आधार_i                          — बचे सेंट, हमेशा < प्राप्तकर्ताओं की संख्या
  3. चरण 1 से सबसे बड़े भिन्नात्मक भाग वाले `शेष` प्राप्तकर्ताओं में से प्रत्येक
     को 1 अतिरिक्त न्यूनतम इकाई दें, जब तक शेष समाप्त न हो

परिणाम: Σ हिस्सा_i == कुल हमेशा, संरचना से

यथार्थ विधि किसी एक हिस्से को कभी अलग से पूर्णांकित नहीं करती — यह पूरे आवंटन को एक ही संक्रिया के रूप में पूर्णांकित करती है, और यही योग-अपरिवर्तनीयता को सत्य बनाता है।

हल किया गया उदाहरण

$100.00 को तीन समान हिस्सों में बाँटना (अनुपात = [1, 1, 1])।

सरल विधि: $100.00 ÷ 3 = $33.333… हर एक को अलग से निकटतम सेंट तक पूर्णांकित करने पर प्रति प्राप्तकर्ता $33.33 मिलता है। योग: $33.33 × 3 = $99.99 — एक सेंट ग़ायब है, और कोई अकेली मद इतनी "ग़लत" नहीं कि आँख से पकड़ी जाए।

यथार्थ विधि: तीनों के लिए आधार = $33.33 (फ़र्श(10,000 / 3) = 3,333 सेंट प्रति प्राप्तकर्ता से कुल 9,999 न्यूनतम इकाइयाँ)। 1 सेंट शेष है (10,000 − 9,999)। वह अकेला बचा सेंट उस प्राप्तकर्ता को जाता है जिसके भाग में सबसे बड़ा भिन्नात्मक अंश है — ठीक कौन-सा प्राप्तकर्ता, यह टाई-ब्रेकिंग का आंतरिक ब्योरा है, जिस पर कॉलर को निर्भर नहीं होना चाहिए। दो प्राप्तकर्ताओं को $33.33 और एक को $33.34 मिलता है, और तीनों हिस्से ठीक-ठीक $100.00 जुड़ते हैं।

यही वह अंकगणित है जिसकी बजट प्रभाव विश्लेषण को ज़रूरत पड़ती है जब भी कुल बजट प्रभाव आँकड़े को स्थान, जनसंख्या समूह या वित्तीय वर्ष के अनुसार बाँटना और प्रकाशित कुल से मिलाना हो — ऐसी बहुत-सी मदों को बिना भटकाव जोड़ने की पूरक समस्या के लिए मुद्रा-सुरक्षित लागत संकलन देखें।

सॉफ़्टवेयर इंजीनियरिंग से संबंध

यह एंटरप्राइज़ सॉफ़्टवेयर आर्किटेक्चर का "Money पैटर्न" ही है — इसी विशिष्ट बग वर्ग के लिए नामित मूलभूत पैटर्न, कोई एक-बार की चाल नहीं। इसी बग से वास्तविक वित्तीय मिलान विफलताएँ प्रोडक्शन तक पहुँची हैं: f64 में गणित किया गया अनुपातिक विभाजन, प्रति प्राप्तकर्ता पूर्णांकित, और मूल कुल के विरुद्ध कभी जाँचा नहीं गया। यह इस रिपॉज़िटरी के स्वामित्व की कुल लागत मॉड्यूल से सीधे जुड़ता है, जो फ़िलहाल वर्षों और विकल्पों में सामान्य फ़्लोटिंग-पॉइंट लागत जोड़ता है — वही शुद्धता का अनुशासन लागू होता है जब TCO या बजट प्रभाव कुल को केवल जोड़ना नहीं, आवंटित करना हो।

सामान्य गलतियाँ

  • सबसे बड़े शेष की जगह प्रतिशत-फिर-पूर्णांकन: फ़्लोटिंग-पॉइंट प्रतिशत से आवंटन करना और प्रत्येक प्राप्तकर्ता को अलग से पूर्णांकित करना, जो पूर्णांकन त्रुटियाँ बढ़ाता है और शायद ही कुल पर लौटकर जुड़ता है, ख़ासकर कई प्राप्तकर्ताओं के साथ।
  • मुद्रा की न्यूनतम इकाई घात की अनदेखी: मान लेना कि हर मुद्रा में 2 दशमलव स्थान होते हैं — जापानी येन में 0, कुछ मुद्राओं में 3 — हाथ से लिखा अनुपातिक विभाजन अक्सर 2 हार्डकोड कर देता है और अन्य मुद्राओं के साथ चुपचाप टूटता है। यथार्थ आवंटन रूटीन घात मुद्रा से ही पढ़ता है (ISO 4217)।
  • पहले से आवंटित शेष का पुनः आवंटन: पिछले आवंटन के बचे हिस्से पर आवंटन रूटीन फिर चलाना, बिना इडेम्पोटेंसी जाँच के, जो उसी प्राप्तकर्ता को वही सेंट दो बार जमा कर सकता है।

स्रोत

  • Fowler M. "Patterns of Enterprise Application Architecture." Addison-Wesley, 2002 — Money और Allocate पैटर्न।
  • ISO 4217 — मुद्रा और निधि कोड का मानक, जो प्रत्येक मुद्रा की न्यूनतम इकाई घात परिभाषित करता है।