स्कैला में >> और >>> के बीच अंतर

Question

क्या स्कैला में >> और >>> ऑपरेटर के बीच कोई अंतर है?

scala> 0x7f >>> 1 
res10: Int = 63 

scala> 0x7f >> 1 
res11: Int = 63 

scala> 0x7f >> 4 
res12: Int = 7 

scala> 0x7f >>> 4 
res13: Int = 7 

Answer 1

>> ऑपरेटर, हस्ताक्षर को बरकरार रखता है (प्रवेश फैली), जबकि >>> शून्यों वाम-पंथी बिट्स (शून्य फैली)।

-10>>2 
res0: Int = -3 
-10>>>2 
res1: Int = 1073741821 

Try it out yourself.

यह सी जैसी भाषाओं जो हस्ताक्षर किए हैं और अहस्ताक्षरित प्रकार में आवश्यक नहीं है, जावा, जो भी >>> है के विपरीत (यह कोई अहस्ताक्षरित पूर्णांकों है क्योंकि)।

Answer 2

उनके पास जावा जैसा ही अर्थ है। हस्ताक्षरित बाएं शिफ्ट ऑपरेटर "< <" बाईं ओर थोड़ा सा पैटर्न बदलता है, और हस्ताक्षरित दायां शिफ्ट ऑपरेटर ">>" दाईं ओर थोड़ा पैटर्न बदलता है। बिट पैटर्न बाएं हाथ के ऑपरेंड द्वारा दिया जाता है, और दाएं हाथ के ऑपरेंड द्वारा स्थानांतरित करने के लिए पदों की संख्या दी जाती है। हस्ताक्षरित दायां शिफ्ट ऑपरेटर ">>>" शून्य को बाएं स्थिति में बदल देता है, जबकि ">>" के बाद बाएं स्थान पर साइन एक्सटेंशन पर निर्भर करता है।

Answer 3

नोट: SLIP 30 (नवंबर 2015) के साथ, स्काला खत्म हो सकता है 4 "आदिम" प्रकार के साथ (2016 2017 में?) अहस्ताक्षरित पूर्णांकों का प्रतिनिधित्व करने के लिए: UByte, UShort, UInt और ULong।

कि Bit shifting operations on UInts and ULongs है, जो भी >> और >>> के बीच अंतर को दिखाता है को प्रभावित करेंगे:

शिफ्ट << छोड़ दिया और स्पष्ट तरीके से तार्किक सही बदलाव >>> व्यवहार।

शिफ्ट अंकगणित दाएं >> का मामला बहस योग्य है।
हम तर्क है कि यह अहस्ताक्षरित पूर्णांकों पर उपलब्ध दो कारणों के लिए नहीं होना चाहिए:

• सबसे पहले, एक पारी गणित सही अहस्ताक्षरित पूर्णांकों पर कोई अर्थ प्रतीत नहीं होता है। >>> पर सही अंकगणितीय शिफ्ट। इसलिए, unary_- के समान, इसे पेश नहीं किया जाना चाहिए।
  एक >> एक अहस्ताक्षरित संकार्य पर हस्ताक्षर नहीं करता है:
• दूसरा, मौजूदा भाषाओं करना है कि इस तरह सी परिवार के रूप में अहस्ताक्षरित पूर्णांक प्रकार, है, वास्तव में पर कि क्या यह एक पर हस्ताक्षर किए या अहस्ताक्षरित संकार्य है निर्भर करता है >> के लिए अलग अलग अर्थ विज्ञान देना -extend। यह स्केल में साइन-विस्तार के लिए x >> 3 के लिए सी डेवलपर को भ्रमित कर देगा, लेकिन यह स्केल डेवलपर के लिए समान रूप से भ्रमित होगा कि x >> 3 साइन-विस्तार नहीं है। इसलिए, हम इसे पूरी तरह से छोड़ना पसंद करते हैं, और एक कंपाइलर त्रुटि को उठाए जाने दें। (x.toInt >> 3).toUInt:

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

नोट: वर्तमान कार्यान्वयन >> प्रदान करता है, जब तक कि हम इस बिंदु पर सहमत न हों।