StackOverflow के इतिहास में कोड का सबसे लोकप्रिय टुकड़ा एक बग है!

हाल ही में एक अध्ययन, "GitHub प्रोजेक्ट्स में स्टैक ओवरफ्लो कोड स्निपेट्स का उपयोग करना और उन्हें जिम्मेदार ठहराना" अचानक पाया गया कि ज्यादातर ओपन सोर्स प्रोजेक्ट्स में, मेरा जवाब लगभग दस साल पहले लिखा गया था। विडंबना यह है कि वहाँ एक बग है।

एक बार की बात है ...

2010 में वापस, मैं अपने कार्यालय में बैठा था और बकवास कर रहा था: मैं कोड गोल्फिंग का शौकीन था और स्टैण्ड ओवरफ्लो में एक रेटिंग जोड़ी ।

निम्नलिखित प्रश्न ने मेरा ध्यान आकर्षित किया: बाइट की संख्या को पठनीय प्रारूप में कैसे प्रदर्शित किया जाए? यानी 123456789 बाइट जैसे किसी चीज़ को “123.5 MB” में कैसे बदलना है।


गुड ओल्ड 2010 इंटरफ़ेस, धन्यवाद वेबैक मशीन

जाहिर है, परिणाम उचित इकाई के साथ 1 और 999.9 के बीच एक संख्या होगी।

लूप के साथ पहले से ही एक जवाब था। यह विचार सरल है: सबसे बड़ी इकाई (ईबी = 10 ¹⁸ बाइट्स) से सबसे छोटी (बी = 1 बाइट) तक सभी डिग्री की जांच करें और पहले लागू करें, जो बाइट्स की संख्या से कम है। छद्म कोड में, यह कुछ इस तरह दिखता है:

suffixes = [ "EB", "PB", "TB", "GB", "MB", "kB", "B" ] magnitudes = [ 10^18, 10^15, 10^12, 10^9, 10^6, 10^3, 10^0 ] i = 0 while (i < magnitudes.length && magnitudes[i] > byteCount) i++ printf("%.1f %s", byteCount / magnitudes[i], suffixes[i]) 

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

खैर यह बीजगणित है, सब कुछ सरल है!

फिर यह मुझ पर छा गया। उपसर्ग किलो हैं-, मेगा-, गीगा-, ... - डिग्री 1000 (या आईईसी मानक में 1024) से अधिक कुछ नहीं है, इसलिए सही उपसर्ग को लघुगणक का उपयोग करके निर्धारित किया जा सकता है, और चक्र नहीं।

इस विचार के आधार पर, मैंने निम्नलिखित प्रकाशित किया:

 public static String humanReadableByteCount(long bytes, boolean si) { int unit = si ? 1000 : 1024; if (bytes < unit) return bytes + " B"; int exp = (int) (Math.log(bytes) / Math.log(unit)); String pre = (si ? "kMGTPE" : "KMGTPE").charAt(exp-1) + (si ? "" : "i"); return String.format("%.1f %sB", bytes / Math.pow(unit, exp), pre); } 

बेशक, यह बहुत पठनीय नहीं है, और लॉग / पॉव अन्य विकल्पों की दक्षता में नीच है। लेकिन लूप नहीं है और लगभग कोई ब्रांचिंग नहीं है, इसलिए मेरी राय में परिणाम बहुत सुंदर है।

गणित सरल है । बाइट्स की संख्या बाइटकाउंट = 1000 ^{एस के} रूप में व्यक्त की जाती है, जहां एस डिग्री का प्रतिनिधित्व करता है (बाइनरी नोटेशन में, बेस 1024 है।) समाधान एस = लॉग ₁₀₀₀ (बाइटकाउंट) देता है।

एपीआई में कोई सरल अभिव्यक्ति लॉग ₁₀₀₀ नहीं है, लेकिन हम इसे प्राकृतिक लघुगणक के रूप में व्यक्त कर सकते हैं जैसे कि एस = लॉग (बाइटकाउंट) / लॉग (1000)। तब हम एस को इंट में बदलते हैं, इसलिए यदि, उदाहरण के लिए, हमारे पास एक से अधिक मेगाबाइट (लेकिन पूर्ण गीगाबाइट नहीं) है, तो एमबी को माप की इकाई के रूप में उपयोग किया जाएगा।

यह पता चला है कि यदि s = 1 है, तो आयाम किलोबाइट है, यदि s = 2 - मेगाबाइट और इसी तरह। 1000 से बाइट को विभाजित करें और उपसर्ग में संबंधित अक्षर को थप्पड़ मारें।

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

एट्रिब्यूशन स्टडी

2018 के लिए तेजी से आगे। ग्रेजुएट स्टूडेंट सेबेस्टियन बाल्इट्स ने "GitHub प्रोजेक्ट्स में स्टैक ओवरफ्लो कोड स्निपेट्स का उपयोग और अटैचमेंट " शीर्षक से वैज्ञानिक पत्रिका Empirical Software Engineering में एक लेख प्रकाशित किया है । उनके शोध का विषय यह है कि स्टैक ओवरफ्लो सीसी बीवाई-एसए 3.0 लाइसेंस का कितना सम्मान किया जाता है, अर्थात लेखक कोड के स्रोत के रूप में स्टैक ओवरफ्लो लिंक को इंगित करते हैं।

विश्लेषण के लिए, कोड के स्निपेट को स्टैक ओवरफ्लो डंप से निकाला गया और कोड को सार्वजनिक गिटहब रिपॉजिटरी में मैप किया गया। सार से उद्धरण:

हम एक बड़े पैमाने पर अनुभवजन्य अध्ययन के परिणामों को प्रस्तुत करते हैं जो सार्वजनिक गिटहब (जीएच) परियोजनाओं में एसओ उत्तरों से जावा कोड के गैर-तुच्छ टुकड़ों के उपयोग और रोपण का विश्लेषण करता है।

(Spoiler: नहीं, अधिकांश प्रोग्रामर लाइसेंस आवश्यकताओं का अनुपालन नहीं करते हैं)।

लेख में ऐसी तालिका है:



पहचानकर्ता 3758880 के साथ ऊपर दिया गया यह उत्तर मुझे आठ साल पहले पोस्ट किया गया उत्तर था। फिलहाल, उनके पास एक लाख से अधिक विचार और एक हजार से अधिक प्लस हैं।

GitHub पर एक त्वरित खोज वास्तव में कोड humanReadableByteCount साथ हजारों रिपॉजिटरी का उत्पादन करती है।



अपने भंडार में इस अंश की खोज करें:

 $ git grep humanReadableByteCount 

एक मजेदार कहानी , जैसा कि मुझे इस अध्ययन के बारे में पता चला।

सेबेस्टियन को OpenJDK रिपॉजिटरी में बिना किसी अटेंशन के मैच मिला, और OpenJDK लाइसेंस CC BY-SA 3.0 के साथ संगत नहीं है। Jdk9-dev मेलिंग सूची में, उन्होंने पूछा: स्टैक ओवरफ्लो कोड OpenJDK से कॉपी किया गया है या इसके विपरीत?

मजेदार बात यह है कि मैंने ओरेकल में OpenJDK प्रोजेक्ट में काम किया है, इसलिए मेरे पूर्व सहयोगी और मित्र ने निम्नलिखित लिखा है:

हैलो,

इस पोस्ट के लेखक को SO (aioobe) पर सीधे क्यों नहीं पूछें? वह OpenJDK का सदस्य है और Oracle में काम करता है जब यह कोड OpenJDK स्रोत रिपॉजिटरी में दिखाई दिया।

ओरेकल इन मुद्दों को बहुत गंभीरता से लेता है। मुझे पता है कि कुछ प्रबंधकों को राहत मिली जब उन्होंने इस उत्तर को पढ़ा और "दोषी" पाया।

तब सेबस्टियन ने मुझे स्थिति स्पष्ट करने के लिए लिखा था, जो मैंने किया था: ओरेकल में शामिल होने से पहले यह कोड जोड़ा गया था और मुझे कमिटमेंट से कोई लेना-देना नहीं था। ओरेकल के साथ मजाक नहीं करना बेहतर है। टिकट खोले जाने के कुछ दिनों बाद , यह कोड हटा दिया गया था ।

बग

मुझे यकीन है कि आप पहले से ही उसके बारे में सोचा था। कोड में किस तरह की त्रुटि है?

एक बार फिर:

 public static String humanReadableByteCount(long bytes, boolean si) { int unit = si ? 1000 : 1024; if (bytes < unit) return bytes + " B"; int exp = (int) (Math.log(bytes) / Math.log(unit)); String pre = (si ? "kMGTPE" : "KMGTPE").charAt(exp-1) + (si ? "" : "i"); return String.format("%.1f %sB", bytes / Math.pow(unit, exp), pre); } 

विकल्प क्या हैं?

एक्साबाइट्स के बाद (10 ¹⁸ ) ज़ेटाबाइट्स (10 ²¹ ) हैं। शायद एक बड़ी संख्या kMGTPE से आगे बढ़ जाएगी? नहीं। अधिकतम मूल्य 2 ⁶³ -1 × 9.2 × 10 ^{18 है} , इसलिए कोई मूल्य कभी भी एक्सैबाइट्स से आगे नहीं जाएगा।

शायद एसआई इकाइयों और बाइनरी सिस्टम के बीच भ्रम? नहीं। उत्तर के पहले संस्करण में भ्रम था, लेकिन यह बहुत जल्दी तय हो गया था।

हो सकता है कि एक्सप ज़ीरोइंग समाप्त हो जाए, जिससे charAt (exp-1) क्रैश हो जाए? नहीं, या तो। यदि पहला बयान इस मामले को कवर करता है। एक्सपेक्ट वैल्यू हमेशा कम से कम 1 होगी।

शायद प्रत्यर्पण में कुछ अजीब गोल त्रुटि? खैर, आखिरकार ...

कई नाइन

समाधान 1 एमबी तक पहुंचने तक काम करता है। जब इनपुट के रूप में "1000,0 kB" बाइट निर्दिष्ट किए जाते हैं, तो परिणाम (SI मोड में) "1000,0 kB" । हालाँकि 999,999 1000 × 1000 ¹ से 999.9 × 1000 ^{1 के} करीब है, लेकिन हस्ताक्षरकर्ता 1000 विनिर्देश द्वारा निषिद्ध है। सही परिणाम "1.0 MB" ।

अपने बचाव में, मैं कह सकता हूँ कि लेखन के समय, ऐसी त्रुटि सभी 22 प्रकाशित उत्तरों में थी, जिसमें अपाचे कॉमन्स और एंड्रॉइड लाइब्रेरी शामिल थे।

इसे कैसे ठीक करें? सबसे पहले, हम ध्यान दें कि घातांक (एक्सप) को 'के' से 'एम' में बदलना होगा जैसे ही बाइट्स की संख्या 1 × 1,000 ² (1 एमबी) के करीब 999.9 × 1000 ¹ (999.9 k) से अधिक होगी )। यह 999,950 पर होता है। इसी तरह, हमें 'M' से 'G' पर स्विच करना चाहिए जब हम 999,950,000 और इतने पर से गुजरते हैं।

हम इस सीमा की गणना करते हैं और bytes अधिक होने पर exp बढ़ाते हैं:

 if (bytes >= Math.pow(unit, exp) * (unit - 0.05)) exp++; 

इस परिवर्तन के साथ, कोड तब तक अच्छी तरह से काम करता है जब तक कि बाइट्स की संख्या 1 EB तक नहीं पहुंच जाती।

अधिक नौ

999 949 999 999 999 999 999 की गणना करते समय, कोड 1000.0 PB देता है, और सही परिणाम 999.9 PB । गणितीय रूप से, कोड सटीक है, इसलिए यहां क्या होता है?

अब हमारा सामना double बाधाओं से है।

फ्लोटिंग पॉइंट अंकगणित का परिचय

आईईईई 754 विनिर्देश के अनुसार, शून्य के करीब फ्लोटिंग पॉइंट वैल्यू में बहुत सघन प्रतिनिधित्व होता है, जबकि बड़े मूल्यों में बहुत कम प्रतिनिधित्व होता है। वास्तव में, सभी मानों में से आधे -1 और 1 के बीच हैं, और जब यह बड़ी संख्या में आता है, तो Long.MAX_VALUE के आकार का कुछ भी मतलब नहीं है। शाब्दिक अर्थों में।

 double l1 = Double.MAX_VALUE; double l2 = l1 - Long.MAX_VALUE; System.err.println(l1 == l2); // prints true 

विवरण के लिए "फ्लोटिंग प्वाइंट बिट्स" देखें।

समस्या को दो गणनाओं द्वारा दर्शाया गया है:

• String.format में डिवीजन और
  
• विस्तार सीमा exp

हम BigDecimal स्विच कर सकते हैं, लेकिन यह उबाऊ है। इसके अलावा, यहां समस्याएं भी पैदा होती हैं, क्योंकि मानक एपीआई में BigDecimal लिए लघुगणक नहीं है।

मध्यवर्ती मूल्यों को कम करना

पहली समस्या को हल करने के लिए, हम bytes के मूल्य को वांछित सीमा तक कम कर सकते हैं, जहां सटीकता बेहतर है, और तदनुसार exp समायोजित करें। किसी भी मामले में, अंतिम परिणाम गोल है, इसलिए यह कोई फर्क नहीं पड़ता कि हम कम से कम महत्वपूर्ण अंक निकालते हैं।

 if (exp > 4) { bytes /= unit; exp--; } 

कम से कम महत्वपूर्ण बिट्स सेटिंग

दूसरी समस्या को हल करने के लिए , कम से कम महत्वपूर्ण बिट्स हमारे लिए महत्वपूर्ण हैं (99994999 ... 9 और 99995000 ... 0 के पास अलग-अलग डिग्री होनी चाहिए), इसलिए हमें एक अलग समाधान खोजना होगा।

सबसे पहले, ध्यान दें कि 12 अलग-अलग थ्रेशोल्ड मान हैं (प्रत्येक मोड के लिए 6), और उनमें से केवल एक त्रुटि होती है। एक गलत परिणाम को विशिष्ट रूप से पहचाना जा सकता है क्योंकि यह D00 ₁₆ में समाप्त होता है। तो आप इसे सीधे ठीक कर सकते हैं।

 long th = (long) (Math.pow(unit, exp) * (unit - 0.05)); if (exp < 6 && bytes >= th - ((th & 0xFFF) == 0xD00 ? 52 : 0)) exp++; 

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

नकारात्मक इनपुट मान

यह स्पष्ट नहीं है कि किन परिस्थितियों में बाइट्स की नकारात्मक संख्या समझ में आती है, लेकिन चूंकि जावा में एक अहस्ताक्षरित long नहीं है, इसलिए इस विकल्प को संभालना सबसे अच्छा है। अभी, -10000 B जैसे इनपुट -10000 B

चलो absBytes :

 long absBytes = bytes == Long.MIN_VALUE ? Long.MAX_VALUE : Math.abs(bytes); 

अभिव्यक्ति इतनी -Long.MIN_VALUE == Long.MIN_VALUE क्योंकि -Long.MIN_VALUE == Long.MIN_VALUE । अब हम bytes बजाय absBytes का उपयोग करते हुए सभी absBytes गणना करते हैं।

अंतिम संस्करण

यहाँ कोड का अंतिम संस्करण है, मूल संस्करण की भावना में संक्षिप्त और संघनित:

 // From: https://programming.guide/the-worlds-most-copied-so-snippet.html public static strictfp String humanReadableByteCount(long bytes, boolean si) { int unit = si ? 1000 : 1024; long absBytes = bytes == Long.MIN_VALUE ? Long.MAX_VALUE : Math.abs(bytes); if (absBytes < unit) return bytes + " B"; int exp = (int) (Math.log(absBytes) / Math.log(unit)); long th = (long) (Math.pow(unit, exp) * (unit - 0.05)); if (exp < 6 && absBytes >= th - ((th & 0xfff) == 0xd00 ? 52 : 0)) exp++; String pre = (si ? "kMGTPE" : "KMGTPE").charAt(exp - 1) + (si ? "" : "i"); if (exp > 4) { bytes /= unit; exp -= 1; } return String.format("%.1f %sB", bytes / Math.pow(unit, exp), pre); } 

ध्यान दें कि यह छोरों और अत्यधिक शाखा से बचने के प्रयास के रूप में शुरू हुआ। लेकिन सभी सीमा स्थितियों को सुचारू करने के बाद, कोड मूल संस्करण की तुलना में कम पठनीय बन गया। व्यक्तिगत रूप से, मैं उत्पादन में इस टुकड़े की नकल नहीं करूंगा।

उत्पादन गुणवत्ता के एक अद्यतन संस्करण के लिए, एक अलग लेख देखें: "एक पठनीय प्रारूप में बाइट का आकार प्रारूपित करना । "

मुख्य खोज

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