सामान्य अभ्यास इंटीजर ओवरफ्लो से कैसे निपटें?

Question

अनुप्रयोग विकास टीम दृष्टिकोण से 99 99 99 * 99 99 99 (परिणाम> Integer.MAX_VALUE) जैसे इंटीजर ओवरफ्लो से निपटने के लिए सामान्य प्रथा क्या है?

कोई भी BigInt अनिवार्य कर सकता है और Integer के उपयोग को प्रतिबंधित कर सकता है, लेकिन क्या यह एक अच्छा/बुरा विचार है?

Answer 1

यदि यह अत्यंत महत्वपूर्ण है कि पूर्णांक अतिप्रवाह नहीं है, आप अपने खुद के अतिप्रवाह को पकड़ने के संचालन, जैसे परिभाषित कर सकते हैं:

def +?+(i: Int, j: Int) = { 
    val ans = i.toLong + j.toLong 
    if (ans < Int.MinValue || ans > Int.MaxValue) { 
    throw new ArithmeticException("Int out of bounds") 
    } 
    ans.toInt 
} 

आप इस चालू करने के लिए समृद्ध-your-पुस्तकालय पैटर्न का उपयोग करने में सक्षम हो सकता है ऑपरेटरों में; यदि JVM ठीक से भागने का विश्लेषण कर प्रबंधन करता है, आप इसके लिए एक दंड का बहुत अधिक मिल जाएगा नहीं:

class SafePlusInt(i: Int) { 
    def +?+(j: Int) = { /* as before, except without i param */ } 
} 
implicit def int_can_be_safe(i: Int) = new SafePlusInt(i) 

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

scala> 1000000000 +?+ 1000000000 
res0: Int = 2000000000 

scala> 2000000000 +?+ 2000000000 
java.lang.ArithmeticException: Int out of bounds 
    at SafePlusInt.$plus$qmark$plus(<console>:12) 
    ... 

यदि यह अत्यंत महत्वपूर्ण नहीं है, तो मानक इकाई परीक्षण और कोड समीक्षा और इस तरह के मामलों के बड़े बहुमत में समस्या को पकड़ना चाहिए। BigInt का उपयोग करना संभव है, लेकिन 100 या उससे अधिक के कारक द्वारा आपके अंकगणितीय को धीमा कर देगा, और जब आपको मौजूदा विधि का उपयोग करना होगा, तो Int लेना होगा।

Answer 2

अब तक का सबसे आम पूर्णांक अतिप्रवाह के बारे में अभ्यास है कि प्रोग्रामर को पता है कि इस मुद्दे को, मौजूद है मामलों में जहां वे हो सकता है के लिए देखने के लिए, और उचित जाँच करता है बनाने के लिए या पुन: व्यवस्थित गणित ताकि जीता overflows उम्मीद कर रहे हैं है ऐसा नहीं होता है, (ए * बी)/सी के बजाए * (बी/सी) करने जैसी चीज़ें। यदि परियोजना इकाई परीक्षण का उपयोग करती है, तो वे मामलों को शामिल करने के लिए ओवरफ्लो को लागू करने और मजबूर करने के लिए शामिल करेंगे।

मैंने कभी भी उस टीम से कोड पर काम नहीं किया है या उससे अधिक की आवश्यकता है, इसलिए मैं कहूंगा कि लगभग सभी सॉफ्टवेयर के लिए यह काफी अच्छा है।

एक एम्बेडेड एप्लिकेशन मैंने देखा है कि वास्तव में, ईमानदार-से-स्पेगेटी-राक्षस को ओवरफ्लो को रोकने के लिए आवश्यक है, उन्होंने यह साबित करके यह किया कि प्रत्येक पंक्ति में अतिप्रवाह संभव नहीं था, ऐसा लगता है कि ऐसा हो सकता है।

def naturals[A](implicit f: Integral[A]) = 
    Stream.iterate(f.one)(f.plus(_, f.one)) 

तुम भी कर सकते हैं:

Answer 3

आप स्काला उपयोग कर रहे हैं (और टैग मैं आप कर रहे हैं यह सोचते कर रहा हूँ के आधार पर), एक बहुत सामान्य समाधान scala.math.Integral प्रकार वर्ग के खिलाफ अपने पुस्तकालय कोड लिखना है अच्छे वाक्य रचना के लिए संदर्भ सीमा और Integral.Implicits का उपयोग करें:

import scala.math.Integral.Implicits._ 

def squares[A: Integral] = naturals.map(n => n * n) 

अब आप या तो Int या Long या BigInt की जरूरत के रूप में के साथ इन तरीकों का उपयोग कर सकतेके उदाहरण के बाद सेउन सभी के लिए मौजूद हैं:

scala> squares[Int].take(10).toList 
res0: List[Int] = List(1, 4, 9, 16, 25, 36, 49, 64, 81, 100) 

scala> squares[Long].take(10).toList 
res0: List[Long] = List(1, 4, 9, 16, 25, 36, 49, 64, 81, 100) 

scala> squares[BigInt].take(10).toList 
res1: List[BigInt] = List(1, 4, 9, 16, 25, 36, 49, 64, 81, 100) 

कोई ज़रूरत नहीं पुस्तकालय कोड बदलने के लिए: बस का उपयोग Long या BigInt ओवरफ़्लो चिंता और Int अन्यथा है।

आप प्रदर्शन के मामले में कुछ जुर्माना अदा करेंगे, लेकिन सामान्यता और Int -or- BigInt को स्थगित करने की क्षमता इसके लायक हो सकती है।

Answer 4

सरल मानसिकता के अलावा, जैसा कि @mjfgates द्वारा नोट किया गया है, वहां कुछ अभ्यास हैं जो मैं हमेशा स्केल किए गए-दशमलव (गैर-फ़्लोटिंग-पॉइंट) वास्तविक दुनिया की मात्रा से निपटने के दौरान उपयोग करता हूं। यह आपके विशेष आवेदन के लिए बिंदु पर नहीं हो सकता है - अगर अग्रिम में माफी माँगती है।

सबसे पहले, यदि उपयोग में माप की कई इकाइयां हैं, तो मूल्यों को हमेशा स्पष्ट रूप से पहचानना चाहिए कि वे क्या हैं। यह सम्मेलन नामकरण, या माप की प्रत्येक इकाई के लिए एक अलग वर्ग का उपयोग करके किया जा सकता है। मैंने हमेशा नामों का उपयोग किया है - हर चर नाम पर एक प्रत्यय। errors from confusion over the units को समाप्त करने के अलावा, यह अतिप्रवाह के बारे में सोचने को प्रोत्साहित करता है क्योंकि उपायों को केवल संख्याओं के रूप में सोचा जाने की संभावना कम होती है।

दूसरा, अतिप्रवाह चिंता का मेरा सबसे लगातार स्रोत आम तौर पर एक माप से दूसरे में परिवर्तित होता है - जब इसे बहुत महत्वपूर्ण अंक की आवश्यकता होती है। उदाहरण के लिए, सेमी से इंच तक रूपांतरण कारक 0.3 93700787402 है। महत्वपूर्ण अंक के अतिप्रवाह और हानि से बचने के लिए, आपको सही क्रम में गुणा करने और विभाजित करने के लिए सावधान रहना होगा। मैं इस एक लंबे समय में नहीं किया है, लेकिन मेरा मानना ​​है कि आप क्या चाहते हैं की तरह कुछ:

Rational.scala में जोड़े, पुस्तक से:

def rescale(i:Int) : Int = { 
     (i * (numer/denom)) + (i/denom * (numer % denom)) 

तो फिर तुम के रूप में परिणाम (एक specs2 से छोटा मिल परीक्षण):

val InchesToCm = new Rational(1000000000,393700787) 
    InchesToCm.rescale(393700787) must_== 1000000000 
    InchesToCm.rescale(1) must_== 2 

यह नकारात्मक स्केलिंग कारकों के दौर में नहीं है, या सौदा नहीं करता है। एक उत्पादन कार्यान्वयन numer/denom और numer % denom को कारक बनाना चाहता है।