क्या स्रोत कोड का उपयोगी तरीके से विश्लेषण करने के लिए एंट्रोपी की अवधारणा का उपयोग किया जा सकता है?


19

यह मेरे लिए तर्कसंगत लगता है कि कोई व्यक्ति स्थिर स्रोत कोड विश्लेषण के लिए एक संदर्भ को परिभाषित कर सकता है जिसमें जटिलता के सापेक्ष मूल्य का उत्पादन करने के नियम शामिल थे। मुझे पता है कि यह भौतिक अर्थों में पसंद नहीं है क्योंकि सोर्स कोड में "ऊर्जा" नहीं है, लेकिन मैं शर्त लगा रहा हूं कि एक समानांतर आकर्षित करने के लिए, अकादमिक स्तर पर प्रयास किए गए हैं। क्या किसी को भी इसका कोई ज्ञान है और यदि हां, तो इसके उपयोगी परिणाम क्या हैं?


मुझे उस पर कोई विशेष ज्ञान नहीं है। लेकिन एक इंजीनियर के रूप में मेरा मानना ​​है कि आप इस अवधारणा को ब्रह्मांड में अपनी इच्छानुसार लागू कर सकते हैं। “सब कुछ ऊर्जा है। आपके कोड को एक इकाई के रूप में तैयार किया जा सकता है, जिसमें ऊर्जा है।
18

3
कोड जटिलता के पहले से ही उपाय हैं - साइक्लोमैटिक जटिलता, वर्ग लंबाई (LOC), विधि की लंबाई (LOC), खेतों की संख्या, विधि मापदंडों की संख्या, n- पथ जटिलता, प्रशंसक में / पंखे और डेटा प्रवाह विश्लेषण (DU) डीडी चेन)। घनत्व को बनाए रखने, बनाए रखने के प्रयास और समझने में आसानी के लिए इनका सहसंबंध बनाने के लिए काम किया गया है। आप इनसे तुलना करने के लिए क्या देख रहे हैं?
थॉमस ओवेन्स

@ थोमस ओवेन्स: मुझे लगता है कि यह वही है जो ओपी पूछ रहा था, कृपया इसे उत्तर के रूप में पोस्ट करें!
१।

@Simon, ठीक है, अगर आपको ऐसा लगता है। मुझे 100% यकीन नहीं है।
थॉमस ओवेन्स

1
बल्कि अपरंपरागत दृष्टिकोण के लिए, आप स्रोत कोड के लिए सीधे डेटा संपीड़न अनुपात की गणना कर सकते हैं, या किसी प्रकार के सामान्य होने के बाद डेटा संपीड़न अनुपात की गणना कर सकते हैं। (उदा। c2.com/doc/SignatureSurvey ) - मुझे नहीं पता कि यह कितना सार्थक या उपयोगी होगा, लेकिन यह अधिक पारंपरिक मैट्रिक्स के साथ संयोजित होने पर कुछ अंतर्दृष्टि दे सकता है।
विलियम पायने

जवाबों:


22

कोड जटिलता के पहले से ही कई उपाय हैं:

  • साइक्लोमेटिक कम्पलेक्सिटी
  • कक्षा की लंबाई
  • विधि की लंबाई
  • क्षेत्रों की संख्या
  • विधि मापदंडों की संख्या
  • एन-पथ की जटिलता
  • फैन-इन और फैन-आउट
  • डेटा प्रवाह विश्लेषण (DU / DD चेन)

घनत्व को बनाए रखने, बनाए रखने के प्रयास और समझने में आसानी के लिए इनका सहसंबंध बनाने के लिए काम किया गया है। कुछ दूसरों की तुलना में अधिक सार्थक हैं, इस पर निर्भर करता है कि आप अपने विश्लेषण से क्या सीखने की कोशिश कर रहे हैं। मैं भौतिक विज्ञान से एन्ट्रॉपी की अवधारणा से परिचित नहीं हूं, लेकिन मुझे आश्चर्य है कि यदि मैंने समय के साथ माप और मीट्रिक ट्रैक किए हैं, और समय के साथ दोषों से संबंधित हैं, तो आप जो देख रहे हैं, उसके समान होगा।

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


13

मुझे लगता है कि आप थर्मोडायनामिक एन्ट्रापी और "जटिलता" के बीच एक समानांतर खींचने की कोशिश कर रहे हैं। बात यह है, एन्ट्रापी अव्यवस्था का एक पैमाना है न कि जटिलता । मुझे विश्वास नहीं होता कि दोनों समान और परस्पर विनिमय योग्य हैं।

थर्मोडायनामिक एन्ट्रापी का निकटतम एनालॉग शैनन एंट्रोपी है जो एक यादृच्छिक चर में विकार की मात्रा को मापता है। यह धारणा मुख्य रूप से एक संदेश में "सूचना" की मात्रा से संबंधित है।

उस संबंध में, कोड के एक टुकड़े में बहुत सारी जानकारी (उच्च एन्ट्रापी) हो सकती है लेकिन बहुत कम जटिलता। एक ऐसे कार्यक्रम के बारे में सोचें, जो मनमाने चरित्रों की एक बहुत लंबी स्ट्रिंग को छापता है। इसमें बहुत सारी जानकारी है, लेकिन कम जटिलता है।


1
स्रोत कोड के लिए एंट्रॉपी को उसी मॉडल से गणना नहीं की जाएगी, जो कि असंरचित पाठ के लिए है। स्रोत कोड के लिए अनुकूल मॉडल के साथ , यह एक एंट्रॉपी की गणना करने के लिए सार्थक होना चाहिए जो मनमाने ढंग से स्थितियों के लिए व्यापक रूप से भिन्न नहीं होगा, जैसे कि आपके द्वारा वर्णित वर्णों की लंबी स्ट्रिंग।
मैथ्यू रोडैटस

तो आप दिए गए कार्यक्रम में एन्ट्रापी और जटिलता का मूल्यांकन कैसे करेंगे? मेरा तर्क है कि इसमें बहुत सी जानकारी शामिल है, चाहे आप किसी भी मॉडल का उपयोग करें। हालांकि जटिलता की परिभाषा बहुत कम स्पष्ट है।
tskuzzy

1
जैसे यह प्राकृतिक भाषा पाठ के लिए थर्मोडायनामिक एन्ट्रापी की गणना करने के लिए समझ में नहीं आता है, यह कंप्यूटर स्रोत कोड के लिए शैनन एन्ट्रापी का उपयोग करने का कोई मतलब नहीं है, क्योंकि एक कार्यक्रम का अर्थ नियमों और पैटर्न के एक अलग सेट के भीतर संरचित है (अर्थात वाक्य - विन्यास)। प्राकृतिक भाषा का अपना सिंटैक्स होता है। मॉडल को डोमेन के सिंटैक्स के अनुरूप होना चाहिए। थर्मोडायनामिक एन्ट्रापी को केल्विन में जूल में मापा जाता है। शैनन एन्ट्रापी को बिट्स में मापा जाता है। स्रोत कोड एन्ट्रापी को पूरी तरह से ... विभिन्न आयामों में मापा जाएगा। मैंने अपने जवाब में मॉडल की तरह दिखने वाला एक स्टैब लिया।
मैथ्यू रोडैटस

मुझे आपका उत्तर पसंद है - मैं सोच रहा था, उदाहरण के लिए, जब "खराब" कोड पेश किया जाता है, तो पूरे वातावरण में एक एन्ट्रापी बढ़ जाती है, अर्थात कोडर्स सहित जिन्हें कठिन परिश्रम करना पड़ता है - इस तरह से शायद एक व्यावहारिक है, यदि ऊष्मा गतिकी का वैज्ञानिक संबंध नहीं है?
एरोन एनोडाइड

2

एन्ट्रॉपी "विकार का एक उपाय है [या] अप्रत्याशितता।" जानकारी में अद्वितीय पैटर्न की एक विस्तृत श्रृंखला (यानी मोटे तौर पर "अधिक अर्थ") एन्ट्रापी की उच्च डिग्री का संकेत देती है।

कंप्यूटर स्रोत कोड के लिए लागू, मुझे लगता है कि यह सिद्धांत उपयोगी हो सकता है। हालांकि, स्रोत कोड के लिए एक संभाव्य मॉडल को डिजाइन करना आवश्यक होगा जिसके साथ एन्ट्रापी की गणना करना है। (एक डेटा संरचना जो आसानी से मन में आती है, वह विभिन्न प्रकारों के साथ एक ग्राफ है: कॉल, क्लास इनहेरिटेंस, आदि)

एक बार जब मॉडल तैयार किया जाता है और फिर एक सॉफ्टवेयर एप्लिकेशन के स्रोत कोड (यानी नोड्स / किनारों के लिए आवृत्तियों) के साथ आबादी होती है, तो एन्ट्रापी की गणना की जा सकती है।

मुझे इस पर किसी भी शोध का पता नहीं है, लेकिन मेरा अंतर्ज्ञान यह है कि एन्ट्रापी की एक कम डिग्री का मतलब होगा कि स्रोत कोड पूरे एप्लिकेशन (यानी DRY ) में सामान्य पैटर्न का पुन: उपयोग करता है । इसके विपरीत, एन्ट्रापी की एक उच्च डिग्री का मतलब होगा कि स्रोत कोड जटिलता में उच्च है और अच्छी तरह से फैक्टर नहीं किया गया है।


2

एन्ट्रॉपी के बारे में सोचने का एक तरीका है "प्राप्त की जाने वाली औसत जानकारी", इसलिए मुझे लगता है कि मॉडलिंग की जानकारी पर वापस जाना बेहतर है। मुझे गणितीय रूप से मॉडलिंग की जानकारी के लिए दो बुनियादी तरीकों का पता है। (विकिपीडिया संदर्भ देने के लिए मुझे क्षमा करें, लेकिन IMHO वे बुरे नहीं हैं।)

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

  • सोलोमोनॉफ़ (या कोलमोगोरोव ) जानकारी। यहाँ एक और व्याख्या है। इस सूत्रीकरण में, किसी प्रतीक या घटना की सूचना सामग्री को सबसे छोटे कार्यक्रम की लंबाई से दर्शाया जाता है जो इसकी गणना कर सकता है। यहां फिर से, यह रिश्तेदार है, संभावना को असाइन करने वाले पर्यवेक्षक के लिए नहीं, बल्कि एक सार्वभौमिक मशीन के लिए जो प्रोग्राम को निष्पादित कर सकता है। चूँकि प्रत्येक सार्वभौमिक मशीन को एक सार्वभौमिक ट्यूरिंग मशीन द्वारा अनुकरण किया जा सकता है, जिसका अर्थ है, किसी अर्थ में, कि प्रतीक या घटना की सूचना सामग्री सापेक्ष नहीं है, लेकिन निरपेक्ष है।

यदि मैं यह बताने की स्वतंत्रता ले सकता हूं कि मुझे क्या लगता है कि इसका मतलब रोजमर्रा के संदर्भ में है, जिसके बारे में मैंने एक किताब लिखी है , तो इसका सीधा मतलब है कि एक कार्यक्रम की जटिलता इसकी लंबाई है, जब कार्यात्मक कल्पना और भाषा जैसी चीजों को लगातार आयोजित किया जाता है, उपयुक्त के साथ टिप्पणियों और नाम की लंबाई जैसी चीजों के लिए भत्ते। लेकिन इसके साथ एक समस्या है - "एपीएल टारपीट", जहां संक्षिप्तता समझ से बाहर है।

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

मुझे खेद है कि यदि संदर्भ कमजोर / व्यक्तिगत हैं, लेकिन मुझे लगता है कि यह समग्र प्रश्न बहुत महत्वपूर्ण है।


शैनन और कोलमोगोरोव के लिए +1 , दोनों प्रासंगिक हैं ...
एलेक्स फीनमैन

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

2

जॉन जैगर और ओल्वे मौडल का कोड एन्ट्रॉपी से थोड़ा अलग दृष्टिकोण है, जैसा कि उनके 2011 अक्यू कॉन्फ्रेंस सेशन कोड एन्ट्रॉपी और फिजिक्स ऑफ सॉफ्टवेयर में देखा जा सकता है ।

वे कोड की स्थिरता के बारे में बात करते हैं कि क्या भविष्य के डेवलपर्स / अनुचर उस कोड को बदलने की संभावना रखते हैं।

इसे प्रदर्शित करने के लिए, उन्होंने कई कोड स्निपेट के साथ एक सर्वेक्षण किया और परिणाम काफी दिलचस्प थे।

  • एक-सच-ब्रेस स्टाइल के खिलाफ एक मजबूत पूर्वाग्रह लग रहा था ।
  • लेकिन अगर एक बयान को गले लगाने के लिए एक मजबूत पूर्वाग्रह है ।
  • अस्थायी चर का उपयोग करने के खिलाफ एक मजबूत पूर्वाग्रह था।
  • ऑपरेटर वरीयता को स्पष्ट करने के लिए कोष्ठक जोड़ने के लिए एक मजबूत पूर्वाग्रह था।

साथ ही 16 अन्य।

सामान्य प्रवृत्ति कोड को समझने में आसान बनाने की दिशा में थी, और गलत-समझ के लिए अधिक कठिन थी।

वे वर्षों में एक बड़े कोडबेस में किए गए कुछ परिवर्तनों को भी देखते हैं।

हालाँकि, अपने स्वयं के स्लाइड सत्र के प्रतिलेख नहीं होने से पीड़ित हैं, फिर भी वहाँ कुछ दिलचस्प बिंदु हैं।


1

मैं एक के अधीन अध्ययन के प्रोफेसर जो कार्यक्रमों की जटिलता का एक उपाय के रूप में इस्तेमाल किया एन्ट्रापी (हमारे पाठ्यपुस्तक के एक पुराने संस्करण था इस एक , उसके पब में से कुछ हैं यहाँ )। एफएयू में कई शोध प्रबंध थे जहां यह प्रमुख उपायों में से एक था, लेकिन स्कूल की वेबसाइट तब से बदल गई है जब मैंने आखिरी बार देखा था, और मैं यह पता लगाने में असमर्थ हूं कि छात्र थीसिस / शोध प्रबंध अब कहां स्थित हैं।

ऐसा ही एक शोध प्रबंध सूचना सिद्धांत और सॉफ्टवेयर मापन है


0

यदि आप एक परिभाषा चाहते हैं कि एंट्रॉपी जिस तरह से "मैथी" है, तो आप कोलमोगोरोव जटिलता को देख सकते हैं, जो कोड की न्यूनतम मात्रा द्वारा जटिलता को मापता है, संभवतः कुछ किया जा सकता है। हालांकि, यह कोड की जटिलता नहीं है। लेकिन आप कोड के साथ क्या करने की कोशिश कर रहे हैं। लेकिन आप सोच सकते हैं कि यह प्रासंगिक है क्योंकि आप सैद्धांतिक रूप से कोड के एक विशेष टुकड़े की तुलना कम से कम कर सकते हैं। हालांकि, यह वर्तमान में वास्तविक विश्व कोड की जटिलता को मापने के लिए एक उपयोगी तकनीक नहीं है।


0

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

तो कोई सोच सकता है, फिर मैं कोड गुण को मापने के लिए गुणांक के रूप में संपीड़न अनुपात का उपयोग करके एंट्रॉपी / कोडलाइन जैसी किसी चीज की गणना कर सकता हूं, हालांकि यह समस्या है कि कुल यादृच्छिक इनपुट दुनिया में सबसे अच्छे कोड की तरह दिखाई देगा, जो स्पष्ट रूप से नहीं है।

वास्तव में कोड के एन्ट्रापी को मापने के लिए संपीड़न अनुपात एक अच्छा मीटर है, हालाँकि दोनों ही कोड गुणवत्ता के लिए अच्छे मीटर नहीं हैं।


0

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

यह, सिद्धांत रूप में, स्रोत कोड जटिलता के लिए खूबसूरती से लागू किया जा सकता है: "बस" एक कंप्रेसर लिखता है जो केवल पूरी तरह से मानक अनुपालन स्रोत कोड पर काम करता है, और जो इसे कंपाइलर की तरह पार्स कर रहा होता है, उसी अनुरूप सिंटैक्स ट्री का निर्माण करता है। फिर यह इस सिंटेक्स ट्री को चला सकता है, और प्रत्येक नोड पर निर्णय ले सकता है कि प्रत्येक नोड पर कौन सा नोड संभव होगा, उस नोड को उस ज्ञान के साथ एन्कोडिंग।

इसलिए, उदाहरण के लिए, यदि भाषा या तो किसी मौजूदा पहचानकर्ता, या कोष्ठक में संलग्न कुछ, या किसी विशिष्ट बिंदु पर उत्पाद की अनुमति देती है, तो कंप्रेसर संभावित मौजूदा पहचानकर्ताओं की गणना करेगा, प्रकार की जानकारी को ध्यान में रखते हुए (जैसा कि आपके पास ऐसे 3 पहचानकर्ता हैं ), और 5 संभावित संभावनाओं को देते हुए, दो संभावित उप-विभाजनों के लिए 2 जोड़ें। तो नोड lb 5 = 2.32बिट्स के साथ एन्कोड किया जाएगा । दो संभव उप-संदर्भों के मामले में, उनकी सामग्री को एन्कोड करने के लिए अधिक बिट्स की आवश्यकता होगी।

यह वास्तव में कोड की जटिलता के लिए एक बहुत ही सटीक उपाय देगा जैसा कि यह है। हालाँकि, यह उपाय अभी भी बेकार है! यह एक ही कारण के लिए बेकार है कि सभी कोड जटिलता माप बेकार हैं: वे असफल कोड मापा जटिलता (जो कुछ भी हो सकता है) और कोड की समस्या की जटिलता के बीच संबंध बनाते हैं। आप अपने एलओसी काउंट के साथ अपने नियोक्ता को प्रभावित करने के लिए हमेशा अपनी प्रोग्रामिंग समस्याओं का हास्यास्पद जटिल समाधान पा सकते हैं , लेकिन कोई भी कोड जटिलता उपाय आपको यह नहीं बताएगा कि कार्य को प्रयास के एक अंश के साथ हल किया जा सकता था।


-2

कोड Code की संख्या के समान ही एन्ट्रापी है।

कोड रखरखाव और परिवर्तन एन्ट्रापी का परिचय दे सकता है (क्योंकि इसमें संभावित राज्य परिवर्तन शामिल है)।

लेकिन कोड सिर्फ एक बड़ी संख्या है। एक द्विआधारी प्रतिनिधित्व के साथ।


इस तरह से सोचने से आप यह नहीं कह सकते थे कि gzip'd होने पर सभी कोड में समान एंट्रॉपी होती है?
एरोन एनोडाइड 20

@ गैब्रिएल: यह एक अलग बात है। वह एन्ट्रापी बिट्स के बीच शोर की मात्रा है जब बिट्स के अनुक्रम के रूप में उस संख्या को देखते हैं। एकल, स्थिर संख्या के रूप में नहीं देख रहा है। स्रोत कोड 42 की तरह एक एकल स्थिर संख्या है। केवल बहुत अधिक बिट्स के साथ।
S.Lott

बस जिज्ञासु, इस दृष्टि से दशमलव 42 और बाइनरी 42 में समान एन्ट्रापी है या कि टिप्पणी यह ​​कह रही है कि संख्याओं में एन्ट्रापी नहीं है, और इसके बारे में क्या है?
एरोन एनोडाइड

"संख्या में एन्ट्रापी नहीं है"। वे बस हैं। एक प्रतिनिधित्व, प्रतीकों की एक धारा के रूप में देखा जा सकता है एन्ट्रापी, लेकिन एक पूरे के रूप में संख्या सिर्फ एक संख्या है।
S.Lott
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.