डबल रूपांतरण में फ़्लोट - यूनिट परीक्षण में सर्वश्रेष्ठ दावा?

Question

बयान

float f = 7.1f; 
double d = f; 

क्या हम घ के बारे में एक इकाई परीक्षण में जोर कर सकते हैं को देखते हुए?

---

उदाहरण के लिए यह काम नहीं करता:

Console.WriteLine(d == 7.1d); // false 
Console.WriteLine(d < 7.1d + float.Epsilon); // true by luck 
Console.WriteLine(d > 7.1d - float.Epsilon); // false (less luck) 

सबसे अच्छा तरीका है मैं अब तक पाया मूल्य वापस कन्वर्ट करने के लिए है:

float f2 = (float)d; 
Console.WriteLine(f2 == f); // true 

कौन सा जानवर के रूप में ही किया जाएगा

Console.WriteLine(d == 7.1f); // 7.1f implicitly converted to double as above 

यह प्रश्न सामान्य रूप से डबल और फ्लोट परिशुद्धता के बारे में नहीं है, लेकिन वास्तव में व्यावहारिक प्रश्न के बारे में केवल एक इकाई परीक्षण डी की सीमाओं का सबसे अच्छा वर्णन कैसे कर सकता है। मेरे मामले में, डी एक रूपांतरण का परिणाम है जो हल्के वजन कोड उत्पादन द्वारा उत्पन्न कोड में होता है। इस कोड पीढ़ी का परीक्षण करते समय, मुझे इस समारोह के नतीजे के बारे में दावा करना होगा और अंततः उपरोक्त सरल प्रश्न पर उबाल लें।

Answer 1

आपका "सबसे अच्छा तरीका" यह कह रहा है कि आपका जेनरेट कोड float त्रुटि के मार्जिन, 7.1 के भीतर कुछ देता है। यह हो सकता है कि आप जो जांचना चाहते हैं, उस स्थिति में, आगे बढ़ें।

दूसरी ओर, यदि आप अपने उत्पन्न कोड रिटर्न पर जोर करना चाह सकते हैं विशेष रूप से एक double को 7.1f कास्टिंग का परिणाम है, इस स्थिति में आप कर सकता है:

Console.WriteLine(d == (double)f); 

यह और अधिक कठोर है - आपका परीक्षण दावा करता है कि d एक छोटी सी सीमा के भीतर है, जबकि उपरोक्त परीक्षण का दावा है कि d एक विशिष्ट मान है।

यह वास्तव में इस बात पर निर्भर करता है कि आप d का उपयोग किस प्रकार करेंगे। यदि यह एक ऐसा मामला है जहां चीजें गलत हो जाएंगी, तो यह सही मूल्य नहीं है, तो सटीक मान का परीक्षण करें, लेकिन यदि यह मान के float के भीतर होना ठीक है, तो float के विरुद्ध जांचें।

Answer 2

दो नाव बिंदु ibm sugests महत्व देता abs(a/b - 1) < epsilon

एक msnd कहा गया है कि Epsilon संपत्ति छोटी से छोटी सकारात्मक मूल्य है कि संख्यात्मक संचालन या तुलना में महत्वपूर्ण है जब उदाहरण का मान शून्य है दर्शाता है परीक्षण करने के लिए तुलना करने के लिए।

तो वास्तव में आप

Math.Abs(d/(double)f) - 1) < float.Epsilon) 

Answer 3

(float) d == f जांच होनी चाहिए।

एक और उत्तर d == (double) f का सुझाव दिया गया है, लेकिन यह एक बेकार परीक्षण है क्योंकि (double) f उसी रूपांतरण को करता है जो d = f स्पष्ट रूप से निष्पादित करता है। तो इस धारणा का परीक्षण करने वाली एकमात्र चीज यह है कि कार्यान्वयन का कुछ पहलू टूट गया है (उदा।, कंपाइलर ने रूपांतरणों में से एक को गलत तरीके से कार्यान्वित किया और दूसरी तरफ से अलग किया), कुछ बाहरी तंत्र ने d या f असाइनमेंट और दावे के बीच बदल दिया, या स्रोत कोड टूटा गया ताकि d न तो double और न ही float और न ही किसी प्रकार का जो f के मान को पकड़ सकता है या असाइनमेंट d = f निष्पादित नहीं किया गया था।

आम तौर पर, हम फ्लोटिंग-पॉइंट त्रुटि की अपेक्षा करते हैं, क्योंकि फ्लोटिंग-पॉइंट के प्रत्येक सामान्य कार्यान्वयन में, एक रेडिक्स की व्यापक परिशुद्धता के लिए एक संक्षिप्त परिशुद्धता से परिवर्तित करने में कोई त्रुटि नहीं होती है, क्योंकि व्यापक परिशुद्धता प्रत्येक मूल्य का प्रतिनिधित्व कर सकती है संकुचित परिशुद्धता कर सकते हैं। असामान्य परिस्थितियों में, एक व्यापक फ़्लोटिंग-पॉइंट प्रारूप में एक छोटी एक्सपोनेंट रेंज हो सकती है। केवल इस मामले में, या विपरीत रूप से परिभाषित फ्लोटिंग-पॉइंट प्रारूपों में, एक व्यापक प्रारूप में परिवर्तित हो सकता है क्योंकि मूल्य में परिवर्तन होता है। इन मामलों में, एक ही रूपांतरण करने से परिवर्तन का पता नहीं लगाया जाएगा।

इसके बजाय, हम बड़े प्रारूप से वापस संकुचित प्रारूप में परिवर्तित करते हैं। यदि df से अलग है, तो इस रूपांतरण में त्रुटि का पता लगाने का मौका है। उदाहरण के लिए, मान लें कि f में 0x1p-1000 है, लेकिन, किसी कारण से, यह d के प्रारूप में प्रतिनिधित्व योग्य नहीं है, इसलिए यह शून्य पर गोल किया गया था। फिर (float) d == f(float) 0 == 0x1p-1000 पर मूल्यांकन करता है, फिर 0 == 0x1p-1000 पर, फिर false पर। इसके अतिरिक्त, यह परीक्षण अन्य सुझावों के समान त्रुटियों का पता लगा सकता है: एक टूटा कार्यान्वयन, d या f का परिवर्तन, गलत प्रकार का d, और d = f का एक गुम असाइनमेंट।

इसके अलावा, आप यहां किसी दावे के साथ किस त्रुटि का पता लगाने की कोशिश कर रहे हैं?