यह कोई रहस्य नहीं है कि वित्तीय जानकारी (खाते, पोस्टिंग और अन्य बहीखाते) फ्लोटिंग पॉइंट संख्याओं के साथ बहुत अनुकूल नहीं हैं, और कई लेख एक निश्चित बिंदु अंकगणित का उपयोग करने की सलाह देते हैं। जावा में, यह प्रारूप वास्तव में, केवल BigDecimal वर्ग द्वारा प्रस्तुत किया गया है, जिसका उपयोग हमेशा प्रदर्शन कारणों से नहीं किया जा सकता है। हमें विकल्प तलाशने होंगे। यह आलेख निश्चित-सटीक संख्याओं पर अंकगणितीय संचालन करने के लिए एक स्व-लिखित जावा पुस्तकालय का वर्णन करता है। लाइब्रेरी को उच्च-प्रदर्शन वित्तीय अनुप्रयोगों में काम करने के लिए बनाया गया था और आपको स्वीकार्य प्रदर्शन बनाए रखते हुए 9 दशमलव स्थानों की सटीकता के साथ काम करने की अनुमति देता है। स्रोत और बेंचमार्क का एक लिंक लेख के अंत में दिया गया है।

फ्लोटिंग पॉइंट अंकगणित

आधुनिक कंप्यूटर केवल सीमित सटीकता के साथ अंकगणितीय संचालन कर सकते हैं। ये असतत डिवाइस हैं जो सभी संभव संख्याओं के साथ काम नहीं कर सकते हैं, लेकिन केवल उनमें से कुछ गणनीय सबसेट के साथ। कंप्यूटर मेमोरी में वास्तविक संख्याओं के साथ काम करने के लिए सबसे आम प्रारूप एक फ्लोटिंग (बाइनरी) बिंदु - फ्लोटिंग (बाइनरी) बिंदु है, जब संख्याओं को M * 2 ^ E, जहां M और E पूर्णांक मंटिसा और संख्या के क्रम में संग्रहीत किए जाते हैं। लेकिन कुछ संख्याएं, जैसे कि 0.1, को इस प्रारूप में सटीक रूप से प्रस्तुत नहीं किया जा सकता है। इसलिए, जटिल गणना के दौरान, कुछ त्रुटि अनिवार्य रूप से जमा होती है। यही है, मशीन गणना का परिणाम, 0.1 + 0.1 + 0.1 कहते हैं, गणितीय रूप से सही 0.3 के साथ मेल नहीं खाता है। उपरोक्त को देखते हुए, जब प्रोग्रामिंग जटिल अंकगणित, आप कई रणनीतियों का पालन कर सकते हैं:

रणनीति 1 - उपेक्षा। त्रुटि पर ध्यान न दें, सभी कार्यों को आदर्श गणितीय मानें और आशा करें कि स्वीकार्य परिणाम के लिए उपलब्ध सटीकता पर्याप्त है। सबसे आम विकल्प।

रणनीति 2 - सावधानीपूर्वक गणना। मशीन त्रुटियों की गणना के सूत्र दशकों से ज्ञात हैं। वे किसी भी अंकगणितीय ऑपरेशन की सापेक्ष त्रुटि के ऊपर से अनुमान लगाना संभव बनाते हैं। शायद, यह वही है जो आपको गंभीर संख्यात्मक सिमुलेशन के लिए करना है। समस्या यह है कि यह बहुत समय लगता है। वास्तव में, कोड में प्रत्येक + - * / वर्ण त्रुटि गणना के साथ होना चाहिए। आपको गणनाओं के बीच सभी निर्भरता को ध्यान में रखना होगा और कोड बदलने पर हर बार प्रक्रिया को दोहराना होगा।

रणनीति 3 - द्विआधारी के बजाय एक दशमलव बिंदु (अस्थायी दशमलव बिंदु) का उपयोग करें। यही है, संख्याओं को M * 10 ^ E के रूप में संग्रहीत करें। यह त्रुटि की समस्याओं को हल नहीं करता है (मंटिसा अभी भी महत्वपूर्ण अंकों के एक परिमित संख्या में गोल है), लेकिन कम से कम एक व्यक्ति (जैसे 1.1) के लिए सभी "सरल" संख्याओं को अब सही ढंग से स्मृति में दर्शाया गया है। पेबैक परफॉर्मेंस होगा। संख्याओं के किसी भी सामान्यीकरण (अर्थात, मंटिसा में एक बराबर कमी और क्रम में वृद्धि) के लिए 10 की शक्ति से एक विभाजन की आवश्यकता होती है, जो कि एक शक्ति द्वारा विभाजन के विपरीत बहुत तेज़ नहीं है। 2. और आपको बहुत कुछ सामान्य करना होगा - प्रत्येक अतिरिक्त या अलग-अलग आदेशों के साथ घटाव।

रणनीति 4 - एक निश्चित बिंदु (निश्चित दशमलव बिंदु) का उपयोग करें। रणनीति 3 का सरलीकरण, जब हम क्रम ई को ठीक करते हैं। इस मामले में, जोड़ / घटाव के लिए सामान्यीकरण आवश्यक नहीं है। इसके अलावा, सभी गणनाओं में एक ही पूर्ण त्रुटि होगी। यह लेख इसी रणनीति के लिए समर्पित है।

निश्चित बिंदु अंकगणित

भौतिकी के विपरीत, जहां सापेक्ष त्रुटि महत्वपूर्ण है, वित्त में बस निरपेक्ष की आवश्यकता है। यदि, एक जटिल वित्तीय लेनदेन के बाद, ग्राहक को $ 1,000,000.23 का बिल दिया जाता है, जबकि वह $ 1,000,000,18 की उम्मीद करता है, तो कुछ कठिनाइयां उत्पन्न हो सकती हैं। स्पष्टीकरण जैसे "आपको 8 महत्वपूर्ण अंकों में सटीकता की आवश्यकता क्यों है ??" सवारी नहीं हो सकती। और यहाँ बिंदु 5 सेंट के नुकसान में नहीं है (इसके विपरीत करने के लिए, "ग्राहक के पक्ष में" बहुत बेहतर नहीं है), लेकिन लेखांकन में विसंगतियों में। इसलिए, गणना और गोलाई के नियम पार्टियों के बीच स्पष्ट रूप से निर्दिष्ट हैं, और दोहरे और फ्लोट चर के उपयोग से कलाकृतियां कभी-कभी जीवन को जटिल बनाती हैं।

जावा में निश्चित बिंदु अंकगणित के लिए एक मानक वर्ग है - बिगडेसीमल। इसके साथ दो समस्याएं हैं: यह धीमा है (इसकी सार्वभौमिकता के कारण) और यह स्थिर नहीं है। गैर-स्थिरता का मतलब है कि कोई भी ऑपरेशन ढेर पर एक ऑब्जेक्ट आवंटित करता है। किसी वस्तु के संदर्भ में चयन और विमोचन में थोड़ा समय लगता है, लेकिन "हॉट" कोड में गहन गणना जीसी पर एक सभ्य भार पैदा करती है, जो कुछ मामलों में अस्वीकार्य है। आप भागने के विश्लेषण और स्केलराइजेशन पर भरोसा कर सकते हैं, लेकिन वे इस अर्थ में बहुत अस्थिर हैं कि कोड में या यहां तक ​​कि जेआईटी में थोड़ा बदलाव (जैसे कि एक नया इंटरफ़ेस लागू करना आलसी होना) पूरे इनलाइन संरचना को उल्टा कर सकता है, और विधि ने एक मिनट पहले ठीक काम किया, अचानक स्मृति को आबंटित करना शुरू कर देता है।
टिप्पणियों में प्रश्नों के कारण UPD: बिगडेसिमल और बिगइंटर को छोड़ने का मुख्य कारण सभी कम कम्प्यूटेशनल प्रदर्शन नहीं है, लेकिन स्थिरता और वस्तुओं के चयन में कमी है।

वर्णित पुस्तकालय इस तथ्य का परिणाम है कि मैं प्रत्येक नए नियोक्ता के लिए स्क्रैच से निश्चित-बिंदु गैर-आवंटन अंकगणित को फिर से लिखने के लिए थक गया था, और मैंने बाद के आउटसोर्सिंग के लिए अपनी खुद की लाइब्रेरी लिखने का फैसला किया।

कार्यान्वयन विवरणों पर जाने से पहले मैं तुरंत उपयोग का एक उदाहरण दिखाऊंगा:

public class Sample { private final Decimal margin; private final Quantity cumQuantity = new Quantity(); private final Quantity contraQuantity = new Quantity(); private final Quantity cumContraQuantity = new Quantity(); private final Price priceWithMargin = new Price(); private final Price avgPrice = new Price(); public Sample(int marginBp) { // 1 + margin / 10000 this.margin = Decimal.create(marginBp).divRD(10000L).add(1); } public Price calculateAvgPrice(Quantity[] quantities, Price[] prices) { cumQuantity.set(0); contraQuantity.set(0); // avg = sum(q * p * margin) / sum(q) for (int i = 0; i < quantities.length; i++) { cumQuantity.add(quantities[i]); priceWithMargin.set(prices[i]).mulRD(margin); contraQuantity.set(quantities[i]).mulRD(priceWithMargin); cumContraQuantity.add(contraQuantity); } return avgPrice.quotientRD(cumContraQuantity, cumQuantity); } public static void main(String[] args) throws ParseException { Price p1 = Price.create("1.5"); Price p2 = Price.create(1.6); Quantity q1 = Quantity.create("100"); Quantity q2 = Quantity.create(200); // apply 0.05% margin to the prices Sample sample = new Sample(5); System.out.println(sample.calculateAvgPrice(new Quantity[]{q1, q2}, new Price[]{p1, p2})); } } 

कार्यान्वयन का विचार

तो, हमें एक पूर्णांक के एक पूर्णांकिक आवरण की आवश्यकता होती है, जो अधिक सटीक, एक long'a है, जो हमें लगभग 19 महत्वपूर्ण अंक देगा (पूर्णांक और भिन्नात्मक भाग के लिए पर्याप्त)। लंबे समय में, हम एन दशमलव स्थानों का मतलब है। उदाहरण के लिए, एन = 2 के साथ, संख्या 2.56 को 256 (बाइनरी 100000000) के रूप में संग्रहीत किया जाता है। नकारात्मक संख्याओं को मानक के रूप में संग्रहीत किया जाता है, अतिरिक्त कोड में:

-2.56
-256

(इसके बाद, इटैलिक "गणितीय" संख्याओं और गणनाओं को इंगित करते हैं, और बोल्ड में उनके आंतरिक प्रतिनिधित्व)

यह मुझे एक अलग मूल्य के रूप में NaN दर्ज करने के लिए भी उपयोगी लग रहा था, जो अंकगणितीय त्रुटियों (अपवाद या कचरे के बजाय) के मामले में वापस आ गया है। NaN को आंतरिक रूप से Long.MIN_VALUE के रूप में दर्शाया गया है , सभी कार्यों के माध्यम से "प्रचारित" किया गया है और शेष सभी नंबरों के लिए साइन इनवर्जन निर्धारित करने की अनुमति देता है।

चलो मामले के लिए अंकगणितीय संचालन के एल्गोरिदम का अनुमान लगाने की कोशिश करते हैं जब एन = 2।

जोड़ और घटाव को किसी भी अतिरिक्त इशारों की आवश्यकता नहीं है, बस मानों का उपयोग करें जैसे वे हैं:

1.20 + 2.30 = 3.50
120 + 230 = 350

गुणन और विभाजन के लिए अतिरिक्त सामान्यीकरण की आवश्यकता होती है, अर्थात 10 ^ N से गुणा / भाग (हमारे उदाहरण में 100)

1.20 * 2.00 = 2.40
120 * 200/100 = 240

1.20 / 2.00 = 0.60
100 * 120/200 = 60

अतिरिक्त विभाजन सबसे तेज़ संचालन नहीं है। लेकिन इस मामले में, यह एक स्थिर द्वारा एक विभाजन है, क्योंकि हमने पहले एन = 2 और 10 ^ एन = 100 निर्धारित किया था। निरंतर, विशेष रूप से "सुंदर" (प्रकार 10) द्वारा विभाजन, सीपीयू में गहन रूप से अनुकूलित है और एक यादृच्छिक संख्या से विभाजन की तुलना में बहुत तेज है। हम हर बार 10 से कई डिवीज़न करते हैं, हम किसी भी संख्या को एक स्ट्रिंग (उदाहरण के लिए, लॉग में) में परिवर्तित करते हैं, और सीपीयू निर्माता इसके बारे में जानते हैं ( अनुकूलन के बारे में अधिक जानकारी के लिए "स्थिर द्वारा डिवीजन" देखें)।

हम जो कर रहे हैं, उसकी समझ को मजबूत करने के लिए, मैं एक और ऑपरेशन दूंगा: एक नंबर का एकतरफा व्युत्क्रम, अर्थात 1 / x। यह विभाजन का एक विशेष मामला है, आपको बस हमारे प्रारूप में 1.00 जमा करने की आवश्यकता है और इसे सामान्य करने के लिए मत भूलना:

1.00 / 2.00 = 0.50
100 * 100/200 = 50

खैर, जबकि सब कुछ काफी सरल है, आइए विवरणों में तल्लीन करने का प्रयास करें।

गोलाई

आइए एक और संख्या खींचने की कोशिश करें:

1.00 / 3.00 = 0.33
100 * 100/300 = 33

एक ईमानदार गणितीय परिणाम ०.३३ और ०.३४ के बीच है, लेकिन हम इसकी सटीक कल्पना नहीं कर सकते। गोल करने का कौन सा तरीका? आमतौर पर 0 पर गोल किया जाता है, और यह सबसे तेज़ तरीका है (हार्डवेयर समर्थित)। लेकिन, वास्तविक वित्तीय समस्याओं की ओर लौटना, हमेशा ऐसा नहीं होता है। आमतौर पर, जब ग्राहक के साथ लेन-देन की प्रक्रिया होती है, तो राउंडिंग "ग्राहक के पक्ष में होता है।" यही है, अगर ग्राहक बेच रहा है, और ग्राहक खरीद रहा है, तो कीमत गोल हो गई है। लेकिन अन्य विकल्पों की आवश्यकता हो सकती है, उदाहरण के लिए, अकाउंटिंग विसंगतियों को कम करने के लिए उपप्रकारों (अर्ध-अप, आधा-डाउन, आधा-सम) के साथ निकटतम संख्या में अंकगणितीय गोलाई। या नकारात्मक कीमतों (कुछ वित्तीय साधनों के लिए) के लिए ± अनंत तक गोलाई। Java BigDecimal में पहले से ही मानक गोलाई मोड्स की एक सूची है, और वर्णित लाइब्रेरी उन सभी का समर्थन करती है। यदि ऑपरेशन में अनपेक्षित रूप से राउंडिंग की आवश्यकता है तो UNNECESSARY NaN लौटाता है।

राउंड-अप मोड में, हमारी गणना देनी चाहिए:

1.00 / 3.00 = 0.34
100 * 100/300 + 1 = 34

कैसे पता लगाएं कि आपको एक इकाई जोड़ने की आवश्यकता है? आपको शेष बचे विभाजन की आवश्यकता 10,000% 300 = 100 है। यह विभाजन जितना ही धीमा है। सौभाग्य से, यदि आप "a / b;% b" कोड में एक पंक्ति में लिखते हैं, तो JIT को एहसास होगा कि 2 डिवीजनों की आवश्यकता नहीं है, बस एक असेंबलर div कमांड है जो 2 नंबर (भागफल और शेष) लौटाता है।

अन्य राउंडिंग विकल्प थोड़ा अधिक जटिल हैं, लेकिन शेष और विभाजक के आधार पर भी गणना की जा सकती है।

एपीआई में, मैंने जानबूझकर जहां कहीं भी होता है, एक पैरामीटर के रूप में या आर ओाउंड डी के प्रत्यय के तरीकों का उल्लेख करने का उल्लेख किया है, जहां यह शून्य से चूकता है।

बाढ़

हम सबसे कठिन हिस्से में आते हैं। हमारे गुणन को फिर से याद करें:

1.20 * 2.00 = 2.40
120 * 200/100 = 240

अब कल्पना करें कि हम 1980 के दशक में हैं और हमारे पास 16-बिट प्रोसेसर हैं। यही है, केवल 65535 के अधिकतम मूल्य के साथ हमारे लिए कम उपलब्ध है। पहला गुणन ओवरफ्लो होगा और 240000 & 0xFFFF = 44392 के बराबर होगा (यदि यह अहस्ताक्षरित है, तो संकेत के साथ यह भी नकारात्मक होगा, जो हमारे लिए परिणाम को तोड़ देगा।

यह काम नहीं किया हमारे पास 2 सामान्य (मूल्यों की हमारी सीमा में फिट) तर्क हैं, और समान सामान्य अपेक्षित परिणाम हैं, लेकिन हम आधे रास्ते से बह जाते हैं। ठीक यही स्थिति 64-बिट लॉन्गऑम के साथ संभव है, बस संख्याओं की अधिक आवश्यकता है।

1980 के दशक में, हमें 32-बिट परिणाम देने वाले गुणन की आवश्यकता होगी। आज हमें 128-बिट परिणाम के साथ गुणा की आवश्यकता है। सबसे अधिक कष्टप्रद यह है कि दोनों गुणन क्रमशः असेम्बलर्स 8086 और x86-64 में उपलब्ध हैं, लेकिन हम उन्हें जावा के साथ उपयोग नहीं कर सकते हैं! जेएनआई, यहां तक ​​कि तेजी से जावा क्रिटिकल के साथ एक हैक के मामले में, दसियों नैनोसेकंड का एक ओवरहेड देता है, तैनाती और संगतता के साथ कठिनाइयों का परिचय देता है, कॉल की अवधि के लिए जीसी को जमा देता है। इसके अलावा, हमें किसी तरह मूल विधि से 128-बिट परिणाम वापस करना होगा, और एक सरणी (स्मृति में) के संदर्भ में लिखना एक अतिरिक्त देरी है।

सामान्य तौर पर, मुझे मैनुअल गुणा और विभाजन लिखना था। कॉलम। मुझे 2 सहायक कार्यों की आवश्यकता थी:

1. ए (64) * बी (64) = टी (128); T (128) / N (32) = Q (64), R (32) - गुणक A / B के निश्चित बिंदु के भाग के रूप में
2. एन (32) * ए (64) = टी (96); टी (96) / बी (64) = क्यू (64), आर (64) - निश्चित बिंदु विभाजन ए / बी के हिस्से के रूप में
   (कोष्ठक में बिट्स में डेटा के आयाम को इंगित करता है, टी एक अस्थायी चर है जिसे अतिप्रवाह नहीं किया जाना चाहिए)

दोनों ऑपरेशन भागफल और शेष (विधि के परिणामस्वरूप एक, वस्तु क्षेत्र में दूसरा) वापस करते हैं। वे अतिप्रवाह भी कर सकते हैं, लेकिन केवल अंतिम चरण में, जब यह अपरिहार्य है। यहाँ एक उदाहरण है (1980 के दशक से):

500.00 / 0.50 = 1000.00
100 * 50,000 / 50 = 100,000 - अतिप्रवाह!

स्तंभ विभाजन एक ला नॉट सबसे आसान एल्गोरिथ्म नहीं है। साथ ही, यह अपेक्षाकृत तेज होना चाहिए। इसलिए, दोनों ऑपरेशनों का कोड गंभीर बिट मैजिक की सैकड़ों लाइनें हैं, मुझे फिर से याद करने में बहुत समय लगेगा कि वास्तव में वहां क्या हो रहा है। मैंने उन्हें एक अलग वर्ग में खींच लिया और विस्तार से टिप्पणी की जैसा मैं कर सकता था।

गुणन एल्गोरिथ्म ऑपरेशन 1 को लागू करने तक सीमित नहीं है, लेकिन शेष कोड इतना जटिल नहीं है और सिर्फ नकारात्मक संख्याओं, गोलाई और NaN के लिए समर्थन जोड़ता है।

आमतौर पर (विशेष मामलों को छोड़कर), दोनों ऑपरेशनों में 4 गुणा और 2 विभाजन होते हैं। ऑपरेशन 1 2 की तुलना में काफी तेज है, क्योंकि इसमें ये विभाजन एक स्थिर है।

वैसे, अगर किसी पर ध्यान दिया जाए, तो N (32) सामान्यीकरण के लिए हमारा 10 ^ N है। यह 32-बिट है, जिसमें से यह निम्न है कि एन अधिकतम 9 हो सकता है। मैंने जो वास्तविक एप्लिकेशन देखे, उनमें 2, 4 या 8 दशमलव स्थानों का उपयोग किया गया था। मैंने 9 से अधिक नहीं देखे हैं, इसलिए यह पर्याप्त होना चाहिए। यदि आप 10 ^ N 64-बिट बनाते हैं, तो कोड अधिक जटिल हो जाता है (और धीमा हो जाता है) और भी अधिक।

कई अलग सटीक

कभी-कभी अलग-अलग दशमलव स्थानों के साथ तर्कों पर एक ऑपरेशन करना आवश्यक होता है। कम से कम, सामान्य लंबे समय से जुड़े ऑपरेशन दर्ज करें।

उदाहरण के लिए:

2.0000 (एन = 4) + 3.00 (एन = 2) = 5.0000 (एन = 4)
20,000 + 300 * 100 = 50,000

3.00 (एन = 2) + 2.0000 (एन = 4) = 5.00 (एन = 2)
300 + 20,000 / 100 = 500

इस मामले में, किसी एक तर्क का अतिरिक्त सामान्यीकरण आवश्यक है। ध्यान दें कि गणितीय रूप से दोनों ऑपरेशन समान हैं, लेकिन परिणाम की विभिन्न सटीकता के कारण, उनकी गणना अलग-अलग की जाती है। यह भी ध्यान देने योग्य है कि दूसरे ऑपरेशन में आम तौर पर गोलाई की आवश्यकता होती है।

दशमलव स्थानों की संख्या ऑब्जेक्ट में संग्रहीत नहीं है। इसके बजाय, प्रत्येक सटीकता के लिए एक अलग उपवर्ग ग्रहण किया जाता है। वर्ग के नाम व्यवसाय-उन्मुख हो सकते हैं, उदाहरण के लिए मूल्य (एन = 8), मात्रा (एन = 2)। और उन्हें सामान्यीकृत किया जा सकता है: Decimal1, Decimal2, Decimal3, ... अधिक से अधिक सटीकता, संग्रहीत मूल्यों की सीमा जितनी छोटी होगी, न्यूनतम सीमा में दशमलव 9: 33 9223372036 है। यह माना जाता है कि आवश्यक कार्यक्षमता को कवर करने के लिए एक या दो कक्षाएं पर्याप्त होंगी, जिस स्थिति में अमूर्त getScale विधि सबसे अधिक संभावना के साथ विचलन और इनलाइन होगी। उपवर्ग (एक अतिरिक्त क्षेत्र के बजाय) आपको तर्क और परिणाम की सटीकता को सख्ती से टाइप करने की अनुमति देता है, साथ ही संकलन चरण में संभावित गोलाई के बारे में संकेत देता है।

पुस्तकालय विभिन्न सटीकता के अधिकतम 2 (लेकिन 3 नहीं) के साथ संचालन की अनुमति देता है। यही है, या तो दो तर्कों की सटीकता को मेल खाना चाहिए, या किसी एक तर्क और परिणाम की सटीकता। फिर, 3 अलग-अलग परिशुद्धता का समर्थन कोड को बहुत धीमा कर देगा और एपीआई को जटिल करेगा। तर्कों के रूप में, आप एक नियमित रूप से लंबा पास कर सकते हैं, जिसके लिए एन = 0 की सटीकता मान ली जाती है।

2.0000 / 3.0 = 0.6667 - ठीक है (2 विभिन्न परिशुद्धता)
2/3 = 0.6667 - ठीक है (लंबे तर्क, दशमलव परिणाम)
2 / 3.0 = 0.6667 - असंभव! (3 विभिन्न परिशुद्धता)

फायदे और नुकसान

जाहिर है, लाइब्रेरी द्वारा निष्पादित उच्च-बिट कंप्यूटिंग हार्डवेयर-समर्थित की तुलना में धीमी है। हालाँकि, ओवरहेड इतना बड़ा नहीं है (नीचे बेंचमार्क देखें)।

इसके अलावा, जावा में ऑपरेटर ओवरलोडिंग की कमी के कारण, अंकगणितीय ऑपरेटरों के बजाय तरीकों का उपयोग करना कोड की धारणा को जटिल बनाता है।

इसके आधार पर, आमतौर पर पुस्तकालय का उपयोग उन स्थानों पर किया जाता है जहां पूर्ण सटीकता का नुकसान महत्वपूर्ण है। उदाहरण के लिए, सटीक वित्तीय आंकड़ों की गणना, वर्तमान वित्तीय संकेतकों (ट्रेडिंग पदों, PnL, निष्पादित आदेश) को ध्यान में रखते हुए। सिस्टम के बीच वित्तीय जानकारी के नेटवर्क एक्सचेंज में, दशमलव बिंदु (बाइनरी के बजाय) के साथ प्रारूपों का उपयोग करना अधिक सुविधाजनक है।

जटिल गणितीय एल्गोरिदम (मॉडलिंग, सांख्यिकी, पूर्वानुमान) आमतौर पर मानक रूप से दोहरे में ले जाने के लिए आसान होते हैं, क्योंकि उनका परिणाम किसी भी मामले में बिल्कुल सटीक होता है।

कोड और बेंचमार्क

कोड

सामान्य तौर पर, BigDecimal की तुलना में गुणा 4 गुना तेज है, विभाजन 1.5 है। विभाजन दर तर्कों पर अत्यधिक निर्भर है, इसलिए मूल्यों का बिखराव है।