हस्ताक्षरित बनाम अहस्ताक्षरित पूर्णांक


395

क्या मैं एक हस्ताक्षरित और अहस्ताक्षरित पूर्णांक के बीच अंतर कहना सही हूँ:

  1. अहस्ताक्षरित एक बड़ा सकारात्मक मान रख सकता है, और कोई नकारात्मक मूल्य नहीं।
  2. Unsigned वैल्यू के एक हिस्से के रूप में अग्रणी बिट का उपयोग करता है, जबकि हस्ताक्षरित संस्करण बाएं-सबसे-बिट का उपयोग करता है ताकि यह पता लगाया जा सके कि संख्या सकारात्मक है या नकारात्मक।
  3. हस्ताक्षरित पूर्णांक धनात्मक और ऋणात्मक दोनों संख्याओं को धारण कर सकते हैं।

कोई अन्य मतभेद?


6
क्योंकि 0 न तो धनात्मक है और न ही ऋणात्मक है , अहस्ताक्षरित पूर्णांकों के लिए धनात्मक मान के बजाय गैर-ऋणात्मक मान शब्द का उपयोग करना अधिक उपयुक्त है ।
डैनियल

जवाबों:


344

अहस्ताक्षरित एक बड़ा सकारात्मक मान रख सकता है, और कोई नकारात्मक मूल्य नहीं।

हाँ।

Unsigned वैल्यू के एक हिस्से के रूप में अग्रणी बिट का उपयोग करता है, जबकि हस्ताक्षरित संस्करण बाएं-सबसे-बिट का उपयोग करता है ताकि यह पता लगाया जा सके कि संख्या सकारात्मक है या नकारात्मक।

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

हस्ताक्षरित पूर्णांक धनात्मक और ऋणात्मक दोनों संख्याओं को धारण कर सकते हैं।

हाँ


मुझे यकीन नहीं है कि अगर यह ठीक वैसा ही है, लेकिन मुझे एक और कड़ी मिल गई है। पीडीएफ के 9 वें पृष्ठ पर जाएं (यह वास्तव में पुस्तक का 38 वां पृष्ठ है) और आप डेटा प्रतिनिधित्व (धारा 1.3) नामक अनुभाग देख सकते हैं। इसमें ऊपर कही गई सभी बातों की व्याख्या है। lms.uop.edu.jo/lms/pluginfile.php/2420/mod_resource/content/1/…
WeirdElfB0y

92

मैं x86 पर हार्डवेयर स्तर पर अंतर में जाऊँगा। जब तक आप कंपाइलर नहीं लिख रहे हैं या असेंबली लैंग्वेज का उपयोग नहीं कर रहे हैं, यह ज्यादातर अप्रासंगिक है। लेकिन जानकर अच्छा लगा।

सबसे पहले, x86 को दो हस्ताक्षरित संख्याओं के पूरक प्रतिनिधित्व के लिए मूल समर्थन है । आप अन्य अभ्यावेदन का उपयोग कर सकते हैं लेकिन इसके लिए अधिक निर्देशों की आवश्यकता होगी और आमतौर पर प्रोसेसर समय की बर्बादी होगी।

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

सबसे पहले, दो पूरक संख्याओं में संपत्ति होती है जो जोड़ और घटाव केवल अहस्ताक्षरित संख्याओं के लिए होती है। इससे कोई फर्क नहीं पड़ता कि संख्या सकारात्मक है या नकारात्मक। (तो आप बस आगे बढ़ें ADDऔर SUBआपकी संख्या बिना किसी चिंता के।)

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

हस्ताक्षरित और अहस्ताक्षरित पूर्णांक से निपटने के लिए गुणा और विभाजन निर्देश के दो सेट भी हैं।

अंत में: यदि आप ओवरफ्लो के लिए, कहना चाहते हैं, तो आप इसे हस्ताक्षरित और अहस्ताक्षरित संख्याओं के लिए अलग तरह से करना चाहेंगे।


अहस्ताक्षरित और हस्ताक्षरित संख्याओं से आपका क्या तात्पर्य है, यदि मैं पूछना चाहता हूं कि क्या मैंने अहस्ताक्षरित int a = 2 लिखा है और int b = 2 पर हस्ताक्षर किए हैं, तो वे दोनों हस्ताक्षरित या अहस्ताक्षरित हैं, क्या कोई संख्या हस्ताक्षरित या अहस्ताक्षरित है जो प्रकार पर निर्भर करता है हम इसे असाइन करते हैं, या इस पर निर्भर करते हैं कि इसमें नकारात्मक चिन्ह है या नहीं? यह थोड़ी देर के लिए मुझे गुस्सा दिला रहा है।
सूरज जैन

@SurajJain ने प्रकारों के लिए हस्ताक्षरित और अहस्ताक्षरित किया । वे संकेत मिलता है कि क्या यह है संभव एक चर या अभिव्यक्ति एक नकारात्मक मूल्य के लिए के लिए।
आर्टेलियस

मुझे निम्नलिखित संदेह है, मैंने सवाल पूछा है, कोई संतोषजनक जवाब अभी तक नहीं मिला है, इसे यहां देखें, stackoverflow.com/questions/41399092/…
सूरज जैन

62

उन्होंने केवल हस्ताक्षरित और अहस्ताक्षरित के बारे में पूछा। पता नहीं क्यों लोग इसमें अतिरिक्त सामान जोड़ रहे हैं। इसका जवाब आपको बता दूं।

  1. अहस्ताक्षरित: इसमें केवल गैर-नकारात्मक मान होते हैं, जो 0 से 255 तक होते हैं।

  2. हस्ताक्षरित: इसमें नकारात्मक और सकारात्मक दोनों मूल्य शामिल हैं, लेकिन विभिन्न स्वरूपों में

    • 0 से +127 तक
    • -1 से -128

और यह स्पष्टीकरण 8-बिट संख्या प्रणाली के बारे में है।


17

पूर्णता के लिए बस कुछ बिंदु:

  • यह उत्तर केवल पूर्णांक निरूपण पर चर्चा कर रहा है। फ्लोटिंग पॉइंट के लिए अन्य उत्तर हो सकते हैं;

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

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

  • किसी के पूरक या हस्ताक्षरित परिमाण का उपयोग करते समय आप एक सकारात्मक या नकारात्मक संख्या के रूप में शून्य का प्रतिनिधित्व कर सकते हैं (जो उन कारणों में से एक है जो ये प्रतिनिधित्व आमतौर पर उपयोग नहीं किए जाते हैं)।


अगर मैं अहस्ताक्षरित int = -2 लिखता हूं, और हस्ताक्षरित b = -2 पर हस्ताक्षर करता हूं, तो अंतर्निहित प्रतिनिधित्व वही होगा, मुझे पता है कि अहस्ताक्षरित संख्या को नकारात्मक मान दिया जाना अच्छा नहीं है, लेकिन फिर भी अगर मैं इसे दे दूं, तो क्या होगा अंतर्निहित प्रतिनिधित्व?
सूरज जैन

1
माइनर निगल: साइन और परिमाण का उपयोग IEEE फ्लोटिंग पॉइंट में किया जाता है, इसलिए यह वास्तव में काफी सामान्य है। :-)
एलेस्टेयर

14

हमने कक्षा में जो सीखा, उसके अनुसार हस्ताक्षरित पूर्णांक दोनों सकारात्मक का प्रतिनिधित्व कर सकते हैं और ऋणात्मक संख्याओं का , जबकि अहस्ताक्षरित पूर्णांक केवल गैर-ऋणात्मक होते हैं।

उदाहरण के लिए, 8-बिट संख्या को देखना:

अहस्ताक्षरित मूल्यों 0को255

हस्ताक्षरित मान से -128लेकर127


11

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


क्या वह छोटी-एंडियन और बड़ी-एंडियन चीज है?
vIceBerg

छोटे बनाम बड़े एंडियन को प्लेटफॉर्म पर बाइट्स के आदेश के साथ क्या करना है। छोटा एंडियन 0xFF 0xFE 0x7F कर सकता है जबकि बड़ा एंडियन 0x7F 0xFE 0xFF करेगा।
जैस्पर बेकर्स

10

एक और अंतर है जब आप विभिन्न आकारों के पूर्णांकों के बीच परिवर्तित कर रहे हैं।

उदाहरण के लिए, यदि आप बाइट स्ट्रीम से एक पूर्णांक निकाल रहे हैं (कहते हैं कि सादगी के लिए 16 बिट्स), अहस्ताक्षरित मूल्यों के साथ, आप कर सकते हैं:

i = ((int) b[j]) << 8 | b[j+1]

(शायद 2 एन डी बाइट कास्ट करना चाहिए , लेकिन मुझे अनुमान है कि कंपाइलर सही काम करेगा)

हस्ताक्षरित मूल्यों के साथ आपको साइन एक्सटेंशन के बारे में चिंता करनी होगी और करना होगा:

i = (((int) b[i]) & 0xFF) << 8 | ((int) b[i+1]) & 0xFF

5

आम तौर पर बोलना सही है। इस बारे में अधिक जानकारी के बिना कि आप उन मतभेदों की तलाश में क्यों हैं जिनके बारे में मैं हस्ताक्षरित और अहस्ताक्षरित के बीच किसी अन्य अंतर के बारे में नहीं सोच सकता।


4

ऊपर और ऊपर जो दूसरों ने कहा है, सी में, आप एक अहस्ताक्षरित पूर्णांक को ओवरफ्लो नहीं कर सकते हैं; व्यवहार को मापांक अंकगणितीय माना जाता है। आप एक हस्ताक्षरित पूर्णांक को ओवरफ्लो कर सकते हैं और, सिद्धांत रूप में (हालांकि मौजूदा मुख्यधारा प्रणालियों पर व्यवहार में नहीं है), अतिप्रवाह एक गलती को ट्रिगर कर सकता है (शायद शून्य गलती से विभाजन के समान)।


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

4
  1. हां, अहस्ताक्षरित पूर्णांक बड़े मूल्य को संग्रहीत कर सकता है।
  2. नहीं, सकारात्मक और नकारात्मक मूल्यों को दिखाने के लिए अलग-अलग तरीके हैं।
  3. हां, हस्ताक्षरित पूर्णांक में सकारात्मक और नकारात्मक दोनों मान हो सकते हैं।

4

(दूसरे प्रश्न के उत्तर में) केवल एक साइन बिट (और 2 के पूरक नहीं) का उपयोग करके, आप -0 से समाप्त कर सकते हैं। बहुत सुंदर नहीं है।


इस उत्तर को जोड़ने के लिए, मूल रूप से इसका मतलब है कि 10 == 00 जहां दोनों संख्याएं आधार हैं 2.

4

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

C में अनइंस्टॉल किए गए पूर्णांकों में पूर्णांकों के अमूर्त बीजगणितीय वलयों के रूप में व्यवहार किया जाता है, जो दो प्रकार की शक्ति है, जिसमें बड़े, प्रकारों के साथ रूपांतरण, या परिचालनों को शामिल करते हुए, दो की कुछ शक्ति है। किसी भी आकार के पूर्णांक को 32-बिट अहस्ताक्षरित रूप में परिवर्तित करने से सदस्य को उन चीज़ों के अनुरूप मिलेगा, जो कि पूर्णांक mod ​​4,294,967,296 के अनुरूप हैं। 2 पैदावार 4,294,967,295 में से 3 को घटा देने का कारण यह है कि 4,294,967,295 में 3 से कुछ के लिए कुछ के साथ कुछ जोड़ने पर 2 से कुछ बधाई मिलेगी।

सार बीजीय के छल्ले प्रकार अक्सर काम की चीजें हैं; दुर्भाग्य से, सी एक प्रकार का अँगूठी के रूप में व्यवहार करना चाहिए या नहीं, इसके लिए निर्णायक कारक के रूप में सी का उपयोग किया जाता है। बड़े प्रकारों में परिवर्तित होने पर रिंग सदस्यों के बजाय बदतर, अहस्ताक्षरित मानों को संख्याओं के रूप में माना जाता है, और intजब कोई अंकगणित उन पर किया जाता है, तो संख्याओं में परिवर्तित होने से छोटा अहस्ताक्षरित मान । अगर vएक uint32_tसमान है 4,294,967,294, तो v*=v;बनाना चाहिए v=4। दुर्भाग्य से, अगर int64 बिट्स है, तो कोई भी नहीं बता रहा है कि क्या v*=v;कर सकता है।

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


3

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

unsigned int ui = -1;
signed int si = -1;

if (ui < 0) {
    printf("unsigned < 0\n");
}
if (si < 0) {
    printf("signed < 0\n");
}
if (ui == si) {
    printf("%d == %d\n", ui, si);
    printf("%ud == %ud\n", ui, si);
}

जब आप इसे चलाते हैं, तो आपको निम्न आउटपुट मिलेंगे, भले ही दोनों मान -1 को दिए गए हों और अलग-अलग घोषित किए गए हों।

signed < 0
-1 == -1
4294967295d == 4294967295d

0

एक हस्ताक्षरित और सी में एक अहस्ताक्षरित मूल्य के बीच एकमात्र गारंटीकृत अंतर यह है कि हस्ताक्षरित मूल्य नकारात्मक, 0 या सकारात्मक हो सकता है, जबकि एक अहस्ताक्षरित केवल 0 या सकारात्मक हो सकता है। समस्या यह है कि C प्रकारों के प्रारूप को परिभाषित नहीं करता है (इसलिए आप नहीं जानते कि आपके पूर्णांक दो के पूरक हैं)। आपके द्वारा उल्लेखित पहले दो बिंदुओं को सख्ती से बोलना गलत है।


0

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

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