@brtzsnr शायद आपको इस दस्तावेज़ को प्रस्ताव प्रक्रिया के चरणों में उल्लिखित प्रस्ताव रेपो में जमा करना चाहिए?

चूंकि यह टेम्पलेट के बाद पहले से ही मार्कडाउन है, इसलिए फ़ाइल डिज़ाइन/18616-bit-twiddling.md (या जो कुछ भी) बनाने वाले सीएल में कॉपी-पेस्ट करना आसान होना चाहिए।

@cespare https://github.com/golang/proposal से "यदि लेखक एक डिज़ाइन दस्तावेज़ लिखना चाहता है, तो वे एक लिख सकते हैं"। यह एक डिजाइन डॉक्टर के रूप में शुरू हुआ, अगर यह मजबूत भावना है कि मुझे इसे जमा करना चाहिए, तो मैं पूरी तरह से ठीक हूं।

मैं इसके साथ ठीक रहूंगा, यह कई एल्गोरिदमिक पुस्तकालयों में उपयोग की जाने वाली सामान्य कार्यक्षमता है और गणित/बिट्स उपयुक्त स्थान की तरह लगता है।

(एक के लिए, गणित/बड़ा भी nlz (== clz) लागू करता है।)

नामों के बारे में शायद कुछ बाइक शेडिंग है। मैं एक के लिए कार्यों को यह कहना पसंद करूंगा कि वे जो करते हैं उसके बजाय वे क्या लौटाते हैं; जो बदले में छोटे नामों को जन्म दे सकता है। उदाहरण के लिए:

bits.TrailingZeros64(x) बजाय bits.CountTrailingZeros64(x)

इत्यादि।

प्रस्ताव बहुत स्पष्ट और न्यूनतम लगता है - एक डिज़ाइन दस्तावेज़ अधिक लगता है। मुझे लगता है कि इस समय एक सीएल अधिक उपयुक्त होगा।

(यह एपीआई और बुनियादी कार्यान्वयन के साथ एक सीएल है - एक डिजाइन दस्तावेज़ के स्थान पर चर्चा के उद्देश्य से। हमें अभी भी यह तय करने की आवश्यकता है कि यह प्रस्ताव स्वीकार किया जाना चाहिए या नहीं।)

@brtzsnr ने पहले ही डिज़ाइन दस्तावेज़ लिखा है: यह समस्या विवरण में है और यह टेम्पलेट का अनुसरण करता

हार्डवेयर समर्थन तालिका में सूचीबद्ध अंतिम आर्क "बीएसडब्ल्यूएपी" है - टाइपो?

इसे लिखने के लिए धन्यवाद।

ctz और clz के लिए दस्तावेज़ स्ट्रिंग को 0 पास होने पर परिणाम निर्दिष्ट करना चाहिए।

मैं भी पसंद करता हूं (उदाहरण के लिए) TrailingZeros32 से CountTrailingZeros32। मुझे Ctz32 से भी खुशी होगी। यह संक्षिप्त है, अधिकांश के लिए परिचित है, और बाकी के लिए आसानी से गूगल करने योग्य है।

प्रस्ताव के लिए धन्यवाद।
मैं केवल यह जोड़ना चाहता हूं कि हम शायद केवल निर्देशों पर ध्यान केंद्रित करने के बजाय उपयोग पर ध्यान केंद्रित करना चाहते हैं। उदाहरण के लिए, @ dr2chase ने एक बार पाया कि कंपाइलर/असेंबलर में कई log2 फ़ंक्शन हैं। यह सीएलजेड के करीब है लेकिन ऐसा नहीं है। इस तरह के कार्य शायद बिट ट्विडलिंग पैकेज में भी होने चाहिए। और शायद उन उपयोगी कार्यों को भी शामिल करें जो इन निर्देशों से संबंधित नहीं हैं।

कैसे के बारे में हम द्वारा परिभाषित सभी बिट ट्विडलिंग प्राइमेटिव के लिए एक पैकेज प्रदान करते हैं
हैकर की प्रसन्नता?

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

@minux , सौभाग्य से, मुझे अब तक जिस भी बिट

हैकर्स डिलाइट का अनुसरण करने का यह लाभ है कि हमें नामों के बारे में बहस करने में समय बर्बाद करने की आवश्यकता नहीं है।

मैं निम्नलिखित जोड़ना चाहता हूं:

रिवर्सबिट्स (uint32 और uint64 के लिए)
RotateLeft/Right (दो पारियों के साथ इनलाइन का विस्तार किया जा सकता है, लेकिन संकलक
हमेशा शिफ्ट रेंज के मुद्दों के कारण परिवर्तन नहीं कर सकता)

शायद दो परिणाम जोड़ने और घटाने के रूप में भी? उदाहरण के लिए

func AddUint32 (x, y, कैरीइन uint32) (कैरीआउट, योग uint32) // कैरीइन करना चाहिए
0 या 1 हो।
और इसी तरह uint64 के लिए।

और SqrtInt.

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

संबंधित रूप से, यह जांचने के लिए कार्य करता है कि कोई जोड़/गुणा अतिप्रवाह होगा या नहीं।

एक संबंधित डेटा बिंदु: ऐसे कई मुद्दे हैं जो तेजी से सीजीओ के लिए दायर किए गए हैं। ऐसे ही एक उदाहरण में (प्रस्ताव #16051), तथ्य यह है कि bsr/ctz/etc. हो सकता है कि उपयोग के मामलों के सेट पर उम्मीद के मुताबिक छिलने का उल्लेख किया गया हो, जहां लिखने वाले लोग cgo का उपयोग करने के लिए ललचाते हैं।

@aclements ने 1 जुलाई 2016 को टिप्पणी की:

@eloff , पॉपकाउंट और बीएसआर जैसी चीजों के लिए कार्यों को जोड़ने के लिए कुछ चर्चा (हालांकि मेरे ज्ञान के लिए कोई ठोस प्रस्ताव नहीं है) किया गया है, जहां समर्थित है (जैसे गणित। वर्ग आज है)। 1.7 के साथ हम इसे रनटाइम में आज़मा रहे हैं, जिसमें अब एक ctz इंट्रिन्सिक है जो इसे amd64 SSA पर उपलब्ध है। जाहिर है कि समग्र समस्या का समाधान नहीं होता है, लेकिन यह कम-ओवरहेड संदर्भ में सीजीओ का उपयोग करने के एक और कारण को दूर कर देगा।

बहुत से लोग (स्वयं शामिल) प्रदर्शन के कारण जाने के लिए आकर्षित होते हैं, इसलिए बिट ट्विडलिंग के इस वर्तमान प्रस्ताव जैसी चीजों से मदद मिलेगी। (और हाँ, cgo भी अब 1.8 में तेज है, जो कि अच्छा भी है)।

RotateLeft/Right (दो पारियों के साथ इनलाइन का विस्तार किया जा सकता है, लेकिन संकलक
हमेशा शिफ्ट रेंज के मुद्दों के कारण परिवर्तन नहीं कर सकता)

@minux क्या आप विस्तार से

@brtzsnr : मुझे लगता है कि मिनक्स का जिक्र यह है कि जब आप (x << k) | (x >> (64-k)) लिखते हैं, तो आप जानते हैं कि आप 0 <= k < 64 का उपयोग कर रहे हैं, लेकिन संकलक आपके दिमाग को नहीं पढ़ सकता है, और यह स्पष्ट रूप से नहीं है कोड से व्युत्पन्न। अगर हमारे पास समारोह था

func leftRot(x uint64, k uint) uint64 {
   k &= 63
   return (x << k) | (x >> (64-k))
}

तब हम सुनिश्चित कर सकते हैं (&63 के माध्यम से) कि संकलक जानता है कि k की सीमा सीमित है।
इसलिए यदि कंपाइलर इनपुट को बाउंडेड साबित नहीं कर सकता है, तो हमें एक अतिरिक्त AND की आवश्यकता है। यह रोटेट असेंबली को बिल्कुल नहीं बनाने से बेहतर है।

शुक्र, 13 जनवरी, 2017 को रात 10:37 बजे, कीथ रान्डेल नोटिफिकेशन @github.com
लिखा था:

@brtzsnr https://github.com/brtzsnr : मुझे लगता है कि मिनक्स क्या कह रहा है
यह है कि जब आप लिखते हैं (x << k) | (x >> (64-k)), आप जानते हैं कि आप 0 . का उपयोग कर रहे हैं
<= k < 64, लेकिन संकलक आपके दिमाग को नहीं पढ़ सकता है, और यह स्पष्ट रूप से नहीं है
कोड से व्युत्पन्न। अगर हमारे पास समारोह था

func leftRot (x uint64, k uint) uint64 {
कश्मीर और = 63
वापसी (एक्स << के) | (एक्स >> (64-के))
}

तब हम सुनिश्चित कर सकते हैं (&63 के माध्यम से) कि संकलक जानता है कि रेंज
k से घिरा हुआ है।
इसलिए यदि कंपाइलर इनपुट को बाउंडेड साबित नहीं कर सकता है, तो हमें एक अतिरिक्त की आवश्यकता है
तथा। यह रोटेट असेंबली को बिल्कुल नहीं बनाने से बेहतर है।

सही। यदि हम RotateLeft और RotateRight कार्यों को परिभाषित करते हैं, तो हम औपचारिक रूप से कर सकते हैं
फ़ंक्शन को परिभाषित करें बाएं/दाएं k बिट्स घुमाएं (कोई फर्क नहीं पड़ता कि k क्या है)। यह है
हमारे शिफ्ट संचालन को कैसे परिभाषित किया जाता है। और यह परिभाषा भी
नक्शे को वास्तविक घुमाने के निर्देश को अच्छी तरह से (शिफ्ट के विपरीत, जहां हमारे अधिक
सहज ज्ञान युक्त परिभाषा के लिए कुछ आर्किटेक्चर पर तुलना की आवश्यकता होती है)।

ब्लॉस्क संपीड़न पुस्तकालय द्वारा उपयोग किए जाने वाले बाइट और बिट स्लाइड्स (फेरबदल 17 स्लाइड से शुरू होती है)। ये कार्य SSE2/AVX2 त्वरित किए जा सकते हैं।

शुक्र, 13 जनवरी, 2017 पर 11:24 pm पर, opennota [email protected] लिखा है:

ब्लॉस्क द्वारा उपयोग किए जाने वाले बाइट और बिट शफलिंग कार्यों के बारे में कैसे?
https://github.com/Blosc/c-blosc संपीड़न पुस्तकालय? स्लाइड
http://www.slideshare.net/PyData/blosc-py-data-2014 (फेरबदल)
स्लाइड 17 से शुरू होता है)। ये कार्य SSE2/AVX2 त्वरित किए जा सकते हैं।

SIMD एक बड़ी समस्या है और यह इस पैकेज के दायरे से बाहर है। यह है

17373.

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

@minux और बाकी सभी: क्या आप जानते हैं कि घुमाए गए बिट्स की निरंतर संख्या के साथ बाएं/दाएं घुमाने का उपयोग कहां किया जाता है? क्रिप्टो/sha256 उदाहरण के लिए रोटेट का उपयोग करता है, लेकिन बिट्स की निरंतर संख्या के साथ।

इनलाइन को इस तरह से लिखना आसान है कि कंपाइलर पहचान सके।

यह उन लोगों के लिए आसान है जो कंपाइलर के इंटर्नल से परिचित हैं। इसे गणित/बिट्स पैकेज में रखना सभी के लिए आसान बनाता है।

क्या आप जानते हैं कि घुमाए गए बिट्स की गैर-स्थिर संख्या के साथ बाएं/दाएं घुमाने का उपयोग कहां किया जाता है?

यहां #9337 से एक उदाहरण दिया गया है:

https://play.golang.org/p/rmDG7MR5F9

प्रत्येक आमंत्रण में यह हर बार घुमाए गए बिट्स की निरंतर संख्या होती है, लेकिन फ़ंक्शन स्वयं वर्तमान में इनलाइन नहीं होता है, इसलिए यह बिना किसी घुमाए निर्देशों के संकलित होता है। एक गणित/बिट्स लाइब्रेरी फ़ंक्शन निश्चित रूप से यहां मदद करेगा।

शनिवार, 14 जनवरी, 2017 को सुबह 5:05 बजे, अलेक्जेंड्रू मोओई नोटिफिकेशन @github.com
लिखा था:

वर्तमान प्रस्तावित कार्यों में गो मूल कार्यान्वयन बहुत बड़ा है
और अनुपातहीन रूप से इष्टतम से अधिक महंगा है। दूसरी ओर घुमाएँ
इनलाइन लिखना इस तरह से आसान है कि संकलक पहचान सके।

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

@minux https://github.com/minux और अन्य सभी: क्या आप जानते हैं
घुमाए गए बिट्स की गैर-स्थिर संख्या के साथ बाएं/दाएं घुमाएं कहां उपयोग किया जाता है?
क्रिप्टो/sha256 उदाहरण के लिए रोटेट का उपयोग करता है, लेकिन बिट्स की निरंतर संख्या के साथ।

भले ही वास्तविक समस्या में घूमने वाले बिट्स की संख्या स्थिर हो,
संकलक शायद इसे देखने में सक्षम न हो। उदाहरण के लिए जब शिफ्ट काउंट जमा हो जाता है
एक सरणी में, या लूप काउंटर में छुपाएं या यहां तक ​​​​कि एक इनलाइन के कॉलर भी नहीं
समारोह।

घुमाने की परिवर्तनीय संख्या का उपयोग करने का एक सरल उदाहरण एक दिलचस्प है
पॉपकाउंट का कार्यान्वयन:
// https://play.golang.org/p/ctNRXsBt0z

func RotateRight(x, k uint32) uint32
func Popcount(x uint32) int {
    var v uint32
    for i := v - v; i < 32; i++ {
        v += RotateRight(x, i)
    }
    return int(-int32(v))
}

@ जोशेरियन उदाहरण खराब इनलाइनर निर्णय की तरह दिखता है यदि सड़ांध इनलाइन नहीं है। आप के रूप में समारोह लिखने के लिए कोशिश की func rot(x, n) के बजाय rot = func(x, n) ?

@minux : मैं

उदाहरण के लिए: कैरी रिटर्न के साथ ऐड का सिग्नेचर क्या होना चाहिए? Add(x, y uint64) (c, s uint64) ? math/big हमें शायद Add(x, y uintptr) (c, s uintptr) भी चाहिए।

उदाहरण खराब इनलाइनर निर्णय की तरह दिखता है यदि सड़ांध इनलाइन नहीं है।

हां। यह इनलाइनिंग के बारे में शिकायत करने वाले बग का हिस्सा है। :)

क्या आपने फ़ंक्शन को रोट = func (x, n) के बजाय func रोट (x, n) के रूप में लिखने का प्रयास किया था?

यह मेरा कोड नहीं है - और यह बिंदु का हिस्सा है। और वैसे भी, यह उचित कोड है।

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

गुरु, 19 जनवरी, 2017 को पूर्वाह्न 11:50 बजे, माइकल मुंडे नोटिफिकेशन @github.com
लिखा था:

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

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

उस ने कहा, यह भी नगण्य संभावना है कि अंतर्निहित
माइक्रोआर्किटेक्चर एक बहु-चक्र शिफ्टर का उपयोग करता है, और हम गारंटी नहीं दे सकते
निरंतर समय उन कार्यान्वयनों पर घूमता है।

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

जबकि मैं इस तरह की गारंटी की आवश्यकता को समझता हूं, लेकिन यह वास्तव में परे है
हमारा नियंत्रण।

मैं @minux से सहमत होने के इच्छुक हूं। यदि आप निरंतर समय क्रिप्टो प्राइमेटिव चाहते हैं, तो उन्हें क्रिप्टो/सूक्ष्म में रहना चाहिए। क्रिप्टो/सूक्ष्म आसानी से उन प्लेटफार्मों पर गणित/बिट्स पर रीडायरेक्ट कर सकते हैं जहां उन कार्यान्वयनों को सत्यापित किया गया है। वे कुछ और कर सकते हैं यदि धीमे लेकिन निरंतर-समय के कार्यान्वयन की आवश्यकता होती है।

ऐसा करने लायक लगता है। पशु चिकित्सक के लिए @griesemer और @ Randall77 के लिए

अब जबकि यह प्रस्ताव आगे बढ़ सकता है, हमें एपीआई के विवरण पर सहमत होना चाहिए। इस समय मुझे जो प्रश्न दिखाई दे रहे हैं:

• कौन से कार्यों को शामिल करना है?
• किस प्रकार को संभालना है ( uint64 , uint32 केवल, या uint64 , uint32 , uint16 , uint8 , या uintptr )?
• हस्ताक्षर विवरण (उदाहरण के लिए TrailingZeroesxx(x uintxx) uint , xx = 64, 32, आदि के साथ, बनाम TrailingZeroes(x uint64, size uint) uint जहां आकार 64, 32, आदि में से एक है। - बाद वाला एक छोटे एपीआई की ओर ले जाएगा और हो सकता है कार्यान्वयन पर अभी भी पर्याप्त तेज़ हो)
• कुछ नाम बाइक शेडिंग (मुझे "हैकर डिलाइट" शब्दावली पसंद है लेकिन इसकी वर्तनी अधिक उपयुक्त हो सकती है)
• क्या इस पैकेज के लिए गणित/बिट्स से बेहतर जगह है।

@brtzsnr क्या आप इस प्रयास को आगे

मैं व्यक्तिगत रूप से एक्सएक्स नामों की वर्तनी पसंद करता हूं: बिट्स। ट्रेलिंगजेरो (यूइंट 64 (एक्स), 32) बिट्स की तुलना में अधिक बोझिल और कम पठनीय है। ट्रेलिंगजेरो 32 (एक्स), आईएमओ, और यह नामकरण योजना प्लेटफॉर्म-चर-आकार के साथ काम करेगी uintptr अधिक आसानी से (xx = Ptr?)।

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

यदि वर्तनी वाले नामों का उपयोग किया जाता है, तो मुझे लगता है कि हैकर की खुशी की शर्तों को विवरण में "इस रूप में भी जाना जाता है" के रूप में शामिल किया जाना चाहिए ताकि खोज (पृष्ठ में या खोज इंजन के माध्यम से) यदि आप गलत वर्तनी की खोज करते हैं तो आसानी से विहित नाम ढूंढ सकते हैं .

मुझे लगता है कि गणित/बिट्स एक अच्छी जगह है—यह बिट्स के साथ गणित है।

मैं नोट करना चाहिए कि SwapBytes{16,32,64} में कार्यों के साथ और अधिक सुसंगत है sync/atomic से SwapBytes(..., bitSize uint) ।

हालांकि strconv पैकेज का उपयोग करता है ParseInt(..., bitSize int) पैटर्न, वहाँ के बीच अधिक संबंध है bits और atomic , की तुलना में वहाँ के साथ है strconv ।

मुझे SwapBytes (uint64, size uint) पसंद नहीं आने के तीन कारण:

1. लोग इसका उपयोग उन मामलों में कर सकते हैं जहां आकार संकलन समय स्थिर नहीं है (at
   कम से कम वर्तमान कंपाइलर के लिए),
2. इसके लिए बहुत सारे प्रकार के रूपांतरणों की आवश्यकता होती है। uint32 को . में बदलने के लिए सबसे पहले
   uint64, और फिर इसे वापस कनवर्ट करने के लिए।
3. हमें भविष्य के जेनेरिक के लिए सामान्य नाम स्वैपबाइट्स आरक्षित करना चाहिए
   फ़ंक्शन का संस्करण (जब गो को जेनरिक समर्थन मिलता है)।

@griesemer रॉबर्ट, कृपया प्रस्ताव को

ऐसा लगता है कि फ़ॉर्म के हस्ताक्षर के लिए एक स्पष्ट प्राथमिकता है:

func fffNN(x uintNN) uint

जो खुला छोड़ देता है कि कौन सा एनएन समर्थन करता है। आइए निरंतर चर्चा के उद्देश्य से NN=64 पर ध्यान दें। शेष प्रकारों को आवश्यकतानुसार जोड़ना आसान होगा (incl. uintptr)।

जो हमें सीधे @brtzsnr द्वारा मूल प्रस्ताव और निम्नलिखित कार्यों (और विभिन्न प्रकारों के लिए उनके संबंधित रूपांतर) की ओर ले जाता है, साथ ही इस बीच लोगों ने क्या सुझाव दिया है:

// LeadingZeros64 returns the number of leading zero bits in x.
// The result is 64 if x == 0.
func LeadingZeros64(x uint64) uint

// TrailingZeros64 returns the number of trailing zero bits in x.
// The result is 64 if x == 0.
func TrailingZeros64(x uint64) uint

// Ones64 returns the number of bits set in x.
func Ones64(x uint64) uint

// RotateLeft64 returns the value of x rotated left by n%64 bits.
func RotateLeft64(x uint64, n uint) uint64

// RotateRight64 returns the value of x rotated right by n%64 bits.
func RotateRight64(x uint64, n uint) uint64

हमारे पास स्वैप फ़ंक्शंस का एक सेट भी हो सकता है। व्यक्तिगत रूप से मुझे इनके बारे में संदेह है: 1) मुझे कभी भी स्वैपबिट्स की आवश्यकता नहीं है, और स्वैपबाइट्स के अधिकांश उपयोग कोड के कारण होते हैं जो एंडियन-जागरूक होते हैं जब यह नहीं होना चाहिए। टिप्पणियाँ?

// SwapBits64 reverses the order of the bits in x.
func SwapBits64(x uint64) uint64

// SwapBytes64 reverses the order of the bytes in x.
func SwapBytes64(x uint64) uint64

फिर पूर्णांक संचालन का एक सेट हो सकता है। वे केवल इस पैकेज में होंगे क्योंकि उनमें से कुछ (जैसे लॉग 2) इस पैकेज में अन्य कार्यों के करीब हो सकते हैं। ये कार्य कहीं और हो सकते हैं। शायद पैकेज नाम bits को समायोजित करने की आवश्यकता है। टिप्पणियाँ?

// Log2 returns the integer binary logarithm of x.
// The result is the integer n for which 2^n <= x < 2^(n+1).
// If x == 0, the result is -1.
func Log2(x uint64) int

// Sqrt returns the integer square root of x.
// The result is the value n such that n^2 <= x < (n+1)^2.
func Sqrt(x uint64) uint64

अंत में, @minux ने AddUint32 आदि जैसे संचालन का सुझाव दिया। मैं उन्हें अभी के लिए छोड़ने जा रहा हूं क्योंकि मुझे लगता है कि वे सही ढंग से निर्दिष्ट करने के लिए और अधिक मुश्किल हैं (और अधिक विविधता है)। हम बाद में उनके पास वापस आ सकते हैं। आइए उपरोक्त पर कुछ आम सहमति प्राप्त करें।

प्रशन:

• फ़ंक्शन नामों के बारे में कोई राय?
• पूर्णांक ऑप्स के बारे में कोई राय?
• पैकेज के नाम/स्थान के बारे में कोई राय?

मैं लंबे कार्यों के नाम पसंद करूंगा। गो फ़ंक्शन नामों में संक्षिप्तीकरण से बचा जाता है। इस तरह से पैकेज खोजने वाले लोगों के लिए टिप्पणियाँ उनके उपनाम ("nlz", "ntz", आदि) कह सकती हैं।

@griesemer , आपको लगता है कि आपके संदेश में टाइपो हैं। टिप्पणियां फ़ंक्शन हस्ताक्षर से मेल नहीं खातीं।

मैं संपीड़न अनुप्रयोगों में SwapBits का उपयोग करता हूं। उस ने कहा, क्या प्रमुख आर्किटेक्चर कुशलतापूर्वक बिट रिवर्सल करने की क्षमता प्रदान करते हैं? मैं बस अपने कोड में करने की योजना बना रहा था:

v := bits.SwapBytes64(v)
v = (v&0xaaaaaaaaaaaaaaaa)>>1 | (v&0x5555555555555555)<<1
v = (v&0xcccccccccccccccc)>>2 | (v&0x3333333333333333)<<2
v = (v&0xf0f0f0f0f0f0f0f0)>>4 | (v&0x0f0f0f0f0f0f0f0f)<<4

@bradfitz , @dsnet : अद्यतन हस्ताक्षर (निश्चित टाइपो)। साथ ही अद्यतन प्रश्न (लोग शॉर्टकट के स्पष्ट नाम पसंद करते हैं)।

जब तक बिट-स्वैपिंग के लिए मूल समर्थन न हो, मैं SwapBits को छोड़ने के लिए मतदान करूंगा। यह अकेले नाम से थोड़ा अस्पष्ट हो सकता है कि क्या बिट्स केवल प्रत्येक बाइट के भीतर या पूरे uint64 में स्वैप किए जाते हैं।

केवल निर्देश उपलब्धता के आधार पर किसी चीज़ को बाहर क्यों करें? रिवर्स बिट
एफएफटी में उल्लेखनीय उपयोग हैं।

रिवर्स बिट निर्देश उपलब्धता के आपके प्रश्न का उत्तर देने के लिए: arm has
आरबीआईटी निर्देश।

@griesemer जहाँ तक प्रकार के कार्यों के हस्ताक्षर की तरह है

func Ones64(x uint64) uint
func RotateLeft64(x uint64, n uint) uint64

क्या RotateLeftN आदि यूंट लेते हैं क्योंकि यह आसान आंतरिककरण (जब संभव हो) के लिए आवश्यक है या सिर्फ इसलिए कि वह डोमेन है? यदि कोई मजबूत तकनीकी आवश्यकता नहीं है, तो इनट्स लेने के लिए एक मजबूत मिसाल है, भले ही नकारात्मक मूल्यों का कोई मतलब न हो। यदि कोई मजबूत तकनीकी आवश्यकता है, तो क्या उन्हें नियमितता के लिए उपयुक्त N के लिए uintN होना चाहिए?

भले ही OnesN और इसके ilk को ints वापस करना चाहिए, जब तक कि ऐसा न हो, इन ऑपरेशनों को अन्य बिट ऑपरेशंस के साथ बनाया जा सकता है, जिस स्थिति में उन्हें उपयुक्त N के लिए एक uintN वापस करना चाहिए।

@jimmyfrasche क्योंकि यह डोमेन है। सीपीयू परवाह नहीं है। तुलना के अलावा अधिकांश संचालन के लिए कुछ चीजें एक int या uint अप्रासंगिक है या नहीं। उस ने कहा, अगर हम इसे एक इंट बनाते हैं, तो हमें यह समझाना होगा कि यह कभी भी नकारात्मक (परिणाम) नहीं होता है, या यह नकारात्मक (तर्क) नहीं होना चाहिए, या निर्दिष्ट करें कि इसे नकारात्मक होने पर क्या करना चाहिए (घूर्णन के लिए तर्क)। हम उस मामले में सिर्फ एक रोटेट से दूर हो सकते हैं जो अच्छा होगा।

मुझे विश्वास नहीं है कि int का उपयोग करने से चीजें आसान हो जाती हैं। यदि ठीक से डिज़ाइन किया गया है, तो uints uints में प्रवाहित होंगे (यह गणित/बड़े में मामला है) और किसी रूपांतरण की आवश्यकता नहीं है। लेकिन अगर रूपांतरण की आवश्यकता है, तो भी यह सीपीयू लागत के मामले में मुफ्त होगा (हालांकि पठनीयता के मामले में नहीं)।

लेकिन मुझे अन्यथा ठोस तर्क सुनने/देखने में प्रसन्नता हो रही है।

से मेल खाने के लिए रोटेट बिट काउंट यूंट (बिना किसी विशिष्ट आकार के) होना चाहिए
भाषा के शिफ्ट ऑपरेटर।

इंट का उपयोग न करने का कारण यह है कि अस्पष्टता होगी कि क्या
RotateRight -2 बिट RotateLeft 2 बिट्स के बराबर है।

@minux कोई अस्पष्टता नहीं है जब Rotate(x, n) को x को n mod 64 बिट्स द्वारा घुमाने के लिए परिभाषित किया गया है: 10 बिट्स द्वारा बाएं घुमाएं 64-10 = 54 बिट्स द्वारा दाएं घुमाने जैसा ही है, या (यदि हम इंट तर्कों की अनुमति देते हैं) -10 बिट्स (सकारात्मक मान मानते हुए बाएं घुमाएं)। -10 मॉड 64 = 54। संभवतः हमें सीपीयू निर्देश के साथ भी मुफ्त में प्रभाव मिलता है। उदाहरण के लिए, 32 बिट x86 ROL/ROR निर्देश पहले से ही केवल CL रजिस्टर के निचले 5 बिट्स को देखते हैं, 32 बिट रोटेट के लिए मॉड 32 को प्रभावी ढंग से निष्पादित करते हैं।

एकमात्र वास्तविक तर्क बाकी stdlib के साथ नियमितता है। ऐसे कई स्थान हैं जहां uint बहुत मायने रखते हैं लेकिन इसके बजाय ints का उपयोग किया जाता है।

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

मुझे लगता है कि @minux का अर्थ कार्यान्वयन में अस्पष्टता के बजाय कोड पढ़ने/डिबगिंग करने वाले किसी व्यक्ति के लिए अस्पष्टता है, जो कि इसके लिए एक प्रेरक तर्क है।

बिट्स चाहिए। स्वैपबिट्स को वास्तव में बिट्स प्रत्यय के साथ नामित किया जाना चाहिए जब पैकेज का नाम पहले से ही बिट्स कहा जाता है? कैसे बिट्स के बारे में।स्वैप?

एक अन्य विचार बिट्स है। बिट्स के बजाय स्वैपएन (v uint64, n int)। स्वैपबाइट्स जहां n स्वैप के लिए समूह में बिट्स की संख्या का प्रतिनिधित्व करता है। जब n=1 बिट्स उलट जाते हैं, जब n=8, बाइट्स को स्वैप किया जाता है। एक लाभ यह है कि बिट्स। स्वैपबाइट्स का अब अस्तित्व नहीं है, हालांकि मैंने कभी भी n के किसी अन्य मूल्य की आवश्यकता नहीं देखी है, शायद अन्य असहमत होंगे।

जैसा कि ऊपर बताया गया है , LeadingZeros64 , TrailingZeros64 , Ones64 सभी LGTM।

एक एकल Rotate64 हस्ताक्षरित रोटेट राशि के साथ आकर्षक है। अधिकांश घुमाव एक स्थिर राशि से भी होंगे, इसलिए (यदि/जब यह एक आंतरिक हो जाता है) अलग-अलग दाएं/बाएं फ़ंक्शन न होने के लिए कोई रनटाइम लागत नहीं होगी।

बिट/बाइट शफलिंग/स्वैपिंग/रिवर्सिंग के बारे में मेरी कोई मजबूत राय नहीं है। बिट्स को उलटने के लिए, bits.Reverse64 एक बेहतर नाम लगता है। और शायद bits.ReverseBytes64 ? मुझे Swap64 थोड़ा अस्पष्ट लगता है। मुझे Swap64 समूह का आकार लेने की अपील दिखाई दे रही है, लेकिन जब समूह का आकार समान रूप से 64 को विभाजित नहीं करता है तो व्यवहार क्या होता है? यदि एकमात्र समूह आकार मायने रखता है 1 और 8 , तो उन्हें केवल अलग-अलग कार्य देना आसान होगा। मुझे यह भी आश्चर्य है कि क्या किसी प्रकार का सामान्य बिट फ़ील्ड हेरफेर बेहतर हो सकता है, शायद प्रेरणा के लिए arm64 और amd64 BMI2 निर्देशों को देख रहा हो।

मुझे विश्वास नहीं है कि पूर्णांक गणित कार्य इस पैकेज में हैं। ऐसा लगता है कि वे पैकेज गणित से संबंधित हैं, जहां वे अपने कार्यान्वयन में बिट्स फ़ंक्शंस का उपयोग कर सकते हैं। संबंधित, क्यों नहीं func Sqrt(x uint64) uint32 ( uint64 वापस करने के बजाय)?

हालांकि AddUint32 और मित्र जटिल हैं, मुझे आशा है कि हम अंततः उन पर फिर से विचार करेंगे। अन्य बातों के साथ, MulUint64 एचएमयूएल तक पहुंच प्रदान करेगा, जो कि सुपर-मिनिमलिस्ट आरआईएससी-वी आईएसए भी एक निर्देश के रूप में प्रदान करता है। लेकिन हाँ, पहले कुछ समझ लेते हैं; हम हमेशा बाद में विस्तार कर सकते हैं।

bits स्पष्ट रूप से सही पैकेज नाम की तरह लगता है। मैं यह कहने के लिए ललचा रहा हूं कि आयात पथ सिर्फ bits होना चाहिए, न कि math/bits , लेकिन मैं दृढ़ता से महसूस नहीं करता।

बिट्स स्पष्ट रूप से सही पैकेज नाम की तरह लगता है। मैं यह कहने का लुत्फ उठा रहा हूं कि आयात पथ सिर्फ बिट्स होना चाहिए, गणित/बिट्स नहीं, लेकिन मुझे दृढ़ता से महसूस नहीं होता है।

आईएमओ, अगर यह सिर्फ bits , (पैकेज दस्तावेज़ों को पढ़े बिना) मैं उम्मीद करता हूं कि यह कुछ हद तक पैकेज bytes । यही है, बिट्स पर काम करने के लिए कार्यों के अलावा, मुझे बाइट स्ट्रीम से/बिट्स पढ़ने और लिखने के लिए Reader और Writer खोजने की उम्मीद है। इसे math/bits से यह और अधिक स्पष्ट हो जाता है कि यह केवल स्टेटलेस फ़ंक्शंस का एक सेट है।

(मैं प्रस्तावित नहीं कर रहा हूं कि हम बिट स्ट्रीम के लिए रीडर/राइटर जोड़ें)

एक रोटेट 64 साइन की हुई रोटेट राशि के साथ आकर्षक है। अधिकांश घुमाव एक स्थिर राशि से भी होंगे, इसलिए (यदि/जब यह एक आंतरिक हो जाता है) अलग-अलग दाएं/बाएं फ़ंक्शन न होने के लिए कोई रनटाइम लागत नहीं होगी।

मैं देख सकता हूं कि बाएं/दाएं घुमाकर एक Rotate में जोड़कर थोड़ा छोटा पैकेज एपीआई रखना सुविधाजनक कैसे हो सकता है, लेकिन फिर n पैरामीटर को प्रभावी ढंग से दस्तावेज करने का मामला भी है संकेत मिलता है कि:

• नकारात्मक n परिणाम बाईं ओर घुमाते हैं
• शून्य n परिणाम में कोई बदलाव नहीं
• सकारात्मक n परिणाम सही घुमाते हैं

मेरे लिए, जोड़ा गया मानसिक और दस्तावेज़ीकरण ओवरहेड दोनों को एक Rotate में संयोजित करने का औचित्य प्रतीत नहीं होता है। एक स्पष्ट RotateLeft और RotateRight जहां n एक uint है, मेरे लिए अधिक सहज महसूस करता है।

@mdlayher ध्यान रखें कि k बिट्स द्वारा बाईं ओर घूमने वाले n-बिट शब्द के लिए nk बिट्स को दाईं ओर घुमाने के समान है। यहां तक ​​​​कि अगर आप इसे दो कार्यों में अलग करते हैं, तब भी आपको यह समझने की आवश्यकता है कि k बिट्स द्वारा बाईं ओर घूमने का मतलब हमेशा (k mod n) बिट्स द्वारा घूमना होता है (यदि आप n बिट्स से अधिक घुमाते हैं, तो आप फिर से शुरू करते हैं)। एक बार जब आप ऐसा कर लेते हैं, तो आप बस इतना कह सकते हैं कि रोटेट फ़ंक्शन हमेशा k mod n बिट्स द्वारा घूमता है और आपका काम हो गया। नकारात्मक मान या दूसरे फ़ंक्शन की व्याख्या करने की कोई आवश्यकता नहीं है। यह बस काम करता है। यह वास्तव में सरल है।

उसके ऊपर, हार्डवेयर (उदाहरण के लिए x86 पर) आपके लिए यह स्वचालित रूप से करता है, यहां तक ​​कि गैर-स्थिर k के लिए भी।

@griesemer , Rotate का नकारात्मक पक्ष यह है कि यह नहीं कहता कि कौन सी दिशा सकारात्मक है। क्या Rotate32(1, 1) 2 या 0x80000000 के बराबर है? उदाहरण के लिए, अगर मैं उस कोड को पढ़ रहा था जो इसका इस्तेमाल करता था, तो मुझे उम्मीद है कि परिणाम 2 होगा, लेकिन जाहिर तौर पर @mdlayher इसे 0x80000000 होने की उम्मीद करेगा। दूसरी ओर, RotateLeft और RotateRight स्पष्ट नाम हैं, चाहे वे हस्ताक्षरित या अहस्ताक्षरित तर्क लेते हों। (मैं @minux से असहमत

@aclements जिसे RotateLeft64 नामक केवल एक फ़ंक्शन के द्वारा ठीक किया जा सकता है और नकारात्मक मानों का उपयोग करके दाएं घुमाने के लिए उपयोग किया जा सकता है। या डॉक्स के साथ। (एफडब्ल्यूआईडब्ल्यू, आपके उदाहरण में, मैं भी 2 की अपेक्षा करूंगा, 0x800000000 की नहीं।)

@ जोशेरियन , मैं सहमत हूं, हालांकि RotateLeft बिना RotateRight थोड़ा अजीब लगता है। एक हस्ताक्षरित रोटेशन होने की स्थिरता संभावित रूप से मूल्यवान लगती है यदि रोटेशन की गणना की जाती है, लेकिन निरंतर रोटेशन के लिए मैं बहुत अधिक कोड पढ़ता हूं जो कहता है कि "दो बिट्स से दाएं घुमाएं" की तुलना में "नकारात्मक दो बिट्स मजाक करके बाएं घुमाएं"।

डॉक्स के साथ इसे ठीक करने में समस्या यह है कि डॉक्स फ़ंक्शन को कॉल करने वाले कोड की पठनीयता में मदद नहीं करते हैं।

कोड लिखने वाले लोग बाएँ घुमाना या दाएँ घुमाना चाहते हैं। वे निर्भर करते हुए बाएँ या दाएँ घुमाना नहीं चाहते। यदि हम केवल रोटेट-लेफ्ट प्रदान करते हैं, तो जो कोई भी राइट रोटेट करना चाहता है, उसे अपने राइट रोटेशन को लेफ्ट रोटेशन में बदलने के लिए एक एक्सप्रेशन लिखना होगा। यह एक प्रकार की अभिव्यक्ति है जिसे कंप्यूटर तुच्छ रूप से कर सकते हैं लेकिन प्रोग्रामर गलतियाँ करेंगे। प्रोग्रामर इसे स्वयं क्यों लिखते हैं?

मैं सहमत हूं।

@aclements @ianlancetaylor प्वाइंट लिया। (उस ने कहा, RotateLeft/Right का कार्यान्वयन शायद केवल घुमाने के एक कार्यान्वयन को कॉल करेगा।)

एक नाम विचार हस्ताक्षर नाम के बजाय प्रकार को पैकेज नाम में रखना है। bits64.Ones बजाय bits.Ones64 ।

@btracey , मैंने अपने मुंह में थोड़ा सा वहां फेंक दिया। :) हमारे पास flag64.Int या math64.Floatfrombits या sort64.Floats या atomic64.StoreInt ।

@bradfitz golang.org/x/image/math/f64 और golang.org/x/image/math/f32 हालांकि मौजूद हैं

मैंने उदाहरण के रूप में atomic बारे में नहीं सोचा था (मेरे सामान्य गो उपयोग में नहीं, शुक्र है)। अन्य उदाहरण अलग हैं क्योंकि पैकेज कई अलग-अलग प्रकारों के लिए दोहराए गए कार्यों के सेट से बड़े हैं।

जब आप bits64 और देखते हैं तो दस्तावेज़ीकरण को देखना आसान होता है (जैसे, गोडोक पर),
Ones LeadingZeros TrailingZeros

bits जाकर देखने के बजाय
Ones8 Ones16 Ones32 Ones64 LeadingZeros8 ...

@iand , वह भी बहुत सकल है। मुझे लगता है कि 32 और 64 एफ़, मैट और वीईसी के लिए सभी मौजूदा संख्यात्मक प्रत्ययों के लिए अच्छा नहीं लग रहा था। फिर भी, मैं कहूंगा कि यह सामान्य गो शैली के बजाय एक अपवाद है।

गो में pkg64.foo के बजाय pkg.foo64 नामकरण शैली का उपयोग करने के लिए बहुत मजबूत मिसाल है।

यदि हमारे पास n प्रकार हैं, तो पैकेज API n गुना बड़ा हो जाता है, लेकिन API जटिलता नहीं होती है। इसे हल करने का एक बेहतर तरीका प्रलेखन के माध्यम से हो सकता है और एपीआई को गो डॉक जैसे टूल के माध्यम से कैसे प्रस्तुत किया जाता है। उदाहरण के लिए, इसके बजाय:

// TrailingZeros16 returns the number of trailing zero bits in x.
// The result is 16 if x == 0.
func TrailingZeros16(x uint16) uint

// TrailingZeros32 returns the number of trailing zero bits in x.
// The result is 32 if x == 0.
func TrailingZeros32(x uint32) uint

// TrailingZeros64 returns the number of trailing zero bits in x.
// The result is 64 if x == 0.
func TrailingZeros64(x uint64) uint

जो स्पष्ट रूप से एपीआई को देखते समय मानसिक उपरि जोड़ता है, हम इसे इस प्रकार प्रस्तुत कर सकते हैं:

// TrailingZerosN returns the number of trailing zero bits in a uintN value x for N = 16, 32, 64.
// The result is N if x == 0.
func TrailingZeros16(x uint16) uint
func TrailingZeros32(x uint32) uint
func TrailingZeros64(x uint64) uint

गोडोक उन कार्यों के बारे में स्मार्ट हो सकता है जो उस अर्थ में समान हैं और उन्हें एक एकल दस्तावेज़ स्ट्रिंग वाले समूह के रूप में प्रस्तुत करते हैं। यह अन्य पैकेजों में भी मददगार होगा।

संक्षेप में, मुझे लगता है कि प्रस्तावित नामकरण योजना ठीक और गो परंपरा में लगती है। प्रस्तुति मुद्दा एक अलग प्रश्न है जिस पर कहीं और चर्चा की जा सकती है।

पैकेज नाम में बिट आकार डालने पर +1।

बिट्स 64। लॉग 2 बिट्स से बेहतर पढ़ता है। लॉग 264 (मुझे लगता है कि लॉग 2 वहां से संबंधित है - और पैकेज नामकरण इसे बाहर रखने का एक अच्छा कारण नहीं है)

अंत में, यह स्केलर प्रकार द्वारा "पैरामीटरीकृत" प्रत्येक प्रकार के लिए एक ही एपीआई है, इसलिए यदि कार्यों में समान नाम हैं, तो कोड अलग-अलग पैकेजों के साथ रिफैक्टर करना आसान है - बस आयात पथ बदलें (संपूर्ण-शब्द प्रतिस्थापन हैं gofmt -r के साथ तुच्छ लेकिन कस्टम प्रत्यय परिवर्तन अधिक अजीब हैं)।

मैं @griesmeyer से सहमत

हम एन्कोडिंग/बाइनरी से एक नाटक चुरा सकते हैं, और Uint64, Uint32, ... नामक वर्र्स बना सकते हैं जिसमें संबंधित पूर्वनिर्धारित प्रकारों को स्वीकार करने के तरीके होंगे।

बिट्स.Uint64.RightShift
बिट्स।Uint8.Reverse
बिट्स.Uintptr.Log2
...

@griesemer यह कैसे पता चलेगा कि उन्हें कैसे समूहित किया जाए? वास्तविक नाम के बजाय दस्तावेज़ में एन में समाप्त होने वाले फ़ंक्शन नाम के साथ एक दस्तावेज़ स्ट्रिंग और फिर असंगतता से मेल खाने वाले डॉकस्ट्रिंग के बिना funcs के बीच एक सामान्य उपसर्ग ढूंढना? यह सामान्यीकरण कैसे करता है? यह बहुत कम पैकेजों को परोसने के लिए एक जटिल विशेष मामले की तरह लगता है।

@rogpeppe यह

@nerdatmath यह थोड़ा अलग होगा क्योंकि उनके पास बोलचाल के अर्थ में एक ही इंटरफ़ेस होगा, लेकिन गो अर्थ में नहीं, जैसा कि एन्कोडिंग/बाइनरी में होता है (वे दोनों बाइनरी लागू करते हैं। बाइटऑर्डर), इसलिए चर सिर्फ नेमस्पेसिंग के लिए होंगे और गॉडोक किसी भी तरीके (# 7823) को तब तक नहीं उठाएगा जब तक कि प्रकार निर्यात नहीं किए जाते, जो एक अलग तरीके से गड़बड़ है।

मैं आकार प्रत्यय के साथ ठीक हूं, लेकिन, कुल मिलाकर, मैं अलग पैकेज पसंद करूंगा। हालांकि, इस टिप्पणी से आगे बढ़ने के लिए परेशान करने के लिए पर्याप्त नहीं है।

@nerdatmath यदि वे vars हैं, तो वे bits.Uint64 = bits.Uint8 ), जो संकलक को उन्हें इंट्रिनिक्स के रूप में व्यवहार करने से रोकेगा, जो पैकेज के (कम से कम भाग) के लिए प्रेरणाओं में से एक था।

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

यदि आप कई पैकेजों के साथ जा रहे हैं, हालांकि, यदि पर्याप्त दोहराव और मात्रा है, तो कम से कम "X/बिट्स/int64s", "X/bits/ints", "X/ बिट्स/int32s" "त्रुटियों", "स्ट्रिंग्स", "बाइट्स" से मेल खाने के लिए। अभी भी बहुत सारे पैकेज विस्फोट की तरह लगता है।

मुझे नहीं लगता कि हमें कई प्रकार के विशिष्ट पैकेजों के रास्ते पर जाना चाहिए, एक पैकेज बिट होना सरल है और गो लाइब्रेरी में पैकेजों की संख्या को नहीं बढ़ाता है।

मुझे नहीं लगता कि Ones64 और TrailingZeroes64 अच्छे नाम हैं। वे सूचित नहीं करते कि वे एक गिनती लौटाते हैं। उपसर्ग काउंट जोड़ने से नाम और भी लंबे हो जाते हैं। मेरे कार्यक्रमों में उन कार्यों को अक्सर बड़े भावों में एम्बेड किया जाता है, इसलिए छोटे फ़ंक्शन नाम पठनीयता को बढ़ाएंगे। हालांकि मैंने "हैकर डिलाइट" पुस्तक के नामों का उपयोग किया है, मैं इंटेल असेंबलर निमोनिक्स का पालन करने का सुझाव देता हूं: Popcnt64, Tzcnt64 और Lzcnt64। नाम छोटे हैं, एक सुसंगत पैटर्न का पालन करें, सूचित करें कि एक गिनती लौटा दी गई है और पहले से ही स्थापित हैं।

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

यदि विकल्प (अंकन का दुरुपयोग करने के लिए) गणित/बिट्स/int64s.Ones और गणित/बिट्स.Ones64 के बीच है, तो मैं निश्चित रूप से एक पैकेज को प्राथमिकता दूंगा। आकार के आधार पर विभाजन की तुलना में पैकेज पहचानकर्ता में बिट्स होना अधिक महत्वपूर्ण है। पैकेज आइडेंटिफायर में बिट्स होने से कोड को पढ़ना आसान हो जाता है, जो पैकेज के डॉक्यूमेंटेशन में दोहराव की मामूली असुविधा से ज्यादा महत्वपूर्ण है।

@ulikunitz आप हमेशा कर सकते हैं ctz := bits.TrailingZeroes64 , और इसी तरह, कोड में जो बड़े पैमाने पर बिट्स का उपयोग करता है। यह विश्व स्तर पर स्व-दस्तावेजीकरण नाम और जटिल कोड के लिए स्थानीय रूप से कॉम्पैक्ट नामों के बीच संतुलन बनाता है। विपरीत परिवर्तन, countTrailingZeroes := bits.Ctz64 , कम उपयोगी है क्योंकि अच्छे वैश्विक गुण पहले ही खो चुके हैं।

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

मैं @ulikunitz से सहमत

init() instead of initialize(), 
func instead of function
os instead of operatingsystem
proc instead of process
chan instead of channel

इसके अतिरिक्त, मैं उस बिट्स को चुनौती दूंगा।TrailingZeroes64 स्व-दस्तावेजीकरण है। शून्य के पीछे होने का क्या अर्थ है? स्वयं दस्तावेज़ीकरण संपत्ति इस धारणा के साथ मौजूद है कि उपयोगकर्ता दस्तावेज़ीकरण के अर्थशास्त्र के बारे में कुछ जानता है जिसके साथ शुरू करना है। यदि स्थिरता के लिए हैकर डिलाइट का उपयोग नहीं कर रहे हैं, तो इसे RotateRight64 और RotateLeft64 से मिलान करने के लिए केवल ZeroesRight64 और ZeroesLeft64 ही क्यों न कहें?

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

उदाहरण के लिए, यदि मैं string.HasSuffix को कॉल कर रहा हूं, तो मैं दिए गए नाम का अधिकांश समय उपयोग करता हूं क्योंकि मैं इसे एक या दो बार कॉल कर रहा हूं, लेकिन, कभी-कभी, एक बार की ETL स्क्रिप्ट में या जैसे मैं करूंगा अंत में इसे एक गुच्छा कहते हैं, इसलिए मैं ends := strings.HasSuffix करूँगा जो छोटा है और कोड को स्पष्ट करता है। यह ठीक है क्योंकि उपनाम की परिभाषा हाथ में है।

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

यदि आप अवधारणा से अपरिचित हैं, तो ट्रेलिंगज़ीरो शायद आपको यह नहीं बता पाएगा कि क्या हो रहा है, लेकिन यह आपको सीटीज़ की तुलना में कम से कम मोटे तौर पर क्या हो रहा है, इसका बेहतर विचार देता है।

@jimmyfrasche https://github.com/golang/go/issues/18616#issuecomment -275828661 के संबंध में: गो/डॉक के लिए एक ही फ़ाइल में कार्यों के सन्निहित अनुक्रम को पहचानना बहुत आसान होगा जिसमें सभी नाम हैं जिनके साथ शुरू होता है एक ही उपसर्ग और एक प्रत्यय है जो केवल संख्याओं का एक क्रम है और/या शायद एक शब्द जो उपसर्ग के सापेक्ष "छोटा" है। मैं इसे इस तथ्य के साथ जोड़ूंगा कि इनमें से केवल पहले कार्यों में एक दस्तावेज़ स्ट्रिंग है और दूसरा मिलान उपसर्ग के साथ नहीं है। मुझे लगता है कि यह अधिक सामान्य सेटिंग्स में काफी अच्छा काम कर सकता है। उस ने कहा, आइए इस प्रस्ताव को हाईजैक न करने के लिए इस पर कहीं और चर्चा करें।

FYI करें, go/doc परिवर्तनों पर चर्चा करने और उस वार्तालाप को इससे अलग रखने के लिए #18858 बनाया।

@mdlayher ऐसा करने के लिए धन्यवाद।

@rogpeppe आकार को पैकेज नाम में

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

मैं सहमत हूं कि Log2 में 2 आवश्यक नहीं है। bits.Log का तात्पर्य 2 के आधार से है।

बिट्स। लॉग 64 एसजीटीएम।

@griesemer मेरा कट-ऑफ वाक्य शायद अनाड़ी संपादन की एक कलाकृति थी। मैंने अभी इसे हटा दिया है।

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

@ulikunitz मुझे लगता है कि यहां अधिकांश प्रतिक्रिया स्पष्ट फ़ंक्शन नामों के पक्ष में है जो शॉर्टकट नहीं हैं।

@ulikunitz , इसके अतिरिक्त:

पैकेज बड़ा आंतरिक रूप से nlz का उपयोग करता है, लीडिंगज़ेरोस का नहीं।

आंतरिक निजी गैर-निर्यातित नामों का यहां कोई प्रभाव नहीं है।

जो कुछ भी मायने रखता है वह है सार्वजनिक एपीआई की स्थिरता और मानक अनुभव।

बाइकशेडिंग कष्टप्रद हो सकती है लेकिन नाम तब मायने रखते हैं जब हम उनके साथ हमेशा के लिए फंस जाते हैं।

CL https://golang.org/cl/36315 इस मुद्दे का उल्लेख करता है।

मैंने https://go-review.googlesource.com/#/c/36315/ को समीक्षा के लिए (एक डिज़ाइन दस्तावेज़ के बदले में) प्रारंभिक (आंशिक रूप से परीक्षण किए गए) API (प्रारंभिक कार्यान्वयन के साथ) के रूप में अपलोड किया है।

हम अभी भी सुनिश्चित कर रहे हैं कि एपीआई सही है, इसलिए कृपया अभी के लिए केवल एपीआई (bits.go) पर टिप्पणी करें। मामूली मुद्दों (टाइपो, आदि) के लिए कृपया CL पर टिप्पणी करें। डिजाइन के मुद्दों के लिए, कृपया इस मुद्दे पर टिप्पणी करें। जब तक हम इंटरफ़ेस से खुश नहीं हो जाते, मैं CL को अपडेट करता रहूंगा।

विशेष रूप से, कार्यान्वयन के बारे में चिंता न करें। यह बुनियादी है, और केवल आंशिक रूप से परीक्षण किया गया है। एक बार जब हम एपीआई से खुश हो जाते हैं तो कार्यान्वयन पर विस्तार करना आसान हो जाएगा।

@griesemer मुझे यकीन है कि आप ठीक हैं, लेकिन अगर यह उपयोगी है, तो मेरे पास परीक्षणों के साथ एक CLZ असेंबली कार्यान्वयन है https://github.com/ericlagergren/decimal/tree/ba42df4f517084ca27f8017acfaeb69629a090fb/internal/arith जिसके लिए आप स्वतंत्र हैं चोरी / बेला के साथ / जो कुछ भी।

@ericlagergren लिंक के लिए धन्यवाद। एक बार एपीआई व्यवस्थित हो जाने और हमारे पास हर जगह परीक्षण होने के बाद, हम कार्यान्वयन को अनुकूलित करना शुरू कर सकते हैं। मैं इसे ध्यान में रखूंगा। धन्यवाद।

@griesemer , ऐसा लगता है कि आपका प्रस्तावित एपीआई दस्तावेज एक ही उपसर्ग के साथ कार्यों को पर्याप्त रूप से दस्तावेज़ करने में सक्षम होने पर एक पूर्णांक प्रत्यय पर निर्भर करता है।

क्या 1.9 से पहले उस पर भी काम करने की योजना होगी?

18858, यानी!

@mdlayher यह आदर्श होगा। लेकिन यह शोस्टॉपर नहीं होगा क्योंकि यह "केवल" दस्तावेज़ीकरण को प्रभावित करता है, न कि एपीआई (जो आगे चलकर पिछड़ा-संगत रहना चाहिए)।

@griesemer @bradfitz मैं फ़ंक्शन नामों के संबंध में अपनी स्थिति पर पुनर्विचार करने के लिए कुछ समय पठनीयता होना चाहिए।

निम्नलिखित कोड वास्तव में समझना आसान है:

n := bits.LeadingZeros64(x)

मुझे अभी भी Ones64(x) की स्पष्टता के बारे में थोड़ा संदेह है, लेकिन यह लीडिंगज़ेरोस और ट्रेलिंगज़ेरोस के अनुरूप है। इसलिए मैं अपनी बात पर विराम लगाता हूं और वर्तमान प्रस्ताव का समर्थन करता हूं। एक प्रयोग के रूप में मैंने परीक्षण मामलों सहित पैकेज के प्रायोगिक शुद्ध गो कार्यान्वयन के लिए अपने मौजूदा कोड का उपयोग किया।

रिपोजिटरी: https://github.com/ulikunitz/bits
दस्तावेज़ीकरण: https://godoc.org/github.com/ulikunitz/bits

हमारे पास स्वैप फ़ंक्शंस का एक सेट भी हो सकता है [...] स्वैपबाइट्स के अधिकांश उपयोग कोड के कारण होते हैं जो एंडियन-जागरूक होते हैं जब यह नहीं होना चाहिए। टिप्पणियाँ?

मैं इस कारण से SwapBytes को एपीआई से बाहर रखना चाहता हूं। मुझे चिंता है कि लोग इसे गैर-पोर्टेबल तरीकों से उपयोग करना शुरू कर देंगे क्योंकि यह binary/encoding.BigEndian तुलना में सरल (या तेज माना जाता है) है।

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

@mundaym क्या ये रूटीन कभी SwapBytes64 सीधे BSWAP रूप में संकलित करने देना अनुचित तरीके से इसका उपयोग करने वाले लोगों से अधिक हो सकता है, imo।

मुझे चिंता है कि लोग इसे गैर-पोर्टेबल तरीकों से उपयोग करना शुरू कर देंगे क्योंकि यह बाइनरी/एन्कोडिंग की तुलना में सरल (या तेज़ माना जाता है)।

मेरा मानना ​​​​है कि ReverseBytes का उपयोग केवल गैर-पोर्टेबल है यदि unsafe संयोजन में उपयोग किया जाता है जहां आप निम्न स्तर पर डेटा तक पहुंचते हैं जिस तरह से मशीन उन्हें स्मृति में रखती है। हालाँकि, encoding.{Little,Big}Endian.X का उपयोग उतना ही गैर-पोर्टेबल है जब उस तरह से उपयोग किया जाता है। मैं संपीड़न में उपयोग के लिए ReverseBytes प्रतीक्षा कर रहा हूं और अगर इसे शामिल नहीं किया गया तो मुझे दुख होगा।

@ericlagergren

क्या इन दिनचर्याओं को कभी गहन किया जाएगा?

हां, encoding/binary बाइट रिवर्सल करने वाले फ़ंक्शन कोड पैटर्न का उपयोग करते हैं जो कंपाइलर द्वारा पहचाने जाते हैं और एकल निर्देशों के लिए अनुकूलित (या हो सकते हैं) (जैसे BSWAP ) ऐसे प्लेटफॉर्म पर जो असंरेखित डेटा का समर्थन करते हैं एक्सेस (जैसे 386, amd64, s390x, ppc64le और शायद अन्य)।

SwapBytes64 को सीधे संकलित करने दें क्योंकि BSWAP इसका अनुचित उपयोग करने वाले लोगों से अधिक हो सकता है, imo।

मैं असहमत होने के लिए इच्छुक हूं। एंडियननेस-अनजान कोड में SwapBytes वैध उपयोग हो सकते हैं, लेकिन मुझे संदेह है कि इसका सही तरीके से उपयोग किए जाने की तुलना में अधिक बार इसका दुरुपयोग किया जाएगा।

ध्यान दें कि रनटाइम/आंतरिक/sys ने पहले से ही अनुगामी शून्य और बाइट स्वैप के गो, असेंबली और कंपाइलर आंतरिक संस्करणों को अनुकूलित किया है, इसलिए हम उन कार्यान्वयनों का पुन: उपयोग कर सकते हैं।

@dsnet दिलचस्प, क्या आपके मन में कुछ खास है?

@aclements क्या आप जानते हैं कि रनटाइम में बाइट स्वैप इंट्रिंसिक का उपयोग कहाँ किया जाता है? मुझे परीक्षणों के बाहर कोई उपयोग नहीं मिला है।

@mundaym , AFAIK इसका उपयोग रनटाइम में नहीं किया जाता है। हमें आंतरिक एपीआई के साथ उतना सावधान रहने की ज़रूरत नहीं है, इसलिए मुझे लगता है कि हमने इसे सीटीज़ जोड़ते समय अभी जोड़ा है क्योंकि यह आसान था। :) (पॉपकाउंट एक बेहतर विकल्प होता।)

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

उस नोट पर: हमें संभवतः uintptr संस्करण शामिल करने चाहिए क्योंकि इसकी गारंटी नहीं है (हालांकि संभावना है) कि यह uint32 या uint64 के समान आकार का है। (ध्यान दें कि uint हमेशा या तो uint32 या uint64 )। राय? इसे बाद के लिए छोड़ दें? अच्छे नाम क्या होंगे? ( LeadingZerosPtr ?)

हमें अभी uintptr करना चाहिए, नहीं तो मैथ/बिग इसका उपयोग नहीं कर सकता। प्रत्यय Ptr एसजीटीएम। मुझे लगता है कि हमें uint भी करना चाहिए, अन्यथा सभी कॉलिंग कोड को रूपांतरण-मुक्त कॉल करने के लिए int आकार के आसपास सशर्त कोड लिखना होगा। कोई नामकरण विचार नहीं।

Uintptr के लिए Ptr, uint के लिए कोई प्रत्यय नहीं। Ones, Ones8, Ones16, Ones32, Ones64, OnesPtr, आदि।

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

समस्या यह है:
गणित/बड़ा इष्टतम प्रदर्शन के लिए मूल शब्द आकार का उपयोग करना चाहता है,
हालाँकि, पास होने पर, uintptr सही विकल्प नहीं है।
इस बात की कोई गारंटी नहीं है कि एक पॉइंटर का आकार उसी आकार का होता है जैसे
मूल शब्द आकार।
प्रमुख उदाहरण amd64p32 है, और हम mips64p32 और . भी जोड़ सकते हैं
mips64p32le बाद में, जो 64-बिट MIPS होस्ट के लिए बहुत अधिक लोकप्रिय हैं।

मैं निश्चित रूप से इस तरह के और उपयोगों को प्रोत्साहित नहीं करना चाहता। uintptr सबसे अधिक है
पॉइंटर्स के लिए, आर्किटेक्चर तटस्थ पूर्णांक के लिए नहीं।

एक समाधान, हालांकि, एपीआई में एक प्रकार का उपनाम पेश करना है (शायद यह
ब्रांडेड प्रकार होना चाहिए, यह चर्चा के लिए है)।
64-बिट आर्किटेक्चर पर Word = uint32 // या uint64 टाइप करें
// हमें शायद वर्ड के लिए कुछ आदर्श स्थिरांक भी प्रदान करने की आवश्यकता है जैसे
बिट्स, मास्क आदि की संख्या।

और फिर Word लेने के लिए किसी भी प्रकार के उपसर्ग के बिना फ़ंक्शन पेश करें।

वास्तव में, मैं कल्पना करता हूं कि यदि गणित/बिट दो परिणाम प्रदान करता है, उप, मूल,
डिव; गणित/बिग को बिना किसी आर्किटेक्चर विशिष्ट असेंबली के फिर से लिखा जा सकता है।

गणित/बड़ा निर्यात type Word uintptr । मैं मानता हूं कि यह एक गलती हो सकती है, लेकिन मेरा मानना ​​है कि संगतता के लिए यह आवश्यक है कि वह बनी रहे। इसलिए यदि हम गणित/बिट्स का उपयोग गणित/बिग को लागू करने के लिए करना चाहते हैं, जो मुझे लगता है कि हम करते हैं, तो हमें uintptr API की आवश्यकता है।

विषय से थोड़ा भटकना, लेकिन क्या मूल अहस्ताक्षरित शब्द का आकार सिर्फ यूंट नहीं है? इस मामले में, यूंट के लिए कोई प्रत्यय नहीं होना सही लगता है।

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

एफडब्ल्यूआईडब्ल्यू, गणित/बड़े का कार्यान्वयन अभी भी एक uint32/64 आधारित बिट्स एपीआई का उपयोग कर सकता है (यदि कार्यों का कोई uintptr संस्करण नहीं था)।

@minux मैं 2-परिणाम ऐड, सब, mul, div के खिलाफ नहीं हूं - लेकिन चलिए इसे दूसरे चरण में करते हैं। यदि हम अच्छा प्रदर्शन चाहते हैं तो हमें अभी भी असेंबली कोड की आवश्यकता है। लेकिन मुझे संकलक द्वारा अन्यथा आश्वस्त होने में खुशी हो रही है ...

मैंने API में uint और uintptr संस्करण जोड़े हैं। सीएल पर एक नज़र डालें और टिप्पणी करें। हालाँकि, मैं कार्यों के प्रसार से बहुत खुश नहीं हूँ।

@ जोशेरियन 64 बिट मशीन पर भी देशी

यदि uintptr फ़ंक्शंस की एकमात्र वैध आवश्यकता गणित/बड़े का समर्थन करना है, तो शायद गणित/बिट्स का कार्यान्वयन आंतरिक पैकेज में जा सकता है: केवल गणित/बड़े में uintptr सामान का उपयोग करें और बाकी को बेनकाब करें।

@jimmyfrasche , @griesemer यह

यूंट भी गलत है। यह amd64p32 पर 32-बिट है।
दरअसल, गणित/बड़ा uintptr के बजाय uint का उपयोग कर सकते थे, लेकिन गो 1 पर,
int/uint हमेशा 32-बिट होते हैं, जो uintptr को एकमात्र संभव समाधान बनाता है
गणित/बड़े शब्द के लिए।

हम एक नया पैकेज तैयार कर रहे हैं, इसलिए मुझे नहीं लगता कि संगतता बहुत अधिक है
चिंता। गणित/बड़ा गलत प्रकार का उपयोग कर रहा है, लेकिन यह ऐतिहासिक से अधिक है
दुर्घटना। चलिए गलती को आगे नहीं बढ़ाते।

मुझे समझ में नहीं आता कि एक एकीकृत प्रकार "वर्ड" का उपयोग क्यों किया जाता है जो हमेशा सबसे अधिक होता है
किसी दिए गए आर्किटेक्चर के लिए कुशल पूर्णांक प्रकार अधिक जटिल है
uintptr का उपयोग करना। उपयोगकर्ता कोड के लिए, आप इसे एक जादुई प्रकार के रूप में मान सकते हैं जो है
आर्किटेक्चर के आधार पर या तो 32-बिट या 64-बिट। यदि आप लिख सकते हैं
आपका कोड uintptr (जिसकी चौड़ाई भी आर्किटेक्चर पर निर्भर है) का उपयोग कर रहा है
आर्किटेक्चर स्वतंत्र तरीके से, तो मेरा मानना ​​​​है कि आप वर्ड के साथ भी ऐसा ही कर सकते हैं।
और Word सभी आर्किटेक्चर पर सही हैं।

एपीआई के प्रसार के लिए, मेरा सुझाव है कि हम 8 के लिए कार्यों को छोड़ दें
और पहले पास में 16-बिट प्रकार। वे शायद ही कभी उपयोग किए जाते हैं और अधिकांश
आर्किटेक्चर वैसे भी केवल 32-बिट और 64-बिट निर्देश प्रदान करेगा।

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

क्या हम सभी स्पष्ट रूप से आकार के यूंट प्रकार कर सकते हैं? यदि हम uint/uintptr आकार को स्थिरांक के रूप में जानते हैं, तो हम मामूली रूप से एक if-statement लिख सकते हैं जो सही आकार के फ़ंक्शन को कॉल करता है। यदि कथन निरंतर-मुड़ा हुआ होगा, और संबंधित रैपर फ़ंक्शन केवल आकार के फ़ंक्शन को कॉल करता है जिसे रेखांकित किया जाएगा।

अंत में, शब्द प्रकार (गणित/बड़े से स्वतंत्र) के संबंध में सही समाधान क्या है? बेशक हम इसे गणित/बिट्स में परिभाषित कर सकते हैं लेकिन क्या यह सही जगह है? यह एक प्लेटफ़ॉर्म-विशिष्ट प्रकार है। क्या यह एक पूर्व-घोषित प्रकार 'शब्द' होना चाहिए? और क्यों नहीं?

यहां कोई फ़ंक्शन हस्ताक्षर (या नाम) होना जो सीधे uintptr का उल्लेख करता है वह एक गलती की तरह लगता है। लोगों को गो प्वॉइंटर्स पर इस तरह का थोड़ा ट्विस्ट नहीं करना चाहिए।

यदि प्राकृतिक मशीन शब्द प्रकार के लिए कार्य होना चाहिए, तो मुझे लगता है कि वे अब int/uint का उल्लेख कर सकते हैं। हमने गणित/बड़े में यूंट का उपयोग नहीं किया क्योंकि यह 64-बिट सिस्टम पर 32 बिट था, लेकिन हमने इसे ठीक कर दिया है। और जबकि गणित/बिग अपने आप में एक सुसंगत दुनिया है, जहां यह समझ में आता है कि इसका अपना प्रकार बड़ा है। वर्ड, यह पैकेज पिक-एंड-यूटिलिटी रूटीन का एक संग्रह है। इस संदर्भ में एक नए प्रकार को परिभाषित करना कम सम्मोहक है।

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

गणित/बड़े के साथ संभावित बेमेल को संबोधित करने के लिए, कम से कम दो समाधान हैं जो यहां एपीआई में uintptr का उल्लेख नहीं करते हैं।

1. फ़ाइलों को परिभाषित करें word32.go तथा word64.go गणित/बिग में बिल्ड टैग और uintptr-स्वीकार करने वाले रैपर के साथ जो उचित रूप से रीडायरेक्ट करते हैं (और सुनिश्चित करें कि कंपाइलर इनलाइनिंग सही काम करता है)।

2. बिग की परिभाषा बदलें। वर्ड टू यूंट। सटीक परिभाषा एक आंतरिक कार्यान्वयन विवरण है, भले ही यह एपीआई में उजागर हो। इसे बदलना amd64p32 को छोड़कर किसी भी कोड को नहीं तोड़ सकता है, और यहां तक ​​​​कि गणित/बड़े से बाहर की बात होने की संभावना बहुत कम है।

@rsc : "हमने गणित/बड़े में uint का उपयोग नहीं किया क्योंकि यह 64-बिट सिस्टम पर 32 बिट्स था, लेकिन हमने इसे ठीक कर दिया है।" आह हाँ, मैं पूरी तरह से uintptr की पसंद के कारण के बारे में भूल गया। Go uint/int प्रकारों का संपूर्ण बिंदु पूर्णांक प्रकार होना था जो मशीन के प्राकृतिक रजिस्टर आकार को दर्शाता है। मैं बड़ा बदलने की कोशिश करुँगी।उठने के लिए कहो और देखो क्या होता है।

सभी: उपरोक्त चर्चा के अनुसार uintptr फ़ंक्शन संस्करणों को बाहर करने के लिए https://go-review.googlesource.com/#/c/36315/ अपडेट किया गया।

मैंने प्रभाव देखने के लिए गणित/बिट्स का उपयोग करने के लिए गणित/बिग को अस्थायी रूप से अपडेट किया है (https://go-review.googlesource.com/36328)।

कुछ टिप्पणियाँ:
1) मैं के परिणामों बनाने की दिशा में झुकाव रहा हूँ Leading / TrailingZeros कार्यों uint बजाय int । इन परिणामों का उपयोग मूल्य को तदनुसार स्थानांतरित करने के लिए किया जाता है; और math/big इसका प्रमाण है। मैं निरंतरता के लिए Ones एक uint वापस करने के पक्ष में हूं। जवाबी तर्क?

2) मैं One नाम का प्रशंसक नहीं हूं, हालांकि Leading / TrailingZeros अनुरूप हूं। कैसे के बारे में Population ?

3) कुछ लोगों ने शिकायत की है कि Log इस पैकेज में फिट नहीं बैठता है। Log एमएसबी की अनुक्रमणिका के बराबर होता है (x == 0 के लिए -1 के साथ)। तो हम इसे MsbIndex कह सकते हैं (हालांकि लॉग अच्छा लगता है)। वैकल्पिक रूप से, हमारे पास Len फ़ंक्शन हो सकता है जो बिट्स में x की लंबाई है; यानी, `लॉग (एक्स) == लेन (एक्स) -1)।

टिप्पणियाँ?

मैं एक नाम का प्रशंसक नहीं हूं, हालांकि लीडिंग/ट्रेलिंगजेरोस के अनुरूप हूं। जनसंख्या के बारे में कैसे?

पारंपरिक Popcount क्यों नहीं?

वैकल्पिक रूप से, हमारे पास एक लेन फ़ंक्शन हो सकता है जो बिट्स में x की लंबाई है; यानी, `लॉग (एक्स) == लेन (एक्स) -1)।

Len या Length एक अच्छा नाम और अच्छा विचार लगता है।

1.

मैं नाम वन का प्रशंसक नहीं हूं, हालांकि लीडिंग/
अनुगामी शून्य। जनसंख्या के बारे में कैसे?

बिट्स।गिनती?

@aclements क्या

जनसंख्या ऐतिहासिक कारणों से बेहतर नाम हो सकती है लेकिन यह वास्तव में लोगों से अधिक नहीं कहती है यदि आप इस शब्द से परिचित नहीं हैं और एक ही समस्या है तो बस गणना करें: जनसंख्या क्या है?

यह कुछ हद तक एकतरफा है, यहां तक ​​​​कि पैकेज के भीतर भी, लेकिन शायद काउंटऑन इसे एक स्पष्ट, स्पष्ट नाम देने के लिए।

@aclements क्या

"बिट्स" नामक पैकेज में, मुझे यकीन नहीं है कि आप सेट बिट्स को छोड़कर और क्या गिन सकते हैं, लेकिन काउंटऑन भी ठीक है और स्पष्ट रूप से अधिक स्पष्ट है। "Ones" को जोड़ने से LeadingZeros / TrailingZeros में "Zeros" भी समान्तर हो जाता है।

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

हो सकता है कि AllOnes या TotalOnes जैसे कुछ पीछे/अग्रणीZeroes को प्रतिबिंबित करने के लिए, लेकिन निर्दिष्ट करें कि, उनके विपरीत, स्थिति को ध्यान में नहीं रखा जाता है।

AllOnes ऐसा लगता है जैसे यह सभी को लौटाता है (शायद एक बिटमास्क में?), या शायद एक शब्द जो सभी है।

काउंटऑन और टोटलऑन लगभग एक जैसे लगते हैं, लेकिन चूंकि इस ऑपरेशन का सबसे सामान्य नाम "जनसंख्या गणना" है, इसलिए काउंटऑन ऐसा लगता है कि यह बेहतर होगा।

मैंने कुछ बदलावों के साथ एक नया संस्करण (https://go-review.googlesource.com/#/c/36315/) अपलोड किया है:

1) मैंने Ones का नाम बदलकर PopCount : अधिकांश लोग सुसंगत लेकिन कुछ हद तक नीरस नाम Ones को लेकर बहुत उत्साहित नहीं थे। हर कोई जो इस पैकेज का उपयोग करने जा रहा है उसे पता होगा कि PopCount क्या करता है: यह वह नाम है जिसके द्वारा यह फ़ंक्शन आमतौर पर जाना जाता है। यह बाकी के साथ थोड़ा असंगत है लेकिन इसका अर्थ इतना स्पष्ट हो गया है। मैं इस पर राल्फ वाल्डो इमर्सन के साथ जा रहा हूं ("एक मूर्ख स्थिरता छोटे दिमाग का शौक है ...")।

2) मैंने Log का नाम बदलकर Len जैसा कि bits.Len । एक संख्या x की बिट लंबाई बाइनरी प्रतिनिधित्व (https://en.wikipedia.org/wiki/Bit-length) में x का प्रतिनिधित्व करने के लिए आवश्यक बिट्स की संख्या है। उपयुक्त लगता है, और यहां Log की आवश्यकता को हटा देता है जिसमें एक गैर-"बिट-फिडली" गुणवत्ता है। मेरा मानना ​​है कि यह भी एक जीत है क्योंकि Len(x) == Log(x) + 1 देखते हुए कि हमने Log परिभाषित किया है। इसके अलावा इसका यह फायदा है कि अब परिणाम हमेशा> = 0 होता है, और यह (तुच्छ) कार्यान्वयन में कुछ +/- 1 सुधार हटा देता है।

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

टिप्पणियाँ?

जब मैं स्थानांतरण नहीं कर रहा हूं तो गणित/बड़े के साथ मेरा अनुभव कार्यों द्वारा यूंट मोड में मजबूर होने पर निराशा हुई है। मैथ/बिग/प्राइम.गो में, मैंने लिखा

for i := int(s.bitLen()); i >= 0; i-- {

भले ही s.bitLen() रिटर्न इंट नॉट यूंट, क्योंकि मैं बिना देखे अनिश्चित था, और क्या मैं यह भी अनिश्चित था कि कुछ भविष्य के सीएल इसे यूंट वापस करने के लिए नहीं बदल सकते हैं, जिससे लूप को अनंत लूप में बदल दिया जा सकता है। इस रक्षात्मक होने की आवश्यकता से पता चलता है कि कोई समस्या है।

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

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

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

मामूली बदलाव अपलोड किए। आइए प्रति +1 और टिप्पणियों के परिणामों को int रूप में छोड़ दें।

https://go-review.googlesource.com/36315

मैं के लिए इनपुट की गिनती छोड़ दिया RotateLeft/Right के रूप में uint अन्यथा हमारे द्वारा निर्धारित की आवश्यकता होगी क्या होता है जब मान ऋणात्मक है या अस्वीकार यह।

अंत में, हम Len बाद से LenN(x) == N - LeadingZerosN(x) को भी छोड़ सकते हैं। राय?

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

मैं अगले चरण पर चर्चा करना चाहता हूं कि क्या और कौन से अन्य कार्यों को हम शामिल करना चाहते हैं, विशेष रूप से Add / Sub / आदि। जो 2 तर्कों का उपभोग करते हैं और ले जाते हैं, और परिणाम उत्पन्न करते हैं और ले जाते हैं .

आधार 10 Len समारोह पर @gri विचार? यह सिर्फ ((N - clz(x) + 1) * 1233) >> 12

यह बेस 2 की तुलना में कम "बिट हैकी" है लेकिन फिर भी उपयोगी है।
शुक्र, 10 फरवरी, 2017 को शाम 5:03 बजे रॉबर्ट ग्रिसेमर नोटिफिकेशन @github.com
लिखा था:

मामूली बदलाव अपलोड किए। प्रति +1 और टिप्पणियों के परिणामों को छोड़ दें
इंट के रूप में गिना जाता है।

https://go-review.googlesource.com/36315

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

अंत में, हम लेन को भी छोड़ सकते हैं क्योंकि लेनन (एक्स) == एन -
अग्रणी ज़ीरोसएन (एक्स)। राय?

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

मैं अगले कदम पर चर्चा करना चाहता हूं कि हम और कौन से अन्य कार्य कर सकते हैं
शामिल करना चाहते हैं, विशेष रूप से जोड़ें/उप/आदि जो 2 तर्कों का उपभोग करते हैं और
ले जाना, और एक परिणाम उत्पन्न करना और ले जाना।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/18616#issuecomment-279107013 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AFnwZ_QMhMtBZ_mzQAb7XZDucXrpliSYks5rbQjCgaJpZM4Lg5zU
.

भी। अगर मैं इस मुद्दे के दायरे से बाहर हो रहा हूं तो मुझे क्षमा करें, लेकिन मैं चेक किए गए अंकगणित के पक्ष में हूं। जैसे AddN(x, y T) (sum T, overflow bool)

शुक्र, 10 फरवरी, 2017 को रात 8:16 बजे, एरिक लेगरग्रेन नोटिफिकेशन @github.com
लिखा था:

भी। अगर मैं इस मुद्दे के दायरे से बाहर हो रहा हूं तो मुझे क्षमा करें, लेकिन मैं अंदर रहूंगा
चेक किए गए अंकगणित के पक्ष में। जैसे AddN(x, y T) (योग टी, ओवरफ्लो बूल)

क्या आप हस्ताक्षरित अतिप्रवाह के बारे में बात कर रहे हैं? या अहस्ताक्षरित अतिप्रवाह (ले जाना/उधार लेना)?

साथ ही, मैं सरल बनाने के लिए ओवरफ्लो/कैरी/उधार को टाइप टी के रूप में वापस करना पसंद करता हूं
बहु-सटीक अंकगणित।

@ericlagergren (आधार 2) Len फ़ंक्शन, जबकि लगभग log2, अभी भी संक्षेप में थोड़ा गिनती फ़ंक्शन है। एक आधार 10 Len फ़ंक्शन वास्तव में एक लॉग फ़ंक्शन है। इस बात से कोई इंकार नहीं है कि यह उपयोगी है, लेकिन यह इस पैकेज के लिए कम उपयुक्त लगता है।

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

ऐड, सब फ़ंक्शंस के बारे में: मैं @minux से सहमत

गणित/जांच पैकेज उन लोगों के लिए बेहतर घर हो सकता है। checked.Add bits.Add से अधिक स्पष्ट है।

@minux मैं सोच रहा था कि चेक किए गए अंकगणित पर हस्ताक्षर किए गए हैं, इसलिए अतिप्रवाह।

@griesemer पुन: आधार 10 Len : समझ में आता है!

यदि आप चाहें तो मैं चेक किए गए अंकगणित के लिए एक सीएल जमा कर सकता हूं। मुझे @jimmyfrasche का एक अलग पैकेज नाम के तहत होने का विचार पसंद है।

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

चेक/विस्तृत अंकगणितीय परिचालनों को याद रखना एक अच्छा विचार है, लेकिन चलिए उन्हें दूसरे दौर के लिए छोड़ देते हैं।

"हर कोई जो इस पैकेज का उपयोग करने जा रहा है उसे पता होगा कि पॉपकाउंट क्या करता है"

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

मुझे पता है कि मैं पार्टी के लिए हूं, लेकिन "ऑन्सकाउंट" मेरे लिए काफी अधिक स्पष्ट लगता है, और यदि दस्तावेज़ टिप्पणी में "पॉपकाउंट" शब्द का उल्लेख किया गया है, तो जो लोग इसे ढूंढ रहे हैं वे इसे वैसे भी पाएंगे।

चेक/वाइड अंकगणित के लिए संबंधित: #6815। लेकिन हाँ, चलो एक चक्कर लगाते हैं!

@griesemer ने लिखा:

(आधार 2) लेन फ़ंक्शन, जबकि लगभग log2, अभी भी संक्षेप में थोड़ा गिनती फ़ंक्शन है। एक बेस 10 लेन फ़ंक्शन वास्तव में एक लॉग फ़ंक्शन है। इस बात से कोई इंकार नहीं है कि यह उपयोगी है, लेकिन यह इस पैकेज के लिए कम उपयुक्त लगता है।

मैंने पिछले अक्टूबर में "दशमलव अंकों की लंबाई" समस्या के कुछ दृष्टिकोणों की तुलना करने के लिए एक बेंचमार्क लिखा था, जिसे मैंने एक सार में पोस्ट किया था।

प्रस्ताव के रूप में स्वीकृत; आगे बढ़ने में शायद मामूली बदलाव होंगे, और यह ठीक है।

@rogpeppe : PopCount को OnesCount में बदल दिया गया क्योंकि इसे 4 थम्स-अप भी प्राप्त हुए (जैसे PopCount का उपयोग करने के लिए मेरा सुझाव)। दस्तावेज़ स्ट्रिंग में "जनसंख्या गणना" के लिए संदर्भित।

प्रति @rsc , अभी के लिए चेक/वाइड अंकगणितीय परिचालन छोड़कर।

साथ ही प्रति @rsc , सभी गणना कार्य int मान लौटाते हैं, और उपयोग में आसानी के लिए (और #19113 पर नज़र रखते हुए), रोटेशन गणना के लिए int मानों का उपयोग करें।

वाम LenN कार्य करता है, भले ही वे केवल N - LeadingZerosN । लेकिन एक समान समरूपता RotateLeft / Right और हमारे पास दोनों हैं।

TrailingZeroes और पूर्ण परीक्षणों के लिए थोड़ा तेज़ कार्यान्वयन जोड़ा गया।

इस बिंदु पर मेरा मानना ​​​​है कि हमारे पास प्रयोग करने योग्य पहला कार्यान्वयन है। कृपया https://go-review.googlesource.com/36315 , विशेष रूप से एपीआई पर कोड की समीक्षा करें। अगर हम सब खुश हैं तो मैं इसे सबमिट करवाना चाहता हूं।

अगला कदम:

• तेजी से कार्यान्वयन (प्राथमिक)
• अतिरिक्त कार्यक्षमता जोड़ना (माध्यमिक)

हम एक नया पैकेज डिजाइन कर रहे हैं

@minux आपका मतलब नया गणित/बड़ा है? क्या कहीं प्रक्रिया का पालन करना संभव है?

@TuomLarsen : @minux "नए पैकेज" के साथ गणित/बिट्स को संदर्भित करता है। उन्होंने गणित/बिग को ऐसे मामले के रूप में उल्लेख किया जहां गणित/बिट्स का उपयोग किया जाएगा। (भविष्य में, कृपया अपनी टिप्पणियों के बारे में अधिक विशिष्ट रहें ताकि हमें खोजने और अनुमान लगाने की आवश्यकता न हो कि आप क्या कह रहे हैं - धन्यवाद)।

CL https://golang.org/cl/37140 में इस मुद्दे का उल्लेख है।

क्या गो 1.9 के लिए गणित/बिट्स में कोई कंपाइलर-सहायता प्राप्त आंतरिककरण हो रहा है?

@cespare इस पर निर्भर करता है कि क्या हम इसे प्राप्त करते हैं (@khr?) इससे अलग, हम एक अच्छा मंच-स्वतंत्र कार्यान्वयन चाहते हैं। (जिन कारणों से हम गणित/बिग को पूरी तरह से गणित/बिट्स का उपयोग करने के लिए स्थानांतरित नहीं करना चाहते हैं, उनमें से एक यह है कि वर्तमान में हमारे पास गणित/बिग में कुछ प्लेटफ़ॉर्म-विशिष्ट असेंबली है जो तेज़ है।)

मेरी प्लेट पर, कम से कम मेहराब के लिए हम पहले से ही इंट्रिनिक्स करते हैं
(386, amd64, arm, arm64, s390x, mips, शायद ppc64)।

शुक्र, फरवरी 17, 2017 अपराह्न 12:54 बजे, रॉबर्ट ग्रिसेमर < सूचनाएं @github.com

लिखा था:

@cespare https://github.com/cespare इस पर निर्भर करता है कि हम इसे प्राप्त करते हैं या नहीं (
@khr https://github.com/khr ?) उससे स्वतंत्र, हम चाहते हैं कि a
सभ्य मंच-स्वतंत्र कार्यान्वयन। (एक कारण जो हम नहीं करते हैं
गणित/बिट्स का उपयोग करने के लिए पूरी तरह से गणित/बड़े को स्थानांतरित करना चाहते हैं कि वर्तमान में हम
गणित/बड़ी में कुछ प्लेटफ़ॉर्म-विशिष्ट असेंबली है जो तेज़ है।)

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/18616#issuecomment-280763679 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AGkgIIb8v1X5Cr-ljDgf8tQtT4Dg2MGiks5rdgkegaJpZM4Lg5zU
.

x86-64 पर जनसंख्या गणना को लागू करने के सबसे तेज़ तरीके के बारे में यह लेख मददगार हो सकता है: हाथ से कोडित असेंबली गति और सरलता में इंट्रिनिक्स को मात देती है - डैन लुउ, अक्टूबर 2014

CL https://golang.org/cl/38155 में इस मुद्दे का उल्लेख है।

CL https://golang.org/cl/38166 इस मुद्दे का उल्लेख करता है।

CL https://golang.org/cl/38311 में इस मुद्दे का उल्लेख है।

CL https://golang.org/cl/38320 में इस मुद्दे का उल्लेख है।

CL https://golang.org/cl/38323 में इस मुद्दे का उल्लेख है।

कुछ और चर्चा:

मैं:

गणित/बिट्स। रोटेट लेफ्ट को वर्तमान में आतंक के लिए परिभाषित किया गया है यदि इसका तर्क शून्य से कम है।
मैं इसे सही घुमाने के लिए RotateLeft को परिभाषित करने के लिए बदलना चाहता हूं यदि इसका तर्क शून्य से कम है।

इस तरह की एक बुनियादी दिनचर्या होने से एक घबराहट अनावश्यक रूप से कठोर लगती है। मैं तर्क दूंगा कि शून्य से विभाजित (जो घबराहट करता है) के बजाय एक नकारात्मक राशि से घुमाव शब्द आकार (जो घबराता नहीं है) से बड़ा बदलाव के समान होता है। डिवाइड-बाय-जीरो को वास्तव में घबराने की जरूरत है, क्योंकि कोई उचित परिणाम नहीं है, इसके बजाय आप वापस लौटेंगे। ऋणात्मक राशियों द्वारा घुमाने का एक पूरी तरह से परिभाषित परिणाम होता है जिसे हम वापस कर सकते हैं।

मुझे लगता है कि हमें RotateLeft और RotateRight को अलग-अलग कार्यों के रूप में रखना चाहिए, भले ही अब एक को दूसरे के साथ लागू किया जा सकता है। मानक उपयोग अभी भी गैर-ऋणात्मक तर्कों के साथ होगा।

अगर हम यहां कुछ करने जा रहे हैं, तो हमें इसे फ्रीज करके करना चाहिए। एक बार गो 1.9 आउट हो जाने पर हम अपना विचार नहीं बदल सकते।

रोब:

यदि आप वास्तव में ऐसा कुछ चाहते हैं, तो मेरे पास केवल एक फ़ंक्शन होगा, घुमाएं, जो बाएं के लिए सकारात्मक और दाएं के लिए नकारात्मक लेता है।

मैं:

यह समस्या है
बिट्स। घुमाएँ (x, -5)

इस कोड को पढ़ते समय यह स्पष्ट नहीं है कि हम बाएं या दाएं घूमते हैं या नहीं।
बिट्स.रोटेटराइट(5)
बहुत स्पष्ट है, भले ही इसका मतलब है कि गणित/बिट्स में दो बार घुमाएँ * फ़ंक्शन हैं।

माइकल जोन्स:

साइन रोटेट का अर्थ है कोड में कूदना, हाँ? अफ़सोस लगता है।

मैं:

नहीं, प्रस्तावित शब्दार्थ के साथ कार्यान्वयन वास्तव में सरल है। कम 6 बिट्स (64-बिट रोटेट के लिए) को मास्क करें और यह बस काम करता है।

मैं एक हस्ताक्षरित तर्क के साथ सिंगल रोटेट को पसंद करता हूं क्योंकि इसका मतलब है कि कार्यों की संख्या आधी है और बिना किसी घबराहट या यहां तक ​​कि एक सशर्त शाखा के सभी मामलों में बहुत कुशलता से किया जा सकता है।

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

आप हमेशा अंतर को विभाजित कर सकते हैं और हस्ताक्षरित तर्क के साथ केवल RotateLeft प्रदान कर सकते हैं। यह दिशा के लिए एक आसान निमोनिक देता है लेकिन कार्यों की नकल करने से बचता है।

@bcmills @robpike इस सटीक विषय की पिछली चर्चा भी देखें https://github.com/golang/go/issues/18616#issuecomment -275598092 और कुछ टिप्पणियों के लिए जारी

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

लेकिन वह बाईं ओर सकारात्मक है एक घुमाने के निर्देश का उपयोग करने में सक्षम किसी के लिए सहज होना चाहिए।

मैं खुद को घुमाने के निर्देश का उपयोग करने में सक्षम मानना ​​​​पसंद करता हूं और मेरा अंतर्ज्ञान है "गीज़, यह क्यों नहीं कहता कि यह किस दिशा में है? यह शायद बचा हुआ है, लेकिन मुझे यह सुनिश्चित करने के लिए दस्तावेज़ीकरण देखना

जहां तक ​​​​पठनीयता है, time.Duration API की तर्ज पर किसी चीज़ के बारे में कैसे:

const RotateRight = -1

bits.Rotate(x, 5 * RotateRight)

शायद बिट्स द्वारा परिभाषित निरंतर या पाठक (कॉल साइट) के लिए शायद एक अभ्यास?

@aclements और इसलिए आप समान क्षमता वाले दो (गुना एन प्रकार) कार्यों के साथ समाप्त होते हैं जिनका एकमात्र अंतर तर्क में एक संकेत है। अब हम इसे ऐड और सब के लिए सहन करते हैं लेकिन यही एकमात्र उदाहरण है जिसके बारे में मैं सोच सकता हूं।

संख्या अक्ष पर सकारात्मक संख्याएं दाईं ओर बढ़ती हैं, इसलिए मैं सकारात्मक संख्याओं के लिए बिट्स को दाईं ओर ले जाने के लिए दिशा-परिभाषित-बाय-साइन रोटेट/शिफ्ट की अपेक्षा करता हूं।

मुझे कोई समस्या नहीं है अगर यह [दस्तावेज] विपरीत होने जा रहा है, लेकिन मैं इसे सहज ज्ञान युक्त नहीं कहूंगा।

हालांकि @cznic बिट्स दाएं से बाएं लिखे गए हैं

मैं भी केवल Rotate (https://github.com/golang/go/issues/18616#issuecomment-275016583) के पक्ष में हूं यदि हम इसे दोनों दिशाओं में काम करते हैं।

दिशा के बारे में @aclements चिंता के प्रतिवाद के रूप में: एक RotateLeft प्रदान करना जो सही घूर्णन करते समय भी काम करता है, सुरक्षा की झूठी भावना भी प्रदान कर सकता है: "यह RotateLeft कहता है तो निश्चित रूप से यह घूर्णन नहीं कर रहा है अधिकार!"। दूसरे शब्दों में, अगर यह RotateLeft कहता है तो यह बेहतर है कि कुछ और न करें।

साथ ही, bits.Rotate का उपयोग वास्तव में केवल विशेषज्ञ कोड में है। यह एक ऐसा फ़ंक्शन नहीं है जिसका उपयोग बड़ी संख्या में प्रोग्रामर करते हैं। जिन उपयोगकर्ताओं को वास्तव में इसकी आवश्यकता है वे घूर्णन की समरूपता को समझेंगे।

@नाथनी

हालाँकि बिट्स दाएँ-से-बाएँ लिखे जाते हैं

बिट्स सिर्फ बाइनरी अंक हैं। किसी भी आधार में अंकों को बाएँ से दाएँ लिखा जाता है - यहाँ तक कि अधिकांश में, यदि सभी नहीं, तो दाएँ-से-बाएँ लेखन प्रणाली। 123 एक सौ तेईस है, तीन सौ इक्कीस नहीं।

वह अंक के गुणक का घात दाहिनी ओर घटता है वह अलग बात है।

एक बार फिर: मुझे दिशा की परवाह नहीं है, बस सहज ज्ञान युक्त व्यक्तिगत कल्पना की बात है।

मुझे घुमाना पसंद है। मेरे विचार से कम से कम महत्वपूर्ण बिट सहज रूप से 0 पर्याप्त है।

कृपया कुछ ऐसा करने के बजाय RotateLeft और RotateRight दोनों रखें, जिससे आधे डेवलपर गलत तरीके से याद रख सकें। हालांकि नकारात्मक संख्याओं को संभालना ठीक लगता है।

99% डेवलपर्स कभी भी घुमाने के निर्देश को प्रोग्राम नहीं करेंगे, इसलिए स्पष्ट दिशा की आवश्यकता सबसे कमजोर है। एक कॉल काफी है।

इस चर्चा को फिर से जगाने वाली समस्या यह है कि दोनों को इस बारे में बहस करने की आवश्यकता है कि क्या नकारात्मक मूल्य ठीक हैं, और यदि नहीं, तो उनके बारे में क्या करना है। एक ही होने से वह सारा तर्क मिट जाता है। यह क्लीनर डिजाइन है।

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

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

दूसरी ओर रोटेट शायद लोगों को if n < 0 { RotateLeft(...) } else { RotateRight(...) } लिखने से रोकेगा।

@ golang/प्रस्ताव-समीक्षा ने इस पर चर्चा की और केवल एक फ़ंक्शन होने पर समाप्त हुआ, लेकिन कॉल साइटों पर अतिरिक्त स्पष्ट होने के लिए इसे RotateLeft , न कि केवल Rotate । ऋणात्मक संख्याएँ दाईं ओर घूमती हैं, और दस्तावेज़ीकरण इसे स्पष्ट कर देगा।

CL https://golang.org/cl/40394 इस मुद्दे का उल्लेख करता है।

CL https://golang.org/cl/41630 इस मुद्दे का उल्लेख करता है।

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

सबसे विशेष रूप से, हमने निम्नलिखित के लिए कार्यक्षमता पर निर्णय या कार्यान्वयन नहीं किया है:

• परीक्षण करें कि क्या जोड़ें / mul / आदि अतिप्रवाह है
• ऐड/मूल/आदि को लागू करने के लिए कार्य प्रदान करें जो आने वाली कैरी को स्वीकार करते हैं और परिणाम प्लस कैरी (या उच्च शब्द) उत्पन्न करते हैं

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

इस प्रकार, अभी के लिए मैं इस मुद्दे को "हो गया" के रूप में बंद करना चाहता हूं जब तक कि कोई बड़ी आपत्ति न हो। यदि आप इसे बंद करने के खिलाफ हैं तो कृपया अगले सप्ताह तक बोलें।

मैं उन पंक्तियों के साथ कार्यों को जोड़ने के पक्ष में हूं।

मेरा दृढ़ विश्वास है कि वे अपने स्वयं के पैकेज में हैं, अगर किसी अन्य कारण से इसे एक नाम देने के अलावा जो उनकी सामूहिक कार्यक्षमता को बेहतर ढंग से दर्शाता है।

:+1: इस मुद्दे को बंद करने पर और :दिल: अब तक किए गए काम के लिए।

कोई आपत्ति नहीं होने के कारण बंद किया गया।

यह एपीआई के संबंध में भविष्य के निर्णयों के लिए एक टिप्पणी है, मैं समझता हूं कि यह विशेष रूप से सेट है।

Rotate एक विशेषज्ञ कार्य है; संदर्भ को देखते हुए LTR या RTL केवल प्रासंगिक है। @aclements ने एक वैध प्रश्न लाया, न कि एक वैध-विस्तार बिंदु। उनके प्रश्न का उत्तर "यह आरटीएल है, जैसे कि पूर्णांक वृद्धि"; आसान, है ना?

लेकिन इसके बजाय, चतुराई आती है।

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

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

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

आइए हम एपीआई के औचित्य में चतुराई से बचें। यह इस 1.9 अपडेट में दिखाता है।

बदलें https://golang.org/cl/90835 इस मुद्दे का उल्लेख करता है: cmd/compile: arm64 intrinsics for math/bits.OnesCount