| ऑपरेशन | जटिलता |
| --- | --- |
| IEnumerable का उपयोग करके निर्माण करें | (लॉग एन) |

मुझे लगता है कि यह Θ (एन) होना चाहिए। आपको कम से कम इनपुट को फिर से चालू करने की आवश्यकता है।

+1

Rx में अत्यधिक उत्पादन-परीक्षण प्राथमिकता कतार वर्ग है:

https://github.com/Reactive-Extensions/Rx.NET/blob/master/Rx.NET/Source/System.Reactive.Core/Reactive/Internal/PriorityQueue.cs

क्या GetEnumerator को कॉल के दौरान और foreach का उपयोग करते समय अतिरिक्त ढेर आवंटन से बचने के लिए नेस्टेड सार्वजनिक एन्यूमरेटर संरचना का उपयोग किया जाना चाहिए? मेरी धारणा नहीं है, क्योंकि एक कतार में गणना करना एक असामान्य ऑपरेशन है।

मैं Queue<T> अनुरूप होने के लिए स्ट्रक्चर एन्यूमरेटर का उपयोग करने की ओर झुकता हूं जो एक स्ट्रक्चर एन्यूमरेटर का उपयोग करता है। साथ ही, यदि किसी स्ट्रक्चर एन्यूमरेटर का अभी उपयोग नहीं किया जाता है, तो हम भविष्य में किसी एक का उपयोग करने के लिए PriorityQueue<T> को बदलने में सक्षम नहीं होंगे।

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

    public void Enqueue(List<T> items) {
         items.Sort(_comparer);
         ... insertions ...
    }

मैंने यहां प्रारंभिक कार्यान्वयन की एक प्रति फेंक दी

ठंडा। कुछ प्रारंभिक प्रतिक्रिया:

• Queue<T>.Enumerator IEnumerator.Reset स्पष्ट रूप से PriorityQueue<T>.Enumerator ऐसा ही करना चाहिए?
• Queue<T>.Enumerator _index == -2 यह इंगित करने के लिए PriorityQueue<T>.Enumerator में एक ही टिप्पणी है लेकिन एक अतिरिक्त _disposed फ़ील्ड है। अतिरिक्त _disposed फ़ील्ड से छुटकारा पाने पर विचार करें और यह इंगित करने के लिए _index == -2 का उपयोग करें कि संरचना को छोटा बनाने और Queue<T> अनुरूप होने के लिए इसका निपटान किया गया है
• मुझे लगता है कि स्थिर _emptyArray फ़ील्ड को हटाया जा सकता है और उपयोग को इसके बजाय Array.Empty<T>() बदला जा सकता है।

भी...

• अन्य संग्रह जो एक तुलनाकर्ता लेते हैं (उदाहरण के लिए Dictionary<TKey, TValue> , HashSet<T> , SortedList<TKey, TValue> , SortedDictionary<TKey, TValue> , SortedSet<T> , आदि) शून्य होने की अनुमति देते हैं तुलनाकर्ता के लिए पास किया गया, जिस स्थिति में Comparer<T>.Default का उपयोग किया जाता है।

भी...

• ToArray को नई सरणी आवंटित करने से पहले _size == 0 जांच करके अनुकूलित किया जा सकता है, इस मामले में बस Array.Empty<T>() लौटाएं।

@justinvp बढ़िया प्रतिक्रिया, धन्यवाद!

• मैंने एन्यूमरेटर लागू कियास्पष्ट रूप से रीसेट करें क्योंकि यह एक गणक की मूल, गैर-पदावनत कार्यक्षमता है। यह उजागर हुआ है या नहीं, संग्रह प्रकारों में असंगत लगता है, और केवल कुछ ही स्पष्ट प्रकार का उपयोग करते हैं।
• _index के पक्ष में _disposed फ़ील्ड को हटा दिया, धन्यवाद! उस रात आखिरी मिनट में फेंक दिया और स्पष्ट चूक गया। ObjectDisposedException को नए संग्रह प्रकारों के साथ शुद्धता के लिए रखने का निर्णय लिया, भले ही पुराने System.Collections.Generic प्रकार इसका उपयोग नहीं करते हैं।
• सरणी। खालीएक एफ # सुविधा है, इसलिए दुख की बात है कि इसका उपयोग यहां नहीं किया जा सकता है!
• अशक्त, अच्छी खोज को स्वीकार करने के लिए तुलनित्र मापदंडों को संशोधित किया!
• ToArray अनुकूलन मुश्किल है। _तकनीकी रूप से_ बोलने वाले सरणियाँ C# में परिवर्तनशील होती हैं, भले ही उनकी लंबाई शून्य हो। वास्तव में आप सही हैं, आवंटन की आवश्यकता नहीं है और इसे अनुकूलित किया जा सकता है। मैं अधिक सतर्क कार्यान्वयन की ओर झुक रहा हूं, यदि कोई दुष्प्रभाव हैं जिनके बारे में मैं नहीं सोच रहा हूं। अर्थात् कॉलर अभी भी उस आवंटन की अपेक्षा करेगा, और यह मामूली है।

@ एबिकले

Array.Empty एक F# सुविधा है, इसलिए दुख की बात है कि यहाँ इसका उपयोग नहीं कर सकता!

अब और नहीं: https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/Array.cs#L1060 -L1069

मैंने इश्यू -574 शाखा में कोड को

ऐरे को लागू किया। खाली() नियमित बिल्ड पाइपलाइन में सब कुछ बदलें और प्लग करें। एक मामूली अस्थायी कीचड़ जो मुझे पेश करना था, वह था System.Collections प्रोजेक्ट System.Collections nuget पैकेज पर निर्भर करता है, तुलनाकर्ता के रूप मेंअभी तक खुला स्रोत नहीं है।

डॉटनेट/कोरएफएक्स#966 जारी होने के बाद इसे ठीक किया जाएगा।

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

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

एक और चीज जिस पर मुझे फीडबैक चाहिए वह यह है कि क्या कतार समान प्राथमिकता वाले दो आइटमों के लिए स्थिर होनी चाहिए (0 के परिणाम की तुलना करें)। आम तौर पर प्राथमिकता कतारें इस बात की कोई गारंटी नहीं देती हैं कि समान प्राथमिकता वाले दो आइटम को उसी क्रम में हटा दिया जाएगा जिस क्रम में उन्हें लगाया गया था, लेकिन मैंने देखा कि System.Reactive.Core में उपयोग की जाने वाली आंतरिक प्राथमिकता कतार कार्यान्वयन ने इस संपत्ति को सुनिश्चित करने के लिए कुछ अतिरिक्त ओवरहेड लिया। मेरी प्राथमिकता ऐसा नहीं करना होगा, लेकिन मुझे पूरी तरह से यकीन नहीं है कि डेवलपर्स की अपेक्षाओं के संदर्भ में कौन सा विकल्प बेहतर है।

मैं इस पीआर पर हुआ क्योंकि मुझे भी .NET में प्राथमिकता कतार जोड़ने में दिलचस्पी थी। यह देखकर खुशी हुई कि कोई इस प्रस्ताव को बनाने के प्रयास में गया :)। कोड की समीक्षा करने के बाद, मैंने निम्नलिखित देखा:

• जब IComparer ऑर्डरिंग Equals अनुरूप नहीं है, तो इस Contains कार्यान्वयन (जो IComparer का उपयोग करता है) का व्यवहार कुछ उपयोगकर्ताओं के लिए आश्चर्यजनक हो सकता है, क्योंकि यह अनिवार्य रूप से _ समान प्राथमिकता वाला आइटम शामिल है_।
• मुझे Dequeue में सरणी को सिकोड़ने के लिए कोड नहीं दिखाई दिया। चौथाई पूर्ण होने पर हीप सरणी को आधा घटाना विशिष्ट है।
• क्या Enqueue पद्धति को null तर्कों को स्वीकार करना चाहिए?
• मुझे लगता है कि Clear की जटिलता Θ(n) होनी चाहिए, क्योंकि यह System.Array.Clear की जटिलता है, जिसका वह उपयोग करता है। https://msdn.microsoft.com/en-us/library/system.array.clear%28v=vs.110%29.aspx

मुझे Dequeue में सरणी को सिकोड़ने के लिए कोड नहीं दिखाई दिया। चौथाई पूर्ण होने पर हीप सरणी को आधा घटाना विशिष्ट है।

Queue<T> और Stack<T> भी अपने सरणियों को सिकोड़ते नहीं हैं ( संदर्भ स्रोत के आधार पर, वे अभी तक CoreFX में नहीं हैं)।

@mbeidler मैं @svick ने बताया कि यह समान डेटा संरचनाओं के संदर्भ कार्यान्वयन में मौजूद नहीं है। मैं .NET कोर/बीसीएल टीम में किसी से भी यह जानने के लिए उत्सुक हूं कि क्या कोई विशेष कारण है कि उन्होंने कार्यान्वयन की शैली को चुना है।

अद्यतन: मैंने सूची की जाँच की, पंक्ति, Queue, और ArrayList - उनमें से कोई भी हटाने/डेक्यू पर आंतरिक सरणी के आकार को छोटा नहीं करता है।

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

दिलचस्प है, मैंने @svick द्वारा लिंक किए गए संदर्भ स्रोत में देखा कि Queue<T> में एक अप्रयुक्त निजी स्थिरांक है जिसका नाम _ShrinkThreshold । शायद वह व्यवहार पिछले संस्करण में मौजूद था।

के उपयोग के संबंध में IComparer के बजाय Equals के कार्यान्वयन में Contains :, मैं निम्नलिखित इकाई परीक्षण, जो वर्तमान में विफल हो जाएगा लिखा https: //gist.github। कॉम/एमबीडलर/9e9f566ba7356302c57e

@mbeidler अच्छा बिंदु। MSDN के अनुसार, IComparer/ आईतुलनीयकेवल गारंटी देता है कि शून्य के मान में समान क्रम है।

हालांकि, ऐसा लगता है कि अन्य संग्रह वर्गों में एक ही समस्या मौजूद है। अगर मैं SortedList पर काम करने के लिए कोड को संशोधित करता हूं, टेस्ट केस अभी भी कंटेन्सकी पर विफल रहता है। सॉर्टेडलिस्ट का कार्यान्वयन.ContainsKey Array.BinarySearch को कॉल करता है, जो समानता की जांच के लिए IComparer पर निर्भर करता है। सॉर्टेडसेट के लिए भी यही सच है.

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

मेरी कांटा शाखा में एक फिक्स और टेस्ट केस किया। कंटेन्स का नया कार्यान्वयन सीधे लिस्ट . के व्यवहार पर आधारित है।शामिल है। चूंकि सूचीIEqualityComparer स्वीकार नहीं करता है, व्यवहार कार्यात्मक रूप से समतुल्य है।

जब मुझे आज कुछ समय बाद मिलेगा, तो संभवत: मैं अन्य अंतर्निर्मित संग्रहों के लिए बग रिपोर्ट सबमिट करूंगा। शायद प्रतिगमन व्यवहार के कारण तय नहीं किया जा सकता है, लेकिन कम से कम दस्तावेज़ीकरण को अद्यतन करने की आवश्यकता है।

मुझे लगता है कि ContainsKey लिए IComparer<TKey> कार्यान्वयन का उपयोग करना समझ में आता है, क्योंकि यही कुंजी निर्दिष्ट करता है। हालांकि, मुझे लगता है कि ContainsValue लिए अपनी रैखिक खोज में IComparable<TValue> बजाय Equals का उपयोग करना अधिक तार्किक होगा; हालांकि इस मामले में दायरा काफी कम हो गया है क्योंकि एक प्रकार का प्राकृतिक क्रम बराबर के साथ असंगत होने की संभावना बहुत कम है।

यह के लिए MSDN दस्तावेज में प्रतीत होता है कि SortedList<TKey, TValue> , टिप्पणी अनुभाग के लिए ContainsValue संकेत मिलता है कि TValue की तरह आदेश समानता के एवज में प्रयोग किया जाता है।

@terrajobst अब तक आप API प्रस्ताव के बारे में कैसा महसूस करते हैं? क्या आपको लगता है कि यह CoreFX के लिए उपयुक्त है?

:+1:

इसे दाखिल करने के लिए धन्यवाद। मेरा मानना ​​है कि हमारे पास इस प्रस्ताव की औपचारिक समीक्षा करने के लिए पर्याप्त डेटा है, इसलिए मैंने इसे 'एपीआई समीक्षा के लिए तैयार' के रूप में लेबल किया है।

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

@andrewgmorris संबंधित https://github.com/dotnet/corefx/issues/4316 "कतार में TryDequeue जोड़ें"

हमने इसकी एक बुनियादी समीक्षा की थी और हम सहमत हैं कि हम ढांचे में एक ProrityQueue चाहते हैं। हालांकि, हमें इसके लिए डिजाइन और कार्यान्वयन को चलाने में मदद करने के लिए किसी को प्राप्त करने की आवश्यकता है। जो कोई भी इस मुद्दे को पकड़ लेता है वह एपीआई को अंतिम रूप देने के लिए @terrajobst पर काम कर सकता है।

तो एपीआई पर क्या काम बचा है?

यह उपरोक्त एपीआई प्रस्ताव से गायब है: PriorityQueue<T> को IReadOnlyCollection<T> को Queue<T> से मेल खाने के लिए लागू करना चाहिए ( Queue<T> अब IReadOnlyCollection<T> को .NET के रूप में लागू करता है। 4.6)।

मुझे नहीं पता कि सरणी-आधारित प्राथमिकता कतार सर्वोत्तम हैं। .NET में मेमोरी आवंटन वास्तव में तेज़ है। हमारे पास वही खोज-छोटे-ब्लॉक समस्या नहीं है जो पुराने मॉलोक से निपटते हैं। यहां से मेरी प्राथमिकता कतार कोड का उपयोग करने के लिए आपका स्वागत है: https://github.com/BrannonKing/Kts.Astar/tree/master/Kts.AStar

@ebickle _speclet_ पर एक छोटा सा नाइट। इसे कहते हैं:

/// Adds an object to the end of the <see cref="PriorityQueue{T}"/>. ... public void Enqueue(T item);

इसके बजाय यह नहीं कहना चाहिए, /// Inserts object into the <see cref="PriorityQueue{T}"> by its priority.

@SunnyWar Enqueue विधि के दस्तावेज़ीकरण को ठीक किया, धन्यवाद!

कुछ समय पहले, मैंने एक स्किप लिस्ट डेटा संरचना के आधार पर प्राथमिकता कतार के समान जटिलताओं के साथ एक डेटा संरचना बनाई थी जिसे मैंने इस बिंदु पर साझा करने का निर्णय लिया है: https://gist.github.com/bbarry/5e0f3cc1ac7f7521fe6ea25947f48ace

https://en.wikipedia.org/wiki/Skip_list

स्किप सूची औसत मामलों में उपरोक्त प्राथमिकता कतार की जटिलताओं से मेल खाती है, सिवाय इसके कि इसमें एक औसत मामला O(log(n)) । इसके अलावा, पहले या अंतिम तत्वों तक पहुंच निरंतर समय संचालन है और आगे और रिवर्स ऑर्डर दोनों में पुनरावृत्ति एक पीक्यू की फॉरवर्ड ऑर्डर जटिलताओं से मेल खाती है।

स्मृति पर उच्च लागत के रूप में इस तरह की संरचना के लिए स्पष्ट रूप से डाउनसाइड्स हैं, और यह O(n) सबसे खराब स्थिति डालने और हटाने के लिए विकसित होता है, इसलिए इसका व्यापार बंद है ...

क्या यह पहले से ही कहीं लागू है? अपेक्षित रिलीज कब है?
मौजूदा आइटम की प्राथमिकता को अपडेट करने के बारे में भी क्या?

@Priya91 @ianhays क्या यह समीक्षा के लिए तैयार होने के लिए तैयार है?

यह ऊपर दिए गए API प्रस्ताव से गायब है: प्रायोरिटी क्यूIReadOnlyCollection लागू करना चाहिएकतार से मेल खाने के लिए(पंक्तिअब IReadOnlyCollection लागू करता है.NET 4.6 के अनुसार)।

मैं यहां @justinvp से सहमत हूं।

@Priya91 @ianhays क्या यह समीक्षा के लिए तैयार होने के लिए तैयार है?

मैं ऐसा कहूंगा। यह थोड़ी देर के लिए बैठा है; चलो उस पर चाल चलते हैं।

@justinvp @ianhays मैंने . शुक्रिया!

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

@NKnusperer ने मौजूदा आइटम की प्राथमिकता को अपडेट करने के बारे में एक अच्छी बात

पूर्ण ढांचे में 2 कार्यान्वयन हैं, जो संभावित विकल्प हैं।
https://referencesource.microsoft.com/#q =priorityqueue

संदर्भ के लिए यहां स्टैक ओवरफ्लो पर जावा प्राथमिकता क्यू के बारे में एक प्रश्न है http://stackoverflow.com/questions/683041/java-how-do-i-use-a-priorityqueue । यह दिलचस्प है कि प्राथमिकता केवल एक साधारण int प्राथमिकता रैपर ऑब्जेक्ट की बजाय तुलनाकर्ता द्वारा नियंत्रित की जाती है। उदाहरण के लिए पहले से ही कतार में किसी आइटम की प्राथमिकता को बदलना आसान नहीं है।

एपीआई समीक्षा:
हम सहमत हैं कि CoreFX में इस प्रकार का होना उपयोगी है, क्योंकि हम उम्मीद करते हैं कि CoreFX इसका उपयोग करेगा।

एपीआई आकार की अंतिम समीक्षा के लिए, हम नमूना कोड देखना चाहेंगे: PriorityQueue<Thread> और PriorityQueue<MyClass> ।

1. हम प्राथमिकता कैसे बनाए रखते हैं? अभी यह केवल T द्वारा निहित है।
2. क्या हम चाहते हैं कि जब आप कोई प्रविष्टि जोड़ें तो प्राथमिकता को पारित करना संभव हो? (जो बहुत आसान लगता है)

टिप्पणियाँ:

• हम उम्मीद करते हैं कि प्राथमिकता अपने आप नहीं बदलेगी - हमें इसके लिए या तो एपीआई की आवश्यकता होगी, या हम कतार में Remove और Add अपेक्षा करेंगे।
• यह देखते हुए कि हमारे यहां एक स्पष्ट ग्राहक कोड नहीं है (केवल सामान्य इच्छा है कि हम प्रकार चाहते हैं), यह तय करना कठिन है कि किसके लिए अनुकूलित किया जाए - perf, बनाम प्रयोज्य बनाम कुछ और?

CoreFX में यह वास्तव में उपयोगी प्रकार होगा। क्या किसी को इसे हथियाने में दिलचस्पी है?

मुझे प्राथमिकता कतार को बाइनरी ढेर में ठीक करने का विचार पसंद नहीं है। विवरण के लिए मेरे AlgoKit विकी पृष्ठ पर एक नज़र डालें। त्वरित विचार:

• यदि हम एक निश्चित प्रकार के ढेर के कार्यान्वयन को ठीक कर रहे हैं, तो इसे 4-आरी हीप बनाएं।
• हमें ढेर के कार्यान्वयन को ठीक नहीं करना चाहिए, क्योंकि कुछ परिदृश्यों में कुछ प्रकार के ढेर दूसरों की तुलना में अधिक प्रदर्शनकारी होते हैं। इस प्रकार, यह देखते हुए कि हम एक निश्चित ढेर प्रकार के कार्यान्वयन को ठीक करते हैं और ग्राहक को अधिक प्रदर्शन के लिए एक अलग की जरूरत है, उसे पूरी प्राथमिकता कतार को जमीन से लागू करने की आवश्यकता होगी। यह गलत है। हमें यहां अधिक लचीला होना चाहिए और उसे कुछ CoreFX कोड (कम से कम कुछ इंटरफेस) का पुन: उपयोग करने देना चाहिए।

पिछले साल मैंने कुछ ढेर प्रकार लागू किए। विशेष रूप से, IHeap इंटरफ़ेस है जिसे प्राथमिकता कतार के रूप में उपयोग किया जा सकता है।

• इसे सिर्फ ढेर क्यों नहीं कहते...? आप ढेर का उपयोग करने के अलावा प्राथमिकता कतार को लागू करने का कोई समझदार तरीका जानते हैं?

मैं एक IHeap इंटरफ़ेस और कुछ सबसे अधिक प्रदर्शन करने वाले कार्यान्वयन (कम से कम उन सरणी आधारित) को पेश करने के लिए हूं। एपीआई और कार्यान्वयन ऊपर लिंक किए गए भंडार में हैं।

तो कोई _प्राथमिकता कतार_ ​​नहीं। ढेर ।

तुम क्या सोचते हो?

@karelz @safern @danmosemsft

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

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

ड्रॉप ICollection , IEnumerable ? बस सामान्य संस्करण हैं (हालांकि सामान्य IEnumerable<T> लाएगा IEnumerable )

@pgolebiowski इसका कार्यान्वयन कैसे बाहरी एपीआई को नहीं बदलता है। PriorityQueue व्यवहार/अनुबंध को परिभाषित करता है; जबकि Heap एक विशिष्ट कार्यान्वयन है।

प्राथमिकता कतार बनाम ढेर

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

इसलिए यदि आप अभी भी मानते हैं कि ढेर-आधारित कार्यान्वयन कुछ सरल सूची-आधारित या सूची-से-सरणी-भाग-आधारित कार्यान्वयन से बेहतर है, तो कृपया बताएं कि क्यों (आदर्श रूप से कुछ वाक्यों/पैराग्राफ में), ताकि हम इस पर सहमति प्राप्त कर सकें कार्यान्वयन दृष्टिकोण [...]

ठीक है। एक प्राथमिकता कतार एक सार डेटा संरचना है जिसे तब किसी तरह से लागू किया जा सकता है। बेशक आप इसे ढेर से अलग डेटा संरचना के साथ कार्यान्वित कर सकते हैं। लेकिन कोई रास्ता अधिक कुशल नहीं है। नतीजतन:

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

अपने शब्दों का समर्थन करने के लिए आइए सैद्धांतिक समर्थन से शुरू करें। एल्गोरिदम का परिचय , कॉर्मेन:

[…] प्राथमिकता वाली कतारें दो रूपों में आती हैं: अधिकतम-प्राथमिकता वाली कतारें और न्यूनतम-प्राथमिकता वाली कतारें। हम यहां इस बात पर ध्यान केंद्रित करेंगे कि अधिकतम-प्राथमिकता वाली कतारों को कैसे लागू किया जाए, जो बदले में अधिकतम- ढेर पर आधारित होती हैं।

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

• जावा: PriorityQueue<T> - ढेर के साथ लागू प्राथमिकता कतार।
• जंग: BinaryHeap — एपीआई में स्पष्ट रूप से ढेर। यह दस्तावेज़ों में कहता है कि यह एक बाइनरी ढेर के साथ लागू प्राथमिकता कतार है। लेकिन एपीआई संरचना पर बहुत स्पष्ट है - एक ढेर।
• स्विफ्ट: CFBinaryHeap - फिर से, स्पष्ट रूप से कहता है कि डेटा संरचना क्या है, अमूर्त शब्द "प्राथमिकता कतार" के उपयोग से बचते हुए। कक्षा का वर्णन करने वाले दस्तावेज़: बाइनरी ढेर प्राथमिकता कतार के रूप में उपयोगी हो सकते हैं। मुझे दृष्टिकोण पसंद है।
• C++: priority_queue — एक बार फिर, एक सरणी के शीर्ष पर बने बाइनरी हीप के साथ कैननिक रूप से कार्यान्वित किया गया।
• पायथन: heapq - एपीआई में ढेर स्पष्ट रूप से उजागर होता है। प्राथमिकता कतार का उल्लेख केवल डॉक्स में किया गया है: यह मॉड्यूल हीप कतार एल्गोरिथ्म का कार्यान्वयन प्रदान करता है, जिसे प्राथमिकता कतार एल्गोरिथ्म के रूप में भी जाना जाता है।
• जाओ: heap package — यहां तक ​​कि एक हीप इंटरफ़ेस भी है। कोई स्पष्ट प्राथमिकता कतार नहीं, लेकिन फिर से केवल डॉक्स में: प्राथमिकता कतार को लागू करने के लिए एक ढेर एक सामान्य तरीका है।

मेरा दृढ़ विश्वास है कि हमें रस्ट/स्विफ्ट/पायथन/गो रास्ते पर जाना चाहिए और डॉक्स में स्पष्ट रूप से बताते हुए एक ढेर को स्पष्ट रूप से

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

मुझे आशा है कि आप सभी को एक हीप डेटा संरचना को स्पष्ट रूप से उजागर करने का तरीका पसंद आएगा - और केवल डॉक्स में प्राथमिकता कतार संदर्भ बनाना।

एपीआई और कार्यान्वयन

हमें उपरोक्त मामले पर सहमत होने की आवश्यकता है, लेकिन मुझे एक और विषय शुरू करने दें - इसे कैसे लागू किया जाए । मैं यहां दो समाधान देख सकता हूं:

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

उपरोक्त दृष्टिकोण में, ArrayHeap एक निहित ढेर-आदेशित पूर्ण डी-आरी पेड़ का प्रतिनिधित्व करता है, जिसे एक सरणी के रूप में संग्रहीत किया जाता है। इसका उपयोग उदाहरण के लिए BinaryHeap या QuaternaryHeap बनाने के लिए किया जा सकता है।

जमीनी स्तर

आगे की चर्चा के लिए मैं आपको इस पेपर को देखने के लिए दृढ़ता से प्रोत्साहित करता हूं। आपको पता चल जाएगा कि:

• 4-आरी ढेर (चतुर्भुज) केवल 2-आरी ढेर (बाइनरी) से तेज होते हैं। पेपर में कई परीक्षण किए गए हैं - आप implicit_4 और implicit_2 (कभी-कभी implicit_simple_4 और implicit_simple_2 ) के प्रदर्शन की तुलना करने में रुचि लेंगे।

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

  • निहित डी-आरी ढेर (ऐरेहेप), <- निश्चित रूप से हमें इसकी आवश्यकता है
  • ढेरों को जोड़ना , <-

  उन दोनों के लिए प्रोग्रामिंग प्रयास आश्चर्यजनक रूप से कम है। मेरे कार्यान्वयन पर एक नज़र डालें।

@karelz @beanadams

CoreFX में यह वास्तव में उपयोगी प्रकार होगा। क्या किसी को इसे हथियाने में दिलचस्पी है?

@safern मुझे अब से इसे हथियाने में बहुत खुशी होगी।

ठीक है, यह मेरे कीबोर्ड और मेरी कुर्सी के बीच एक समस्या थी - PriorityQueue निश्चित रूप से Heap पर आधारित है - मैं सिर्फ Queue बारे में सोच रहा था जहां इसका कोई मतलब नहीं है और भूल गया कि ढेर 'क्रमबद्ध' है - मेरे जैसे किसी व्यक्ति के लिए बहुत शर्मनाक सोच-प्रक्रिया-आउटेज, जो तर्क, एल्गोरिदम, ट्यूरिंग मशीन इत्यादि से प्यार करता है, मेरी माफ़ी। (बीटीडब्लू: जैसे ही मैंने आपके जावा डॉक्स लिंक में कुछ वाक्य पढ़े, विसंगति तुरंत क्लिक की गई)

उस दृष्टिकोण से Heap शीर्ष पर एपीआई बनाना समझ में आता है। हमें उस वर्ग को अभी तक सार्वजनिक नहीं करना चाहिए - इसके लिए अपनी स्वयं की एपीआई समीक्षा और अपनी चर्चा की आवश्यकता होगी यदि यह कुछ ऐसा है जो हमें CoreFX में चाहिए। हम नहीं चाहते हैं कि कार्यान्वयन के कारण एपीआई की सतह रेंग जाए, लेकिन यह करना सही हो सकता है - इसलिए चर्चा की आवश्यकता है।
उस दृष्टिकोण से मुझे नहीं लगता कि हमें अभी IHeap बनाने की आवश्यकता है। बाद में अच्छा फैसला हो सकता है।
यदि कोई शोध है कि सामान्य यादृच्छिक इनपुट के लिए विशिष्ट ढेर (उदाहरण के लिए 4-आरी) सबसे अच्छा है, तो हमें उसे चुनना चाहिए। @Safern @ianhays के लिए आइए प्रतीक्षा की पुष्टि / आवाज राय को @stephentoub।

कई कार्यान्वित विकल्पों के साथ अंतर्निहित ढेर का पैरामीट्रिजेशन कुछ ऐसा है जो आईएमओ कोरएफएक्स में नहीं है (मैं यहां गलत हो सकता हूं, फिर से - देखते हैं कि दूसरे क्या सोचते हैं)।
मेरा कारण यह है कि आईएमओ हम जल्द ही विशेष संग्रह के गजिलियन भेज देंगे जो लोगों के लिए बहुत कठिन होगा (एल्गोरिदम की बारीकियों में मजबूत पृष्ठभूमि के बिना औसत डेवलपर) से चुनने के लिए। हालाँकि, इस तरह की लाइब्रेरी आपके/समुदाय के स्वामित्व वाले क्षेत्र के विशेषज्ञों के लिए एक बेहतरीन NuGet पैकेज बनाएगी। भविष्य में, हम इसे PowerCollections में जोड़ने पर विचार कर सकते हैं (हम पिछले 4 महीनों से सक्रिय रूप से चर्चा कर रहे हैं कि GitHub पर इस पुस्तकालय को कहाँ रखा जाए और यदि हमें इसका स्वामित्व होना चाहिए, या यदि हमें समुदाय को इसके मालिक होने के लिए प्रोत्साहित करना चाहिए - इस मामले पर अलग-अलग राय हैं , मुझे उम्मीद है कि हम 2.0 के बाद इसके भाग्य को अंतिम रूप देंगे)

आपको असाइन करना जैसा कि आप उस पर काम करना चाहते हैं ...

@pgolebiowski सहयोगी आमंत्रण भेजा गया - जब आप मुझे पिंग स्वीकार करते हैं, तो मैं इसे आपको तब सौंप सकूंगा (GitHub सीमाएं)।

@benaadams मैं ICollection (हल्का वरीयता) रखूंगा । CoreFX में अन्य डीएस के साथ संगति के लिए। आईएमओ यहां एक अजीब जानवर के लायक नहीं है ... अगर हम कुछ मुट्ठी भर नए जोड़ रहे थे (उदाहरण के लिए पावरकोलेक्शन भी दूसरे रेपो में), तो हमें गैर-जेनेरिक लोगों को शामिल नहीं करना चाहिए ... विचार?

ठीक है, यह मेरे कीबोर्ड और मेरी कुर्सी के बीच एक समस्या थी।

हाहा कोई चिंता नहीं।

ढेर के शीर्ष पर एपीआई बनाने के लिए यह समझ में आता है। हमें उस वर्ग को अभी तक सार्वजनिक नहीं करना चाहिए [...] हम कार्यान्वयन के कारण एपीआई सतह रेंगना नहीं चाहते हैं, लेकिन यह सही काम हो सकता है - इसलिए चर्चा की आवश्यकता है। [...] मुझे नहीं लगता कि हमें अभी IHeap बनाने की आवश्यकता है। बाद में अच्छा फैसला हो सकता है।

यदि समूह का निर्णय PriorityQueue साथ जाना है, तो मैं केवल डिजाइन और इसे लागू करने में मदद करूंगा। हालांकि, कृपया इस तथ्य को ध्यान में रखें कि यदि हम अभी PriorityQueue जोड़ते हैं, तो बाद में एपीआई में Heap जोड़ना गड़बड़ हो जाएगा - क्योंकि दोनों मूल रूप से समान व्यवहार करते हैं। यह अतिरेक आईएमओ की तरह होगा। यह मेरे लिए एक डिजाइन गंध होगी। मैं प्राथमिकता कतार नहीं जोड़ूंगा। यह मदद नहीं करता है।

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

IHeap + ArrayHeap + PairingHeap लिए वोटिंग! (जैसे रस्ट/स्विफ्ट/पायथन/गो में)

यदि युग्मन ढेर बहुत अधिक है -- ठीक है। लेकिन आइए कम से कम IHeap + ArrayHeap साथ चलें। क्या आप लोगों को नहीं लगता कि PriorityQueue वर्ग के साथ जाने से भविष्य में संभावनाएं बंद हो रही हैं और एपीआई कम स्पष्ट हो रही है?

लेकिन जैसा कि मैंने कहा - यदि आप सभी प्रस्तावित समाधान पर PriorityQueue वर्ग के लिए वोट करते हैं - ठीक है।

सहयोगी आमंत्रण भेजा गया - जब आप मुझे पिंग स्वीकार करते हैं, तो मैं इसे आपको तब सौंप सकूंगा (GitHub सीमाएं)।

@ करेल्ज़ पिंग :)

कृपया इस तथ्य को ध्यान में रखें कि यदि हम अभी एक प्रायोरिटी क्यू जोड़ते हैं, तो बाद में एपीआई में हीप को जोड़ना गड़बड़ हो जाएगा - क्योंकि दोनों मूल रूप से समान व्यवहार करते हैं। यह अतिरेक आईएमओ की तरह होगा। यह मेरे लिए एक डिजाइन गंध होगी। मैं प्राथमिकता कतार नहीं जोड़ूंगा। यह मदद नहीं करता है।

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

आइए देखें कि मतदान और आगे की डिजाइन चर्चा कैसे चलती है ... मैं धीरे-धीरे IHeap + ArrayHeap के विचार को गर्म कर रहा हूं, लेकिन अभी तक पूरी तरह से आश्वस्त नहीं हूं ...

अगर हम कुछ नए जोड़ रहे थे ... हमें गैर-जेनेरिक लोगों को शामिल नहीं करना चाहिए

एक बैल को लाल चीर। किसी के पास जोड़ने के लिए कुछ अन्य संग्रह हैं ताकि हम ICollection छोड़ सकें?

परिपत्र/अंगूठी बफर; सामान्य और समवर्ती?

@karelz नामकरण समस्या का समाधान IPriorityQueue जैसा कुछ हो सकता है जैसे DataFlow उत्पादन/उपभोक्ता पैटर्न के लिए करता है। प्राथमिकता कतार को लागू करने के कई तरीके और यदि आपको इसकी परवाह नहीं है तो इंटरफ़ेस का उपयोग करें। कार्यान्वयन के बारे में परवाह है या एक उदाहरण बना रहे हैं कार्यान्वयन वर्ग का उपयोग करें।

क्या आप इस बारे में अधिक जानकारी दे सकते हैं कि यह बाद में गन्दा क्यों होगा? आपकी क्या चिंताएं हैं?
PriorityQueue एक अवधारणा है जिसका लोग उपयोग करते हैं। इस तरह नामित एक प्रकार का होना उपयोगी है, है ना? [...] मैं धीरे-धीरे IHeap + ArrayHeap के विचार को गर्म कर रहा हूं, लेकिन अभी तक पूरी तरह आश्वस्त नहीं हूं ...

@karelz मेरे अनुभव से, मुझे एक अमूर्त होना वास्तव में महत्वपूर्ण लगता है ( IPriorityQueue या IHeap )। इस तरह के दृष्टिकोण के लिए धन्यवाद एक डेवलपर कोड लिख सकता है जो डिकूप्ड है। क्योंकि यह एक इंटरफेस (एक विशिष्ट कार्यान्वयन के बजाय) के खिलाफ लिखा गया है, इसमें अधिक लचीलापन और आईओसी भावना है। ऐसे कोड के लिए यूनिट परीक्षण लिखना बहुत आसान है (निर्भरता इंजेक्शन होने से कोई भी अपने नकली IPriorityQueue या IHeap को इंजेक्ट कर सकता है और देख सकता है कि किस समय और किस तर्क के साथ कौन से तरीकों को बुलाया जाता है)। एब्स्ट्रक्शन अच्छे हैं।

यह सच है कि "प्राथमिकता कतार" शब्द का प्रयोग आमतौर पर किया जाता है। समस्या यह है कि प्राथमिकता कतार को प्रभावी ढंग से लागू करने का एक ही तरीका है - एक ढेर के साथ। ढेर सारे प्रकार के ढेर। तो हमारे पास हो सकता है:

class ArrayHeap : IPriorityQueue {}
class PairingHeap : IPriorityQueue {}
class FibonacciHeap : IPriorityQueue {}
class BinomialHeap : IPriorityQueue {}

या

class ArrayHeap : IHeap {}
class PairingHeap : IHeap {}
class FibonacciHeap : IHeap {}
class BinomialHeap : IHeap {}

मेरे लिए, दूसरा दृष्टिकोण बेहतर दिखता है। आप इसके बारे में कैसा महसूस करते हैं?

PriorityQueue वर्ग के संबंध में - मुझे लगता है कि यह बहुत अस्पष्ट होगा और पूरी तरह से इस तरह के वर्ग के खिलाफ है। एक अस्पष्ट इंटरफ़ेस अच्छा है, लेकिन कार्यान्वयन नहीं। यदि यह एक बाइनरी ढेर है, तो बस इसे BinaryHeap कॉल करें। अगर यह कुछ और है, तो उसी के अनुसार नाम दें।

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

आइए एक ढेर को एक ढेर नाम दें।

@benaadams उनमें से प्रत्येक को इसे CoreFX में बनाना है (यानी इसे CoreFX कोड के लिए ही मूल्यवान होना चाहिए, या इसे उतना ही बुनियादी और व्यापक रूप से उपयोग किया जाना चाहिए जितना हमारे पास पहले से है) - हमने हाल ही में उन चीजों पर काफी चर्चा की है। . अभी भी 100% आम सहमति नहीं है, लेकिन कोई भी CoreFX में और संग्रह जोड़ने के लिए उत्सुक नहीं है।

सबसे संभावित परिणाम (पक्षपाती दावा, क्योंकि मुझे समाधान पसंद है) यह है कि हम एक और रेपो बनाएंगे और इसे PowerCollections के साथ प्राइम करेंगे और फिर समुदाय को हमारी टीम से कुछ बुनियादी मार्गदर्शन/निगरानी के साथ इसका विस्तार करने देंगे।
BTW: @terrajobst को लगता है कि यह इसके लायक नहीं है ("हमारे पास करने के लिए पारिस्थितिकी तंत्र में बेहतर और अधिक प्रभावशाली चीजें हैं") और हमें समुदाय को इसे पूरी तरह से चलाने के लिए प्रोत्साहित करना चाहिए (मौजूदा PowerCollections के साथ शुरू करें) और इसे हमारे में से एक नहीं बनाना चाहिए रेपो - कुछ हालांकि हमारे सामने चर्चा और निर्णय।
// मुझे लगता है कि हमारे विचार करने से पहले समुदाय के लिए इस समाधान पर कूदने का अवसर है ;-)। इससे चर्चा (और मेरी वरीयता) मूक हो जाएगी ;-)

@pgolebiowski आप धीरे-धीरे मुझे Heap का होना PriorityQueue से बेहतर है - हमें केवल मजबूत मार्गदर्शन और दस्तावेज़ों की आवश्यकता होगी "इस तरह आप PriorityQueue - Heap उपयोग करें

हालांकि, मैं CoreFX में 1 से अधिक हीप कार्यान्वयन को शामिल करने में बहुत संकोच कर रहा हूं। 98%+ 'सामान्य' सी # डेवलपर्स की परवाह नहीं है। वे यह सोचना भी नहीं चाहते कि कौन सा सबसे अच्छा है, उन्हें बस कुछ ऐसा चाहिए जो काम पूरा करे। प्रत्येक SW के प्रत्येक टुकड़े को उच्च-प्रदर्शन को ध्यान में रखकर डिज़ाइन नहीं किया गया है, ठीक ही ऐसा है। सभी एकतरफा टूल, UI ऐप्स आदि के बारे में सोचें। जब तक आप उच्च-प्रदर्शन स्केलिंग-आउट सिस्टम डिज़ाइन नहीं कर रहे हैं, जहां यह डीएस महत्वपूर्ण पथ पर है, आपको परवाह नहीं करनी चाहिए।

उसी तरह, मुझे परवाह नहीं है कि SortedDictionary या ArrayList या अन्य डीएस कैसे लागू किए जाते हैं - वे अपना काम शालीनता से करते हैं। मैं (कई अन्य) समझता हूं कि अगर मुझे अपने परिदृश्यों के लिए इन डीएस में से उच्च-परफ की आवश्यकता मेरे परिदृश्यों के लिए पर्याप्त

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

उस ने कहा, एक इंटरफ़ेस होने पर IHeap (जैसे IDictionary और IReadOnlyDictionary ), समझ में आ सकता है - मुझे इसके बारे में थोड़ा और सोचना होगा / एपीआई समीक्षा विशेषज्ञों से पूछना होगा स्थान ...

हमारे पास पहले से ही (कुछ हद तक) है जो @pgolebiowski ISet<T> और HashSet<T> । मैं कहता हूं बस इसे दर्पण करो। तो उपरोक्त एपीआई को एक इंटरफ़ेस ( IPriorityQueue<T> ) में बदल दिया गया है और फिर हमारे पास एक कार्यान्वयन ( HeapPriorityQueue<T> ) है जो आंतरिक रूप से एक ढेर का उपयोग करता है जो सार्वजनिक रूप से अपनी कक्षा के रूप में उजागर हो सकता है या नहीं।

क्या इसे ( PriorityQueue<T> ) भी IList<T> लागू करना चाहिए?

@karelz ICollection साथ मेरी समस्या SyncRoot और IsSynchronized ; या तो उन्हें लागू किया जाता है जिसका अर्थ है कि लॉक ऑब्जेक्ट के लिए अतिरिक्त आवंटन है; या वे फेंक देते हैं, जब उनका होना थोड़ा व्यर्थ होता है।

@benaadams यह भ्रामक होगा। चूंकि प्राथमिकता कतारों के 99.99% कार्यान्वयन सरणी पर आधारित ढेर हैं (और जैसा कि मैं देख सकता हूं कि हम यहां भी एक के साथ जा रहे हैं), क्या इसका मतलब सरणी की आंतरिक संरचना तक पहुंच को उजागर करना होगा?

मान लें कि हमारे पास 4, 8, 10, 13, 30, 45 तत्वों के साथ एक ढेर है। आदेश को ध्यान में रखते हुए, उन्हें 0, 1, 2, 3, 4, 5 इंडेक्स द्वारा एक्सेस किया जाएगा। हालांकि, ढेर की आंतरिक संरचना है [4, 8, 30, 10, 13, 45] (बाइनरी में, चतुर्धातुक में यह अलग होगा)।

• इंडेक्स i पर आंतरिक नंबर लौटाना वास्तव में उपयोगकर्ता के दृष्टिकोण से कोई मतलब नहीं रखता है, क्योंकि यह लगभग मनमाना है।
• किसी संख्या को क्रम में लौटाना (प्राथमिकता के आधार पर) बहुत महंगा है -- यह रैखिक है।
• इनमें से किसी एक को वापस करना वास्तव में अन्य कार्यान्वयन में समझ में नहीं आता है। अक्सर यह केवल i तत्वों को पॉप कर रहा है, i -th तत्व प्राप्त कर रहा है, और फिर उन्हें एक बार फिर से धक्का दे रहा है।

IList<T> आम तौर पर इसके लिए चुटीला समाधान है: मैं अपने एपीआई द्वारा स्वीकार किए गए संग्रह के साथ लचीला होना चाहता हूं, और मैं उन्हें गिनना चाहता हूं लेकिन IEnumerable<T> माध्यम से आवंटित नहीं करना चाहता

बस एहसास हुआ कि इसके लिए कोई सामान्य इंटरफ़ेस नहीं है

ICollection<T>
{
    int Count
    CopyTo(T[], int index)
}

तो उस बारे में कभी भी ध्यान न दें 😢 (हालांकि इसकी तरह IReadOnlyCollection)

लेकिन एन्यूमरेटर पर रीसेट को स्पष्ट रूप से लागू किया जाना चाहिए क्योंकि यह खराब है और इसे फेंक देना चाहिए।

तो मेरे सुझाए गए परिवर्तन

public bool TryDequeue(out T item);     // Add
public bool TryPeek(out T item);        // Add

public struct Enumerator : IEnumerator<T>
{
    public T Current { get; }
    object IEnumerator.Current { get; }
    public bool MoveNext();
    void IEnumerator.Reset();             // Explicit
    public void Dispose();
}

चूंकि आप विधियों पर चर्चा कर रहे हैं... हम अभी तक IHeap बनाम IPriorityQueue बात पर सहमत नहीं हुए हैं - यह विधियों के नाम और तर्क को थोड़ा प्रभावित करता है। हालांकि, किसी भी तरह से, मुझे वर्तमान एपीआई प्रस्ताव में निम्नलिखित गायब हैं:

• कतार से एक निश्चित तत्व को हटाने की क्षमता
• किसी तत्व की प्राथमिकता को अद्यतन करने की क्षमता
• इन संरचनाओं को मिलाने की क्षमता

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

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

आपके क्या विचार हैं दोस्तों?

IHeapNode clr प्रकार KeyValuePair से बहुत अलग नहीं है?

हालाँकि यह तब प्राथमिकता को अलग कर रहा है और अब यह PriorityQueue<TKey, TValue> साथ IComparer<TKey> comparer ?

KeyValuePair न केवल एक संरचना है बल्कि इसके गुण केवल पढ़ने के लिए हैं। यह मूल रूप से संरचना के अद्यतन होने पर हर बार एक नई वस्तु बनाने के बराबर होगा।

केवल एक कुंजी का उपयोग करना समान कुंजियों के साथ काम नहीं करता है -- यह जानने के लिए अधिक जानकारी की आवश्यकता है कि किस तत्व को अद्यतन/निकालना है।

IHeapNode और ArrayHeapNode :

    /// <summary>
    /// Represents a heap node. It is a wrapper around a key and a value.
    /// </summary>
    public interface IHeapNode<out TKey, out TValue>
    {
        /// <summary>
        /// Gets the key for the value.
        /// </summary>
        TKey Key { get; }

        /// <summary>
        /// Gets the value contained in the node.
        /// </summary>
        TValue Value { get; }
    }

    /// <summary>
    /// Represents a node of an <see cref="ArrayHeap{TKey,TValue}"/>.
    /// </summary>
    public class ArrayHeapNode<TKey, TValue> : IHeapNode<TKey, TValue>
    {
        /// <inheritdoc cref="IHeapNode{TKey,TValue}.Key"/>
        public TKey Key { get; internal set; }

        /// <inheritdoc cref="IHeapNode{TKey,TValue}.Value"/>
        public TValue Value { get; }

        /// <summary>
        /// The index of the node within an <see cref="ArrayHeap{TKey,TValue}"/>.
        /// </summary>
        public int Index { get; internal set; }

        /// <summary>
        /// Initializes a new instance of the <see cref="ArrayHeapNode{TKey,TValue}"/> class,
        /// containing the specified value.
        /// </summary>
        public ArrayHeapNode(TKey key, TValue value, int index)
        {
            this.Key = key;
            this.Value = value;
            this.Index = index;
        }
    }

और ArrayHeap भीतर अद्यतन विधि:

        /// <inheritdoc cref="IHeap{TKey,TValue}.Update"/>
        public override void Update(ArrayHeapNode<TKey, TValue> node, TKey key)
        {
            if (node == null)
                throw new ArgumentNullException(nameof(node));

            var relation = this.Comparer.Compare(key, node.Key);
            node.Key = key;

            if (relation < 0)
                this.MoveUp(node);
            else
                this.MoveDown(node);
        }

लेकिन अब हीप में प्रत्येक तत्व एक अतिरिक्त वस्तु है; क्या होगा यदि मुझे प्रायोरिटी क्यू व्यवहार चाहिए लेकिन मुझे ये अतिरिक्त आवंटन नहीं चाहिए?

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

साथ ही, हर दूसरे ढेर कार्यान्वयन में - तत्व स्पष्ट रूप से केवल नोड्स हैं। यह अन्य मामलों में पूरी तरह से स्वाभाविक है, यहां यह थोड़ा कृत्रिम है, लेकिन अद्यतन/निकालने के लिए आवश्यक है।

जावा में प्राथमिकता कतार में तत्वों को अद्यतन करने का विकल्प नहीं होता है। नतीजा:

• Java की प्रायोरिटी क्यू में चेंज प्रायोरिटी मेथड का अभाव क्यों है?
• जावा प्राथमिकता कतार अद्यतन समस्या
• प्राथमिकता कतार / ढेर अद्यतन

जब मैंने एल्गोकिट परियोजना के लिए ढेर लागू किया और इन सभी डिजाइन समस्याओं में आया तो मैंने सोचा कि यही कारण है कि .NET के लेखकों ने इस तरह की बुनियादी डेटा संरचना को ढेर (या प्राथमिकता कतार) के रूप में जोड़ने का फैसला नहीं किया। क्योंकि न तो डिजाइन अच्छा है। प्रत्येक की अपनी कमियां हैं।

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

यदि आप किसी अन्य वस्तु के साथ किसी सरणी में तत्वों को लपेटने के बारे में बुरा महसूस करते हैं - यह एकमात्र समस्या नहीं है। एक और विलय हो रहा है। सरणी-आधारित ढेर के साथ, यह पूरी तरह से अक्षम है। हालाँकि... यदि हम पेयरिंग हीप डेटा संरचना का उपयोग करते हैं ( पेयरिंग हीप: स्व-समायोजन हीप का एक नया रूप ), तो:

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

असल में, हम इसे निम्नलिखित तरीके से हल कर सकते हैं:

• IHeap इंटरफ़ेस जोड़ें जो सभी विधियों का समर्थन करता है
• उन सभी हैंडल के साथ ArrayHeap और PairingHeap , अपडेट करना, हटाना, मर्ज करना
• PriorityQueue जो एपीआई को सरल बनाने के लिए ArrayHeap आसपास सिर्फ एक रैपर है

PriorityQueue System.Collections.Generic और सभी ढेर System.Collections.Specialized ।

काम करता है?

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

यही कारण है कि मैं HeapNode वर्ग का प्रशंसक नहीं हूं। इमो उस तरह की चीज केवल आंतरिक होनी चाहिए और यदि संभव हो तो एपीआई को पहले से मौजूद मौजूदा प्रकार का पर्दाफाश करना चाहिए - इस मामले में केवीपी शायद।

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

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

उपयोगकर्ता डेटा संरचना में तत्वों की प्राथमिकताओं को अद्यतन करने में सक्षम नहीं होंगे।

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

        public override void Update(ArrayHeapNode<TKey, TValue> node, TKey key)
        {

        }

आपके पास उदाहरण होगा

        public override void Update(TKey item, TValue priority)
        {

        }

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

void Update(TKey item, TValue priority)

पहला -- आपके कोड में TKey और TValue क्या है? यह कैसे काम करना चाहिए? कंप्यूटर विज्ञान में सम्मेलन यह है कि:

• कुंजी = प्राथमिकता
• value = जो भी आप किसी तत्व में स्टोर करना चाहते हैं

दूसरा:

इमो अधिकांश लोग डिफ़ॉल्ट प्राथमिकता प्रकार का उपयोग करने जा रहे हैं और टीवीएल्यू एक अनावश्यक विशिष्टता होगी।

कृपया "डिफ़ॉल्ट प्राथमिकता प्रकार" को परिभाषित करें। मैं महसूस कर सकता हूं कि आप केवल PriorityQueue<T> , क्या यह सही है? यदि ऐसा है, तो इस तथ्य पर विचार करें कि एक उपयोगकर्ता को अपनी प्राथमिकता और मूल्य के आसपास एक नया वर्ग, एक आवरण बनाना होगा, साथ ही IComparable जैसे कुछ लागू करना होगा या एक कस्टम तुलनित्र प्रदान करना होगा। बहुत गरीब।

पहला -- आपके कोड में TKey और TValue क्या है?

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

मुद्दा यह है कि एक अद्यतन विधि को उजागर करने के लिए एक नोड वर्ग को उजागर करने की आवश्यकता नहीं है।

कृपया "डिफ़ॉल्ट प्राथमिकता प्रकार" को परिभाषित करें। मैं महसूस कर सकता हूं कि आप केवल प्रायोरिटी क्यू रखना चाहते हैं, क्या वह सही है?

हां। हालाँकि इस सूत्र को फिर से पढ़कर, मैं पूरी तरह से आश्वस्त नहीं हूँ कि यह मामला है।

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

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

मुझे लगता है कि इस प्रकार को PriorityQueue<T> कहा जाना चाहिए, न कि Heap<T> , ArrayHeap<T> या यहां तक ​​कि QuaternaryHeap<T> को शेष .Net के अनुरूप रहने के लिए कहा जाना चाहिए:

• हमारे पास List<T> , न कि ArrayList<T> ।
• हमारे पास Dictionary<K, V> , न कि HashTable<K, V> ।
• हमारे पास ImmutableList<T> , न कि ImmutableAVLTreeList<T> ।
• हमारे पास Array.Sort() , न कि Array.IntroSort() ।

ऐसे प्रकार के उपयोगकर्ता आमतौर पर परवाह नहीं करते कि उन्हें कैसे कार्यान्वित किया जाता है, यह निश्चित रूप से प्रकार के बारे में सबसे प्रमुख बात नहीं होनी चाहिए।

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

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

सारांश एपीआई में तुलना प्रदान किए गए तुलनाकर्ता IComparer<T> comparer द्वारा प्रदान की जाती है, किसी रैपर की आवश्यकता नहीं होती है। अक्सर प्राथमिकता प्रकार का हिस्सा होगी जैसे एक समय अनुसूचक के पास प्रकार की संपत्ति के रूप में निष्पादन समय होगा।

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

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

@svick

मुझे लगता है कि इस प्रकार को PriorityQueue<T> कहा जाना चाहिए, न कि Heap<T> , ArrayHeap<T> या यहां तक ​​कि QuaternaryHeap<T> को शेष .Net के अनुरूप रहने के लिए कहा जाना चाहिए।

मेरा मानवता पर से विश्वास उठ रहा है।

• डेटा संरचना को कॉल करना PriorityQueue बाकी .NET के साथ संगत किया जा रहा है और इसे Heap कॉल करना नहीं है? ढेर में कुछ गड़बड़ है? उसी तरह ढेर और कतारों पर लागू होना चाहिए।
• ArrayHeap -> QuaternaryHeap लिए बेस क्लास। बहुत बड़ा फर्क।
• चर्चा कोई अच्छा नाम लेने की नहीं है। एक निश्चित डिज़ाइन पथ का अनुसरण करने के परिणामस्वरूप बहुत सारी चीज़ें आ रही हैं। कृपया धागे को दोबारा पढ़ें।
• हैशटेबल , ऐरेलिस्ट । उनका अस्तित्व प्रतीत होता है। बीटीडब्लू, एक "सूची" आईएमओ नामकरण का एक बहुत बुरा विकल्प है, क्योंकि उपयोगकर्ता का पहला विचार यह है कि List एक सूची है, लेकिन यह एक सूची नहीं है। मैं
• यह मज़े करने और यह कहने के बारे में नहीं है कि किसी चीज़ को कैसे लागू किया जाता है। यह सार्थक नाम देने के बारे में है जो उपयोगकर्ताओं को तुरंत दिखाता है कि वे किसके साथ काम कर रहे हैं।

बाकी .NET के साथ संगत रहना चाहते हैं और इस तरह की समस्याओं में भाग लेना चाहते हैं?

• SortedList और SortedDictionary में क्या अंतर है? .

और मैं वहां क्या देखता हूं... जॉन स्कीट ने कहा कि SortedDictionary को SortedTree कहा जाना चाहिए क्योंकि यह कार्यान्वयन को अधिक बारीकी से दर्शाता है।

@pgolebiowski

ढेर में कुछ गड़बड़ है?

हां, यह कार्यान्वयन का वर्णन करता है, उपयोग का नहीं।

उसी तरह ढेर और कतारों पर लागू होना चाहिए।

न तो वास्तव में कार्यान्वयन का वर्णन करता है, उदाहरण के लिए नाम आपको यह नहीं बताता कि वे सरणी-आधारित हैं।

ArrayHeap -> QuaternaryHeap लिए बेस क्लास। बहुत बड़ा फर्क।

हां, मैं आपका डिजाइन समझता हूं। मैं जो कह रहा हूं वह यह है कि इसमें से कोई भी उपयोगकर्ता के सामने नहीं आना चाहिए।

एक निश्चित डिज़ाइन पथ का अनुसरण करने के परिणामस्वरूप बहुत सारी चीज़ें आ रही हैं। कृपया धागे को दोबारा पढ़ें।

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

यदि डिफ़ॉल्ट कार्यान्वयन उनके लिए पर्याप्त नहीं है, तो वहीं अन्य पुस्तकालय (जैसे आपके स्वयं के) आते हैं।

हैशटेबल, ArrayList. उनका अस्तित्व प्रतीत होता है।

हां, वे .Net Framework 1.0 वर्ग हैं जिनका अब कोई उपयोग नहीं करता है। जहां तक ​​मैं बता सकता हूं, उनके नाम जावा से कॉपी किए गए थे और नेट फ्रेमवर्क 2.0 डिजाइनरों ने उस सम्मेलन का पालन नहीं करने का फैसला किया। मेरी राय में यह सही फैसला था।

बीटीडब्लू, एक "सूची" आईएमओ नामकरण का एक बहुत बुरा विकल्प है, क्योंकि उपयोगकर्ता का पहला विचार यह है कि List एक सूची है, लेकिन यह एक सूची नहीं है।

यह है। यह एक लिंक्ड सूची नहीं है, लेकिन यह वही बात नहीं है। और मुझे हर जगह ArrayList या ResizeArray (F# का नाम List<T> ) लिखना पसंद नहीं है।

यह सार्थक नाम देने के बारे में है जो उपयोगकर्ताओं को तुरंत दिखाता है कि वे किसके साथ काम कर रहे हैं।

यदि वे QuaternaryHeap देखते हैं तो अधिकांश लोगों को पता नहीं होगा कि वे क्या व्यवहार कर रहे हैं। दूसरी ओर, यदि वे PriorityQueue देखते हैं, तो यह स्पष्ट होना चाहिए कि वे किसके साथ काम कर रहे हैं, भले ही उनके पास कोई सीएस पृष्ठभूमि न हो। उन्हें यह नहीं पता होगा कि कार्यान्वयन क्या है, लेकिन दस्तावेज़ीकरण इसी के लिए है।

@ianhays

पहला -- आपके कोड में TKey और TValue क्या है?

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

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

मुद्दा यह है कि एक अद्यतन विधि को उजागर करने के लिए एक नोड वर्ग को उजागर करने की आवश्यकता नहीं है।

मेरा मानना ​​​​है कि यह है: देशी पुस्तकालयों में कमी-कुंजी/वृद्धि-कुंजी समर्थन । इस विषय पर भी, इसलिए डेटा संरचनाओं से निपटने के लिए सहायक वर्ग शामिल हैं:

• LinkedListNode
• DictionaryEntry

मुझे लगता है कि उचित मात्रा में उपयोगकर्ताओं को कस्टम तुलनित्र तर्क के साथ एक रैपर प्रकार बनाना होगा। मुझे लगता है कि ऐसे उपयोगकर्ताओं की एक उचित मात्रा भी है जिनके पास पहले से एक तुलनीय प्रकार है जिसे वे प्राथमिकता में रखना चाहते हैं या एक परिभाषित तुलनित्र के साथ एक प्रकार। सवाल यह है कि दोनों में से कौन सा कैंप बड़ा है।

मैं दूसरों के बारे में नहीं जानता, लेकिन मुझे हर बार कस्टम तुलनित्र तर्क के साथ एक रैपर बनाना पड़ता है जब मैं प्राथमिकता कतार का उपयोग बहुत भयानक होने के लिए करना चाहता हूं ...

एक और विचार - मान लें कि मैंने एक रैपर बनाया है:

class Wrapper
{
    public int Priority { get; set; }
    public string SomeStuff ...
}

मैं इस प्रकार के साथ PriorityQueue<T> फ़ीड करता हूं। इसलिए यह इसके आधार पर अपने तत्वों को प्राथमिकता देता है। मान लीजिए कि इसने कुछ प्रमुख चयनकर्ताओं को परिभाषित किया है। ऐसा डिज़ाइन ढेर के आंतरिक कार्य को क्रैश कर सकता है। आप किसी भी समय प्राथमिकताएं बदल सकते हैं क्योंकि आप तत्व के स्वामी हैं। ढेर को अद्यतन करने के लिए कोई सूचना तंत्र नहीं है। आप उस सब को संभालने और उसे कॉल करने के लिए जिम्मेदार होंगे। मेरे लिए बहुत खतरनाक और सीधे-सीधे नहीं।

मेरे द्वारा प्रस्तावित हैंडल के मामले में - उपयोगकर्ता के दृष्टिकोण से प्रकार अपरिवर्तनीय था। और विशिष्टता के साथ कोई समस्या नहीं थी।

IMO मुझे एक IHeap इंटरफ़ेस और फिर उस इंटरफ़ेस को लागू करने वाले क्लास API का विचार पसंद है। मैं इस पर @ianhays के साथ एपिस को उजागर नहीं करने जा रहे हैं क्योंकि एक एपीआई समीक्षा प्रक्रिया की आवश्यकता होगी और हम PriorityQueue पर ध्यान केंद्रित करना चाहेंगे।

दूसरा मुझे लगता है कि कतार में मूल्यों को संग्रहीत करने के लिए नोड आंतरिक/सार्वजनिक वर्ग होने की कोई आवश्यकता नहीं है। अतिरिक्त आवंटन की कोई आवश्यकता नहीं है, हम कुछ प्रकार का अनुसरण कर सकते हैं जो IDictionary करता है और संख्यात्मक बनाने के लिए मूल्यों को उत्पन्न करते समय KeyValuePairवस्तुओं अगर हम प्रत्येक आइटम के लिए प्राथमिकता रखने के विकल्प के लिए जाते हैं (जो मुझे नहीं लगता कि यह जाने का सबसे अच्छा तरीका है, मैं प्रति आइटम प्राथमिकता को संग्रहीत करने के लिए पूरी तरह से आश्वस्त नहीं हूं)। सबसे अच्छा तरीका जो मैं चाहूंगा वह होगा PriorityQueue<T> (यह नाम सिर्फ इसे देने के लिए है)। इस दृष्टिकोण के साथ हमारे पास एक कंस्ट्रक्टर हो सकता है जो पूरे बीसीएल IComparer<T> साथ करता है और प्राथमिकता देने के लिए उस तुलनाकर्ता के साथ तुलना कर रहा है। पैरामीटर के रूप में प्राथमिकता को पारित करने वाले एपीआई को उजागर करने की कोई आवश्यकता नहीं है।

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

नाम वे हैं जो वे करते हैं, न कि वे इसे कैसे करते हैं।

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

उसी तरह ढेर और कतारों पर लागू होना चाहिए।

Stack एक असीमित आकार बदलने वाला सरणी है और Queue एक असीमित आकार बदलने वाले सर्कुलर बफर के रूप में कार्यान्वित किया जाता है। उनका नाम उनकी अमूर्त अवधारणाओं के नाम पर रखा गया है। स्टैक (सार डेटा प्रकार) : लास्ट-इन-फर्स्ट-आउट (LIFO), क्यू (सार डेटा प्रकार) : फर्स्ट-इन-फर्स्ट-आउट (फीफो)

हैशटेबल, ArrayList. उनका अस्तित्व प्रतीत होता है।

शब्दकोश प्रविष्टि

हाँ, लेकिन दिखावा करते हैं कि वे नहीं करते हैं; वे कम सभ्य समय की कलाकृतियाँ हैं। यदि आप प्राइमेटिव या स्ट्रक्चर का उपयोग करते हैं तो उनके पास कोई प्रकार की सुरक्षा और बॉक्स नहीं है; इसलिए प्रत्येक ऐड पर आवंटित करें।

आप @terrajobst के प्लेटफ़ॉर्म संगतता विश्लेषक का उपयोग कर सकते हैं और यह आपको बताएगा: "कृपया ऐसा न करें"

सूची एक सूची है, लेकिन यह एक सूची नहीं है

यह वास्तव में एक सूची (सार डेटा प्रकार) है जिसे अनुक्रम के रूप में भी जाना जाता है।

समान रूप से प्राथमिकता कतार एक सार प्रकार है जो आपको बताती है कि यह उपयोग में क्या हासिल करता है; कार्यान्वयन में यह कैसे नहीं करता है (क्योंकि कई अलग-अलग कार्यान्वयन हो सकते हैं)

बहुत बढ़िया चर्चा!

मूल विनिर्देश कुछ मूल सिद्धांतों को ध्यान में रखकर तैयार किया गया था:

• सामान्य उद्देश्य - अधिकांश उपयोग के मामलों को सीपीयू और मेमोरी खपत के बीच संतुलन के साथ कवर करें।
• जितना संभव हो सके, System.Collections.Generic में मौजूदा पैटर्न और परंपराओं के साथ संरेखित करें।
• एक ही तत्व की कई प्रविष्टियों की अनुमति दें।
• मौजूदा बीसीएल तुलना इंटरफेस और कक्षाओं का उपयोग करें (यानी तुलनाकर्ता)*
• उच्च स्तर की अमूर्तता - विनिर्देश उपभोक्ताओं को अंतर्निहित कार्यान्वयन तकनीक से बचाने के लिए डिज़ाइन किया गया है।

@karelz @pgolebiowski
"हीप" का नाम बदलना या डेटा संरचना कार्यान्वयन से जुड़ा कोई अन्य शब्द संग्रह के लिए अधिकांश बीसीएल सम्मेलनों से मेल नहीं खाएगा। ऐतिहासिक रूप से, .NET संग्रह कक्षाओं को विशिष्ट डेटा संरचना/पैटर्न पर ध्यान केंद्रित करने के बजाय सामान्य उद्देश्य के लिए डिज़ाइन किया गया है। मेरी मूल सोच यह थी कि .NET पारिस्थितिकी तंत्र की शुरुआत में एपीआई डिजाइनर जानबूझकर "ArrayList" से "List ." में चले गए थे"। परिवर्तन एक ऐरे के साथ एक भ्रम के कारण होने की संभावना थी - आपके औसत डेवलपर ने सोचा होगा "ArrayList? मुझे सिर्फ एक सूची चाहिए, एक सरणी नहीं"।

यदि हम हीप के साथ जाते हैं, तो ऐसा ही हो सकता है - कई मध्यवर्ती-कुशल डेवलपर्स (दुख की बात है) "हीप" देखेंगे और इसे "सामान्यीकृत डेटा संरचना को ढेर" के बजाय एप्लिकेशन के मेमोरी हीप (यानी हीप और स्टैक) के लिए भ्रमित करेंगे। System.Collections.Generic की व्यापकता के कारण यह लगभग हर .NET डेवलपर के बुद्धिमान प्रस्ताव में दिखाई देगा, और उन्हें आश्चर्य होगा कि वे एक नया मेमोरी हीप क्यों आवंटित कर सकते हैं :)

प्रायोरिटी क्यू, तुलनात्मक रूप से, अधिक खोज योग्य है और भ्रम की संभावना कम है। आप "कतार" टाइप कर सकते हैं और प्रायोरिटी क्यू के लिए प्रस्ताव प्राप्त कर सकते हैं।

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

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

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

मेरे पास आप सभी ग्राहक कोड उदाहरण हैं - मेरी मूल योजना उदाहरणों के आधार के रूप में उपयोग करने के लिए प्रायोरिटी क्यू के मौजूदा बीसीएल कार्यान्वयन के माध्यम से जाना था।

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

प्रस्तावित ओपी एपीआई के तहत, कक्षा का उपयोग करने के लिए इनमें से एक को पूरा करने की आवश्यकता है:

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

दोहरे प्रकार के एपीआई का उद्देश्य दूसरे दो विकल्पों के बोझ को कम करना है, हाँ? जब आपके पास पहले से ही प्राथमिकता वाला प्रकार होता है तो एक नई प्राथमिकता क्यू/हीप का निर्माण कार्य कैसे होता

मेरा मानना ​​​​है कि यह है: देशी पुस्तकालयों में कमी-कुंजी/वृद्धि-कुंजी समर्थन।

public override void Update(ArrayHeapNode<TKey, TValue> node, TKey key) {}
public override void Update(TKey key, TValue value);

किसी भी मामले में, दी गई प्राथमिकता से जुड़े आइटम को अपडेट किया जाता है। अद्यतन करने के लिए ArrayHeapNode की आवश्यकता क्यों है? यह क्या हासिल करता है जिसे सीधे TKey/TValue लेकर पूरा नहीं किया जा सकता है?

@ianhays

किसी भी मामले में, दी गई प्राथमिकता से जुड़े आइटम को अपडेट किया जाता है। अद्यतन करने के लिए ArrayHeapNode की आवश्यकता क्यों है? यह क्या हासिल करता है जिसे सीधे TKey/TValue लेकर पूरा नहीं किया जा सकता है?

कम से कम बाइनरी हीप (जिससे मैं सबसे ज्यादा परिचित हूं) के साथ, यदि आप कुछ मूल्य की प्राथमिकता को अपडेट करना चाहते हैं और आप ढेर में इसकी स्थिति जानते हैं, तो आप इसे जल्दी से कर सकते हैं (ओ (लॉग एन) समय में)।

लेकिन अगर आप केवल मूल्य और प्राथमिकता जानते हैं, तो आपको सबसे पहले वह मान ढूंढना होगा, जो धीमा है (ओ (एन))।

दूसरी ओर, यदि आपको कुशलता से अपडेट करने की आवश्यकता नहीं है, तो ढेर में प्रति आइटम एक आवंटन शुद्ध ओवरहेड है।

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

दोहरे प्रकार के एपीआई का उद्देश्य दूसरे दो विकल्पों के बोझ को कम करना है, हाँ? जब आपके पास पहले से ही प्राथमिकता वाला प्रकार होता है तो एक नई प्राथमिकता क्यू/हीप का निर्माण कार्य कैसे होता है? एपीआई कैसा दिखता है?

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

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

मेरे लिए, वही सिद्धांत कतारों पर लागू होता है। एक कतार, ऐतिहासिक रूप से, एक आयामी डेटा संरचना है।

मेरा आधुनिक सी ++ एसटीडी पुस्तकालय ज्ञान स्वीकार्य रूप से थोड़ा जंगली है, लेकिन यहां तक ​​​​कि std::priority_queue में पुश, पॉप, और एक तुलनाकर्ता को एक टेम्पलेटेड (जेनेरिक) पैरामीटर के रूप में लेना प्रतीत होता है। सी ++ मानक लाइब्रेरी क्रू उतना ही संवेदनशील है जितना आप प्राप्त कर सकते हैं :)

मैंने अभी कुछ प्रोग्रामिंग भाषाओं में प्राथमिकता कतार और ढेर कार्यान्वयन का एक बहुत तेज़ स्कैन किया है - सी ++, जावा, जंग, और एक ही प्रकार के साथ सभी काम करें (यहां पोस्ट की गई मूल एपीआई के समान)। एनपीएम में सबसे लोकप्रिय ढेर/प्राथमिकता कतार कार्यान्वयन की एक सरसरी नज़र इसे दिखाती है।

@pgolebiowski मुझे गलत नहीं लगता उनके विशिष्ट कार्यान्वयन के बाद स्पष्ट रूप से नामित चीजों के विशिष्ट कार्यान्वयन होना चाहिए।

हालांकि ऐसा तब होता है जब आप जानते हैं कि आप कौन सी विशिष्ट डेटा संरचना चाहते हैं जो आपके प्रदर्शन लक्ष्यों से मेल खाती है और आपके द्वारा स्वीकार किए जाने वाले व्यापार बंद हैं।

आम तौर पर ढांचे के संग्रह में 90% उपयोग शामिल होते हैं जहां आप सामान्य व्यवहार चाहते हैं। फिर यदि आप एक बहुत विशिष्ट व्यवहार या कार्यान्वयन चाहते हैं तो आप शायद किसी तृतीय पक्ष पुस्तकालय के लिए जाएंगे; और उम्मीद है कि उन्हें कार्यान्वयन के नाम पर रखा जाएगा ताकि आप जान सकें कि यह आपकी ज़रूरत से मेल खाता है।

बस सामान्य व्यवहार प्रकारों को एक विशिष्ट कार्यान्वयन से जोड़ना नहीं चाहते हैं; तब के रूप में यह अजीब है अगर कार्यान्वयन बदलता है क्योंकि प्रकार का नाम वही रहना है और वे मेल नहीं खाएंगे।

ऐसी कई चिंताएँ हैं जिन पर चर्चा की आवश्यकता है, लेकिन आइए उस समस्या से शुरू करें जिसका वर्तमान में उन हिस्सों पर सबसे अधिक प्रभाव पड़ता है जिनके बारे में हम असहमत हैं: तत्वों को अद्यतन करना और निकालना ।

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

1. फ़ोरम पर बहुत सारे प्रश्न हैं कि अनुपलब्ध सुविधाओं के कारण वर्कअराउंड कैसे करें।
2. प्रथम-पक्ष कार्यान्वयन को प्रतिस्थापित करने के लिए ढेर/प्राथमिकता कतार के तीसरे पक्ष के कार्यान्वयन हैं, क्योंकि यह काफी बेकार है।

यह सिर्फ दयनीय है। क्या कोई है जो वास्तव में इस तरह से आगे बढ़ना चाहता है? मुझे ऐसी अक्षम डेटा संरचना जारी करने में शर्म आएगी।

@pgolebiowski निश्चिंत रहें कि यहां सभी के पास मंच के लिए सबसे अच्छे इरादे हैं। कोई भी टूटे हुए एपीआई को शिप नहीं करना चाहता। हम दूसरों की गलतियों से सीखना चाहते हैं, इसलिए कृपया ऐसी उपयोगी प्रासंगिक जानकारी लाते रहें (जैसे कि जावा कहानी को छोड़कर)।

हालाँकि, मैं दो बातों की ओर इशारा करना चाहता हूँ:

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

मैंने अभी पूछा है कि यदि आप प्रस्तावित दृष्टिकोण को पसंद नहीं करते हैं तो आप लोग अद्यतन/हटाने वाली चीज़ को कैसे डिज़ाइन करना चाहते हैं ... यह दूसरों को सुन रहा है और आम सहमति की तलाश में है, मुझे विश्वास है।

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

हीप बनाम प्रायोरिटी क्यू बहस पर मेरे दो सेंट: दोनों दृष्टिकोण मान्य हैं और स्पष्ट रूप से लाभ और कमियां हैं।

उस ने कहा, "PriorityQueue" मौजूदा .NET दृष्टिकोण के साथ कहीं अधिक सुसंगत लगता है। आज मुख्य संग्रह हैं List, शब्दकोश, ढेर, पंक्ति, हैशसेट, क्रमबद्ध शब्दकोश, और सॉर्टेडसेट. इनका नाम कार्यक्षमता और शब्दार्थ के नाम पर रखा गया है, एल्गोरिथम नहीं। हैशसेटएकमात्र बाहरी है, लेकिन यहां तक ​​​​कि इसे सेट समानता शब्दार्थ (सॉर्टेडसेट की तुलना में) से संबंधित के रूप में युक्तिसंगत बनाया जा सकता है) आखिरकार, अब हमारे पास ImmutableHashSet हैजो हुड के नीचे एक पेड़ पर आधारित है।

एक संग्रह के लिए यहां चलन को कम करना अजीब लगेगा।

मुझे लगता है कि अतिरिक्त कंस्ट्रक्टर के साथ प्रायोरिटी क्यू: प्रायोरिटी क्यू(आईहेप) समाधान हो सकता है। IHeap पैरामीटर के बिना कंस्ट्रक्टर डिफ़ॉल्ट हीप का उपयोग कर सकते हैं।
उस स्थिति में प्राथमिकता कतारसार डेटा प्रकार (अधिकांश C# संग्रह के रूप में) का प्रतिनिधित्व करेगा और IPriorityQueue को लागू करेगाइंटरफ़ेस लेकिन विभिन्न ढेर कार्यान्वयन का उपयोग कर सकते हैं जैसे @pgolebiowski ने सुझाव दिया:

वर्ग ArrayHeap : IHeap {}
क्लास पेयरिंगहीप : IHeap {}
क्लास फाइबोनैचिहीप: आईहेप {}
वर्ग द्विपद ढेर : IHeap {}

ठीक है। बहुत सारी अलग-अलग आवाजें हैं। मैंने फिर से चर्चा की और अपने दृष्टिकोण को परिष्कृत किया। मैं सामान्य चिंताओं को भी संबोधित करता हूं। नीचे दिया गया पाठ उपरोक्त पदों के उद्धरणों का उपयोग करता है।

हमारा लक्ष्य

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

• उच्चतम प्राथमिकता वाले तत्व को पुनः प्राप्त करें (और इसे हटाने में सक्षम हो)।
• संग्रह में एक नया तत्व जोड़ें।
• संग्रह से एक तत्व निकालें।
• संग्रह में एक तत्व को संशोधित करें।
• दो संग्रह मर्ज करें।

अन्य मानक पुस्तकालय

अन्य मानक पुस्तकालयों के लेखकों ने भी इस कार्यक्षमता का समर्थन करने का प्रयास किया है। इस खंड में, मैं इसका उल्लेख करूंगा कि इसे पायथन , जावा , सी ++ , गो , स्विफ्ट और रस्ट में कैसे हल किया गया था।

उनमें से कोई भी संग्रह में पहले से डाले गए तत्वों को संशोधित करने का समर्थन StackOverflow । यह इंटरनेट पर ऐसे अनेक प्रश्नों में से एक है। डिजाइनर विफल रहे हैं।

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

हम इससे क्या सीखते हैं?

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

प्रस्तावित दृष्टिकोण

मुझे दृढ़ता से लगता है कि हमें प्रदान करना चाहिए:

• IHeap<T> इंटरफ़ेस
• Heap<T> वर्ग

IHeap इंटरफ़ेस में स्पष्ट रूप से इस पोस्ट की शुरुआत में वर्णित सभी कार्यों को प्राप्त करने के तरीके शामिल होंगे। चतुर्धातुक ढेर के साथ कार्यान्वित Heap वर्ग, 98% मामलों में सबसे आसान समाधान होगा। तत्वों का क्रम कंस्ट्रक्टर में पारित IComparer<T> पर आधारित होगा या यदि कोई प्रकार पहले से तुलनीय है तो डिफ़ॉल्ट ऑर्डरिंग।

औचित्य

• डेवलपर्स एक इंटरफेस के खिलाफ अपना तर्क लिख सकते हैं। मुझे लगता है कि हर कोई जानता है कि यह कितना महत्वपूर्ण है और विवरण में नहीं जाएगा। पढ़ें: निर्भरता उलटा सिद्धांत , निर्भरता इंजेक्शन , अनुबंध द्वारा डिजाइन , नियंत्रण का उलटा ।
• डेवलपर्स अन्य ढेर कार्यान्वयन प्रदान करके अपनी कस्टम जरूरतों को पूरा करने के लिए इस कार्यक्षमता का विस्तार कर सकते हैं। इस तरह के कार्यान्वयन को PowerCollections जैसे तृतीय-पक्ष पुस्तकालयों में शामिल किया जा सकता है। ऐसी लाइब्रेरी का संदर्भ देकर, आप बस अपने कस्टम ढेर को किसी भी तर्क में इंजेक्ट कर सकते हैं जो इनपुट के रूप में IHeap लेता है। अन्य ढेरों के कुछ उदाहरण जो कुछ विशिष्ट परिस्थितियों में चतुर्धातुक ढेर से बेहतर व्यवहार करते हैं: बाँधना ढेर , द्विपद ढेर, और हमारे प्रिय द्विआधारी ढेर।
• यदि किसी डेवलपर को केवल एक उपकरण की आवश्यकता होती है जो बिना किसी आवश्यकता के काम पूरा कर लेता है, तो यह सोचने के लिए कि कौन सा प्रकार सबसे अच्छा है, वे सामान्य उद्देश्य Heap कार्यान्वयन का उपयोग कर सकते हैं। यह 98% उपयोग के मामलों की ओर अनुकूलन कर रहा है।
• हम बहुत ही सभ्य प्रदर्शन विशेषताओं के साथ सिंगल-ईश विकल्प की पेशकश के संबंध में .NET पारिस्थितिकी तंत्र के महान मूल्य में वृद्धि करते हैं, जो अधिकांश उपयोग के मामलों के लिए उपयोगी है, साथ ही उन लोगों के लिए उच्च-प्रदर्शन एक्सटेंशन की अनुमति देता है जिन्हें इसकी आवश्यकता है और खुदाई करने के इच्छुक हैं गहराई से और अधिक जानें / शिक्षित विकल्प और ट्रेडऑफ़ बनाएं।
• प्रस्तावित दृष्टिकोण वर्तमान सम्मेलनों को दर्शाता है:
  
  
  
  • ISet और HashSet
  
  
  • IList और List
  
  
  • IDictionary और Dictionary
  
  
• कुछ लोगों ने कहा है कि हमें उनके उदाहरणों के आधार पर कक्षाओं का नाम देना चाहिए, न कि वे इसे कैसे करते हैं। यह पूरी तरह से सच नहीं है। यह कहना एक सामान्य शॉर्टकट है कि हमें कक्षाओं का नाम उनके व्यवहार के अनुसार रखना चाहिए। यह वास्तव में कई मामलों में लागू होता है। हालांकि, ऐसे मामले हैं जहां यह उचित दृष्टिकोण नहीं है। सबसे उल्लेखनीय उदाहरण बुनियादी बिल्डिंग ब्लॉक हैं - जैसे आदिम प्रकार, एनम प्रकार या डेटा संरचनाएं। सिद्धांत केवल उन नामों को चुनना है जो अर्थपूर्ण हैं (यानी उपयोगकर्ता के लिए स्पष्ट)। इस तथ्य को ध्यान में रखें कि हम जिस कार्यक्षमता की चर्चा कर रहे हैं वह हमेशा एक ढेर के रूप में प्रदान की जाती है - चाहे वह पायथन, जावा, सी ++, गो, स्विफ्ट या रस्ट हो। हीप सबसे प्राथमिक डेटा संरचनाओं में से एक है। Heap वास्तव में स्पष्ट और स्पष्ट है। यह Stack , Queue , List , और Array अनुरूप भी है। नामकरण के साथ एक ही दृष्टिकोण सबसे आधुनिक मानक पुस्तकालयों (गो, स्विफ्ट, रस्ट) में लिया गया था - वे स्पष्ट रूप से एक ढेर को उजागर करते हैं।

@pgolebiowski मैं नहीं देख रहा हूँ कि कैसे Heap<T> / IHeap<T> को Stack<T> , Queue<T> , और/या List<T> ? उन नामों में से कोई भी यह नहीं बताता है कि उन्हें आंतरिक रूप से कैसे कार्यान्वित किया जाता है (टी की एक सरणी जैसा होता है)।

@ सैमुएलइंग्लार्ड

Heap यह नहीं बताता कि इसे आंतरिक रूप से कैसे कार्यान्वित किया जाता है। मैं यह समझने में विफल हूं कि इतने सारे लोगों के लिए एक ढेर तुरंत एक विशिष्ट कार्यान्वयन का पालन क्यों करता है। ढेर के कई प्रकार हैं जो एक ही एपीआई साझा करते हैं, शुरू करने के लिए:

• डी-आरी ढेर,
• 2-3 ढेर,
• वामपंथी ढेर,
• नरम ढेर,
• कमजोर ढेर,
• बी-ढेर,
• मूलांक ढेर,
• तिरछा ढेर,
• ढेर जोड़ना,
• फाइबोनैचि ढेर,
• द्विपद ढेर,
• रैंक-पेयरिंग ढेर,
• भूकंप के ढेर,
• उल्लंघन ढेर।

यह कहना कि हम ढेर के साथ काम कर रहे हैं, अभी भी बहुत सारगर्भित है। वास्तव में, यहां तक ​​​​कि यह कहना कि हम एक चतुर्धातुक ढेर के साथ काम कर रहे हैं, सार है - इसे या तो T की एक सरणी के आधार पर एक अंतर्निहित डेटा संरचना के रूप में लागू किया जा सकता है (जैसे हमारे Stack<T> , Queue<T> , और List<T> ) या स्पष्ट (नोड्स और पॉइंटर्स का उपयोग करके)।

संक्षेप में, Heap<T> Stack<T> , Queue<T> , और List<T> , क्योंकि यह एक प्राथमिक डेटा संरचना है, एक बुनियादी सार बिल्डिंग ब्लॉक है, जो कई तरह से लागू किया जा सकता है। इसके अतिरिक्त, जैसा भी होता है, वे सभी नीचे T की एक सरणी का उपयोग करके कार्यान्वित किए जाते हैं। मुझे यह समानता बहुत मजबूत लगती है।

क्या इसका कोई मतलब है?

रिकॉर्ड के लिए, मैं नामकरण के प्रति उदासीन हूं। जो लोग C++ मानक पुस्तकालय का उपयोग करने के आदी हैं, वे शायद _priority_queue_ पसंद करेंगे। डेटा संरचनाओं के बारे में शिक्षित लोग _Heap_ पसंद कर सकते हैं। अगर मुझे वोट देना होता, तो मैं _heap_ चुनता, हालांकि यह मेरे लिए एक सिक्के के उछाल के करीब है।

@pgolebiowski मैंने अपने प्रश्न को गलत बताया, यह मेरा बुरा है। हां, Heap<T> यह नहीं बताता कि इसे आंतरिक रूप से कैसे कार्यान्वित किया जाता है।

हाँ हीप एक मान्य डेटा संरचना है, लेकिन हीप! = प्राथमिकता कतार। वे दोनों अलग-अलग एपीआई सतहों को उजागर करते हैं और विभिन्न विचारों के लिए उपयोग किए जाते हैं। Heap<T> / IHeap<T> डेटा प्रकार होना चाहिए जो आंतरिक रूप से (सिर्फ सैद्धांतिक नाम) PriorityQueue<T> / IPriorityQueue<T> ।

@ सैमुएलइंग्लार्ड
कंप्यूटर विज्ञान की दुनिया कैसे व्यवस्थित है, इसके संदर्भ में, हाँ। यहाँ अमूर्तता के स्तर हैं:

• कार्यान्वयन : एक सरणी के आधार पर निहित चतुर्धातुक ढेर
• अमूर्तता : चतुर्धातुक ढेर
• अमूर्तता : ढेर का परिवार
• अमूर्तता : प्राथमिकता कतारों का परिवार

और हाँ, IHeap और Heap , PriorityQueue का कार्यान्वयन मूल रूप से होगा:

public class PriorityQueue<T>
{
    private readonly IHeap<T> heap;

    public PriorityQueue(IHeap<T> heap)
    {
        this.heap = heap;
    }

    public void Add<T>(T item) => this.heap.Add(item);

    public void Remove<T>(T item) => this.heap.Remove(item);

    // etc...
}

आइए यहां एक निर्णय वृक्ष चलाते हैं।

एक प्राथमिकता कतार भी एक ढेर के कुछ रूपों (सैद्धांतिक रूप से) से भिन्न डेटा संरचना के साथ लागू की जा सकती है। यह PriorityQueue के डिज़ाइन को ऊपर वाले की तरह बदसूरत बनाता है, क्योंकि यह केवल ढेर के परिवार के लिए तय किया गया है। यह IHeap आसपास एक बहुत पतला आवरण भी है। यह एक प्रश्न उत्पन्न करता है - _ क्यों न केवल ढेर के परिवार का उपयोग करें_?

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

हम चर्चा के बीच से डिज़ाइन विकल्प के साथ वापस आ गए हैं - PriorityQueue और IPriorityQueue । लेकिन तब हम मूल रूप से होंगे:

class BinaryHeap : IPriorityQueue {}
class PairingHeap : IPriorityQueue {}
class FibonacciHeap : IPriorityQueue {}
class BinomialHeap : IPriorityQueue {}

न केवल बदसूरत लगता है, बल्कि वैचारिक रूप से भी गलत है - ये प्राथमिकता वाली कतारों के प्रकार नहीं हैं और एक ही एपीआई साझा नहीं करते हैं (जैसा कि @SamuelEnglard पहले ही नोट किया गया है)। मुझे लगता है कि हमें ढेरों से चिपके रहना चाहिए, एक ऐसा परिवार जो उनके लिए एक अमूर्तता रखने के लिए पर्याप्त है। हमें मिलेगा:

class BinaryHeap : IHeap {}
class PairingHeap : IHeap {}
class FibonacciHeap : IHeap {}
class BinomialHeap : IHeap {}

और, हमारे द्वारा प्रदान किया गया, class Heap : IHeap {} ।

बीटीडब्ल्यू, किसी को निम्नलिखित सहायक मिल सकता है:

| गूगल क्वेरी | परिणाम |
| :--------------------------------------: | :-----: |
| "डेटा संरचना" "प्राथमिकता कतार" | 172,000 |
| "डेटा संरचना" "ढेर" | 430,000 |
| "डेटा संरचना" "कतार" - "प्राथमिकता कतार" | 496,000 |
| "डेटा संरचना" "कतार" | 530,000 |
| "डेटा संरचना" "स्टैक" | 577,000 |

@pgolebiowski मुझे लगता है कि मैं यहां आगे और पीछे जा रहा हूं इसलिए मैं मान लूंगा

@karelz @safern आप उपरोक्त के बारे में कैसा महसूस करते हैं? क्या हम IHeap + Heap दृष्टिकोण पर खुद को ठीक कर सकते हैं ताकि मैं एक विशिष्ट एपीआई प्रस्ताव पेश कर सकूं?

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

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

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

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

@pgolebiowski अब जब आपने पूछा है, तो मेरी व्यक्तिगत राय है (मुझे कुछ हद तक यकीन है कि अन्य एपीआई समीक्षक/आर्किटेक्ट इसे साझा करेंगे क्योंकि मैंने कुछ के साथ राय की जांच की है):
नाम PriorityQueue होना चाहिए, और हमें IHeap इंटरफ़ेस पेश नहीं करना चाहिए। बिल्कुल एक कार्यान्वयन होना चाहिए (संभवतः कुछ ढेर के माध्यम से)।
IHeap इंटरफ़ेस बहुत उन्नत विशेषज्ञ परिदृश्य है - मैं इसे PowerCollections पुस्तकालय (अंततः बनने के लिए) या किसी अन्य पुस्तकालय में स्थानांतरित करने का सुझाव दूंगा।
यदि पुस्तकालय और IHeap इंटरफ़ेस वास्तव में लोकप्रिय हो जाते हैं, तो हम बाद में अपना विचार बदल सकते हैं और मांग के आधार पर IHeap जोड़ सकते हैं (आपके कंस्ट्रक्टर अधिभार के माध्यम से), लेकिन मुझे नहीं लगता कि यह उपयोगी/गठबंधन है बाकी बीसीएल के साथ अब नया इंटरफ़ेस जोड़ने की जटिलता को उचित ठहराने के लिए पर्याप्त है। सरल शुरुआत करें, जटिल से तभी बढ़ें जब वास्तव में जरूरत हो।
... बस मेरे 2 (व्यक्तिगत) सेंट

विचारों में अंतर को देखते हुए, मैं प्रस्ताव को आगे बढ़ाने के लिए निम्नलिखित दृष्टिकोण का प्रस्ताव करता हूं (जो मैंने इस सप्ताह के शुरू में @ianhays को

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

... मेरी राय (जो आपने मांगी थी) के बारे में पूरी तरह से पारदर्शी होने की कोशिश कर रहा है, कृपया इसे निराशा के रूप में न लें या पीछे धकेलें - आइए देखें कि एपीआई प्रस्ताव कैसे जाता है।

@ करेल्ज़

नाम PriorityQueue . होना चाहिए

कोई तर्क? यह कम से कम अच्छा होगा यदि आपने केवल ना कहने के बजाय ऊपर जो लिखा है उसे संबोधित करें।

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

इसके अलावा, यह सिर्फ नाम के बारे में नहीं है । ऐसा नहीं है कि उथला है। कृपया पढ़ें कि मैंने क्या लिखा है। यह अमूर्तता के स्तरों के बीच काम करने और इसके ऊपर कोड/निर्माण को बढ़ाने में सक्षम होने के बारे में है।

ओह, इस चर्चा में एक तर्क था कि क्यों:

यदि हम ढेर के साथ जाते हैं, तो कई मध्यवर्ती-कुशल डेवलपर्स (दुख की बात है) "हीप" देखेंगे और इसे "सामान्यीकृत डेटा संरचना को ढेर" के बजाय एप्लिकेशन के मेमोरी हीप (यानी ढेर और स्टैक) के लिए भ्रमित करेंगे। [...] उन्हें आश्चर्य होगा कि वे एक नया मेमोरी हीप क्यों आवंटित कर सकते हैं।

मैं

हमें IHeap इंटरफ़ेस पेश नहीं करना चाहिए। IHeap इंटरफ़ेस बहुत उन्नत विशेषज्ञ परिदृश्य है - मैं इसे PowerCollections लाइब्रेरी में स्थानांतरित करने का सुझाव दूंगा।

@bendono ने इस पर बहुत अच्छी टिप्पणी लिखी। @safern भी एक इंटरफ़ेस के साथ कार्यान्वयन को वापस करना चाहता था। और कुछ अन्य।

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

लेकिन फिर, आपने इस पर अच्छी तरह से टिप्पणी की: कोई भी टूटे हुए एपीआई को शिप नहीं करना चाहता।

विचारों में अंतर को देखते हुए, मैं प्रस्ताव को आगे बढ़ाने के लिए निम्नलिखित दृष्टिकोण का प्रस्ताव करता हूं। [...] 2 वैकल्पिक प्रस्ताव बनाएं [...] आइए इसे एपीआई समीक्षा में लाएं, वहां इस पर चर्चा करें और वहां निर्णय लें। यदि मैं उस समूह के कम से कम एक व्यक्ति को हीप्स प्रस्ताव के लिए मतदान करते हुए देखता हूं, तो मुझे अपने दृष्टिकोण पर पुनर्विचार करने में खुशी होगी।

ऊपर एपीआई के विभिन्न हिस्सों पर काफी चर्चा हुई। इसने निपटाया:

• PriorityQueue बनाम Heap
• एक इंटरफ़ेस जोड़ना
• संग्रह से तत्वों को अद्यतन/निकालने में सहायता करना

आपके मन में जो लोग हैं वे इस चर्चा में योगदान क्यों नहीं दे सकते? इसके बजाय हमें इसे फिर से क्यों शुरू करना चाहिए?

यदि हम ढेर के साथ जाते हैं, तो कई मध्यवर्ती-कुशल डेवलपर्स (दुख की बात है) "हीप" देखेंगे और इसे "सामान्यीकृत डेटा संरचना को ढेर" के बजाय एप्लिकेशन के मेमोरी हीप (यानी ढेर और स्टैक) के लिए भ्रमित करेंगे।

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

मुझे विश्वास नहीं हो रहा है कि

कोई तर्क? यह कम से कम अच्छा होगा यदि आपने केवल ना कहने के बजाय ऊपर जो लिखा है उसे संबोधित करें।

यदि आप मेरा उत्तर पढ़ते हैं, तो आप देख सकते हैं कि मैंने अपनी स्थिति के लिए मुख्य तर्कों का उल्लेख किया है:

• IHeap इंटरफ़ेस बहुत उन्नत विशेषज्ञ परिदृश्य है
• मुझे नहीं लगता कि यह अब नया इंटरफ़ेस जोड़ने की जटिलता को उचित ठहराने के लिए शेष बीसीएल के साथ उपयोगी/गठबंधन है

वही तर्क जो धागे पर कई बार आईएमओ पर दोहराया गया है। मैंने अभी उन्हें संक्षेप में प्रस्तुत किया है

. कृपया पढ़ें कि मैंने क्या लिखा है।

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

डेवलपर्स संभवतः उस इंटरफ़ेस के विरुद्ध अपना कोड कैसे लिख सकते हैं और हमारी कार्यक्षमता का उपयोग कैसे कर सकते हैं?

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

आपके मन में जो लोग हैं वे इस चर्चा में योगदान क्यों नहीं दे सकते?

एपीआई समीक्षा सक्रिय चर्चा, विचार-मंथन, सभी कोणों को महत्व देने वाली बैठक है। कई मामलों में यह GitHub मुद्दों पर आगे-पीछे की तुलना में अधिक उत्पादक/कुशल है। देखें dotnet/corefx#14354 और इसके पूर्ववर्ती dotnet/corefx#8034 - बहुत लंबी चर्चा, गैज़िलियन ट्विक्स के साथ कई अलग-अलग राय जिन्हें ट्रैक करना मुश्किल है, कोई निष्कर्ष नहीं है, जबकि महान चर्चा, कुछ लोगों के लिए गैर-तुच्छ अपशिष्ट समय भी, जब तक हम बैठ गए और इसके बारे में बात नहीं की और आम सहमति नहीं बन गई।
एपीआई समीक्षक हर एक एपीआई मुद्दे की निगरानी करते हैं, या यहां तक ​​​​कि सिर्फ गपशप करने वाले भी अच्छी तरह से स्केल नहीं करते हैं।

इसके बजाय हमें इसे फिर से क्यों शुरू करना चाहिए?

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

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

नाम PriorityQueue . होना चाहिए

कोई तर्क?

यदि आप मेरा उत्तर पढ़ते हैं, तो आप देख सकते हैं कि मैंने अपनी स्थिति के लिए मुख्य तर्कों का उल्लेख किया है।

गीज़ ... मैं जो उद्धृत कर रहा था ( जाहिर है ) - आप ढेर के बजाय प्राथमिकता कतार के साथ जाने का फैसला कर रहे थे। और हाँ, मैंने आपका उत्तर पढ़ लिया है -- इसमें इसके लिए ठीक 0% तर्क हैं।

मैं हर समय सक्रिय रूप से इस धागे की निगरानी कर रहा था। मैंने सभी तर्कों और बिंदुओं को पढ़ा। आपके और दूसरों के सभी बिंदुओं को पढ़ने (और समझने) के बावजूद, यह मेरी संक्षिप्त राय है।

आप अतिशयोक्तिपूर्ण होना पसंद करते हैं, मैंने इसे पहले देखा है। आप केवल बिंदुओं के अस्तित्व को स्वीकार करते हैं।

डेवलपर्स संभवतः उस इंटरफ़ेस के विरुद्ध अपना कोड कैसे लिख सकते हैं और हमारी कार्यक्षमता का उपयोग कैसे कर सकते हैं?

IHeap उन्नत परिदृश्य की परवाह करने वाले डेवलपर्स इंटरफ़ेस और तृतीय पक्ष लाइब्रेरी से कार्यान्वयन का संदर्भ देंगे। जैसा कि मैंने कहा, अगर यह लोकप्रिय साबित होता है, तो हम इसे बाद में CoreFX में ले जाने पर विचार कर सकते हैं।

क्या आप जानते हैं कि आप मेरे शब्दों को यहाँ दोहरा रहे हैं और उस मुद्दे को बिल्कुल भी संबोधित नहीं कर रहे हैं जो मैंने उपरोक्त के परिणामस्वरूप प्रस्तुत किया है? मैंने लिखा:

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

मैं इसे आपके लिए बहुत स्पष्ट कर दूंगा। लोगों के दो असंबद्ध समूह होंगे:

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

जैसा कि मैंने कहा, यहाँ समस्या यह है कि वे लोगों के अलग-अलग समूह हैं । और वे ऐसे कोड का निर्माण कर रहे हैं जो एक साथ काम नहीं करते हैं , क्योंकि कोई सामान्य आर्किटेक्चरल कोर नहीं है। _ कोडबेस संगत नहीं है _. आप इसे बाद में पूर्ववत नहीं कर सकते।

अच्छी खबर यह है कि IHeap को बाद में जोड़ना पूरी तरह से संभव है - यह मूल रूप से प्रायोरिटी क्यू पर सिर्फ एक कंस्ट्रक्टर ओवरलोड जोड़ता है।

मैंने पहले ही लिखा है कि यह क्यों बेकार है: इस पोस्ट को देखें ।

आपके मन में जो लोग हैं वे इस चर्चा में योगदान क्यों नहीं दे सकते?

एपीआई समीक्षक हर एक एपीआई मुद्दे की निगरानी करते हैं, या यहां तक ​​​​कि सिर्फ गपशप करने वाले भी अच्छी तरह से स्केल नहीं करते हैं।

हां, मैं पूछ रहा था कि एपीआई समीक्षक हर एक एपीआई मुद्दे की निगरानी क्यों नहीं कर सकते। ठीक है, आपने वास्तव में उसी के अनुसार प्रतिक्रिया दी।

समझ में आता है?

नहीं, मैं वास्तव में इस चर्चा से थक गया हूँ। आप में से कुछ लोग इसमें स्पष्ट रूप से भाग ले रहे हैं क्योंकि यह आपका काम है और आपको बताया गया है। आप में से कुछ लोगों को हर समय मार्गदर्शन की आवश्यकता होती है, जो बहुत थकाऊ होता है। आपने मुझे यह साबित करने के लिए भी कहा कि आंतरिक रूप से ढेर के साथ प्राथमिकता कतार क्यों लागू की जानी चाहिए, स्पष्ट रूप से कंप्यूटर विज्ञान पृष्ठभूमि की कमी है। आप में से कुछ लोग यह भी नहीं समझते हैं कि ढेर वास्तव में क्या है, जिससे चर्चा और भी अराजक हो जाती है।

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

और यह... यह सिर्फ दिमागी उड़ाने वाला है:

यदि हम ढेर के साथ जाते हैं, तो कई मध्यवर्ती-कुशल डेवलपर्स (दुख की बात है) "हीप" देखेंगे और इसे "सामान्यीकृत डेटा संरचना को ढेर" के बजाय एप्लिकेशन के मेमोरी हीप (यानी ढेर और स्टैक) के लिए भ्रमित करेंगे।

अपने दृष्टिकोण के साथ एपीआई प्रस्तुत करें। मैं उत्सुक हूँ।

मुझे विश्वास नहीं हो रहा है कि ऐसा सच में हो रहा है...

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

बात अभी भी कायम है, हालांकि। किसी चीज के ढेर का मतलब यह नहीं है कि उसे किसी तरह से ऑर्डर किया जा रहा है। अगर मुझे एक संग्रह की आवश्यकता होती है जो मुझे चीजों की वस्तुओं को संसाधित करने की अनुमति देता है, जहां बाद में आने वाले कुछ उदाहरणों को जल्द ही संसाधित करने की आवश्यकता हो सकती है, तो मैं Heap नामक किसी चीज़ की खोज नहीं करूँगा। दूसरी ओर PriorityQueue , पूरी तरह से संचार करता है कि यह ठीक यही करता है।

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

ठीक है, मुझे यह जानने के लिए एक उचित कंप्यूटर विज्ञान शिक्षा प्राप्त करने का अवसर नहीं मिला है कि हीप किसी प्रकार की डेटा संरचना है जो मेमोरी हीप से अलग है।

यह मज़ाकीय है। साथ ही आप उस तरह की कार्यक्षमता जोड़ने के संबंध में चर्चा में भाग लेना चाहते हैं। यह ट्रोलिंग जैसा लगता है।

किसी चीज के ढेर का मतलब यह नहीं है कि उसे किसी तरह से ऑर्डर किया जा रहा है।

आप गलत हैं। यह आदेश दिया जाता है, एक ढेर के रूप में। जैसे आपके द्वारा लिंक की गई तस्वीरों में।

एक समर्थन कार्यान्वयन के रूप में? निश्चित रूप से, कार्यान्वयन विवरण मेरी चिंता का विषय नहीं होना चाहिए।

मैं इसे पहले ही संबोधित कर चुका हूं। ढेर का परिवार बहुत बड़ा है और कार्यान्वयन के ऊपर अमूर्तता के दो स्तर हैं। प्राथमिकता कतार तीसरी अमूर्त परत है।

अगर मुझे एक संग्रह की आवश्यकता होती है जो मुझे चीजों की वस्तुओं को संसाधित करने की अनुमति देता है, जहां बाद में आने वाले कुछ उदाहरणों को जल्द ही संसाधित करने की आवश्यकता हो सकती है, तो मैं ढेर नामक किसी चीज़ की खोज नहीं करूँगा। दूसरी ओर प्रायोरिटीक्यू, पूरी तरह से संचार करता है कि यह ठीक वैसा ही करता है।

और बिना किसी पृष्ठभूमि के, आप Google से आपको प्राथमिकता वाली कतारों में लेख उपलब्ध कराने के लिए कहेंगे? खैर, हम बहस कर सकते हैं कि हमारी राय में क्या कम या ज्यादा होने की संभावना है। लेकिन, जैसा कि बहुत अच्छी तरह से कहा गया है:

यदि आपके पास इनपुट है, तो उसे प्रदान करें, डेटा और साक्ष्य के साथ उसका समर्थन करें। अगर आप असहमत हैं तो दूसरे की राय के खिलाफ सबूत दें।

और आंकड़ों के अनुसार आप गलत हैं:

प्रश्न | हिट्स
:----: |:----:|
| "डेटा संरचना" "प्राथमिकता कतार" | 172,000 |
| "डेटा संरचना" "ढेर" | 430,000 |

डेटा संरचनाओं के बारे में पढ़ते समय यह लगभग 3 गुना अधिक होने की संभावना है। साथ ही, यह एक ऐसा नाम है जिससे स्विफ्ट, गो, रस्ट और पायथन डेवलपर्स परिचित हैं, क्योंकि उनके मानक पुस्तकालय ऐसी डेटा संरचना प्रदान करते हैं।

प्रश्न | हिट्स
:----: |:----:|
| "गोलंग" "प्राथमिकता कतार" | 3.390 |
| "जंग" "प्राथमिकता कतार" | 8.630 |
| "तेज" "प्राथमिकता कतार" | 18.600 |
| "पायथन" "प्राथमिकता कतार" | 72.800 |
| "गोलंग" "ढेर" | 79.000 |
| "जंग" "ढेर" | 492.000 |
| "तेज" "ढेर" | 551.000 |
| "पायथन" "ढेर" | 555.000 |

वास्तव में यह सी ++ के लिए भी समान है, क्योंकि पिछली शताब्दी में कभी-कभी एक ढेर डेटा संरचना पेश की गई थी।

कुछ ऐसा गुप्त नाम देना जो अपने इरादे को अच्छी तरह से नहीं बताता है और बाद में खोज योग्यता को सीमित करता है? मैं

कोई राय नहीं। आंकड़े। ऊपर देखो। खासतौर पर किसी ऐसे व्यक्ति से कोई राय नहीं जिसकी कोई पृष्ठभूमि न हो। आप पहले डेटा संरचनाओं के बारे में कुछ पढ़े बिना Google को प्राथमिकता कतार नहीं देंगे। और ढेर कई डेटा संरचना 101 में शामिल है ।

यह कंप्यूटर विज्ञान में नींव है। यह प्राथमिक है। जब आपके पास एल्गोरिदम और डेटा संरचनाओं के कई सेमेस्टर होते हैं, तो ढेर कुछ ऐसा होता है जिसे आप शुरुआत में देखते हैं।

फिर भी:

• पहले - ऊपर दिए गए नंबरों को देखें।
• दूसरा - अन्य सभी भाषाओं के बारे में सोचें जहां ढेर मानक पुस्तकालय का हिस्सा है।

संपादित करें: Google रुझान देखें।

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

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

मैं एपीआई नामकरण के बारे में हमारे विचार के बारे में कुछ स्पष्टीकरण प्रदान करता हूं:

1. हम लगभग किसी भी चीज़ से ऊपर .NET प्लेटफॉर्म के भीतर निरंतरता का पक्ष लेते हैं। एपीआई को परिचित और अनुमानित दिखने के लिए यह महत्वपूर्ण है। कभी-कभी इसका मतलब यह है कि हम स्वीकार करते हैं कि कोई नाम 100% सही नहीं है, यदि यह एक ऐसा शब्द है जिसका हमने पहले उपयोग किया है।

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

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

इसलिए, मैं @karelz से सहमत PriorityQueue बेहतर विकल्प की तरह दिखता है । यह एक मौजूदा अवधारणा (कतार) को जोड़ती है और वांछित क्षमता को व्यक्त करने वाले मोड़ को जोड़ती है: प्राथमिकता के आधार पर पुनर्प्राप्ति का आदेश दिया। लेकिन हम उस नाम से अडिग नहीं हैं। हमने अक्सर ग्राहकों की प्रतिक्रिया के आधार पर डेटा संरचनाओं और तकनीकों के नाम बदले हैं।

हालाँकि, मैं यह बताना चाहूंगा कि यह:

यदि आप लोगों का इनपुट नहीं चाहते हैं, तो इसे ओपन-सोर्स न बनाएं और इसके लिए न पूछें।

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

@pgolebiowski :

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

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

कृपया सम्मान करें। विचारों की जोश से आलोचना करना उचित खेल है, लेकिन लोगों पर हमला करना नहीं है। धन्यवाद।

प्रिय हर कोई जो निराश महसूस करता है,

मैं अपने कठोर-ईश रवैये से आपके खुशी के स्तर को कम करने के लिए क्षमा चाहता हूं।

@ करेल्ज़

मैंने वहां तकनीकी गलती करके खुद को बेवकूफ बनाया है। मैंने माफी मांगी। इसे स्वीकार कर लिया गया। फिर भी बाद में मुझ पर फेंका। कूल आईएमओ नहीं।

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

और हाँ, हर कोई गलती करता है। यह ठीक है। मैं भी, उदाहरण के लिए कभी-कभी बहक जाने से।

मुझे सबसे ज्यादा जो मिला वह था "आपको बस ऐसा करने के लिए कहा जा रहा है, आप इस पर विश्वास नहीं करते" - हाँ, यही कारण है कि मैं इसे सप्ताहांत पर भी करता हूं।

मुझे खेद है, मैं देख सकता हूं कि आप कड़ी मेहनत करते हैं और मैं इसकी बहुत सराहना करता हूं। यह मुझे दिखाई दे रहा था कि आप 5/10 मील के पत्थर तक कितने विशेष रूप से समर्पित थे।

@terrajobst

सिर्फ इसलिए कि आप हमसे असहमत हैं, आपको यह आरोप लगाने की अनुमति नहीं देता है कि हमारे पास विशेषज्ञता नहीं है या परवाह नहीं है क्योंकि यह "सिर्फ हमारा काम" है।

• विशेषज्ञता न होना - बिना कंप्यूटर विज्ञान पृष्ठभूमि वाले और ढेर/प्राथमिकता कतारों की अवधारणा को न समझने वाले लोगों के प्रति संबोधित। अगर ऐसा विवरण किसी पर लागू होता है -- ठीक है, यह लागू होता है, इसमें मेरी गलती नहीं है।
• परवाह नहीं करना - कुछ तकनीकी बिंदुओं को अनदेखा करने की प्रवृत्ति वाले लोगों के प्रति संबोधित, इस प्रकार दोहराए जाने वाले तर्कों को लागू करना, जैसे चर्चा को अराजक बनाना और अन्य लोगों द्वारा पालन करना कठिन होता है (जो बदले में कम इनपुट की ओर जाता है)।

आपकी तरह की टिप्पणियां बहुत अनुचित हैं और डिजाइन को आगे बढ़ाने में भी मदद नहीं करती हैं।

• मेरी कठोर टिप्पणियाँ इस चर्चा में अक्षमता का परिणाम थीं। अक्षमता = चर्चा का अराजक तरीका, जहाँ मुद्दों का समाधान / समाधान नहीं किया जाता है और हम इसके बावजूद आगे बढ़ते हैं => थकाऊ।
• इसके अलावा, चर्चा में प्रमुख ड्राइवरों में से एक के रूप में, मुझे दृढ़ता से लगता है कि डिजाइन को आगे बढ़ाने में मदद करने के लिए मैंने बहुत कुछ किया है। कृपया मुझे बदनाम न करें, जैसा कि आप यहां और सोशल मीडिया में करने की कोशिश कर रहे हैं।

अगर कोई बीमार है जो "मुझे चाटना" चाहता है, तो कृपया बेझिझक।

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

@pgolebiowski

उम्मीद है कि हम किसी समय व्यक्तिगत रूप से मिल सकते हैं। मैं ईमानदारी से मानता हूं कि सब कुछ ऑनलाइन करने की चुनौती का एक हिस्सा यह है कि व्यक्तित्व कभी-कभी किसी भी पक्ष से बिना किसी इरादे के खराब तरीके से मिल सकते हैं।

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

मेरा भी यही विचार है। यह एक दिलचस्प जगह है और हम एक साथ बहुत सारी अद्भुत चीजें कर सकते हैं :-)

@pgolebiowski पहले, आपके उत्तर के लिए धन्यवाद। यह दिखाता है कि आप परवाह करते हैं और आप अच्छी तरह से मतलब रखते हैं (जो कुछ ऐसा है जो मैं गुप्त रूप से उम्मीद करता हूं कि दुनिया में हर व्यक्ति/डेवलपर करता है, सभी संघर्ष सिर्फ गलतफहमी/गलत संचार है)। और इससे मुझे बहुत खुशी मिलती है - यह मुझे उत्साहित और उत्साहित रखता है।
मेरा सुझाव है कि हम अपने रिश्ते को फिर से शुरू करें। आइए चर्चा को वापस तकनीकी की ओर मोड़ें, आइए हम सभी इस सूत्र से सीखें, भविष्य में इसी तरह की स्थितियों को कैसे संभालना है, आइए हम सभी फिर से मान लें कि मंच के लिए दूसरे पक्ष के पास केवल सर्वोत्तम हित है।
BTW: यह पिछले 9 महीनों में CoreFX रेपो पर कुछ अधिक कठिन मुठभेड़ों/चर्चाओं में से एक है, और जैसा कि आप देखते हैं, हम (incl./esp. me) अभी भी सीख रहे हैं कि उन्हें कैसे अच्छी तरह से संभालना है - इसलिए यह विशेष उदाहरण चल रहा है हमें भी लाभान्वित करने के लिए और यह हमें भविष्य में बेहतर बनाएगा और जोशीले समुदाय के सदस्यों के अलग-अलग दृष्टिकोणों को बेहतर ढंग से समझने में हमारी मदद करेगा। हो सकता है कि यह हमारे अपडेट को योगदान डॉक्स में आकार देगा ...

मेरी कठोर टिप्पणियाँ इस चर्चा में अक्षमता का परिणाम थीं। अक्षमता = चर्चा का अराजक तरीका, जहाँ मुद्दों का समाधान / समाधान नहीं किया जाता है और हम इसके बावजूद आगे बढ़ते हैं => थकाऊ।

आपकी हताशा को समझा! दिलचस्प बात यह है कि इसी तरह की निराशा दूसरी तरफ भी इसी कारण से थी 😉 ... यह लगभग अजीब है कि दुनिया कैसे काम करती है :)।
दुर्भाग्य से, जब आप कोई डिज़ाइन निर्णय लेते हैं तो कठिन चर्चा नौकरी का हिस्सा होती है। यह बहुत काम है। बहुत से लोग इसे कम आंकते हैं। आवश्यक मुख्य कौशल सभी के साथ धैर्य और अपनी राय से ऊपर कदम रखने की क्षमता है और यह सोचना है कि आम सहमति कैसे चलाई जाए, भले ही यह आपके रास्ते पर न जाए। इसलिए मैंने एपीआई समीक्षक समूह के लिए 2 प्रस्तावों और तकनीकी चर्चा को "बढ़ाने" का सुझाव दिया (मुख्यतः क्योंकि मुझे यकीन नहीं है कि मैं सही हूं, हालांकि मैं गुप्त रूप से आशा करता हूं कि मैं सही हूं क्योंकि दुनिया में हर दूसरा डेवलपर होगा )

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

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

अब जबकि मैं तकनीकी प्रश्नों पर चर्चा करने से नहीं डरता, यहाँ मैं पहले जो पूछना चाहता था:

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

यह कुछ ऐसा है जो मुझे समझ नहीं आ रहा है। अगर हम IHeap (मेरे / मूल प्रस्ताव में) छोड़ देते हैं, तो यह संभव क्यों नहीं होगा?
आईएमओ वर्ग क्षमताओं के दृष्टिकोण से 2 प्रस्तावों के बीच कोई अंतर नहीं है, केवल अंतर यह है - क्या हम PriorityQueue(IHeap) कंस्ट्रक्टर अधिभार जोड़ते हैं या नहीं (वर्ग नाम विवाद को हल करने के लिए स्वतंत्र समस्या के रूप में छोड़कर) .

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

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

@karelz ऊपर की चर्चा की लंबाई के कारण, यदि प्रवाह को संशोधित नहीं किया जाता है, तो किसी के लिए भी योगदान करने की अत्यधिक संभावना नहीं है। इस प्रकार, मैं अभी निम्नलिखित दृष्टिकोण का प्रस्ताव करना चाहूंगा:

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

क्या इसका कोई मतलब निकालने का मौका है?

प्राथमिकता कतार जो तत्वों को अद्यतन करने और हटाने की अनुमति नहीं देती है।

यह मूल प्रस्ताव के संबंध में था, जिसमें इन क्षमताओं का अभाव था :) इसे स्पष्ट न करने के लिए क्षमा करें।

यदि आपके पास इसे समझाने/चर्चा चलाने के लिए ऊर्जा नहीं है (जो आपकी ओर से कठिनाइयों और समय के निवेश को देखते हुए पूरी तरह से समझ में आता है), तो बस इतना कहें, कोई कठोर भावना नहीं। कृपया मुझ पर या किसी के द्वारा दबाव महसूस न करें (और यह धागे पर सभी पर लागू होता है)।

में छोडूंगा नहीं। कोई दर्द नहीं कोई लाभ नहीं xD

@xied75

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

अछा लगता है ;)

एक इंटरफ़ेस प्रदान करना

कोई फर्क नहीं पड़ता कि हम Heap / IHeap या PriorityQueue / IPriorityQueue (या कुछ और) के साथ जाते हैं, कार्यक्षमता के लिए हम प्रदान करने वाले हैं ...

_क्या आप कार्यान्वयन के साथ-साथ एक इंटरफ़ेस रखना चाहेंगे?_

के लिये

• डेवलपर्स एक इंटरफेस के खिलाफ अपना तर्क लिख सकते हैं। पढ़ें: निर्भरता उलटा सिद्धांत , निर्भरता इंजेक्शन , अनुबंध द्वारा डिजाइन , नियंत्रण का उलटा ।
• डेवलपर्स अन्य कार्यान्वयन प्रदान करके अपनी कस्टम आवश्यकताओं को पूरा करने के लिए इस कार्यक्षमता का विस्तार कर सकते हैं। इस तरह के कार्यान्वयन को PowerCollections जैसे तृतीय-पक्ष पुस्तकालयों में शामिल किया जा सकता है।

@ बेंडोनो

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

जो लोग इसकी परवाह नहीं करते वे इसे अनदेखा कर सकते हैं और सीधे ठोस कार्यान्वयन के लिए जा सकते हैं। जो परवाह करते हैं वे अपनी पसंद के किसी भी कार्यान्वयन का उपयोग कर सकते हैं।

के खिलाफ

@madelson

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

इसके अलावा, एक बार एक इंटरफ़ेस जारी हो जाने के बाद इसे कॉम्पेट के कारण कभी नहीं बदला जा सकता है। इसका मतलब है कि इंटरफ़ेस कार्यक्षमता के मामले में ठोस वर्गों के पीछे पड़ जाता है (आज IList और IDictionary के साथ एक समस्या)।

@ करेल्ज़

इंटरफ़ेस बहुत उन्नत विशेषज्ञ परिदृश्य है।

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

संभावित निर्णय प्रभाव

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

इस पर वोट करने के लिए और का प्रयोग करें (क्रमशः एक इंटरफेस के लिए और उसके खिलाफ)। वैकल्पिक रूप से, एक टिप्पणी लिखें। आदर्श रूप से, एपीआई समीक्षक भाग लेंगे।

मैं यह जोड़ना चाहता हूं कि इंटरफेस बदलना कठिन है, विस्तार विधियों (और गुण आने वाले) इंटरफेस के साथ विस्तार करना और/या काम करना आसान है (LINQ देखें)

मैं यह जोड़ना चाहता हूं कि इंटरफेस बदलना कठिन है, विस्तार विधियों (और गुण आने वाले) इंटरफेस के साथ विस्तार करना और/या काम करना आसान है (LINQ देखें)

वे केवल इंटरफ़ेस पर सार्वजनिक रूप से परिभाषित विधियों के साथ काम कर सकते हैं; तो इसका मतलब है इसे पहली बार सही करना।

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

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

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

मैं नोट करना चाहिए वहाँ भी है कि SortedSet<T> अब, के कई गैर-बीसीएल कार्यान्वयन का उल्लेख नहीं ISet<T> । मैंने सार्वजनिक एपीआई में ISet<T> किया है और इसके लिए मैं आभारी हूं। मेरा निजी कार्यान्वयन किसी भी ठोस कार्यान्वयन का उपयोग कर सकता है जो मुझे सही लगता है। मैं बिना कुछ तोड़े किसी अन्य के लिए कार्यान्वयन को आसानी से स्वैप कर सकता हूं। यह इंटरफेस के बिना संभव नहीं होगा।

उन लोगों के लिए जो कहते हैं कि हम हमेशा अपने स्वयं के इंटरफेस को परिभाषित कर सकते हैं, इस पर विचार करें। एक पल के लिए मान लें कि BCL में ISet<T> कभी नहीं हुआ। अब मैं अपना स्वयं का इंटरफ़ेस IMySet<T> और साथ ही ठोस कार्यान्वयन बना सकता हूं। हालांकि, एक दिन बीसीएल HashSet<T> जारी किया जाता है। यह ISet<T> लागू कर सकता है या नहीं भी कर सकता है, लेकिन यह IMySet<T> लागू नहीं करता है। परिणामस्वरूप, मैं अपने IMySet<T> कार्यान्वयन के रूप में HashSet<T> में स्वैप नहीं कर सकता।

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

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

@ebickle @svick @horaciojcfilho @paulcbetts @justinvp @akoeplinger @mbeidler @SirCmpwn @andrewgmorris @weshaggard @BrannonKing @NKnusperer @danmosemsft @ianhays @safern @VisualMelon @ Joe4xied @

अधिसूचित के लिए: दोस्तों, क्या आप कृपया अपना इनपुट प्रदान कर सकते हैं? यह बहुत मददगार होगा, भले ही आप :+1:, :-1: के साथ वोट करें। आप इस मुद्दे पर टिप्पणी पढ़ना शुरू कर सकते हैं (यहाँ ऊपर 4 पोस्ट) -- हम चर्चा कर रहे हैं कि क्या एक इंटरफ़ेस प्रदान करना एक अच्छा विचार है (अभी के लिए केवल यह पहलू, जब तक इसका समाधान नहीं हो जाता)।_

हो सकता है कि इनमें से कुछ लोग एपीआई समीक्षक हों, लेकिन मेरा मानना ​​है कि आगे बढ़ने से पहले हमें इस मौलिक निर्णय में उनके समर्थन की आवश्यकता है। @karelz , @terrajobst , क्या यह संभव होगा कि आप उनसे इस पहलू को सुलझाने में हमारी मदद करने के लिए कहें? उनका इनपुट बहुत मूल्यवान होगा, क्योंकि वे वही हैं जो अंततः इसकी समीक्षा करेंगे - एक निश्चित दृष्टिकोण (या 1 से अधिक प्रस्ताव के साथ जाने से पहले, इस बिंदु पर इसे जानना बहुत उपयोगी होगा, जो थकाऊ होगा) और थोड़ा व्यर्थ, जैसा कि हम उनके निर्णय को पहले जान सकते हैं)।

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

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

बीटीडब्ल्यू: एपीआई समीक्षा बैठकें लगभग हर मंगलवार को होती हैं।

इसे शुरू करने में मदद के लिए, यहां बताया गया है कि एक प्रस्ताव कैसा दिखना चाहिए:

प्रस्ताव उदाहरण / बीज

```सी#
नेमस्पेस सिस्टम
{
सार्वजनिक वर्ग प्राथमिकता कतार
: IEnumerable, ICollection, IEnumerable, IReadOnlyCollection
{
सार्वजनिक प्राथमिकता कतार ();
सार्वजनिक प्राथमिकता कतार (इंट क्षमता);
सार्वजनिक प्राथमिकता कतार (IComparer .)तुलनाकर्ता);
सार्वजनिक प्राथमिकता कतार(IEnumerableसंग्रह);
सार्वजनिक प्राथमिकता कतार(IEnumerableसंग्रह, आईसीओएमपेयरतुलनाकर्ता);
सार्वजनिक प्राथमिकता कतार (इंट क्षमता, आईसीओएमपेयर)तुलनाकर्ता);

    public IComparer<T> Comparer { get; }
    public int Count { get; }

    public void Enqueue(T item);
    public T Dequeue();
    public T Peek();
    public void Clear();
    public bool Contains(T item);

    // Sets the capacity to the actual number of elements
    public void TrimExcess();

    public void CopyTo(T[] array, int arrayIndex);
    void ICollection.CopyTo(Array array, int index);
    public T[] ToArray();

    public Enumerator GetEnumerator();
    IEnumerator<T> IEnumerable<T>.GetEnumerator();
    IEnumerator IEnumerable.GetEnumerator();

    bool ICollection.IsSynchronized { get; }
    object ICollection.SyncRoot { get; }
    public struct Enumerator : IEnumerator<T>
    {
        public T Current { get; }
        object IEnumerator.Current { get; }
        public bool MoveNext();
        public void Reset();
        public void Dispose();
    }
}

}
```

करने के लिए:

• गुम उपयोग उदाहरण (यह मेरे लिए अस्पष्ट है कि मैं वस्तुओं की प्राथमिकता कैसे व्यक्त करता हूं) - शायद हमें इसे 'int' को प्राथमिकता मान इनपुट के रूप में फिर से डिज़ाइन करना चाहिए? शायद उस पर कुछ अमूर्त? (मुझे लगता है कि इस पर ऊपर चर्चा की गई थी, लेकिन धागा पढ़ने के लिए बहुत लंबा है, इसलिए हमें ठोस प्रस्तावों की आवश्यकता है और अधिक चर्चा की नहीं)
• UpdatePriority परिदृश्य गुम है
• ऊपर चर्चा की गई कोई और बात यहां गायब है?

@karelz ठीक है, यह करूँगा, बने रहें! :मुस्कुराओ:

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

इष्टतम जटिलताओं और महान वास्तविक दुनिया के प्रदर्शन को बनाए रखते हुए, मुख्य ध्यान शुद्धता, कार्यक्षमता के मामले में पूर्णता और सहजता पर है।

@karelz @terrajobst

प्रस्ताव

दलील

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

1. संग्रह में एक नया तत्व जोड़ें।
2. उच्चतम प्राथमिकता वाले तत्व को पुनः प्राप्त करें (और इसे हटाने में सक्षम हो)।
3. संग्रह से एक तत्व निकालें।
4. संग्रह में एक तत्व को संशोधित करें।
5. दो संग्रह मर्ज करें।

प्रयोग

शब्दकोष

• मान - उपयोगकर्ता डेटा।
• कुंजी - एक वस्तु जिसका उपयोग आदेश देने के लिए किया जाता है।

विभिन्न प्रकार के उपयोगकर्ता डेटा

सबसे पहले हम प्राथमिकता कतार (केवल तत्वों को जोड़ने) के निर्माण पर ध्यान केंद्रित करेंगे। इसे करने का तरीका उपयोगकर्ता डेटा के प्रकार पर निर्भर करता है।

दृष्टांत 1

• TKey और TValue अलग-अलग वस्तुएं हैं।
• TKey तुलनीय है।

var queue = new PriorityQueue<int, string>();

queue.Enqueue(5, "five");
queue.Enqueue(1, "one");
queue.Enqueue(3, "three");

परिदृश्य 2

• TKey और TValue अलग-अलग वस्तुएं हैं।
• TKey तुलनीय नहीं है।

var comparer = Comparer<MyKey>.Create(/* custom logic */);

var queue = new PriorityQueue<MyKey, string>(comparer);

queue.Enqueue(new MyKey(5), "five");
queue.Enqueue(new MyKey(1), "one");
queue.Enqueue(new MyKey(3), "three");

परिदृश्य 3

• TKey TValue भीतर समाहित है।
• TKey तुलनीय नहीं है।

public class MyClass
{
    public MyKey Key { get; set; }
}

एक प्रमुख तुलनित्र के अलावा, हमें एक प्रमुख चयनकर्ता की भी आवश्यकता है:

var selector = new Func<MyClass, MyKey>(item => item.Key);

var queue = new PriorityQueue<MyKey, MyClass>(selector, comparer);

queue.Enqueue(new MyClass( /* args */ ));
queue.Enqueue(new MyClass( /* args */ ));
queue.Enqueue(new MyClass( /* args */ ));

टिप्पणियाँ

• हम यहां एक अलग Enqueue पद्धति का उपयोग करते हैं। इस बार यह केवल एक तर्क लेता है ( TValue )।
• यदि कुंजी चयनकर्ता परिभाषित किया गया है, तो विधि Enqueue(TKey, TValue) को InvalidOperationException फेंकना चाहिए।
• यदि कुंजी चयनकर्ता परिभाषित नहीं है, तो विधि Enqueue(TValue) को InvalidOperationException फेंकना चाहिए।

परिदृश्य 4

• TKey TValue भीतर समाहित है।
• TKey तुलनीय है।

var queue = new PriorityQueue<MyKey, MyClass>(selector);

queue.Enqueue(new MyClass( /* args */ ));
queue.Enqueue(new MyClass( /* args */ ));
queue.Enqueue(new MyClass( /* args */ ));

टिप्पणियाँ

• के लिए comparer TKey माना जाता है Comparer<TKey>.Default , के रूप में परिदृश्य 1 ।

परिदृश्य 5

• TKey और TValue अलग-अलग वस्तुएं हैं, लेकिन एक ही प्रकार की हैं।
• TKey तुलनीय है।

var queue = new PriorityQueue<int, int>();

queue.Enqueue(5, 50);
queue.Enqueue(1, 10);
queue.Enqueue(3, 30);

परिदृश्य 6

• उपयोगकर्ता डेटा एक एकल वस्तु है, जो तुलनीय है।
• कोई भौतिक कुंजी नहीं है या कोई उपयोगकर्ता इसका उपयोग नहीं करना चाहता है।

public class MyClass : IComparable<MyClass>
{
    public int CompareTo(MyClass other) => /* custom logic */
}

var queue = new PriorityQueue<MyClass, MyClass>();

queue.Enqueue(new MyClass( /* args */ ));
queue.Enqueue(new MyClass( /* args */ ));
queue.Enqueue(new MyClass( /* args */ ));

टिप्पणियाँ

शुरुआत में एक अस्पष्टता है।

• यह संभव है कि MyClass एक अलग वस्तु है और उपयोगकर्ता केवल कुंजी और मूल्य को अलग रखना चाहेगा, जैसा कि परिदृश्य 5 में था।
• हालाँकि, यह एक एकल वस्तु भी हो सकती है (जैसे इस मामले में)।

यहां बताया गया है कि PriorityQueue अस्पष्टता से कैसे निपटता है:

• यदि कुंजी चयनकर्ता परिभाषित किया गया है, तो कोई अस्पष्टता नहीं है। केवल Enqueue(TValue) की अनुमति है। इसलिए, परिदृश्य 6 का एक वैकल्पिक समाधान केवल एक चयनकर्ता को परिभाषित करना और इसे कंस्ट्रक्टर को पास करना है।
• यदि कुंजी चयनकर्ता परिभाषित नहीं है, तो अस्पष्टता को Enqueue विधि के पहले उपयोग के साथ हल किया जाता है:
  
  
  
  • यदि Enqueue(TKey, TValue) को पहली बार कहा जाता है, तो कुंजी और मान को अलग-अलग ऑब्जेक्ट माना जाता है ( परिदृश्य 5 )। तब से, Enqueue(TValue) विधि को InvalidOperationException फेंकना होगा।
  
  
  • यदि Enqueue(TValue) को पहली बार कहा जाता है, तो कुंजी और मान को एक ही वस्तु माना जाता है, कुंजी चयनकर्ता का अनुमान लगाया जाता है ( परिदृश्य 6 )। तब से, Enqueue(TKey, TValue) विधि को InvalidOperationException फेंकना होगा।
  
  

अन्य कार्यक्षमता

हम पहले ही प्राथमिकता कतार के निर्माण को कवर कर चुके हैं। हम यह भी जानते हैं कि संग्रह में तत्वों को कैसे जोड़ा जाता है। अब हम शेष कार्यक्षमता पर ध्यान देंगे।

सर्वोच्च प्राथमिकता तत्व

तत्व पर हम सर्वोच्च प्राथमिकता के साथ दो ऑपरेशन कर सकते हैं - इसे पुनः प्राप्त करें या इसे हटा दें।

var queue = new PriorityQueue<int, string>();

queue.Enqueue(5, "five");
queue.Enqueue(1, "one");
queue.Enqueue(3, "three");

// retrieve the element with the highest priority
var element = queue.Peek();

// remove that element
queue.Dequeue();

Peek और Dequeue विधियों द्वारा वास्तव में क्या लौटाया जा रहा है, इस पर बाद में चर्चा की जाएगी।

एक तत्व को संशोधित करना

एक मनमाना तत्व के लिए, हम इसे संशोधित करना पसंद कर सकते हैं। एक उदाहरण के रूप में, यदि किसी सेवा के पूरे जीवनकाल के दौरान प्राथमिकता कतार का उपयोग किया जाता है, तो एक उच्च संभावना है कि डेवलपर प्राथमिकताओं को अद्यतन करने की संभावना रखना चाहेगा।

आश्चर्यजनक रूप से, ऐसी कार्यक्षमता समान डेटा संरचनाओं द्वारा प्रदान नहीं की जाती है: पायथन , जावा , सी ++ , गो , स्विफ्ट और रस्ट में । शायद कुछ अन्य भी, लेकिन मैंने केवल उनको चेक किया है। परिणाम? निराश डेवलपर्स:

• Java की प्रायोरिटी क्यू में चेंज प्रायोरिटी मेथड का अभाव क्यों है?
• जावा प्राथमिकता कतार अद्यतन समस्या
• प्राथमिकता कतार / ढेर अद्यतन

हमारे यहां मूल रूप से दो विकल्प हैं:

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

हैंडल

हर बार जब कोई उपयोगकर्ता प्राथमिकता कतार में कोई तत्व जोड़ता है, तो उन्हें एक हैंडल दिया जाता है:

var handle = queue.Enqueue(42, "forty two");

हैंडल निम्नलिखित सार्वजनिक एपीआई वाला एक वर्ग है:

public class PriorityQueueHandle<TKey, TValue>
{
    public TKey Key { get; }
    public TValue Value { get; }
}

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

इस तरह का दृष्टिकोण हमें प्राथमिकता कतार में एक बहुत ही सहज और सरल तरीके से एक अद्वितीय तत्व को आसानी से संशोधित करने की अनुमति देता है:

/*
 * User wants to retrieve a server that at any given moment
 * has the lowest average response time.
 * He doesn't want to maintain a separate key object (it is
 * inside his type) and the key is already comparable.
 */

var queue = new PriorityQueue<double, ServerStats>(selector);

/* adding some elements */

var handle = queue.Enqueue(server);

/*
 * Server stats are kept along with handles (e.g. in a dictionary).
 * Whenever there is a need of updating the priority of a certain
 * server, the user simply updates the appropriate ServerStats object
 * and then simply uses the handle associated with it:
 */

queue.Update(handle);

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

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

परिदृश्यों

परिदृश्य 7

• TKey और TValue अलग-अलग वस्तुएं हैं।

var queue = new PriorityQueue<int, string>();

var handle = queue.Enqueue(1, "three");
queue.Enqueue(1, "three");
queue.Enqueue(2, "three");

queue.Update(handle, 3);

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

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

var queue = new PriorityQueue<int, string>();

queue.Enqueue(1, "one");
queue.Enqueue(2, "three");
queue.Enqueue(3, "three");

queue.Update("three", 30);

ऊपर दी गई विधि पहले तत्व को "three" बराबर मान के साथ ढूंढती है। इसकी कुंजी को 30 अपडेट किया जाएगा। हालांकि, हम नहीं जानते कि शर्त को पूरा करने वाले एक से अधिक होने पर किसे अपडेट किया जाएगा।

यह Update(TKey oldKey, TValue, TKey newKey) विधि से थोड़ा सुरक्षित हो सकता है। यह एक और शर्त जोड़ता है - पुरानी कुंजी का भी मिलान होना चाहिए। दोनों समाधान सरल हैं, लेकिन 100% सुरक्षित और कम प्रदर्शनकारी नहीं हैं (O(1 + log n) बनाम O(n + log n))।

परिदृश्य 8

• TKey TValue भीतर समाहित है।

var queue = new PriorityQueue<int, MyClass>(selector);

/* adding some elements */

queue.Update(handle);

यह परिदृश्य वह है जो हैंडल अनुभाग में एक उदाहरण के रूप में दिया गया था।

उपरोक्त ओ (लॉग एन) में हासिल किया गया है। वैकल्पिक रूप से, उपयोगकर्ता एक विधि Update(TValue) उपयोग कर सकता है जो पहले तत्व को निर्दिष्ट के बराबर पाता है और आंतरिक पुनर्व्यवस्था करता है। बेशक, यह ओ (एन) है।

परिदृश्य 9

• TKey और TValue अलग-अलग वस्तुएं हैं, लेकिन एक ही प्रकार की हैं।

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

परिदृश्य 10

• उपयोगकर्ता डेटा एक एकल वस्तु है।

एक हैंडल के साथ, फिर कोई समस्या नहीं है। अन्य विधियों के माध्यम से अद्यतन करना आसान हो सकता है - लेकिन फिर से, कम प्रदर्शन करने वाला और हमेशा सही नहीं (बराबर प्रविष्टियां)।

एक तत्व को हटाना

एक हैंडल के माध्यम से सरल और सही ढंग से किया जा सकता है। वैकल्पिक रूप से, विधियों के माध्यम से Remove(TValue) और Remove(TKey, TValue) । पहले बताए गए समान मुद्दे।

दो संग्रह विलय

var queue1 = new PriorityQueue<int, string>();
var queue2 = new PriorityQueue<int, string>();

/* add some elements to both */

queue1.Merge(queue2);

टिप्पणियाँ

• विलय होने के बाद, कतारें समान आंतरिक प्रतिनिधित्व साझा करती हैं। उपयोगकर्ता दोनों में से किसी का भी उपयोग कर सकता है।
• प्रकारों का मिलान करना होता है (स्थिर रूप से जाँच की जाती है)।
• तुलना करने वालों को बराबर होना चाहिए, अन्यथा InvalidOperationException ।
• चयनकर्ताओं को समान होना चाहिए, अन्यथा InvalidOperationException ।

प्रस्तावित एपीआई

public class PriorityQueue<TKey, TValue>
    : IEnumerable,
    IEnumerable<PriorityQueueHandle<TKey, TValue>>,
    IReadOnlyCollection<PriorityQueueHandle<TKey, TValue>>
    // ICollection not included on purpose
{
    public PriorityQueue();
    public PriorityQueue(IComparer<TKey> comparer);
    public PriorityQueue(Func<TValue, TKey> keySelector);
    public PriorityQueue(Func<TValue, TKey> keySelector, IComparer<TKey> comparer);

    IComparer<TKey> Comparer { get; }
    Func<TValue, TKey> KeySelector { get; }
    public int Count { get; }

    public void Clear();

    public bool Contains(PriorityQueueHandle<TKey, TValue> handle); // O(log n)
    public bool Contains(TValue value); // O(n)
    public bool Contains(TKey key, TValue value); // O(n)

    public PriorityQueueHandle<TKey, TValue> Enqueue(TKey key, TValue value); // O(log n)
    public PriorityQueueHandle<TKey, TValue> Enqueue(TValue value); // O(log n)

    public PriorityQueueHandle<TKey, TValue> Peek(); // O(1)
    public PriorityQueueHandle<TKey, TValue> Dequeue(); // O(log n)

    public void Update(PriorityQueueHandle<TKey, TValue> handle); // O(log n)
    public void Update(PriorityQueueHandle<TKey, TValue> handle, TKey newKey); // O(log n)
    public void Update(TValue value, TKey newKey); // O(n)
    public void Update(TKey oldKey, TValue value, TKey newKey); // O(n)

    public void Remove(PriorityQueueHandle<TKey, TValue> handle); // O(log n)
    public void Remove(TValue value); // O(n)
    public void Remove(TKey key, TValue value); // O(n)

    public void Merge(PriorityQueue<TKey, TValue> other); // O(1)

    public IEnumerator<PriorityQueueHandle<TKey, TValue>> GetEnumerator();
    IEnumerator IEnumerable.GetEnumerator();
}

public class PriorityQueueHandle<TKey, TValue>
{
    public TKey Key { get; }
    public TValue Value { get; }
}

प्रश्न खोलें

इसके बजाय भविष्यवाणी करता है

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

• UpdateFirst(Func<PriorityQueueHandle<TKey, TValue>, bool> predicate)
• UpdateAll(Func<PriorityQueueHandle<TKey, TValue>, bool> predicate)

उपयोग बहुत प्यारा और शक्तिशाली होगा। और वास्तव में सहज ज्ञान युक्त। और पठनीय (बहुत अभिव्यंजक)। मैं उसी के लिए हूं।

var queue = new PriorityQueue<int, string>();

/* add some elements */

queue.UpdateAll(x => x.Key < 15, 0);

// or for example

queue.UpdateFirst(x => x.Value.State == State.Idle, 100);

नई कुंजी सेट करना संभावित रूप से एक फ़ंक्शन भी हो सकता है, जो पुरानी कुंजी लेता है और इसे किसी भी तरह बदल देता है।

Contains और Remove ।

अद्यतन कुंजी

यदि कुंजी चयनकर्ता परिभाषित नहीं है (और इस प्रकार कुंजी और मान अलग-अलग रखे जाते हैं), तो विधि को UpdateKey नाम दिया जा सकता है। यह शायद अधिक अभिव्यंजक है। जब कुंजी चयनकर्ता को परिभाषित किया जाता है, तो Update बेहतर होता है, क्योंकि कुंजी पहले ही अपडेट हो चुकी होती है और जो करने की आवश्यकता होती है वह प्राथमिकता कतार के भीतर कुछ तत्वों की पुनर्व्यवस्था है।

सामान्य प्रश्न

क्या हैंडल अक्षम नहीं हैं?

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

फिर आप इसे कैसे लागू करने जा रहे हैं?

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

यह कितना प्रदर्शनकारी होगा?

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

संदर्भ

• माइकल एल. फ़्रेडमैन, रॉबर्ट सेडगेविक, डेनियल डी. स्लेटर, और रॉबर्ट ई. टार्जन (1986), द पेयरिंग हीप: ए न्यू फॉर्म ऑफ़ सेल्फ- एडजस्टिंग हीप , एल्गोरिथम 1:111-129 ।
• डेनियल एच. लार्किन, सिद्धार्थ सेन, और रॉबर्ट ई. टार्जन (2014), ए बैक-टू-बेसिक्स एम्पिरिकल स्टडी ऑफ़ प्रायोरिटी क्यूई ,

बीटीडब्ल्यू, यह पहली एपीआई समीक्षा पुनरावृत्ति के लिए है। _open प्रश्नों_ वाले अनुभाग को हल करने की आवश्यकता है (मुझे आपकी राय चाहिए [और यदि संभव हो तो एपीआई समीक्षकों की])। यदि पहली पुनरावृत्ति कम से कम आंशिक रूप से गुजरती है, तो शेष चर्चा के लिए मैं एक नया मुद्दा बनाना चाहता हूं (इसे बंद करें और संदर्भ दें)।

जहां तक ​​​​मैं कह सकता हूं, एक इंटरफ़ेस या ढेर एपीआई समीक्षा पास नहीं करेगा।

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

@ बेंडोनो
ठीक है, Microsoft का अंतिम शब्द यहाँ है, कुछ लोग थ्रेड पर टिप्पणी नहीं कर रहे हैं। और हम जानते हैं कि:

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

इसे @karelz , सॉफ़्टवेयर इंजीनियर मैनेजर, और @terrajobst , प्रोग्राम मैनेजर और इस रिपॉजिटरी के मालिक + कुछ API समीक्षकों द्वारा साझा किया गया है।

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

फिर इस मुद्दे को बंद क्यों नहीं कर देते? इंटरफेस के बिना, यह वर्ग बेकार के करीब है।

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

और कृपया, मुझे इस तरह की बयानबाजी से बचाएं। यह वास्तव में बचकाना है - बेहतर करो।

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

@pgolebiowski बेशक यह Microsoft का निर्णय है। लेकिन एक एपीआई पेश करना बेहतर है जिसे आप उपयोग करना चाहते हैं जो आपकी आवश्यकताओं को पूरा करता है। अगर इसे खारिज कर दिया जाता है, तो ऐसा ही हो। मुझे प्रस्ताव से समझौता करने की आवश्यकता नहीं दिखती।

अगर आपने मेरी टिप्पणियों को आपको दोष देने के रूप में व्याख्यायित किया तो मैं क्षमा चाहता हूं। यह निश्चित रूप से मेरा इरादा नहीं था।

@pgolebiowski हैंडल के लिए KeyValuePair<TKey,TValue> उपयोग क्यों नहीं करते?

@ सैमुएलइंग्लार्ड

हैंडल के लिए KeyValuePair<TKey,TValue> उपयोग क्यों न करें?

• खैर, PriorityQueueHandle वास्तव में _ पेयरिंग हीप नोड _ है। यह दो गुणों को उजागर करता है - TKey Key और TValue Value । हालाँकि, इसके अंदर बहुत अधिक तर्क है, जो सिर्फ आंतरिक है। कृपया इसके मेरे कार्यान्वयन का संदर्भ लें। इसमें उदाहरण के लिए पेड़ में अन्य नोड्स के पॉइंटर्स भी शामिल हैं (कोरएफएक्स में सब कुछ आंतरिक होगा)।
• KeyValuePair एक संरचना है, इसलिए इसे हर बार कॉपी किया जाता है + इसे विरासत में नहीं लिया जा सकता है।
• लेकिन मुख्य बात यह है कि PriorityQueueHandle एक जटिल वर्ग है जो केवल उसी सार्वजनिक एपीआई को KeyValuePair रूप में बेनकाब करने के लिए होता है।

@ बेंडोनो

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

• यह सच है, मैं इसे ध्यान में रखूंगा और देखूंगा कि क्या होता है। @karelz , प्रस्ताव के साथ, क्या आप पिछली कुछ पोस्ट भी पास कर सकते हैं (वे प्रस्ताव से ठीक पहले हैं), जहां हमने इंटरफेस के लिए मतदान किया था? एपीआई समीक्षा के पहले पुनरावृत्ति के बाद, हम बाद में इस पर वापस आ सकते हैं।
• फिर भी, कोई फर्क नहीं पड़ता कि हम किस समाधान पर जाते हैं, कार्यक्षमता बहुत समान होगी और इसकी समीक्षा करना मददगार होगा। क्योंकि यदि हैंडल के लिए विचार अस्वीकार कर दिया गया है और हम वास्तव में तत्वों को ठीक से अपडेट / हटा नहीं सकते हैं (या हमारे पास अलग TKey और TValue ), तो यह वर्ग वास्तव में बेकार होने के करीब है - - जैसा कि अब जावा में है।
• विशेष रूप से, यदि हमारे पास इंटरफ़ेस नहीं है, तो मेरी AlgoKit लाइब्रेरी में CoreFX के साथ ढेर के लिए सामान्य कोर नहीं हो पाएगा, जो वास्तव में मेरे लिए दुखद होगा।
• और हाँ, यह मेरे लिए वास्तव में आश्चर्यजनक है कि एक इंटरफ़ेस जोड़ना Microsoft द्वारा एक नुकसान के रूप में माना जाता है।

यह निश्चित रूप से मेरा इरादा नहीं था।

क्षमा करें, तब मेरी गलती।

डिजाइन पर मेरे प्रश्न (अस्वीकरण: ये प्रश्न और स्पष्टीकरण, कोई कठिन धक्का नहीं (अभी तक)):

1. क्या हमें वास्तव में PriorityQueueHandle ? क्या होगा यदि हम कतार में अद्वितीय मूल्यों की अपेक्षा करते हैं?
   
   
   
   • प्रेरणा: यह बल्कि शामिल अवधारणा लगता है। अगर हमारे पास है, तो मैं यह समझना चाहूंगा कि हमें इसकी आवश्यकता क्यों है? यह कैसे मदद कर रहा है? या यह सिर्फ विशिष्ट कार्यान्वयन विवरण एपीआई सतह में लीक हो रहा है? क्या यह हमें एपीआई में जटिलता के लिए भुगतान करने के लिए इतना अधिक भुगतान करने जा रहा है?
   
   
2. क्या हमें Merge ? क्या अन्य संग्रहों में यह है? हमें एपीआई नहीं जोड़ना चाहिए, सिर्फ इसलिए कि उन्हें लागू करना आसान है, एपीआई के लिए कुछ सामान्य-ईश उपयोग के मामले होने चाहिए।
   
   
   
   • शायद IEnumerable<KeyValuePair<TKey, TValue>> से कुछ इनिशियलाइज़ेशन जोड़ना पर्याप्त होगा? + लिंक पर भरोसा करें
   
   
3. क्या हमें comparer अधिभार की आवश्यकता है? क्या हम हमेशा डिफ़ॉल्ट पर वापस आ सकते हैं? (अस्वीकरण: मुझे इस मामले में ज्ञान/विशेषज्ञता याद आ रही है, इसलिए बस पूछ रहा हूं)
4. क्या हमें keySelector ओवरलोड की आवश्यकता है? मुझे लगता है कि हमें यह तय करना चाहिए कि क्या हम मूल्य के हिस्से के रूप में प्राथमिकता चाहते हैं, या एक अलग चीज। अलग प्राथमिकता मुझे कुछ अधिक स्वाभाविक लगती है, लेकिन मेरे पास मजबूत राय नहीं है। क्या हम पेशेवरों बनाम विपक्ष को जानते हैं?

अलग/समानांतर निर्णय बिंदु:

1. कक्षा का नाम PriorityQueue बनाम Heap
2. IHeap और कंस्ट्रक्टर अधिभार का परिचय दें?

IHeap और कंस्ट्रक्टर अधिभार का परिचय दें?

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

जिस पर मेरी राय इतनी मजबूत नहीं है कि क्या हम इंटरफ़ेस को उसी समय PQueue/Heap/ILikeThisItemMoreThanThisItemList के रूप में करते हैं या यदि हम इसे बाद में जोड़ते हैं। तर्क है कि एपीआई "प्रवाह में" हो सकता है और इस तरह हमें इसे पहले कक्षा के रूप में जारी करना चाहिए जब तक कि हमें फीडबैक न मिले, निश्चित रूप से एक मान्य है जिससे मैं असहमत नहीं हूं। प्रश्न तब बन जाता है जब इसे एक इंटरफ़ेस जोड़ने के लिए पर्याप्त "स्थिर" माना जाता है। थ्रेड में ऊपर का रास्ता IList और IDictionary का उल्लेख उनके विहित कार्यान्वयन 'एपीआई से पिछड़ने के रूप में किया गया था, जिसे हमने कुछ समय पहले जोड़ा था, तो किस समय की अवधि को स्वीकार्य आराम अवधि माना जाता है?

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

और हाँ, यह मेरे लिए वास्तव में आश्चर्यजनक है कि एक इंटरफ़ेस जोड़ना Microsoft द्वारा एक नुकसान के रूप में माना जाता है।

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

इनपुट के लिए धन्यवाद, @karelz और @ianhays!

डुप्लीकेट की अनुमति

क्या हमें वास्तव में PriorityQueueHandle ? क्या होगा यदि हम कतार में अद्वितीय मूल्यों की अपेक्षा करते हैं?

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

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

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

public class PriorityQueue<TElement, TPriority>
    : IEnumerable,
    IEnumerable<(TElement element, TPriority priority)>,
    IReadOnlyCollection<(TElement element, TPriority priority)>
    // ICollection not included on purpose
{
    public PriorityQueue();
    public PriorityQueue(IComparer<TPriority> comparer);
    public PriorityQueue(Func<TElement, TPriority> prioritySelector);
    public PriorityQueue(Func<TElement, TPriority> prioritySelector, IComparer<TPriority> comparer);

    IComparer<TPriority> Comparer { get; }
    Func<TElement, TPriority> PrioritySelector { get; }
    public int Count { get; }

    public void Clear();
    public bool Contains(TElement element); // O(1)

    public (TElement element, TPriority priority) Peek(); // O(1)
    public (TElement element, TPriority priority) Dequeue(); // O(log n)

    public void Enqueue(TElement element, TPriority priority); // O(log n)
    public void Enqueue(TElement element); // O(log n)

    public void Update(TElement element); // O(log n)
    public void Update(TElement element, TPriority priority); // O(log n)

    public void Remove(TElement element); // O(log n)

    public IEnumerator<(TElement element, TPriority priority)> GetEnumerator();
    IEnumerator IEnumerable.GetEnumerator();
}

शीघ्र ही, एक अंतर्निहित Dictionary<TElement, InternalNode> । यह जांचना कि प्राथमिकता कतार में कोई तत्व है या नहीं, पिछले दृष्टिकोण की तुलना में और भी तेज़ी से किया जा सकता है। तत्वों को अद्यतन करना और हटाना काफी सरल है, क्योंकि हम हमेशा कतार में एक प्रत्यक्ष तत्व को इंगित कर सकते हैं।

संभवतः डुप्लिकेट की अनुमति देना परेशानी के लायक नहीं है और उपरोक्त पर्याप्त है। मुझे लगता है कि मैं इसे पसंद किया। तुम क्या सोचते हो?

मर्ज

क्या हमें Merge ? क्या अन्य संग्रहों में यह है? हमें एपीआई नहीं जोड़ना चाहिए, सिर्फ इसलिए कि उन्हें लागू करना आसान है, एपीआई के लिए कुछ सामान्य-ईश उपयोग के मामले होने चाहिए।

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

तुलनाकर्ता

क्या हमें तुलनित्र अधिभार की आवश्यकता है? क्या हम हमेशा डिफ़ॉल्ट पर वापस आ सकते हैं? (अस्वीकरण: मुझे इस मामले में ज्ञान/विशेषज्ञता याद आ रही है, इसलिए बस पूछ रहा हूं)

मुझे लगता है कि यह दो कारणों से बहुत महत्वपूर्ण है:

• एक उपयोगकर्ता अपने तत्वों को आरोही क्रम या अवरोही क्रम में क्रमबद्ध करना चाहता है। सर्वोच्च प्राथमिकता हमें यह नहीं बताती कि ऑर्डर कैसे करना चाहिए।
• यदि हम एक तुलनाकर्ता को छोड़ देते हैं, तो हम उपयोगकर्ता को हमेशा हमें एक वर्ग वितरित करने के लिए लागू करते हैं जो IComparable ।

साथ ही, यह मौजूदा एपीआई के अनुरूप है। SortedDictionary पर एक नज़र डालें।

चयनकर्ता

क्या हमें keySelector अधिभार की आवश्यकता है? मुझे लगता है कि हमें यह तय करना चाहिए कि क्या हम मूल्य के हिस्से के रूप में प्राथमिकता चाहते हैं, या एक अलग चीज। अलग प्राथमिकता मुझे कुछ अधिक स्वाभाविक लगती है, लेकिन मेरे पास मजबूत राय नहीं है। क्या हम पेशेवरों बनाम विपक्ष को जानते हैं?

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

चयनकर्ता के बारे में अभी...

पेशेवरों

यह वही है जो इस प्राथमिकता कतार को लचीला बनाता है। यह उपयोगकर्ताओं को यह करने की अनुमति देता है:

• तत्वों और उनकी प्राथमिकताओं को अलग तत्वों के रूप में
• तत्व (जटिल वर्ग) जिनके अंदर कहीं प्राथमिकताएं हैं
• एक बाहरी तर्क जो किसी दिए गए तत्व के लिए प्राथमिकता प्राप्त करता है
• तत्व जो IComparable

यह मेरे द्वारा सोचे जा सकने वाले हर कॉन्फ़िगरेशन की बहुत अधिक अनुमति देता है। मुझे यह उपयोगी लगता है, क्योंकि उपयोगकर्ता केवल "प्लग एन प्ले" कर सकते हैं। यह बल्कि सहज ज्ञान युक्त भी है।

दोष

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

अलग/समानांतर निर्णय बिंदु

वर्ग का नाम PriorityQueue बनाम Heap

IHeap और कंस्ट्रक्टर ओवरलोड का परिचय दें।

• ऐसा लगता है कि PriorityQueue को Heap बजाय CoreFX का हिस्सा होना चाहिए।
• IHeap इंटरफ़ेस के बारे में - क्योंकि एक प्राथमिकता कतार को ढेर से अलग कुछ के साथ लागू किया जा सकता है, शायद हम इसे इस तरह से उजागर नहीं करना चाहेंगे। हालांकि, हमें IPriorityQueue आवश्यकता हो सकती है।

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

पूर्णतया सहमत!

तुलनीय तत्व

यदि हम एक और धारणा जोड़ते हैं: तत्वों को तुलनीय होना चाहिए, तो एपीआई और भी आसान है। लेकिन फिर, यह कम लचीला है।

पेशेवरों

• IComparer की कोई आवश्यकता नहीं है।
• चयनकर्ता की कोई आवश्यकता नहीं है।
• एक Enqueue और Update विधि।
• दो के बजाय एक सामान्य प्रकार।

दोष

• हमारे पास अलग-अलग वस्तुओं के रूप में तत्व और प्राथमिकता नहीं हो सकती है। उपयोगकर्ताओं को एक नया रैपर-वर्ग प्रदान करने की आवश्यकता है यदि उनके पास उस प्रारूप में है।
• इस प्राथमिकता कतार का उपयोग करने से पहले उपयोगकर्ताओं को हमेशा IComparable लागू करने की आवश्यकता होती है।
• यदि हमारे पास तत्व और प्राथमिकताएं अलग हैं, तो हम बेहतर प्रदर्शन और मेमोरी उपयोग के साथ इसे आसान तरीके से कार्यान्वित कर सकते थे - आंतरिक शब्दकोश <TElement, InternalNode> और InternalNode में TPriority ।

public class PriorityQueue<T> : IEnumerable, IEnumerable<T>, IReadOnlyCollection<T>
    where T : IComparable<T>
    // ICollection not included on purpose
{
    public PriorityQueue();
    // some other constructors like building it from a collection, or initial capacity if we have an array beneath

    public int Count { get; }

    public void Clear();
    public bool Contains(T element);

    public T Peek();
    public T Dequeue();

    public void Enqueue(T element);
    public void Update(T element);
    public void Remove(T element);

    public IEnumerator<T> GetEnumerator();
    IEnumerator IEnumerable.GetEnumerator();
}

सब कुछ एक व्यापार बंद है। हम कुछ सुविधाओं को हटा देते हैं, कुछ लचीलापन खो देते हैं, लेकिन हो सकता है कि हमें अपने 95% उपयोगकर्ताओं को संतुष्ट करने के लिए इसकी आवश्यकता न हो।

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

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

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

ठीक है, मैं तुलनाकर्ता के बारे में आश्वस्त हूं, यह समझ में आता है और यह सुसंगत है।
मैं अभी भी चयनकर्ता पर फटा हुआ हूं - आईएमओ हमें इसके बिना जाने की कोशिश करनी चाहिए - आइए इसे 2 प्रकारों में विभाजित करें।

```सी#
सार्वजनिक वर्ग प्राथमिकता कतार
: आईनेमरेबल,
IEnumerable<(TElement तत्व, TP प्राथमिकता प्राथमिकता)>,
IReadOnlyCollection<(TElement तत्व, TP प्राथमिकता प्राथमिकता)>
// आईसीओलेक्शन उद्देश्य पर शामिल नहीं है
{
सार्वजनिक प्राथमिकता कतार ();
सार्वजनिक प्राथमिकता कतार (IComparer .)तुलनाकर्ता);

public IComparer<TPriority> Comparer { get; }
public int Count { get; }

public void Clear();
public bool Contains(TElement element); // O(1)

public (TElement element, TPriority priority) Peek(); // O(1)
public (TElement element, TPriority priority) Dequeue(); // O(log n)

public void Enqueue(TElement element, TPriority priority); // O(log n)
public void Update(TElement element, TPriority priority); // O(log n)

public void Remove(TElement element); // O(log n)

public IEnumerator<(TElement element, TPriority priority)> GetEnumerator();
IEnumerator IEnumerable.GetEnumerator();

//
// चयनकर्ता भाग
//
सार्वजनिक प्राथमिकता कतार (Func .)प्राथमिकता चयनकर्ता);
सार्वजनिक प्राथमिकता कतार (Func .)प्राथमिकता चयनकर्ता, आईसीओएमपेयरतुलनाकर्ता);

public Func<TElement, TPriority> PrioritySelector { get; }

public void Enqueue(TElement element); // O(log n)
public void Update(TElement element); // O(log n)

}
````

प्रश्न खोलें:

1. वर्ग का नाम PriorityQueue बनाम Heap
2. IHeap और कंस्ट्रक्टर अधिभार का परिचय दें? (क्या हमें बाद में इंतजार करना चाहिए?)
3. परिचय IPriorityQueue ? (क्या हमें बाद में प्रतीक्षा करनी चाहिए - IDictionary उदाहरण)
4. चयनकर्ता का उपयोग करें (मूल्य के अंदर संग्रहीत प्राथमिकता का) या नहीं (5 एपीआई अंतर)
5. टुपल्स का प्रयोग करें (TElement element, TPriority priority) बनाम KeyValuePair<TPriority, TElement>
   
   
   
   • क्या Peek और Dequeue बजाय टपल के बजाय out तर्क होना चाहिए?
   
   

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

फिक्स्ड Peek और Dequeue tuple फ़ील्ड नाम priority (धन्यवाद @pgolebiowski इसे इंगित करने के लिए)।
शीर्ष पोस्ट ऊपर नवीनतम प्रस्ताव के साथ अद्यतन किया गया।

मैं दूसरी @safern की टिप्पणी - इसे आगे बढ़ाने के लिए @pgolebiowski को बहुत-बहुत धन्यवाद!

प्रश्न खोलें:

मुझे लगता है कि हमारे यहां एक और हो सकता है:

1. अपने आप को केवल अद्वितीय तत्वों तक सीमित रखें (डुप्लिकेट की अनुमति न दें)।

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

क्या हमें bool से Remove वापस करना चाहिए? और out priority तर्क के रूप में भी प्राथमिकता? (मेरा मानना ​​​​है कि हमने हाल ही में अन्य डेटा संरचनाओं में समान अधिभार जोड़े हैं)

Contains - मुझे यकीन है कि कोई इसमें से प्राथमिकता चाहता है। हम out priority साथ एक अधिभार जोड़ना चाह सकते हैं।

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

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

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

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

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

मैं KeyValuePair का बिल्कुल भी उपयोग नहीं करने का समर्थन करता हूं, और या तो सादे टुपल्स का उपयोग करता हूं

मैं आपके साथ टुपल्स पर हूं।

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

• मुझे इंडेक्सर के साथ Dictionary भीतर समानता दिखाई देती है। वहां, जब आप dictionary["something"] = 5 तो यह अपडेट हो जाता है यदि "something" पहले वहां एक कुंजी थी। अगर यह वहां नहीं था, तो यह बस जुड़ जाता है।
• हालाँकि, Enqueue पद्धति मेरे लिए शब्दकोश में Add पद्धति के समान है। जिसका अर्थ है कि इसे अपवाद फेंकना चाहिए।
• उपरोक्त बिंदुओं को ध्यान में रखते हुए, हम आपके मन में व्यवहार का समर्थन करने के लिए प्राथमिकता कतार में एक अनुक्रमणिका जोड़ने पर विचार कर सकते हैं।
• लेकिन बदले में, एक अनुक्रमणिका कुछ ऐसा नहीं हो सकता है जो कतारों की अवधारणा के साथ काम करता हो।
• जो हमें इस निष्कर्ष पर ले जाता है कि अगर कोई डुप्लिकेट तत्व जोड़ना चाहता है तो Enqueue विधि को अपवाद फेंकना चाहिए। इसी तरह, Update विधि को एक अपवाद फेंकना चाहिए यदि कोई किसी ऐसे तत्व की प्राथमिकता को अद्यतन करना चाहता है जो मौजूद नहीं है।
• जो हमें एक नए समाधान की ओर ले जाता है -- TryUpdate विधि जोड़ें जो वास्तव में bool लौटाती है।

मैं चयनकर्ता के प्रस्ताव का समर्थन नहीं करता, साधारण कारण से कि यह अतिरेक का तात्पर्य है

क्या ऐसा नहीं है कि कुंजी को भौतिक रूप से कॉपी नहीं किया गया है (यदि यह मौजूद है), लेकिन चयनकर्ता केवल एक फ़ंक्शन बना रहता है जिसे प्राथमिकताओं का मूल्यांकन करने की आवश्यकता होने पर कॉल किया जाता है? अतिरेक कहाँ है?

मुझे लगता है कि प्राथमिकता और तत्व को अलग करने से संभावित समस्या से बचने में मदद मिलेगी

एकमात्र समस्या तब होती है जब ग्राहक के पास भौतिक प्राथमिकता नहीं होती है। तब वह बहुत कुछ नहीं कर सकता।

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

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

var queue = new PriorityQueue<string, double>();

queue.Enqueue("first", 0.1);
queue.Enqueue("first", 0.5); // should be unsuccessful IMO

@VisualMelon क्या

@pgolebiowski

मैं TryUpdate जोड़ने के साथ पूरी तरह सहमत हूं, और Update फेंकना मुझे समझ में आता है। मैं ISet की तर्ज पर Enqueue (बजाय IDictionary ) के बारे में सोच रहा था। फेंकना भी समझ में आता है, मैंने उस बिंदु को याद किया होगा, लेकिन मुझे लगता है कि वापसी bool प्रकार की 'सेटनेस' बताती है। शायद एक TryEnqueue क्रम में भी होगा ( Add फेंकने के साथ)? एक TryRemove की भी सराहना की जाएगी (खाली होने पर विफल)। आपके अंतिम बिंदु के संबंध में, हाँ, यही व्यवहार मेरे मन में भी था। मैं के साथ एक सादृश्य लगता है IDictionary तुलना में बेहतर है ISet प्रतिबिंब पर, और कहा कि स्पष्ट पर्याप्त होना चाहिए। (संक्षेप में: मैं आपके सुझाव के अनुसार सब कुछ फेंकने का समर्थन करता हूं, लेकिन यदि ऐसा है तो Try* होना जरूरी है; मैं विफलता की स्थिति के बारे में आपके बयानों से भी सहमत हूं)।

इंडेक्सर के संबंध में, मुझे लगता है कि आप सही हैं कि यह वास्तव में कतार अवधारणा को 'फिट' नहीं करता है, मैं इसका समर्थन नहीं करता। यदि कुछ भी, कतार या अद्यतन के लिए एक अच्छी तरह से नामित विधि क्रम में होगी।

क्या ऐसा नहीं है कि कुंजी को भौतिक रूप से कॉपी नहीं किया गया है (यदि यह मौजूद है), लेकिन चयनकर्ता केवल एक फ़ंक्शन बना रहता है जिसे प्राथमिकताओं का मूल्यांकन करने की आवश्यकता होने पर कॉल किया जाता है? अतिरेक कहाँ है?

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

ध्यान दें कि चयनकर्ता प्रस्ताव के साथ अब तक मेरी सभी घोषित पकड़ एपीआई की मजबूती के बारे में हैं: मुझे लगता है कि चयनकर्ता गलत तरीके से उपयोग करना आसान बनाता है। हालांकि, उपयोगिता एक तरफ, अवधारणात्मक रूप से, कतार में तत्वों को उनकी प्राथमिकता नहीं जाननी चाहिए। यह उनके लिए संभावित रूप से अप्रासंगिक है, और यदि उपयोगकर्ता अपने तत्वों को struct Queable<T>{} या कुछ और में लपेटता है तो यह एक घर्षण रहित एपीआई प्रदान करने में विफलता की तरह लगता है (जितना मुझे इस शब्द का उपयोग करने के लिए दर्द होता है)।

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

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

_संपादित करें: हालांकि इसके बारे में कुछ और होने के बावजूद, स्वयं निहित PriorityQueue s होना बहुत अच्छा होगा, जिसे आप केवल तत्वों को फेंक सकते हैं, लेकिन मेरा मानना ​​​​है कि इसके आसपास काम करने की लागत बहुत अच्छी होगी, जबकि शुरू करने की लागत काफी कम होगी।_

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

उपयोग 1: रोसलिन अधिसूचना सेवा
https://github.com/dotnet/roslyn/
रोसलिन कंपाइलर में एक निजी प्राथमिकता कतार कार्यान्वयन शामिल है जिसे "प्राथमिकता क्यू" कहा जाता है जो इसमें एक बहुत ही विशिष्ट अनुकूलन प्रतीत होता है - एक ऑब्जेक्ट कतार जो कतार में वस्तुओं का पुन: उपयोग करने के लिए कचरा एकत्र होने से बचने के लिए है। Enqueue_NoLock विधि current.Value.MinimumRunPointInMS < entry.Value.MinimumRunPointInMS पर मूल्यांकन करती है ताकि यह निर्धारित किया जा सके कि नया नोड कहां रखा जाए। यहां प्रस्तावित दो मुख्य प्राथमिकता कतार डिजाइनों में से कोई भी (तुलनात्मक कार्य/प्रतिनिधि बनाम स्पष्ट प्राथमिकता) इस उपयोग परिदृश्य में फिट होगा।

उपयोग 2: Lucene.net
https://github.com/apache/lucenenet
यह यकीनन .NET में मिलने वाली प्रायोरिटी क्यू के लिए सबसे बड़ा उपयोग उदाहरण है। Apache Lucene.net लोकप्रिय Lucene सर्च इंजन लाइब्रेरी का एक पूर्ण .net पोर्ट है। हम अपनी कंपनी में जावा संस्करण का उपयोग करते हैं, और अपाचे की वेबसाइट के अनुसार कुछ बड़े नाम .NET संस्करण का उपयोग करते हैं। Github में .NET प्रोजेक्ट के लिए बड़ी संख्या में कांटे हैं।

ल्यूसीन में अपना स्वयं का प्रायोरिटी क्यू कार्यान्वयन शामिल है जो कई "विशिष्ट" प्राथमिकता कतारों द्वारा उपवर्गित है: HitQueue, TopOrdAndFloatQueue, PhraseQueue, और सुझावWordQueue। साथ ही, प्रोजेक्ट कई जगहों पर प्रायोरिटी क्यू को सीधे इंस्टेंट करता है।

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

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

उनके कोड आधार के माध्यम से बड़ी संख्या में उपयोग के उदाहरण हैं, उनमें से एक

SloppyPhraseScorer का कंस्ट्रक्टर एक नए PhraseQueue (pq) को इंस्टेंट करता है, जो कि उनके अपने प्रायोरिटी क्यू के कस्टम उपवर्गों में से एक है। PhrasePositions का एक संग्रह उत्पन्न होता है, जो पोस्टिंग के एक सेट, एक स्थिति और शर्तों के एक सेट के लिए एक आवरण प्रतीत होता है। फिलक्यू विधि वाक्यांश पदों पर गणना करती है और उन्हें कतारबद्ध करती है। PharseFreq() एक AdvancePP फ़ंक्शन को कॉल करता है और, उच्च स्तर पर, एक आइटम की प्राथमिकता को अद्यतन करने, और फिर फिर से कतारबद्ध करने के लिए प्रतीत होता है। प्राथमिकता स्पष्ट रूप से निर्धारित की जाती है (एक तुलनाकर्ता का उपयोग करके) स्पष्ट रूप से (प्राथमिकता एनक्यू के दौरान दूसरे पैरामीटर के रूप में "पास" नहीं होती है)।

आप देख सकते हैं कि PhraseQueue के उनके कार्यान्वयन के आधार पर कंस्ट्रक्टर (जैसे पूर्णांक) के माध्यम से पारित एक तुलना मूल्य इसे काट नहीं सकता है। उनका तुलना फ़ंक्शन ("लेसथान") तीन अलग-अलग क्षेत्रों का मूल्यांकन करता है: PhrasePositions.doc, PhrasePositions.position, और PhrasePositions.offset।

उपयोग 3: खेल विकास
मैंने इस स्थान में उपयोग के उदाहरणों के माध्यम से खोज समाप्त नहीं की है, लेकिन मैंने कस्टम .NET प्रायोरिटी क्यू के कुछ उदाहरण गेम विकास में उपयोग किए जा रहे हैं। एक बहुत ही सामान्य अर्थ में इन्हें मुख्य उपयोग के मामले (दिज्क्स्ट्रा) के रूप में पाथफाइंडिंग के आसपास क्लस्टर किया जाता है। आप बहुत से लोगों को यह पूछते हुए पा सकते हैं कि यूनिटी 3डी के कारण .NET में पाथफाइंडिंग एल्गोरिदम को कैसे लागू किया जाए।

अभी भी इस क्षेत्र के माध्यम से खोदने की जरूरत है; स्पष्ट प्राथमिकता के साथ कुछ उदाहरण देखे जा रहे हैं और कुछ उदाहरण तुलनित्र/IComparable का उपयोग कर रहे हैं।

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

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

@ एबिकले

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

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

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

बढ़िया चर्चा। @ebicle का शोध बेहद उपयोगी आईएमओ है!
@ebickle क्या आपने [2] lucene.net पर निष्कर्ष निकाला है - क्या हमारा नवीनतम प्रस्ताव उपयोग के लिए उपयुक्त है या नहीं? (मुझे आशा है कि मैंने इसे आपके विस्तृत विवरण में याद नहीं किया है)

ऐसा लगता है कि हमें ऊपर से Try* वेरिएंट चाहिए + IsEmpty + TryPeek / TryDequeue + EnqueueOrUpdate ? विचार?
```सी#
सार्वजनिक बूल IsEmpty ();

public bool TryPeek(ref TElement element, ref TPriority priority); // false if empty
public bool TryDequeue(ref TElement element, ref TPriority priority); // false if empty

public bool TryEnqueue(TElement element, TPriority priority); // false if it is duplicate (doe NOT update it)
public void EnqueueOrUpdate(TElement element, TPriority priority); // TODO: Should return bool status for enqueued vs. updated?
public bool TryUpdate(TElement element, TPriority priority); // false if element does not exist (does NOT add it)

public bool TryRemove(TElement element); // false if element does not exist

```

@ करेल्ज़

ऐसा लगता है कि हमें ऊपर से Try* वेरिएंट की आवश्यकता है

हाँ बिल्कुल।

संलग्न बनाम अद्यतन के लिए बूल स्थिति वापस करनी चाहिए?

अगर हम हर जगह स्टेटस वापस करना चाहते हैं, तो हर जगह। इस विशेष विधि के लिए, मुझे लगता है कि यह सच होना चाहिए यदि कोई भी ऑपरेशन सफल हुआ ( Enqueue या Update )।

बाकी के लिए - मैं बस सहमत हूं: मुस्कान:

सिर्फ एक सवाल -- क्यों ref बजाय out ? मुझे यकीन नहीं है:

• फ़ंक्शन में प्रवेश करने से पहले हमें इसे प्रारंभ करने की आवश्यकता नहीं है।
• इसका उपयोग विधि के लिए नहीं किया जाता है (यह बस निकल जाता है)।

अगर हम हर जगह स्टेटस वापस करना चाहते हैं, तो हर जगह। इस विशेष विधि के लिए, मुझे लगता है कि यह सच होना चाहिए यदि कोई भी ऑपरेशन सफल हुआ ( Enqueue या Update )।

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

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

यह हमेशा सच लौटेगा

तुम सही हो, मेरे बुरे। माफ़ करना।

मेरे पास स्वयं निर्णय लेने के लिए मजबूत राय/पर्याप्त अनुभव नहीं है।

शायद मुझे कुछ याद आ रहा है, लेकिन मुझे यह बहुत आसान लगता है। यदि हम ref उपयोग करते हैं, तो हम मूल रूप से कह रहे हैं कि Peek और Dequeue किसी भी तरह से TElement और TPriority का उपयोग करना चाहते हैं ( मेरा मतलब है कि उन क्षेत्रों को पढ़ें )। जो वास्तव में मामला नहीं है - हमारे तरीकों को केवल उन चरों को मान निर्दिष्ट करना चाहिए (और वास्तव में उन्हें संकलक द्वारा ऐसा करने की आवश्यकता होती है)।

टॉप-पोस्ट मेरे Try* एपीआई के साथ अपडेट किया गया
2 खुले प्रश्न जोड़े गए:

• [6] क्या Peek और Dequeue फेंकना उपयोगी है?
• [7] TryPeek और TryDequeue - ref या out args का उपयोग करना चाहिए?

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

6: मुझे कुछ याद आ रहा है, लेकिन अगर कोई अपवाद नहीं फेंक रहा है, तो कतार खाली होने पर Peek या Dequeue क्या करना चाहिए? मुझे लगता है कि यह सवाल पूछना शुरू कर देता है कि क्या डेटा संरचना को null स्वीकार करना चाहिए (मैं पसंद नहीं करूंगा, लेकिन कोई दृढ़ राय नहीं)। भले ही हम null अनुमति देते हैं, मान प्रकारों में कोई null ( default निश्चित रूप से गिनती नहीं है), इसलिए Peek और Dequeue है एक अर्थहीन परिणाम व्यक्त करने का कोई तरीका नहीं है, और मुझे लगता है कि विधिवत एक अपवाद फेंकना चाहिए (इस प्रकार out मापदंडों के बारे में किसी भी चिंता को दूर करना!)। मुझे मौजूदा Queue.Dequeue . के उदाहरण का अनुसरण न करने का कोई कारण नहीं दिखता

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

यदि कोई अपवाद नहीं फेंक रहा है, तो कतार खाली होने पर पीक या डेक्यू को क्या करना चाहिए?

सत्य।

इस प्रकार आउट पैरामीटर के बारे में किसी भी चिंता को दूर करना!

कैसे? खैर, out पैरामीटर TryPeek और TryDequeue विधियों के लिए हैं। अपवाद फेंकने वाले Peek और Dequeue ।

मैं सिर्फ इतना जोड़ूंगा कि दिज्क्स्ट्रा को किसी भी प्राथमिकता परिवर्तन की आवश्यकता नहीं होनी चाहिए।

मैं गलत हो सकता हूं, लेकिन मेरी जानकारी के अनुसार, डिजस्ट्रा का एल्गोरिदम DecreaseKey ऑपरेशन का उपयोग करता है। उदाहरण के लिए यह देखें। यह कुशल है या नहीं यह एक अलग पहलू है। वास्तव में, फाइबोनैचि हीप को इस तरह से डिजाइन किया गया था जो DecreaseKey ऑपरेशन को O(1) (दिज्क्स्ट्रा को बेहतर बनाने के लिए) में असम्बद्ध रूप से प्राप्त करता है।

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

क्षमा करें, हाँ, मुझे अब out पैराम्स के साथ समस्या दिखाई दे रही है, चीजों को फिर से गलत तरीके से पढ़ा जा रहा है। और ऐसा लगता है कि डिजस्ट्रा का एक प्रकार (एक नाम जो मेरे विश्वास से अधिक व्यापक रूप से लागू होता है ...) को शायद अधिक कुशलता से लागू किया जा सकता है (यदि आपकी कतार में पहले से ही तत्व शामिल हैं, तो संभवतः दोहराने योग्य खोजों के लिए लाभ है) अद्यतन करने योग्य प्राथमिकताएँ। मुझे लंबे शब्दों और नामों का उपयोग करने के लिए यही मिलता है। ध्यान दें कि मैं प्रस्तावित नहीं कर रहा हूं कि हम Update , यह केवल अच्छा होगा कि एक स्लिमर Heap या अन्य (यानी मूल प्रस्ताव) इस क्षमता को लगाए बिना प्रतिबंध के (शानदार के रूप में) एक क्षमता जैसा कि मैं इसकी सराहना करता हूं)।

7: ये out होने चाहिए। किसी भी इनपुट का कभी कोई अर्थ नहीं हो सकता है, इसलिए मौजूद नहीं होना चाहिए (यानी हमें ref साथ नहीं जाना चाहिए)। out पैराम्स के साथ, हम default मान वापस करने पर सुधार नहीं करने जा रहे हैं। यह वही है जो Dictionary.TryGetValue करता है, और मुझे अन्यथा करने का कोई कारण नहीं दिखता। _उस ने कहा, आप ref को मान या डिफ़ॉल्ट मान सकते हैं, लेकिन यदि आपके पास कोई सार्थक डिफ़ॉल्ट नहीं है तो यह मामलों को निराश करता है।_

एपीआई समीक्षा चर्चा:

• हमें सभी पेशेवरों / विपक्षों पर चर्चा करने के लिए एक उचित डिजाइन मीटिंग (2h) की आवश्यकता होगी, आज हमने जो 30 मिनट का निवेश किया, वह खुले प्रश्नों पर आम सहमति / बंद करने के लिए पर्याप्त नहीं था।
  
  
  
  • हम सबसे अधिक निवेशित समुदाय के सदस्यों को आमंत्रित करेंगे - @pgolebiowski , किसी और को?
  
  

यहाँ प्रमुख कच्चे नोट हैं:

• प्रयोग - हमें
  
  
  
  • हमने अतीत में ImmutableCollections लिए भी ऐसा ही किया था (तेजी से पूर्वावलोकन रिलीज चक्र एपीआई को आकार देने में महत्वपूर्ण और सहायक था)।
  
  
  • हम इस प्रयोग को MultiValueDictionary साथ जोड़ सकते हैं जो पहले से CoreFxLab में है। TODO: जांचें कि क्या हमारे पास अधिक उम्मीदवार हैं, हम उनमें से प्रत्येक को अलग-अलग ब्लॉग पोस्ट नहीं करना चाहते हैं।
  
  
  • प्रयोग समाप्त होने के बाद प्रयोगात्मक NuGet पैकेज को बंद कर दिया जाएगा और हम स्रोत कोड को CoreFX या CoreFXExtensions (बाद में तय किया जाएगा) में स्थानांतरित कर देंगे।
  
  
• विचार: Peek और Dequeue TElement से केवल TPriority वापस न करें (उपयोगकर्ता इसके लिए Try* विधियों का उपयोग कर सकते हैं)।
• स्थिरता (समान प्राथमिकताओं के लिए) - समान प्राथमिकताओं वाली वस्तुओं को उसी क्रम में वापस किया जाना चाहिए जिस क्रम में उन्हें कतार में डाला गया था (सामान्य कतार व्यवहार)
• हम डुप्लीकेट सक्षम करना चाहते हैं (अन्य संग्रहों के समान):
  
  
  
  • Update से छुटकारा पाएं - उपयोगकर्ता Remove और फिर Enqueue आइटम को अलग प्राथमिकता के साथ वापस कर सकता है।
  
  
  • Remove केवल पहली मिली वस्तु को हटा देना चाहिए (जैसा कि List करता है)।
  
  
• विचार: क्या हम IQueue इंटरफ़ेस को अमूर्त Queue और PriorityQueue ( Peek और Dequeue केवल TElement लौटाने में मदद कर सकते हैं यहां)
  
  
  
  • नोट: यह असंभव साबित हो सकता है, लेकिन हमें एपीआई पर बसने से पहले इसका पता लगाना चाहिए
  
  

हमने चयनकर्ता के बारे में लंबी चर्चा की - हम अभी भी तय नहीं हैं (ऊपर IQueue आवश्यकता हो सकती है?) अधिकांश लोगों को चयनकर्ता पसंद नहीं आया, लेकिन भविष्य की एपीआई समीक्षा बैठक में चीजें बदल सकती हैं।

अन्य खुले प्रश्नों पर चर्चा नहीं की गई।

नवीनतम प्रस्ताव मुझे बहुत अच्छा लग रहा है। मेरी राय/प्रश्न:

1. यदि Peek और Dequeue ने out पैरामीटर का उपयोग priority , तो उनके पास ओवरलोड भी हो सकते हैं जो प्राथमिकता बिल्कुल नहीं लौटाते हैं, जो मुझे लगता है कि सरल होगा सामान्य उपयोग। हालांकि एक त्याग का उपयोग करके प्राथमिकता को भी अनदेखा किया जा सकता है, जो इसे कम महत्वपूर्ण बनाता है।
2. मुझे यह पसंद नहीं है कि चयनकर्ता संस्करण एक अलग कंस्ट्रक्टर का उपयोग करके अलग किया जाता है और तरीकों के एक अलग सेट को सक्षम करता है। शायद एक अलग PriorityQueue<T> होना चाहिए? या PriorityQueue<T, T> साथ काम कर रहे स्थिर और विस्तार विधियों का एक सेट?
3. क्या यह परिभाषित किया गया है कि गणना करते समय तत्वों को किस क्रम में लौटाया जाता है? मेरा अनुमान है कि इसे कुशल बनाने के लिए यह अपरिभाषित है।
4. क्या प्राथमिकताओं को अनदेखा करते हुए, प्राथमिकता कतार में केवल वस्तुओं की गणना करने का कोई तरीका होना चाहिए? या priorityQueue.Select(t => t.element) स्वीकार्य जैसी किसी चीज़ का उपयोग करना पड़ रहा है?
5. यदि प्राथमिकता कतार आंतरिक रूप से तत्व प्रकार पर Dictionary का उपयोग कर रही है, तो क्या IEqualityComparer<TElement> पास करने का विकल्प होना चाहिए?
6. Dictionary का उपयोग करके तत्वों को ट्रैक करना अनावश्यक ओवरहेड है यदि मुझे कभी भी प्राथमिकताओं को अपडेट करने की आवश्यकता नहीं है। क्या इसे निष्क्रिय करने का कोई विकल्प होना चाहिए? हालांकि इसे बाद में जोड़ा जा सकता है, अगर यह पता चलता है कि यह उपयोगी है।

@ करेल्ज़

स्थिरता (समान प्राथमिकताओं के लिए) - समान प्राथमिकताओं वाली वस्तुओं को उसी क्रम में वापस किया जाना चाहिए जिस क्रम में उन्हें कतार में डाला गया था (सामान्य कतार व्यवहार)

मुझे लगता है कि इसका मतलब यह होगा कि आंतरिक रूप से, प्राथमिकता (priority, version) की एक जोड़ी की तरह होनी चाहिए, जहां प्रत्येक जोड़ के लिए version में वृद्धि की जाती है। मुझे लगता है कि प्राथमिकता कतार के स्मृति उपयोग में काफी कमी आएगी, विशेष रूप से यह देखते हुए कि version 64 बिट्स होने की संभावना है। मुझे यकीन नहीं है कि यह इसके लायक होगा।

हम डुप्लिकेट मानों को रोकना नहीं चाहते (अन्य संग्रहों के समान):
Update से छुटकारा पाएं - उपयोगकर्ता Remove और फिर Enqueue आइटम को अलग प्राथमिकता के साथ वापस कर सकता है।

कार्यान्वयन के आधार पर, Update Remove बाद Enqueue तुलना में कहीं अधिक कुशल होने की संभावना है। उदाहरण के लिए, द्विआधारी ढेर के साथ (मुझे लगता है कि चतुर्धातुक ढेर में एक ही समय जटिलताएं हैं), Update (अद्वितीय मूल्यों और एक शब्दकोश के साथ) ओ (लॉग एन ) है, जबकि Remove (डुप्लिकेट मानों के साथ) और कोई शब्दकोश नहीं) ओ ( एन ) है।

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

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

@ करेल्ज़
Lucene.net में कम से कम एक प्राथमिकता कतार तुलना फ़ंक्शन होता है (तुलना के समान) जो प्राथमिकता निर्धारित करने के लिए कई क्षेत्रों का मूल्यांकन करता है। ल्यूसीन का "अंतर्निहित" तुलना पैटर्न वर्तमान एपीआई प्रस्ताव के स्पष्ट टीपीआरओरिटी पैरामीटर में अच्छी तरह से मैप नहीं करेगा। किसी प्रकार के मानचित्रण की आवश्यकता होगी - एकाधिक क्षेत्रों को एक या एक 'तुलनीय' डेटा संरचना में संयोजित करना जिसे TP प्राथमिकता के रूप में पारित किया जा सकता है।

प्रस्ताव:
1) प्राथमिकता कतारउपरोक्त मेरे मूल प्रस्ताव के आधार पर वर्ग (मूल प्रस्ताव शीर्षक के तहत सूचीबद्ध)। संभावित रूप से अपडेट (टी), निकालें (टी), और कंटेन्स (टी) सुविधा फ़ंक्शन जोड़ें। ओपन सोर्स समुदाय से मौजूदा उपयोग के अधिकांश उदाहरणों को फिट करता है।
2) प्राथमिकता कतारडॉटनेट/कोरएफएक्स#1 का संस्करण। Dequeue () और Peek () टपल के बजाय TElement लौटाते हैं। कोई कोशिश नहीं * फ़ंक्शन, निकालें () सूची में फिट करने के लिए फेंकने के बजाय बूल लौटाता हैपैटर्न। एक 'सुविधा प्रकार' के रूप में कार्य करता है, इसलिए जिन डेवलपर्स के पास एक स्पष्ट प्राथमिकता मूल्य है, उन्हें अपने स्वयं के तुलनीय प्रकार बनाने की आवश्यकता नहीं है।

दोनों प्रकार डुप्लिकेट तत्वों का समर्थन करते हैं। यह निर्धारित करने की आवश्यकता है कि हम समान प्राथमिकता वाले तत्वों के लिए फीफो की गारंटी देते हैं या नहीं; यदि हम प्राथमिकता अद्यतनों का समर्थन करते हैं तो संभवत: नहीं।

CoreFxLabs में @karelz के सुझाव के अनुसार दोनों प्रकारों का निर्माण करें और प्रतिक्रिया

प्रशन:

public void Enqueue(TElement element, TPriority priority); // Throws if it is duplicate`
public bool TryEnqueue(TElement element, TPriority priority); // Returns false if it is duplicate (does NOT update it)

डुप्लिकेट क्यों नहीं?

public (TElement element, TPriority priority) Peek(); // Throws if empty
public (TElement element, TPriority priority) Dequeue(); // Throws if empty
public void Remove(TElement element); // Throws if element does not exist

यदि ये विधियाँ वांछनीय हैं, तो क्या इन्हें विस्तार विधियों के रूप में लें?

public void Enqueue(TElement element);
public void Update(TElement element);

फेंकना चाहिए; लेकिन क्यों नहीं संस्करण का प्रयास करें, विस्तार विधियां भी?

संरचना आधारित गणक?

बदसूरत हैंडल प्रकार से बचने के लिए मूल रूप से (मेरे द्वारा) डुप्ली पर फेंकने वाले

जब हम उन्हें प्रकार पर जोड़ सकते हैं तो हमें विधियों को विस्तार विधियों के रूप में नहीं जोड़ना चाहिए। एक्सटेंशन विधियां बैकअप हैं यदि हम उन्हें प्रकार पर नहीं जोड़ सकते हैं (उदाहरण के लिए यह इंटरफ़ेस है, या हम इसे .NET Framework पर तेज़ी से वितरित करना चाहते हैं)।

डुप्स: यदि आपके पास कई प्रविष्टियां हैं जो समान हैं तो आपको केवल एक को अपडेट करने की आवश्यकता है? तब वे अलग हो जाते हैं?

फेंकने के तरीके: मूल रूप से रैपर हैं और वे होंगे?

public void Remove(TElement element)
{
    if (!TryRemove(element))
    {
        throw new Exception();
    }
}

हालांकि इसका नियंत्रण अपवादों के माध्यम से प्रवाहित होता है?

@benadams एपीआई समीक्षा नोट्स के साथ मेरे उत्तर की जांच करें: https://github.com/dotnet/corefx/issues/574#issuecomment -308206064

• हम डुप्लीकेट सक्षम करना चाहते हैं (अन्य संग्रहों के समान):
  
  
  
  • Update से छुटकारा पाएं - उपयोगकर्ता Remove और फिर Enqueue आइटम को अलग प्राथमिकता के साथ वापस कर सकता है।
  
  
  • Remove केवल पहली मिली वस्तु को हटा देना चाहिए (जैसा कि List करता है)।
  
  

हालांकि इसका नियंत्रण अपवादों के माध्यम से प्रवाहित होता है?

पक्का नहीं आपका क्या मतलब है। यह बीसीएल में एक बहुत ही सामान्य पैटर्न की तरह लगता है।

हालांकि इसका नियंत्रण अपवादों के माध्यम से प्रवाहित होता है?

पक्का नहीं आपका क्या मतलब है।

यदि आपके पास सिर्फ TryX विधियां हैं

• यदि आप परिणाम की परवाह करते हैं; आप इसे जांचें
• यदि आप परिणाम की परवाह नहीं करते हैं तो आप इसकी जांच नहीं करते हैं

कोई अपवाद भागीदारी नहीं; लेकिन नाम आपको रिटर्न को फेंकने का निर्णय लेने के लिए प्रोत्साहित करता है।

यदि आपके पास गैर-कोशिश अपवाद फेंकने के तरीके हैं

• यदि आप परिणाम की परवाह करते हैं; आपको या तो पूर्व-जांच करनी होगी या पता लगाने के लिए कोशिश/पकड़ का उपयोग करना होगा
• यदि आप परिणाम की परवाह नहीं करते हैं; आपको या तो विधि को खाली करना होगा, या अप्रत्याशित अपवाद प्राप्त करना होगा

तो आप प्रवाह-नियंत्रण के लिए अपवाद हैंडलिंग का

यह बीसीएल में एक बहुत ही सामान्य पैटर्न की तरह लगता है।

ट्राईएक्स विधियां मूल बीसीएल में एक सामान्य पैटर्न नहीं थीं; समवर्ती प्रकारों तक (हालांकि लगता है कि 2.0 में Dictionary.TryGetValue पहला उदाहरण हो सकता है?)

उदाहरण के लिए TryX विधियों को केवल क्यू और स्टैक के लिए कोर में जोड़ा गया है और अभी तक फ्रेमवर्क का हिस्सा नहीं हैं।

स्थिरता

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

IQueue

तब एपीआई संघर्ष हैं। आइए अब एक साधारण IQueue<T> ताकि यह मौजूदा Queue<T> :

public interface IQueue<T> :
    IEnumerable,
    IEnumerable<T>,
    IReadOnlyCollection<T>
{
    void Enqueue(T element);

    T Peek();
    T Dequeue();

    bool TryPeek(out T element);
    bool TryDequeue(out T element);
}

प्राथमिकता कतार के लिए हमारे पास दो विकल्प हैं:

1. IQueue<TElement> ।
2. IQueue<(TElement, TPriority)> ।

मैं केवल संख्या (1) और (2) का उपयोग करके दोनों पथों के निहितार्थ लिखूंगा।

कतारबद्ध करें

प्राथमिकता कतार में, हमें एक तत्व और उसकी प्राथमिकता (वर्तमान समाधान) दोनों को कतारबद्ध करने की आवश्यकता है। साधारण ढेर में, हम केवल एक तत्व जोड़ते हैं।

1. पहले मामले में, हम Enqueue(TElement) पर्दाफाश करते हैं, जो प्राथमिकता कतार के लिए बहुत अजीब है अगर हम प्राथमिकता के बिना तत्व डाल रहे हैं। हम मजबूर हैं तो क्या करें... क्या? मान लें default(TPriority) ? नहीं...
2. दूसरे मामले में, हम Enqueue((TElement, TPriority) element) पर्दाफाश करते हैं। हम अनिवार्य रूप से उनमें से बनाए गए टपल को स्वीकार करके दो तर्क जोड़ते हैं। शायद आदर्श एपीआई नहीं।

पीक और Dequeue

आप चाहते थे कि वे विधियां केवल TElement लौटाएं।

1. आप जो हासिल करना चाहते हैं उसके साथ काम करता है।
2. आप जो हासिल करना चाहते हैं उसके साथ काम नहीं करता - (TElement, TPriority) ।

की गणना

1. ग्राहक कोई भी LINQ क्वेरी नहीं लिख सकता है जो तत्वों की प्राथमिकताओं का उपयोग करता है। ये गलत है।
2. यह काम करता है।

हम PriorityQueue<T> प्रदान करके कुछ मुद्दों को कम कर सकते हैं, जहां कोई भौतिक अलग प्राथमिकता नहीं है।

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

दो प्राथमिकता कतार

यदि हम दो प्राथमिकता वाली कतारें प्रदान करते हैं, तो समग्र समाधान अधिक शक्तिशाली और लचीला होगा। लेने के लिए कुछ नोट हैं:

• हम समान कार्यक्षमता प्रदान करने के लिए दो वर्गों का खुलासा करते हैं, लेकिन केवल विभिन्न प्रकार के इनपुट प्रारूप के लिए। सबसे अच्छा नहीं लगता।
• PriorityQueue<T> संभावित रूप से IQueue<T> लागू कर सकता है।
• PriorityQueue<TElement, TPriority> एक अजीब एपीआई को उजागर करेगा यदि वह IQueue इंटरफ़ेस को लागू करने का प्रयास करता है।

अच्छा ... यह काम करेगा । हालांकि आदर्श नहीं है।

अपडेट करना और हटाना

इस धारणा को देखते हुए कि हम डुप्लिकेट की अनुमति देना चाहते हैं और हम हैंडल की अवधारणा का उपयोग नहीं करना चाहते हैं:

• तत्वों की प्राथमिकताओं को पूरी तरह से सही ढंग से अद्यतन करने की कार्यक्षमता प्रदान करना असंभव
• इसके अतिरिक्त, दोनों ऑपरेशन ओ (एन) में किए जाने हैं, जो बहुत दुखद है, क्योंकि ओ (लॉग एन) दोनों में करना संभव है।

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

वैकल्पिक संभाल

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

void Enqueue(TElement element, TPriority priority, out object handle);

void Update(object handle, TPriority priority);

void Remove(object handle);

ये उन लोगों के लिए तरीके होंगे जो तत्वों को अद्यतन करने और हटाने पर उचित नियंत्रण रखना चाहते हैं (और इसे ओ (एन) में न करें, जैसे कि यह List :stuck_out_tongue_winking_eye :)।

लेकिन बेहतर हालांकि, आइए विचार करें ...

वैकल्पिक दृष्टिकोण

वैकल्पिक रूप से, हम इस कार्यक्षमता को प्राथमिकता कतार से पूरी तरह से हटा सकते हैं और इसके बजाय इसे हीप में जोड़ सकते हैं। इसके कई फायदे हैं:

• Heap का उपयोग करके अधिक शक्तिशाली और कुशल संचालन उपलब्ध हैं।
• सरल API और सीधा उपयोग PriorityQueue का उपयोग करके उपलब्ध है -- उन लोगों के लिए जो चाहते हैं कि उनका कोड केवल काम करे .
• हम जावा की समस्याओं में नहीं आते हैं।
• हम अब PriorityQueue स्थिर बना सकते हैं -- यह अब कोई समझौता नहीं है।
• समाधान इस भावना के अनुरूप है कि मजबूत कंप्यूटर विज्ञान पृष्ठभूमि वाले लोग Heap के अस्तित्व से अवगत होंगे। वे PriorityQueue की सीमाओं से भी अवगत होंगे और इस प्रकार इसके बजाय Heap उपयोग कर सकते हैं (उदाहरण के लिए यदि वे तत्वों को अद्यतन/निकालने पर अधिक नियंत्रण रखना चाहते हैं या डेटा नहीं चाहते हैं संरचना गति और स्मृति उपयोग की कीमत पर स्थिर हो)।
• प्राथमिकता कतार और ढेर दोनों आसानी से डुप्लीकेट की अनुमति दे सकते हैं जबकि उनकी कार्यक्षमता पर समझौता नहीं किया जा सकता है (क्योंकि उनके उद्देश्य अलग हैं)।
• एक सामान्य IQueue इंटरफ़ेस बनाना आसान होगा - क्योंकि शक्ति और कार्यक्षमता को ढेर क्षेत्र में फेंक दिया जाएगा। PriorityQueue एपीआई को अमूर्त के माध्यम से Queue के साथ संगत बनाने पर ध्यान केंद्रित किया जा सकता है।
• हमें अब IPriorityQueue इंटरफ़ेस प्रदान करने की आवश्यकता नहीं है (हम इसके बजाय PriorityQueue और Queue की कार्यक्षमता को समान रखने पर ध्यान केंद्रित करते हैं)। इसके बजाय, हम इसे ढेर क्षेत्र में जोड़ सकते हैं - और अनिवार्य रूप से वहां IHeap है। यह बहुत अच्छा है, क्योंकि यह लोगों को मानक पुस्तकालय के शीर्ष पर तीसरे पक्ष के पुस्तकालय बनाने की अनुमति देता है। और यह सही लगता है - क्योंकि फिर से, हम ढेर को प्राथमिकता वाली कतारों की तुलना में अधिक उन्नत मानते हैं, इसलिए उस क्षेत्र द्वारा एक्सटेंशन प्रदान किए जाएंगे। ऐसे एक्सटेंशन उन विकल्पों से भी प्रभावित नहीं होंगे जो हम PriorityQueue , क्योंकि यह अलग होगा।
• हमें अब PriorityQueue लिए IHeap कंस्ट्रक्टर पर विचार करने की आवश्यकता नहीं है।
• कोरएफएक्स में आंतरिक रूप से उपयोग करने के लिए प्राथमिकता कतार एक सहायक वर्ग होगी। हालांकि, अगर हम स्थिरता जैसी सुविधाओं को जोड़ते हैं और कुछ अन्य कार्यक्षमताओं को छोड़ देते हैं, तो हमें उस समाधान की तुलना में अधिक शक्तिशाली कुछ की आवश्यकता के साथ समाप्त होने की संभावना है। सौभाग्य से, हमारे आदेश में अधिक शक्तिशाली और प्रदर्शन करने वाला Heap !

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

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

महत्वपूर्ण नोट: यदि हम ऐसा दृष्टिकोण चाहते हैं, तो हमें प्राथमिकता कतार और ढेर को एक साथ डिजाइन करने की आवश्यकता है। क्योंकि उनके उद्देश्य अलग होंगे और एक समाधान वह प्रदान करेगा जो दूसरा नहीं करेगा।

IQueue वितरित करना तब

ऊपर प्रस्तुत दृष्टिकोण के साथ, प्राथमिकता कतार के लिए IQueue<T> (ताकि यह समझ में आता है) को लागू करने के लिए, और यह मानते हुए कि हम वहां चयनकर्ता के लिए समर्थन छोड़ देते हैं, इसमें एक सामान्य प्रकार होना चाहिए। हालांकि इसका मतलब यह होगा कि यदि उपयोगकर्ताओं के पास अलग से (user data, priority) तो उन्हें एक रैपर प्रदान करने की आवश्यकता होगी, ऐसा समाधान अभी भी सहज है। और सबसे महत्वपूर्ण बात यह है कि यह सभी इनपुट प्रारूपों की अनुमति देता है (इसीलिए अगर हम चयनकर्ता को छोड़ देते हैं तो इसे इस तरह से किया जाना चाहिए)। चयनकर्ता के बिना, Enqueue(TElement, TPriority) पहले से तुलनीय प्रकारों की अनुमति नहीं देगा। गणना के लिए एक एकल सामान्य प्रकार भी महत्वपूर्ण है -- ताकि इस पद्धति को IQueue<T> में शामिल किया जा सके।

विविध

@svick

क्या यह परिभाषित किया गया है कि गणना करते समय तत्वों को किस क्रम में लौटाया जाता है? मेरा अनुमान है कि इसे कुशल बनाने के लिए यह अपरिभाषित है।

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

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

@pgolebiowski
यह सब बहुत समझदार लगता है। क्या आप Delivering IQueue then अनुभाग में स्पष्ट करना चाहते हैं, क्या आप डुप्लिकेट तत्वों की छूट दिए गए चयनकर्ता के विकल्प के रूप में "एक सामान्य प्रकार" के लिए T : IComparable<T> सुझाव दे रहे हैं?

मैं दो अलग-अलग प्रकार के होने का समर्थन करता हूं।

मैं हैंडल प्रकार के रूप में object का उपयोग करने के पीछे तर्क को समझ नहीं पा रहा हूं: क्या यह सिर्फ एक नया प्रकार बनाने से बचने के लिए है? एक नए प्रकार को परिभाषित करना न्यूनतम कार्यान्वयन ओवरहेड प्रदान करेगा, जबकि एपीआई का दुरुपयोग करना कठिन होगा (जो मुझे string से Remove(object) पास करने की कोशिश कर रहा है?), और उपयोग करने में आसान (जो मुझे कोशिश कर रहा है रोक रहा है) तत्व को स्वयं पास करने के लिए Remove(object) , और कोशिश करने के लिए मुझे कौन दोषी ठहरा सकता है?)

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

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

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

@विजुअलमेलन

क्या आप Delivering IQueue then अनुभाग में स्पष्ट करना चाहते हैं, क्या आप डुप्लिकेट तत्वों की छूट दिए गए चयनकर्ता के विकल्प के रूप में "एक सामान्य प्रकार" के लिए T : IComparable<T> सुझाव दे रहे हैं?

इसे स्पष्ट न करने के लिए खेद है।

• मेरा मतलब था PriorityQueue<T> वितरित करना, बिना किसी बाधा के T ।
• यह अभी भी IComparer<T> ।
• यदि ऐसा होता है कि T पहले से ही तुलनीय है, तो बस Comparer<T>.Default मान लिया जाएगा (और आप बिना किसी तर्क के प्राथमिकता कतार के डिफ़ॉल्ट कंस्ट्रक्टर को कॉल कर सकते हैं)।

• चयनकर्ता का एक अलग उद्देश्य था - सभी प्रकार के उपयोगकर्ता डेटा का उपभोग करने में सक्षम होना। कई विन्यास हैं:

  1. उपयोगकर्ता डेटा प्राथमिकता (दो भौतिक उदाहरण) से अलग है।
  2. उपयोगकर्ता डेटा में प्राथमिकता होती है।
  3. उपयोगकर्ता डेटा प्राथमिकता है।
  4. दुर्लभ मामला: किसी अन्य तर्क के माध्यम से प्राथमिकता प्राप्त की जा सकती है (उपयोगकर्ता डेटा से अलग वस्तु में रहता है)।

  दुर्लभ मामला संभव नहीं होगा PriorityQueue<T> , लेकिन यह ज्यादा मायने नहीं रखता। महत्वपूर्ण यह है कि अब हम (1), (2), और (3) को संभाल सकते हैं। हालांकि, अगर हमारे पास दो सामान्य प्रकार थे, तो हमारे पास Enqueue(TElement, TPrioriity) जैसी विधि होनी चाहिए। यह हमें केवल (1) तक सीमित कर देगा। (2) अतिरेक की ओर ले जाएगा। (3) अविश्वसनीय रूप से बदसूरत होगा। ऊपर IQueue > Enqueue अनुभाग में इस पर कुछ और है (दूसरा Enqueue विधि और default(TPriority )।

मुझे आशा है कि यह अब स्पष्ट हो गया है।

बीटीडब्लू, इस तरह के समाधान को मानते हुए, PriorityQueue<T> और IQueue<T> के एपीआई को डिजाइन करना मामूली होगा। बस कुछ विधियों को Queue<T> , उन्हें IQueue<T> में फेंक दें और PriorityQueue<T> लागू करें। टाडा! मैं

मैं हैंडल प्रकार के रूप में object का उपयोग करने के पीछे तर्क को समझ नहीं पा रहा हूं: क्या यह सिर्फ एक नया प्रकार बनाने से बचने के लिए है?

• हाँ, ठीक। इस धारणा को देखते हुए कि हम इस तरह के प्रकार का खुलासा नहीं करना चाहते हैं, यह अभी भी एक हैंडल की अवधारणा का उपयोग करने का एकमात्र समाधान है (और इस तरह अधिक शक्ति और गति है)। मैं मानता हूं कि यह आदर्श नहीं है - बल्कि यह एक स्पष्टीकरण था कि क्या होगा यदि हम वर्तमान दृष्टिकोण से चिपके रहते हैं और अधिक शक्ति और दक्षता चाहते हैं (जिसके खिलाफ मैं हूं)।
• यह देखते हुए कि हम वैकल्पिक दृष्टिकोण (अलग प्राथमिकता कतार और ढेर) के साथ जाएंगे, यह आसान है। हम PriorityQueue<T> को System.Collections.Generic में रहने दे सकते हैं, जबकि हीप कार्यक्षमता System.Collections.Specialized । वहां, हमारे पास इस तरह के प्रकार को पेश करने का एक उच्च मौका होगा, अंततः अद्भुत संकलन-समय त्रुटि का पता लगाना होगा।
• लेकिन एक बार फिर - अगर हम ऐसा दृष्टिकोण रखना चाहते हैं तो प्राथमिकता कतार और ढेर कार्यक्षमता को एक साथ डिजाइन करना बहुत महत्वपूर्ण है। क्योंकि एक समाधान वह प्रदान करता है जो दूसरा नहीं करता है।

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

यदि हैंडल विचार आगे बढ़ता है, तो मैं प्रस्ताव दूंगा कि यदि यह जानकारी उपयोगी समझी जाती है...

निश्चित रूप से और अधिक संभव है: पलक:। विशेष रूप से हमारे समुदाय द्वारा उन सभी को तृतीय-पक्ष पुस्तकालयों में विस्तारित करने के लिए।

@karelz @safern @ianhays @terrajobst @bendono @svick @ @SamuelEnglard @xied75 और अन्य - क्या आपको लगता है कि इस तरह के दृष्टिकोण से कोई मतलब होगा (जैसा कि इस और इस पोस्ट में वर्णित है)? क्या यह आपकी सभी अपेक्षाओं और जरूरतों को पूरा करेगा?

मुझे लगता है कि दो वर्ग बनाने का विचार बहुत मायने रखता है और बहुत सारे मुद्दों को हल करता है। केवल मेरे पास यह है कि यह PriorityQueue<T> लिए आंतरिक रूप से Heap<T> का उपयोग करने और इसकी उन्नत कार्यक्षमता को "छिपाने" के लिए समझ में आता है।

तो मूल रूप से...

IQueue<T>

public interface IQueue<T> :
    IEnumerable,
    IEnumerable<T>,
    IReadOnlyCollection<T>
{
    int Count { get; }

    void Clear();
    bool Contains(T element);
    bool IsEmpty();

    void Enqueue(T element);

    T Peek();
    T Dequeue();

    bool TryPeek(out T element);
    bool TryDequeue(out T element);
}

टिप्पणियाँ

• System.Collections.Generic ।
• विचार: हम यहां तत्वों को हटाने के तरीके भी जोड़ सकते हैं ( Remove और TryRemove )। हालांकि यह Queue<T> नहीं है। लेकिन यह जरूरी नहीं है।

PriorityQueue<T>

public class PriorityQueue<T> : IQueue<T>
{
    public PriorityQueue();
    public PriorityQueue(IComparer<T> comparer);
    public PriorityQueue(IEnumerable<T> collection);
    public PriorityQueue(IEnumerable<T> collection, IComparer<T> comparer);

    public IComparer<T> Comparer { get; }
    public int Count { get; }

    public bool IsEmpty();
    public void Clear();
    public bool Contains(T element);

    public void Enqueue(T element);

    public T Peek();
    public T Dequeue();

    public bool TryPeek(out T element);
    public bool TryDequeue(out T element);

    public void Remove(T element);
    public bool TryRemove(T element);

    public IEnumerator<T> GetEnumerator();
    IEnumerator IEnumerable.GetEnumerator();
}

टिप्पणियाँ

• System.Collections.Generic ।
• यदि IComparer<T> वितरित नहीं किया जाता है, तो Comparer<T>.Default को समन किया जाता है।
• यह स्थिर है।
• डुप्लिकेट की अनुमति देता है।
• Remove और TryRemove केवल पहली घटना को हटा दें (यदि वे इसे ढूंढते हैं)।
• गणना का आदेश दिया गया है।

ढेर

अभी यहाँ सब कुछ नहीं लिख रहा हूँ, लेकिन:

• System.Collections.Specialized ।
• यह स्थिर नहीं होगा (और स्मृति के मामले में इतना तेज़ और अधिक कुशल)।
• समर्थन संभालना, उचित अद्यतन करना और हटाना
  
  
  
  • ओ (एन) के बजाय ओ (लॉग एन) में जल्दी से किया गया
  
  
  • सही ढंग से किया
  
  
• गणना का आदेश नहीं दिया गया है (तेज़)।
• डुप्लिकेट की अनुमति देता है।

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

• IQueue के लिए विशिष्टताअच्छा लग रहा है।

• IQueue में "int काउंट {get; }" जोड़ने पर विचार करेंताकि यह स्पष्ट हो कि IReadOnlyCollection से हमें विरासत में मिला है या नहीं, इस पर ध्यान दिए बिना गणना वांछित है.

• TryPeek के बारे में बाड़ पर, IQueue में TryDequeueयह देखते हुए कि वे कतार में नहीं हैं, लेकिन उन सहायकों को शायद क्यू और स्टैक में भी जोड़ा जाना चाहिए।

• IsEmpty एक बाहरी की तरह लगता है; बीसीएल में कई अन्य संग्रह प्रकार नहीं हैं। इसे इंटरफ़ेस में जोड़ने के लिए हमें यह मान लेना होगा कि इसे कतार में जोड़ा जाएगा, और इसे क्यू में जोड़ना थोड़ा अजीब लगता हैऔर बाकी कुछ भी नहीं। यह अनुशंसा करते हुए कि हम इसे इंटरफ़ेस से छोड़ दें, और शायद कक्षा भी।

• TryRemove ड्रॉप करें और निकालें को "बूल रिमूव" में बदलें। अन्य संग्रह वर्गों के साथ संरेखण में रखना यहां महत्वपूर्ण होगा - डेवलपर्स के पास बहुत सारी मांसपेशी-स्मृति होगी जो कहती है कि "एक संग्रह में हटाएं() फेंकता नहीं है"। यह एक ऐसा क्षेत्र है जहां कई डेवलपर्स अच्छी तरह से परीक्षण नहीं करेंगे और यदि सामान्य व्यवहार बदल दिया जाता है तो बहुत आश्चर्य होगा।

आपके पहले के उद्धरण @pgolebiowski . से

1. उपयोगकर्ता डेटा प्राथमिकता (दो भौतिक उदाहरण) से अलग है।
2. उपयोगकर्ता डेटा में प्राथमिकता होती है।
3. उपयोगकर्ता डेटा प्राथमिकता है।
4. दुर्लभ मामला: किसी अन्य तर्क के माध्यम से प्राथमिकता प्राप्त की जा सकती है (उपयोगकर्ता डेटा से अलग वस्तु में रहता है)।

5 पर विचार करने की भी सिफारिश करें। उपयोगकर्ता डेटा में कई क्षेत्रों में प्राथमिकता होती है (जैसा कि हमने Lucene.net में देखा था)

TryPeek के बारे में बाड़ पर, IQueue में TryDequeue यह देखते हुए कि वे कतार में नहीं हैं

वे सिस्टम/संग्रह/जेनेरिक/Queue.cs#L253-L295 . हैं

दूसरी ओर कतार नहीं है
c# public void Remove(T element); public bool TryRemove(T element);

IQueue में "int Count {get; }" जोड़ने पर विचार करें ताकि यह स्पष्ट हो कि IReadOnlyCollection से हमें विरासत में मिला है या नहीं, इस पर ध्यान दिए बिना काउंट वांछित है।

ठीक है। इसे संशोधित करेंगे।

IsEmpty एक बाहरी की तरह लगता है; बीसीएल में कई अन्य संग्रह प्रकार नहीं हैं।

इसे @karelz द्वारा जोड़ा गया था, मैंने अभी इसे कॉपी किया है। हालांकि मुझे यह पसंद है, एपीआई समीक्षा में विचार किया जा सकता है :)

TryRemove ड्रॉप करें और निकालें को "बूल रिमूव" में बदलें।

मुझे लगता है कि Remove और TryRemove इस तरह के अन्य तरीकों के अनुरूप है ( Peek और TryPeek या Dequeue और TryDequeue )

1. उपयोगकर्ता डेटा में कई क्षेत्रों में प्राथमिकता होती है

यह एक वैध बिंदु है, लेकिन वास्तव में इसे चयनकर्ता के साथ भी संभाला जा सकता है (यह सब के बाद कोई भी कार्य है) - लेकिन यह ढेर के लिए है।

IsEmpty एक बाहरी की तरह लगता है; बीसीएल में कई अन्य संग्रह प्रकार नहीं हैं।

एफडब्ल्यूआईडब्ल्यू, bool IsEmpty { get; } कुछ ऐसा है जो मेरी इच्छा है कि हम IProducerConsumerCollection<T> जोड़ दें, और मुझे खेद है कि यह कई मौकों पर वहां नहीं रहा है। इसके बिना, रैपर को अक्सर Count == 0 के बराबर करने की आवश्यकता होती है, जो कुछ संग्रहों के लिए लागू करने के लिए काफी कम कुशल है, विशेष रूप से अधिकांश समवर्ती संग्रहों पर।

@pgolebiowski वर्तमान एपीआई अनुबंधों को होस्ट करने के लिए एक जीथब रिपोजिटरी बनाने के विचार के बारे में आप कैसा महसूस करते हैं और एक .md फ़ाइल या दो डिज़ाइन तर्क युक्त। एक बार जब यह स्थिर हो जाता है, तो इसे तैयार होने पर CoreFxLabs तक पीआर करने से पहले प्रारंभिक कार्यान्वयन के निर्माण के लिए एक जगह के रूप में उपयोग किया जा सकता है?

@svick

यदि Peek और Dequeue प्राथमिकता के लिए out पैरामीटर का उपयोग करते हैं, तो उनके पास ओवरलोड भी हो सकते हैं जो प्राथमिकता वापस नहीं करते हैं, जो मुझे लगता है कि सामान्य उपयोग को सरल करेगा

माना। आइए उन्हें जोड़ें।

क्या प्राथमिकताओं को अनदेखा करते हुए, प्राथमिकता कतार में केवल वस्तुओं की गणना करने का कोई तरीका होना चाहिए?

अच्छा प्रश्न। आप क्या प्रस्ताव देंगे? IEnumerable<TElement> Elements { get; } ?

स्थिरता - मुझे लगता है कि इसका मतलब यह होगा कि आंतरिक रूप से, प्राथमिकता (priority, version) जोड़ी की तरह कुछ होनी चाहिए

मुझे लगता है कि हम Update को तार्किक Remove + Enqueue मानकर इससे बच सकते हैं। हम हमेशा समान-प्राथमिकता वाले आइटम के अंत में आइटम जोड़ते हैं (मूल रूप से तुलनाकर्ता परिणाम 0 को -1 के रूप में मानते हैं)। आईएमओ जो काम करना चाहिए।

@बेनादम्स

ट्राईएक्स विधियां मूल बीसीएल में एक सामान्य पैटर्न नहीं थीं; समवर्ती प्रकारों तक (हालांकि लगता है कि Dictionary.TryGetValue 2.0 में पहला उदाहरण हो सकता है?)
उदाहरण के लिए TryX विधियों को केवल क्यू और स्टैक के लिए कोर में जोड़ा गया है और अभी तक फ्रेमवर्क का हिस्सा नहीं हैं।

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

@pgolebiowski

वैकल्पिक रूप से, हम इस कार्यक्षमता को प्राथमिकता कतार से पूरी तरह से हटा सकते हैं और इसके बजाय इसे हीप में जोड़ सकते हैं। इसके कई फायदे हैं

हम्म, कुछ मुझे बताता है कि आपका यहां कोई एजेंडा हो सकता है
अब गंभीरता से, यह वास्तव में अच्छी दिशा है जिसका हम हर समय लक्ष्य कर रहे थे - PriorityQueue कभी भी Heap न करने का कारण नहीं था। यदि हम इस तथ्य के साथ ठीक हैं कि Heap इसे CoreFX में नहीं बना सकता है और PowerCollections के साथ उन्नत डेटा संरचना के रूप में CoreFXExtensions रेपो में "बस" रह सकता है, तो मैं इसके साथ ठीक हूं,

महत्वपूर्ण नोट: यदि हम ऐसा दृष्टिकोण चाहते हैं, तो हमें प्राथमिकता कतार और ढेर को एक साथ डिजाइन करने की आवश्यकता है। क्योंकि उनके उद्देश्य अलग होंगे और एक समाधान वह प्रदान करेगा जो दूसरा नहीं करेगा।

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

IQueue

अद्यतित करने के लिए धन्यवाद। आपकी बातों को देखते हुए, मुझे नहीं लगता कि हमें IQueue जोड़ने के लिए अपने रास्ते से हट जाना चाहिए। आईएमओ यह अच्छा है। अगर हमारे पास चयनकर्ता होता, तो यह स्वाभाविक होता। हालांकि, मुझे चयनकर्ता दृष्टिकोण पसंद नहीं है क्योंकि यह वर्णन करने में अजीबता और जटिलता लाता है जब चयनकर्ता को PriorityQueue (केवल Enqueue और Update पर बुलाया जाता है।

वैकल्पिक (वस्तु) संभाल

इस तरह के ओवरलोड आईएमओ के लिए वास्तव में यह एक बुरा विचार नहीं है (हालांकि थोड़ा बदसूरत)। हमें यह पता लगाने में सक्षम होना होगा कि हैंडल गलत PriorityQueue , जो ओ (लॉग एन) है।
मुझे लगता है कि एपीआई समीक्षक इसे अस्वीकार कर देंगे, लेकिन आईएमओ इसके साथ प्रयोग करने के लिए एक शॉट के लायक है ...

स्थिरता

मुझे नहीं लगता कि स्थिरता किसी भी पूर्ण/मेमोरी ओवरहेड के साथ आती है (मान लीजिए कि हमने Update पहले ही गिरा दिया है या हम Update को तार्किक Remove + Enqueue मानते हैं, इसलिए हम मूल रूप से तत्व की आयु को रीसेट करते हैं)। बस तुलनाकर्ता परिणाम 0 को -1 के रूप में मानें और सब कुछ अच्छा है ... या क्या मुझे कुछ याद आ रहा है?

चयनकर्ता और IQueue<T>

2 प्रस्तावों का होना एक अच्छा विचार हो सकता है (और हम संभावित रूप से दोनों को ले सकते हैं):

• PriorityQueue<T,U> बिना चयनकर्ता के और बिना IQueue (जो बोझिल होगा)
• PriorityQueue<T> चयनकर्ता के साथ और IQueue

काफी कुछ लोगों ने संकेत दिया कि ऊपर।

पुन: @pgolebiowski से नवीनतम प्रस्ताव - https://github.com/dotnet/corefx/issues/574#issuecomment -308427321

IQueue<T> - हम Remove और TryRemove जोड़ सकते हैं, लेकिन Queue<T> वे नहीं हैं।

क्या उन्हें Queue<T> जोड़ने का कोई मतलब होगा? ( @ebickle सहमत हैं) यदि हां, तो हमें अतिरिक्त भी बंडल करना चाहिए।
आइए इसे इंटरफ़ेस में जोड़ें और कॉल करें कि वे संदिग्ध हैं / Queue<T> अतिरिक्त भी चाहिए।
IsEmpty भी - जो कुछ भी Queue<T> और Stack<T> अतिरिक्त की आवश्यकता है, आइए इसे इंटरफ़ेस में चिह्नित करें (इसकी समीक्षा करना और पचाना आसान होगा)।
@pgolebiowski क्या आप कृपया IQueue<T> टिप्पणी जोड़ सकते हैं, उन कक्षाओं की सूची के साथ जो हमें लगता है कि इसे किसके द्वारा लागू किया जाएगा?

PriorityQueue<T>

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

ढेर

नेमस्पेस पसंद: आइए अभी तक नेमस्पेस निर्णय पर समय बर्बाद न करें। यदि Heap CoreFxExtensions में समाप्त होता है, तो हम अभी तक नहीं जानते हैं कि हम वहां किस प्रकार के नेमस्पेस की अनुमति देंगे। शायद Community.* या ऐसा ही कुछ। यह CoreFxExtensions उद्देश्य/ऑपरेशन मोड चर्चा परिणाम पर निर्भर करता है।
नोट: CoreFxExtensions रेपो के लिए एक विचार यह है कि सिद्ध समुदाय के सदस्यों को लिखने की अनुमति दी जाए, और इसे मुख्य रूप से समुदाय द्वारा संचालित किया जाए, जिसमें .NET टीम केवल सलाह प्रदान करे (एपीआई समीक्षा विशेषज्ञता सहित) और .NET टीम / एमएस जरूरत पड़ने पर मध्यस्थ हो। अगर हम यहीं उतरते हैं, तो हम इसे System.* या Microsoft.* नेमस्पेस में नहीं चाहते। (अस्वीकरण: प्रारंभिक सोच, कृपया अभी तक निष्कर्ष पर न जाएं, उड़ान में अन्य वैकल्पिक शासन विचार हैं)

TryRemove ड्रॉप करें और Remove को bool Remove बदलें। अन्य संग्रह वर्गों के साथ संरेखण में रखना यहां महत्वपूर्ण होगा - डेवलपर्स के पास बहुत सारी मांसपेशी-स्मृति होगी जो कहती है कि "एक संग्रह में हटाएं() फेंकता नहीं है"। यह एक ऐसा क्षेत्र है जहां कई डेवलपर्स अच्छी तरह से परीक्षण नहीं करेंगे और यदि सामान्य व्यवहार बदल दिया जाता है तो बहुत आश्चर्य होगा।

हमें निश्चित रूप से कम से कम इसे अन्य संग्रहों के साथ संरेखित करने पर विचार करना चाहिए। क्या कोई अन्य संग्रहों को स्कैन कर सकता है कि उनका Remove पैटर्न क्या है?

@ebicle वर्तमान एपीआई अनुबंधों को होस्ट करने के लिए एक जीथब रिपोजिटरी बनाने के विचार के बारे में आप कैसा महसूस करते हैं और एक .md फ़ाइल या दो डिज़ाइन तर्क युक्त।

आइए इसे सीधे CoreFxLabs में

@ करेल्ज़

क्या प्राथमिकताओं को अनदेखा करते हुए, प्राथमिकता कतार में केवल वस्तुओं की गणना करने का कोई तरीका होना चाहिए?

अच्छा प्रश्न। आप क्या प्रस्ताव देंगे? IEnumerable<TElement> Elements { get; } ?

हाँ, या तो वह या किसी प्रकार की ElementsCollection लौटाने वाली संपत्ति शायद सबसे अच्छा विकल्प है। खासकर जब से यह Dictionary<K, V>.Values के समान है।

हम हमेशा समान-प्राथमिकता वाले आइटम के अंत में आइटम जोड़ते हैं (मूल रूप से तुलनाकर्ता परिणाम 0 को -1 के रूप में मानते हैं)। आईएमओ जो काम करना चाहिए।

ऐसा नहीं है कि ढेर कैसे काम करता है, "समान-प्राथमिकता वाली वस्तुओं का अंत" नहीं होता है। समान प्राथमिकता वाली वस्तुओं को पूरे ढेर में फैलाया जा सकता है (जब तक कि वे वर्तमान न्यूनतम होने के करीब न हों)।

या, एक और तरीका रखें, स्थिरता बनाए रखने के लिए, आपको 0 से -1 के तुलना परिणाम पर विचार करना होगा, न केवल सम्मिलित करते समय, बल्कि तब भी जब वस्तुओं को ढेर में इधर-उधर ले जाया जाए। और मुझे लगता है कि आपको इसे ठीक से करने के लिए version के साथ priority जैसे कुछ स्टोर करना होगा।

IQueue- हम हटा सकते हैं और कोशिश करें हटा सकते हैं, लेकिन कतारउनके पास नहीं है।

क्या उन्हें कतार में जोड़े जाने का कोई मतलब होगा?? ( @ebickle सहमत हैं) यदि हां, तो हमें अतिरिक्त भी बंडल करना चाहिए।

मुझे नहीं लगता कि Remove को IQueue<T> जोड़ा जाना चाहिए; और मैं यह भी सुझाव दूंगा कि Contains बेकार है; यह इंटरफ़ेस की उपयोगिता को सीमित करता है और इसका उपयोग किस प्रकार की कतार के लिए किया जा सकता है जब तक कि आप NotSupportedExceptions को फेंकना शुरू नहीं करते। यानी गुंजाइश क्या है?

क्या यह सिर्फ वैनिला कतारों, संदेश कतारों, वितरित कतारों, सर्विसबस कतारों, एज़्योर स्टोरेज कतारों, सर्विसफैब्रिक विश्वसनीय कतारों आदि के लिए है ... (उनमें से कुछ पर async विधियों को प्राथमिकता देना)

ऐसा नहीं है कि ढेर कैसे काम करता है, "समान-प्राथमिकता वाली वस्तुओं का अंत" नहीं होता है। समान प्राथमिकता वाली वस्तुओं को पूरे ढेर में फैलाया जा सकता है (जब तक कि वे वर्तमान न्यूनतम होने के करीब न हों)।

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

@ebicle वर्तमान एपीआई अनुबंधों को होस्ट करने के लिए एक जीथब रिपोजिटरी बनाने के विचार के बारे में आप कैसा महसूस करते हैं और एक .md फ़ाइल या दो डिज़ाइन तर्क युक्त।

@karelz चलिए इसे सीधे CoreFxLabs में होस्ट करते हैं।

कृपया इस दस्तावेज़ पर एक नज़र डालें।

2 प्रस्तावों का होना एक अच्छा विचार हो सकता है (और हम संभावित रूप से दोनों को ले सकते हैं):

• प्राथमिकता कतारचयनकर्ता के बिना और IQueue के बिना (जो बोझिल होगा)
• प्राथमिकता कतारचयनकर्ता और IQueue के साथ

मैंने चयनकर्ता से पूरी तरह छुटकारा पा लिया। यह तभी आवश्यक है जब हम एक एकीकृत PriorityQueue<T, U> । यदि हमारे पास दो वर्ग हैं - ठीक है, एक तुलनाकर्ता पर्याप्त है।

कृपया मुझे बताएं कि क्या आपको कुछ जोड़ने/बदलने/हटाने योग्य लगता है।

@pgolebiowski

दस्तावेज़ अच्छा लग रहा है। एक ठोस समाधान की तरह महसूस करना शुरू करना मैं .NET कोर पुस्तकालयों में देखने की उम्मीद करता हूं :)

• एक नेस्टेड गणक वर्ग जोड़ना चाहिए। सुनिश्चित नहीं है कि स्थिति बदल गई है, लेकिन वर्षों पहले बाल संरचना होने से GetEnumerator() के परिणाम बॉक्सिंग के कारण कचरा कलेक्टर आवंटन से बचा गया था। उदाहरण के लिए https://github.com/dotnet/coreclr/issues/1579 देखें।
  public class PriorityQueue<T> // ... { public struct Enumerator : IEnumerator<T> { public T Current { get; } object IEnumerator.Current { get; } public bool MoveNext(); public void Reset(); public void Dispose(); } }

• प्राथमिकता कतारएक नेस्टेड एन्यूमरेटर स्ट्रक्चर भी होना चाहिए।

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

• क्या कंस्ट्रक्टर में प्रारंभिक क्षमता निर्दिष्ट करने या TrimExcess फ़ंक्शन होने का कोई मूल्य है, या यह अभी एक माइक्रो-ऑप्टिमाइज़ेशन है - विशेष रूप से IEnumerable पर विचार करते हुएकंस्ट्रक्टर पैरामीटर?

मैं bool Remove(T element) सहमत हूं और कोई TryRemove । सी एफ https://github.com/dotnet/corefx/blob/master/src/System.Collections/src/System/Collections/Generic/CollectionExtensions.cs#L41

@pgolebiowski इसे एक दस्तावेज़ में डालने के लिए धन्यवाद। क्या आप कृपया CoreFxLab मास्टर शाखा के विरुद्ध पीआर के रूप में अपना दस्तावेज़ जमा कर सकते हैं? टैग @ianhays @safern वे
फिर हम विशेष डिजाइन बिंदुओं के बारे में और चर्चा के लिए CoreFxLab मुद्दों का उपयोग कर सकते हैं - यह इस मेगा-इश्यू से आसान होना चाहिए (मैंने अभी-अभी क्षेत्र-प्राथमिकता क्यू बनाने के लिए ईमेल को लात मारी)।

कृपया यहाँ CoreFxLab पुल अनुरोध का लिंक डालें?

• @ebicle @jnm2 -- जोड़ा गया
• @karelz @SamuelEnglard -- संदर्भित

यदि एपीआई अपने वर्तमान स्वरूप (दो वर्गों) में स्वीकृत है, तो मैं एक चतुर्धातुक ढेर ( कार्यान्वयन देखें ) का उपयोग करके दोनों के लिए एक कार्यान्वयन के साथ CoreFXLab के लिए एक और पीआर बनाऊंगा। PriorityQueue<T> नीचे केवल एक सरणी का उपयोग करेगा, जबकि PriorityQueue<TElement, TPriority> दो का उपयोग करेगा - और उनके तत्वों को एक साथ पुनर्व्यवस्थित करेगा। यह हमें अतिरिक्त आवंटन से बचा सकता है और जितना हो सके उतना कुशल हो सकता है। एक बार हरी बत्ती आने पर मैं इसे जोड़ दूंगा।

क्या समवर्ती क्यू की तरह थ्रेड-सुरक्षित संस्करण बनाने की कोई योजना है?

मैं :heart: इसका एक समवर्ती संस्करण देखने के लिए, IProducerConsumerCollection<T> कार्यान्वित करना चाहता हूं, ताकि इसका उपयोग BlockingCollection<T> आदि के साथ किया जा सके।

@aobatact @khellang यह पूरी तरह से अलग धागे की तरह लगता है:

• समीक्षा करने के लिए अलग एपीआई,
• शायद अलग नामस्थान,
• शायद एक पूरी तरह से अलग कार्यान्वयन भी ।

मैं मानता हूँ कि यह बहुत मूल्यवान है हालांकि :पलक :!

public bool IsEmpty();

यह एक तरीका क्यों है? ढांचे पर हर दूसरे संग्रह में IsEmpty है जो इसे एक संपत्ति के रूप में रखता है।

मैंने शीर्ष-पोस्ट में प्रस्ताव को IsEmpty { get; } साथ अद्यतन किया।
मैंने corefxlab रेपो में नवीनतम प्रस्ताव दस्तावेज़ का लिंक भी जोड़ा है।

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

लेकिन इधर-उधर कुछ आपत्तियां भी उठाई गईं। तो मैं अपनी समझ की जांच कर सकता हूं ऐसा लगता है जैसे मुख्य आपत्तियां हैं:
-यह स्पष्ट नहीं है कि डुप्लिकेट तत्व होने पर अपडेट कैसे काम करना चाहिए।
-इस बारे में कुछ तर्क है कि क्या डुप्लिकेट तत्व प्राथमिकता कतार में समर्थन करने के लिए भी वांछनीय हैं
-कुछ चिंता है कि केवल उनकी प्राथमिकता को अद्यतन करने के लिए बैकिंग डेटा संरचना में तत्वों को खोजने के लिए अतिरिक्त लुकअप डेटा संरचना होना अक्षम हो सकता है। विशेष रूप से उन परिदृश्यों के लिए जहां अद्यतन कभी नहीं किया जाता है! और/या सबसे खराब स्थिति प्रदर्शन गारंटी को प्रभावित करते हैं...

मुझे कुछ याद आया?

ठीक है, मुझे लगता है कि एक और था - यह दावा किया गया है कि शब्दार्थ को अद्यतन/निकालें जिसका अर्थ है 'अपडेटफर्स्ट' या 'निकालेंफर्स्ट' अजीब हो सकता है। :)

.नेट कोर के किस संस्करण में हम प्रायोरिटी क्यू का उपयोग शुरू कर सकते हैं?

@memoryfraction .NET कोर के पास अभी तक प्रायोरिटी

@memoryfraction .NET कोर के पास अभी तक प्रायोरिटी

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

इस मुद्दे की वर्तमान स्थिति क्या है? मैंने अभी हाल ही में खुद को एक प्रायोरिटी क्यू की आवश्यकता के रूप में पाया है

यह प्रस्ताव डिफ़ॉल्ट रूप से संग्रह आरंभीकरण को सक्षम नहीं करता है। PriorityQueue<T> Add विधि नहीं है। मुझे लगता है कि एक डुप्लिकेट विधि को जोड़ने के लिए संग्रह आरंभीकरण एक बड़ी पर्याप्त भाषा सुविधा है।

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

@SunnyWar मैं वर्तमान में उपयोग कर रहा हूँ: https://github.com/BlueRaja/High-Speed-Priority-Queue-for-C-Sharp
जिसका अच्छा प्रदर्शन है। मुझे लगता है कि GenericPriorityQueue के खिलाफ आपके कार्यान्वयन का परीक्षण करना समझ में आता है

कृपया मेरी पिछली पोस्ट पर ध्यान न दें। मुझे परीक्षण में त्रुटि मिली। एक बार तय होने के बाद बाइनरी हीप सबसे अच्छा प्रदर्शन करता है।

@karelz यह प्रस्ताव वर्तमान में ICollection<T> कहां है? मुझे नहीं मिला कि इसका समर्थन क्यों नहीं किया जा रहा था, भले ही संग्रह स्पष्ट रूप से पढ़ने के लिए नहीं है?

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

@karelz फिर से गणना आदेश ... प्रकार पर Sort() विधि होने के बारे में जो संग्रह के आंतरिक डेटा ढेर को क्रमबद्ध क्रम में जगह में रखेगा (ओ (एन लॉग एन) में)। और बुला Enumerate() के बाद Sort() में हे (एन) संग्रह विश्लेषण करता है। और अगर सॉर्ट () नहीं कहा जाता है, तो यह ओ (एन) में गैर-क्रमबद्ध क्रम में तत्व लौटाता है?

ट्राइएज: भविष्य में आगे बढ़ना क्योंकि इस पर आम सहमति नहीं लगती है कि हमें इसे लागू करना चाहिए या नहीं।

यह सुनकर बहुत निराशा हुई। मुझे अभी भी इसके लिए तृतीय पक्ष समाधानों का उपयोग करना है।

तीसरे पक्ष के समाधान का उपयोग करना आपको पसंद नहीं आने के प्राथमिक कारण क्या हैं?

लेटकोड करने के लिए ढेर डेटा संरचना एक जरूरी है
अधिक लेटकोड, अधिक सी # कोड साक्षात्कार जिसका अर्थ है अधिक सी # डेवलपर्स।
अधिक डेवलपर्स का अर्थ है बेहतर पारिस्थितिकी तंत्र।
बेहतर पारिस्थितिकी तंत्र का मतलब है कि अगर हम कल भी सी # में प्रोग्राम कर सकते हैं।

संक्षेप में: यह न केवल एक विशेषता है, बल्कि भविष्य भी है। इसलिए इस मुद्दे को 'भविष्य' का लेबल दिया गया है।

तीसरे पक्ष के समाधान का उपयोग करना आपको पसंद नहीं आने के प्राथमिक कारण क्या हैं?

क्योंकि जब कोई मानक नहीं होता है, तो हर कोई अपना खुद का आविष्कार करता है, प्रत्येक के अपने अलग-अलग सेट होते हैं।

कई बार मैंने System.Collections.Generic.PriorityQueue<T> कामना की है क्योंकि यह उस चीज़ के लिए प्रासंगिक है जिस पर मैं काम कर रहा हूं। यह प्रस्ताव अब लगभग 5 साल से है। यह अभी तक क्यों नहीं हुआ है?

यह अभी तक क्यों नहीं हुआ है?

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

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

क्योंकि जब कोई मानक नहीं होता है, तो हर कोई अपना खुद का आविष्कार करता है, प्रत्येक के अपने अलग-अलग सेट होते हैं।

@masonwheeler यह वही है जो आपने PriorityQueue<T> ? कि कई तृतीय पक्ष विकल्प हैं जो विनिमेय नहीं हैं और स्पष्ट रूप से "अधिकांश के लिए सर्वश्रेष्ठ पुस्तकालय" स्वीकार नहीं किया गया है? (मैंने शोध नहीं किया है इसलिए मुझे जवाब नहीं पता)

@eiriktsarpalis लागू करने के बारे में आम सहमति कैसे नहीं है?

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

तीसरे पक्ष के समाधान का उपयोग करना आपको पसंद नहीं आने के प्राथमिक कारण क्या हैं?

@terrajobst
मैंने व्यक्तिगत रूप से अनुभव किया है कि तृतीय पक्ष समाधान हमेशा अपेक्षित प्रदर्शन नहीं करते/वर्तमान भाषा सुविधाओं का उपयोग नहीं करते हैं। एक मानकीकृत संस्करण के साथ मैं (एक उपयोगकर्ता के रूप में) पूरी तरह से निश्चित हो सकता हूं कि प्रदर्शन सबसे अच्छा है जो आप प्राप्त कर सकते हैं।

@danmosemsft

@masonwheeler यह वही है जो आपने PriorityQueue<T> ? कि कई तृतीय पक्ष विकल्प हैं जो विनिमेय नहीं हैं और स्पष्ट रूप से "अधिकांश के लिए सर्वश्रेष्ठ पुस्तकालय" स्वीकार नहीं किया गया है? (मैंने शोध नहीं किया है इसलिए मुझे जवाब नहीं पता)

हां। बस गूगल "सी # प्राथमिकता कतार"; पहला पृष्ठ भरा हुआ है:

1. जीथब और अन्य होस्टिंग साइटों पर प्राथमिकता कतार कार्यान्वयन
2. लोग पूछ रहे हैं कि दुनिया में संग्रह में कोई आधिकारिक प्राथमिकता कतार क्यों नहीं है। सामान्य
3. अपनी खुद की प्राथमिकता कतार कार्यान्वयन का निर्माण करने के तरीके पर ट्यूटोरियल

@terrajobst क्या आपको वास्तव में नायक परिदृश्य की आवश्यकता है जब यह प्रसिद्ध अनुप्रयोगों के साथ एक प्रसिद्ध पैटर्न है? यहां बहुत कम नवाचार की आवश्यकता होनी चाहिए।

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

जाहिर तौर पर हमें एक हीरो की जरूरत है। मैं

@masonwheeler मुझे लगा कि आपका लिंक इस से होगा अब यह मेरे दिमाग में है।

हालांकि जैसा कि @terrajobst कहते हैं, यहां हमारा प्राथमिक मुद्दा संसाधन/ध्यान रहा है (और यदि आप चाहें तो इसके लिए आप हमें दोष दे सकते हैं) हम गैर-माइक्रोसॉफ्ट पारिस्थितिक तंत्र को भी मजबूत करना चाहेंगे ताकि यह अधिक संभावना हो कि आप जो कुछ भी के लिए मजबूत पुस्तकालय ढूंढ सकें परिदृश्य।

[स्पष्टता के लिए संपादित]

@danmosemsft नाह, अगर मैं उस गाने को चुनने जा रहा होता तो मैं श्रेक 2 संस्करण करता।

हीरो ऐप उम्मीदवार # 1: TimerQueue.Portable में एक का उपयोग करने के बारे में कैसे?

https://github.com/dotnet/runtime/blob/4f9ae42d861fcb4be2fcd5d3d55d5f227d30e723/src/libraries/System.Private.CoreLib/src/System/Threading/TimerQueue.Portable.cs

हीरो ऐप उम्मीदवार # 1: TimerQueue.Portable में एक का उपयोग करने के बारे में कैसे?

पहले से ही माना जाता है, प्रोटोटाइप किया जाता है, और त्याग दिया जाता है। यह एक टाइमर के बहुत ही सामान्य मामले को जल्दी से बनाया और नष्ट कर देता है (उदाहरण के लिए एक टाइमआउट के लिए) कम कुशल।

@stephentoub मुझे लगता है कि आपका मतलब है कि कुछ परिदृश्यों के लिए यह कम कुशल है जहां कम संख्या में टाइमर हैं। लेकिन यह कैसे स्केल करता है?

मुझे लगता है कि आपका मतलब है कि कुछ परिदृश्यों के लिए यह कम कुशल है जहां कम संख्या में टाइमर हैं। लेकिन यह कैसे स्केल करता है?

नहीं, मेरा मतलब है कि सामान्य मामला यह है कि आपके पास किसी भी समय बहुत सारे टाइमर होते हैं, लेकिन बहुत कम लोग फायरिंग कर रहे होते हैं। जब टाइमआउट के लिए टाइमर का उपयोग किया जाता है तो यही परिणाम होता है। और महत्वपूर्ण बात वह गति है जिस पर आप डेटा संरचना से जोड़ और हटा सकते हैं ... आप चाहते हैं कि यह 0 (1) हो और बहुत कम ओवरहेड हो। अगर वह ओ (लॉग एन) बन जाता है, तो यह एक समस्या है।

प्राथमिकता कतार होने से निश्चित रूप से C# अधिक साक्षात्कार के अनुकूल हो जाएगा।

प्राथमिकता कतार होने से निश्चित रूप से C# अधिक साक्षात्कार के अनुकूल हो जाएगा।

हाँ यह सच है।
मैं इसे उसी कारण से ढूंढ रहा हूं।

@stephentoub टाइमआउट के लिए जो वास्तव में कभी नहीं होता है, यह मेरे लिए सही समझ में आता है। लेकिन मुझे आश्चर्य है कि सिस्टम का क्या होता है जब अचानक बहुत सारे टाइमआउट होने लगते हैं, क्योंकि अचानक पैकेट नुकसान होता है या एक अनुत्तरदायी सर्वर या जो कुछ भी होता है? इसके अलावा आवर्ती टाइमर एला सिस्टम। टाइमर एक ही कार्यान्वयन का उपयोग करते हैं? वहां, समय समाप्त होने वाला समय 'खुश पथ' होगा।

लेकिन मुझे आश्चर्य है कि सिस्टम का क्या होता है जब अचानक बहुत सारे टाइमआउट होने लगते हैं

इसे अजमाएं। :)

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

इसके अलावा आवर्ती टाइमर एला सिस्टम। टाइमर एक ही कार्यान्वयन का उपयोग करते हैं?

हां। लेकिन वे आम तौर पर वास्तविक दुनिया के अनुप्रयोगों में व्यापक रूप से समान रूप से फैले हुए हैं।

5 साल बाद, अभी भी कोई प्रायोरिटी क्यू नहीं है।

Rx में अत्यधिक उत्पादन-परीक्षण प्राथमिकता कतार वर्ग है:

https://github.com/Reactive-Extensions/Rx.NET/blob/master/Rx.NET/Source/System.Reactive.Core/Reactive/Internal/PriorityQueue.cs

5 साल बाद, अभी भी कोई प्रायोरिटी क्यू नहीं है।

पर्याप्त उच्च प्राथमिकता नहीं होनी चाहिए...

वे रेपो लेआउट के आसपास बदल गए। नया स्थान है https://github.com/dotnet/reactive/blob/master/Rx.NET/Source/src/System.Reactive/Internal/PriorityQueue.cs

@stephentoub लेकिन शायद वास्तव में @eiriktsarpalis हम वास्तव में इस पर किसी भी कर्षण अभी क्या ज़रूरत है? यदि हमारे पास एक अंतिम एपीआई डिजाइन है तो मैं इस पर काम करने को तैयार हूं

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

https://github.com/TimLovellSmith/corefxlab/blob/priorityQueueSpecSold/docs/specs/priority-queue.md

मैं उनके बीच जो मुख्य अंतर देख रहा हूं, वह यह है कि क्या इसे एक शब्दकोश की तरह बात करने की कोशिश करनी चाहिए, और क्या चयनकर्ताओं को एक चीज होनी चाहिए।

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

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

@TimLovellSmith मैं इस व्यवहार की इच्छा को समझता हूं, लेकिन क्योंकि यह 5 साल का Queue.cs रूप में साझा करना उचित नहीं होगा। PriorityQueue बना रहे हैं तो मुझे विश्वास है कि हमें Queue के एपीआई डिज़ाइन का अनुकरण करना चाहिए।

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

@TimLovellSmith क्षमा करें टिम, मुझे विरासत को IDictionary से स्पष्ट करना चाहिए था।

क्या हमारे पास उपयोग का मामला है जहां प्राथमिकता बदल जाएगी?

मुझे आपका कार्यान्वयन पसंद है, लेकिन मुझे लगता है कि हम IDictionary व्यवहार की प्रतिकृति को कम कर सकते हैं। मुझे लगता है कि हमें IDictionary<> से विरासत में नहीं मिलना चाहिए, लेकिन केवल आईसीओलेक्शन, क्योंकि मुझे नहीं लगता कि डिक्शनरी एक्सेस पैटर्न सहज हैं,

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

@Jlalond
यदि हमारे पास प्राथमिकता कतार है, तो इसे उन सभी कार्यों का समर्थन करना चाहिए जो यह सरल और कुशलता से कर सकता है, _और_ जो हैं
इस तरह की डेटा संरचना/एक के अमूर्तन से परिचित लोगों द्वारा 'अपेक्षित' होने की उम्मीद है।

अद्यतन करना प्राथमिकता एपीआई में है क्योंकि यह उन दोनों श्रेणियों में आता है। कई एल्गोरिदम में प्राथमिकता को अद्यतन करना महत्वपूर्ण है कि ढेर डेटा संरचनाओं के साथ ऑपरेशन करने की जटिलता समग्र एल्गोरिदम की जटिलता को प्रभावित करती है, और इसे नियमित रूप से मापा जाता है, देखें:
https://en.wikipedia.org/wiki/Priority_queue#Specialized_heaps

टीबीएच मुख्य रूप से इसकी कमी_की है जो एल्गोरिदम और दक्षता के लिए दिलचस्प है, और मापा जाता है, इसलिए मैं एपीआई के लिए व्यक्तिगत रूप से ठीक हूं, केवल घटाव प्राथमिकता() है, और वास्तव में अद्यतन प्राथमिकता नहीं है।
लेकिन सुविधा के लिए यह अच्छा लगता है कि एपीआई के उपयोगकर्ताओं को इस चिंता से परेशान न करें कि हर बदलाव में वृद्धि या कमी है या नहीं। ताकि जो डेवलपर के पास बॉक्स के बाहर 'अपडेट' हो, यह आश्चर्य किए बिना कि यह केवल कमी का समर्थन क्यों करता है और वृद्धि नहीं करता है, (और कब उपयोग करना है), मुझे लगता है कि सामान्य अपडेट प्राथमिकता एपीआई होना सबसे अच्छा है, लेकिन दस्तावेज़ कम करने के लिए इसका उपयोग करते समय इसकी लागत X होती है, जब इसे वृद्धि के लिए उपयोग करते हैं तो इसकी लागत Y होती है क्योंकि इसे निकालें + जोड़ें के समान ही लागू किया जाता है।

आरई शब्दकोश मैं सहमत हूँ। सरल के नाम पर इसे मेरे प्रस्ताव से हटा देना ही बेहतर है।
https://github.com/TimLovellSmith/corefxlab/blob/priorityQueueSpecSold/docs/specs/priority-queue.md

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

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

@TimLovellSmith

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

क्षमा करें, मैंने गलत समझा कि आपके प्रमुख मूल्य युग्म में TPriorty का क्या अर्थ है।

ठीक है, पिछले दो प्रश्न, क्यों वे TP प्राथमिकता के साथ KeyValuePair हैं, और सबसे अच्छा समय जो मैं पुन: प्राथमिकता के लिए देख सकता हूं वह है एन लॉग एन, मैं मानता हूं कि यह मूल्यवान है, लेकिन यह भी कि एपीआई कैसा दिखेगा?

पुन: प्राथमिकताकरण के लिए मैं जो सबसे अच्छा समय देख सकता हूं वह है एन लॉग एन,

यह एक आइटम के विपरीत एन आइटम के पुनर्प्राथमिकता के लिए सबसे अच्छा समय है, है ना?
मैं दस्तावेज़ को स्पष्ट कर दूंगा: "अपडेट प्राथमिकता | ओ (लॉग एन)" को "अपडेट प्राथमिकता (एकल आइटम) | ओ (लॉग एन)" पढ़ना चाहिए।

@TimLovellSmith समझ में आता है, लेकिन प्राथमिकता का कोई अपडेट वास्तव में ne O2 * (लॉग n) नहीं होगा, क्योंकि हमें तत्व को हटाने और फिर इसे फिर से डालने की आवश्यकता होगी? मेरी धारणा को आधार बनाकर यह एक द्विआधारी ढेर है

@TimLovellSmith समझ में आता है, लेकिन प्राथमिकता का कोई अपडेट वास्तव में ne O2 * (लॉग n) नहीं होगा, क्योंकि हमें तत्व को हटाने और फिर इसे फिर से डालने की आवश्यकता होगी? मेरी धारणा को आधार बनाकर यह एक द्विआधारी ढेर है

जटिलता विश्लेषण में उस 2 जैसे स्थिर कारकों को आम तौर पर नजरअंदाज कर दिया जाता है क्योंकि एन के आकार के बढ़ने के साथ-साथ वे ज्यादातर अप्रासंगिक हो जाते हैं।

समझ गया, ज्यादातर जानना चाहता था कि क्या टिम के पास केवल करने के लिए कोई रोमांचक विचार है
एक ऑपरेशन :)

मंगल, 18 अगस्त, 2020 पर, 23:51 masonwheeler [email protected] लिखा है:

@TimLovellSmith https://github.com/TimLovellSmith समझ में आता है, लेकिन
प्राथमिकता का कोई अद्यतन वास्तव में ne O2 * (लॉग n) नहीं होगा, जैसा कि हमें करने की आवश्यकता होगी
तत्व को हटा दें और फिर इसे दोबारा डालें? मेरी धारणा को आधार बनाकर
एक द्विआधारी ढेर होने के नाते

जटिलता विश्लेषण में आम तौर पर उस तरह के 2 कारकों की अनदेखी की जाती है
क्योंकि N का आकार बढ़ने पर वे अधिकतर अप्रासंगिक हो जाते हैं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/dotnet/runtime/issues/14032#issuecomment-675887763 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AF76XTI3YK4LRUVTOIQMVHLSBNZARanCNFSM4LTSQI6Q
.

@Jlalond
कोई उपन्यास विचार नहीं, मैं सिर्फ एक स्थिर कारक की अनदेखी कर रहा था, लेकिन घटते भी वृद्धि से अलग हैं

यदि प्राथमिकता अद्यतन में कमी है, तो आपको इसे हटाने और इसे फिर से जोड़ने की आवश्यकता नहीं है, यह बस बुलबुले बन जाता है, इसलिए इसका 1 * O (लॉग एन) = ओ (लॉग एन)।
यदि प्राथमिकता अद्यतन एक वृद्धि है, तो आपको शायद इसे हटाना होगा और इसे फिर से जोड़ना होगा, इसलिए इसका 2 * ओ (लॉग एन) = अभी भी ओ (लॉग एन)।

किसी और ने हटाने + पढ़ने की तुलना में प्राथमिकता बढ़ाने के लिए बेहतर डेटास्ट्रक्चर/एल्गोरिदम का आविष्कार किया हो सकता है, लेकिन मैंने इसे खोजने की कोशिश नहीं की है, ओ (लॉग एन) काफी अच्छा लगता है।

KeyValuePair एक शब्दकोश होने के दौरान इंटरफ़ेस में घुस गया, लेकिन शब्दकोश को हटाने से बच गया, मुख्य रूप से ताकि _तत्वों के संग्रह को उनकी प्राथमिकताओं के साथ पुनरावृत्त करना संभव हो। और यह भी कि आप तत्वों को उनकी प्राथमिकताओं से हटा सकते हैं। लेकिन शायद सादगी के लिए फिर से, प्राथमिकताओं के साथ dequeue केवल Dequeue API के 'उन्नत' संस्करण में होना चाहिए। (कोशिश करें: डी)

मैं वह बदलाव करूंगा।

@TimLovellSmith Cool, मुझे आपके संशोधित प्रस्ताव की प्रतीक्षा है। क्या हम इसे समीक्षा के लिए प्रस्तुत कर सकते हैं ताकि मैं इस पर काम शुरू कर सकूं? इसके अतिरिक्त, मुझे पता है कि मर्ज समय में सुधार करने के लिए एक जोड़ी कतार के लिए कुछ प्रोत्साहन था, लेकिन मुझे अभी भी लगता है कि एक सरणी आधारित बाइनरी ढेर सबसे समग्र प्रदर्शन होगा। विचार?

@Jlalond
मैंने उस पीक + डेक्यू एपीआई को सरल बनाने के लिए मामूली बदलाव किए हैं।
कुछ ICollectionKeyValuePair से संबंधित एपीआई अभी भी बनी हुई है, क्योंकि मुझे उन्हें बदलने के लिए कुछ भी स्पष्ट रूप से बेहतर नहीं दिख रहा है।
वही पीआर लिंक। क्या कोई और तरीका है जिससे मुझे इसे समीक्षा के लिए सबमिट करना चाहिए?

https://github.com/TimLovellSmith/corefxlab/blob/priorityQueueSpecSold/docs/specs/priority-queue.md

मुझे कोई फर्क नहीं पड़ता कि यह किस कार्यान्वयन का उपयोग तब तक करता है जब तक यह सरणी आधारित ढेर या बेहतर जितना तेज़ हो।

@TimLovellSmith मैं वास्तव में एपीआई समीक्षा के बारे में कुछ नहीं जानता, लेकिन मुझे लगता है कि @danmosemsft हमें सही दिशा में इंगित कर सकता है।

मेरा पहला सवाल यह है कि क्या होगाहोना? मुझे लगता है कि यह एक इंट, या एक फ्लोटिंग पॉइंट नंबर होगा, लेकिन मेरे लिए कतार में "आंतरिक" संख्या की घोषणा करना मेरे लिए अजीब लगता है

और मैं वास्तव में द्विआधारी ढेर पसंद करता हूं, लेकिन यह सुनिश्चित करना चाहता था कि हम ठीक उसी दिशा में जा रहे हैं

@eiriktsarpalis @layomia क्षेत्र के मालिक हैं और उन्हें एपीआई समीक्षा के माध्यम से इसकी देखभाल करनी होगी। मैं चर्चा का पालन नहीं कर रहा हूं, क्या हम आम सहमति के बिंदु पर पहुंच गए हैं?

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

@Jlalond क्षमा करें, मुझे वह नहीं मिला जो पहला प्रश्न माना जाता है। क्या आप पूछ रहे थे कि TP प्राथमिकता सामान्य क्यों है? या एक नंबर होना चाहिए? मुझे संदेह है कि बहुत से लोग गैर-संख्यात्मक प्राथमिकता प्रकारों का उपयोग करेंगे। लेकिन वे बाइट, इंट, लॉन्ग, फ्लोट, डबल या एनम का उपयोग करना पसंद कर सकते हैं।

@TimLovellSmith हाँ, बस यह जानना चाहता था कि क्या यह सामान्य था

@danmosemsft धन्यवाद दान। मेरे द्वारा अपने प्रस्ताव [1] पर देखी गई आपत्तियों/टिप्पणियों की संख्या लगभग शून्य है, और यह किसी भी महत्वपूर्ण प्रश्न को संबोधित करता है जो शीर्ष पर @ebicle के प्रस्ताव द्वारा खुला छोड़ दिया गया था (जो कि यह तेजी से समान होता जा रहा है)।

इसलिए मेरा दावा है कि यह अब तक विवेक जांच पास कर रहा है। अभी भी कुछ समीक्षा की आवश्यकता होनी चाहिए, हम इस बारे में बात कर सकते हैं कि क्या यह IReadOnlyCollection का उत्तराधिकारी है (बहुत उपयोगी नहीं लगता है लेकिन मुझे विशेषज्ञों को स्थगित करना चाहिए) और इसी तरह - मुझे लगता है कि एपीआई समीक्षा प्रक्रिया यही है! @eiriktsarpalis @layomia क्या मैं आपसे इसे देखने के लिए कह सकता हूं?

[1] https://github.com/TimLovellSmith/corefxlab/blob/priorityQueueSpecSolved/docs/specs/priority-queue.md

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

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

• TElement एक दो बार प्रकट होता है जहां यह TKey होना चाहिए
• मेरे अपने कार्यान्वयन में अक्सर उपयोग में आसानी (और कुछ मामलों में दक्षता) के लिए bool EnqueueOrUpdateIfHigherPriority होता है, जो अक्सर उपयोग की जाने वाली एकमात्र एनक्यूइंग/अपडेटिंग विधि होती है (उदाहरण के लिए ग्राफ खोज में)। जाहिर है कि यह गैर-आवश्यक है और एपीआई में अतिरिक्त जटिलता जोड़ देगा, लेकिन यह एक बहुत अच्छी बात है।
• Enqueue की दो प्रतियां हैं (मेरा मतलब Add ): क्या एक का मतलब bool TryEnqueue ?
• "// संग्रह को मनमाने क्रम में बताता है, लेकिन पहले कम से कम तत्व के साथ": मुझे नहीं लगता कि अंतिम बिट उपयोगी है; मैं पसंद करूंगा कि एन्यूमरेटर को कोई तुलना नहीं करनी पड़े, लेकिन मुझे लगता है कि यह 'फ्री' होगा इसलिए यह मुझे परेशान नहीं करेगा
• EqualityComparer का नामकरण थोड़ा अप्रत्याशित है: मुझे KeyComparer के साथ जाने की उम्मीद PriorityComparer ।
• मैं CopyTo और ToArray की जटिलता पर नोट्स नहीं समझता।

@विजुअलमेलन
समीक्षा के लिए बहुत-बहुत धन्यवाद!

मुझे KeyComparer का नामकरण सुझाव पसंद है। कमी प्राथमिकता API बहुत उपयोगी लगता है। हम उन दोनों में से एक या दोनों एपीआई कैसे जोड़ेंगे। चूंकि हम 'कम से कम प्राथमिकता पहले आता है' मॉडल में उपयोग कर रहे हैं, क्या आप केवल कमी का उपयोग करेंगे? या आप भी बढ़ाना चाहेंगे?

    public void EnqueueOrIncreasePriority(TKey key, TPriority priority); // doesn't throw, only updates priority of keys already in the collection if new priority is higher
    public void EnqueueOrDeccreasePriority(TKey key, TPriority priority); // doesn't throw, only updates priority of keys already in the collection new priroity is lower

जिस कारण से मैंने सोचा था कि कम से कम तत्व पहले रिटर्न की गणना करना मानसिक मॉडल के अनुरूप होना था कि पीक() संग्रह के सामने तत्व लौटाता है। और अगर यह एक बाइनरी ढेर है, तो इसे लागू करने के लिए कोई तुलना आवश्यक नहीं है, इसलिए यह एक फ्रीबी की तरह लग रहा था। लेकिन शायद यह मेरे विचार से कम मुक्त है - अनुचित जटिलता? मुझे इस कारण से इसे बाहर निकालने में खुशी हो रही है।

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

मैं केवल घटते संस्करण का उपयोग करने की कल्पना कर सकता हूं: यह मार्ग में एक प्राकृतिक ऑपरेशन है जो एक नोड को एनक्यू करना चाहता है या मौजूदा नोड को कम प्राथमिकता वाले एक के साथ बदलना चाहता है; मैं तुरंत विपरीत के लिए उपयोग का सुझाव नहीं दे सका। एक boolean वापसी पैरामीटर आसान हो सकता है जब आइटम कतारबद्ध/कतार नहीं होने पर आपको कोई ऑपरेशन करने की आवश्यकता होती है।

मैं एक बाइनरी ढेर नहीं मान रहा था, लेकिन अगर यह मुफ़्त है तो मुझे पहले तत्व के साथ हमेशा न्यूनतम होने में कोई समस्या नहीं है, यह सिर्फ एक अजीब बाधा लग रहा था।

@VisualMelon @TimLovellSmith क्या एक एपीआई ठीक रहेगा?
EnqueueOrUpdatePriority ? मुझे लगता है कि कतार के भीतर एक नोड को पुनर्स्थापित करने की क्षमता ट्रैवर्सल एल्गोरिदम के लिए मूल्यवान है, भले ही यह प्राथमिकता को बढ़ाता या घटाता हो

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

EnqueueOrIncreasePriority को हटाने के लिए अपडेट किया गया, EnqueueOrUpdate और EnqueueOrDecrease रखते हुए। जब कोई आइटम संग्रह में नया जोड़ा जाता है, जैसे हैशसेट। जोड़ें ()।

@Jlalond मैं उपरोक्त त्रुटि के लिए क्षमा चाहता हूं (आपकी नवीनतम टिप्पणी को

मैं सिर्फ यह उल्लेख करना चाहता था कि @eiriktsarpalis अगले सप्ताह वापस आ जाएगा और हम इस सुविधा को प्राथमिकता देने और फिर एपीआई की समीक्षा करने पर चर्चा करेंगे।

यह कुछ ऐसा है जिस पर हम विचार कर रहे हैं लेकिन अभी तक .NET 6 के लिए प्रतिबद्ध नहीं हैं।

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

Corefxlab रेपो में नवीनतम प्रस्ताव देखें।

2017-06-16 तक, हम एक एपीआई समीक्षा की प्रतीक्षा कर रहे थे जो कभी नहीं हुई और स्थिति यह थी:

यदि एपीआई अपने वर्तमान स्वरूप (दो वर्गों) में स्वीकृत है, तो मैं एक चतुर्धातुक ढेर ( कार्यान्वयन देखें ) का उपयोग करके दोनों के लिए एक कार्यान्वयन के साथ CoreFXLab के लिए एक और पीआर बनाऊंगा। PriorityQueue<T> नीचे केवल एक सरणी का उपयोग करेगा, जबकि PriorityQueue<TElement, TPriority> दो का उपयोग करेगा - और उनके तत्वों को एक साथ पुनर्व्यवस्थित करेगा। यह हमें अतिरिक्त आवंटन से बचा सकता है और जितना हो सके उतना कुशल हो सकता है। एक बार हरी बत्ती आने पर मैं इसे जोड़ दूंगा।

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

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

क्या होगा अगर हम अपने पीआर की कोड सामग्री को कम से कम अस्थायी रूप से भूलकर इस पर आगे बढ़ने की कोशिश करते हैं, और यहां पहचाने गए 'खुले मुद्दों' पर चर्चा करना शुरू करते हैं? मैं उन सभी पर अपनी राय देना चाहता हूं।

1. क्लास का नाम प्रायोरिटी क्यू बनाम हीप <- मुझे लगता है कि इस पर पहले ही चर्चा हो चुकी है और सर्वसम्मति यह है कि प्रायोरिटी क्यू बेहतर है।

2. IHeap और कंस्ट्रक्टर अधिभार का परिचय दें? <-- मुझे बहुत अधिक मूल्य की उम्मीद नहीं है। मुझे लगता है कि दुनिया के 95% के लिए कई ढेर कार्यान्वयन के लिए एक अनिवार्य कारण नहीं है (उदाहरण के लिए प्रदर्शन डेल्टा), और अन्य 5% को शायद अपना खुद का लिखना होगा।

3. आई प्रायोरिटी क्यू का परिचय दें? <-- मुझे भी नहीं लगता कि इसकी जरूरत है। मैं मान रहा हूं कि अन्य भाषाएं और ढांचे इन इंटरफेस के बिना उनके मानक पुस्तकालय में ठीक हो जाते हैं। मुझे बताएं कि क्या यह गलत है।

4. चयनकर्ता का उपयोग करें (मूल्य के अंदर संग्रहीत प्राथमिकता का) या नहीं (5 एपीआई अंतर) <- मुझे प्राथमिकता कतार में चयनकर्ताओं का समर्थन करने के पक्ष में एक मजबूत तर्क नहीं दिख रहा है। मुझे लगता है कि आइटम प्राथमिकताओं की तुलना करने के लिए IComparer<> पहले से ही वास्तव में एक अच्छा न्यूनतम एक्स्टेंसिबिलिटी तंत्र के रूप में कार्य करता है, और चयनकर्ता कोई महत्वपूर्ण सुधार प्रदान नहीं करते हैं। इसके अलावा, लोगों को भ्रमित होने की संभावना है कि चयनकर्ताओं को परिवर्तनीय प्राथमिकताओं के साथ कैसे उपयोग किया जाए (या उनका उपयोग कैसे नहीं किया जाए)।

5. टुपल्स (TElement तत्व, TP प्राथमिकता प्राथमिकता) बनाम KeyValuePair का उपयोग करें<- व्यक्तिगत रूप से मुझे लगता है कि KeyValuePair प्राथमिकता कतार के लिए पसंदीदा विकल्प है जहां वस्तुओं की अद्यतन करने योग्य प्राथमिकताएं होती हैं, क्योंकि आइटम को सेट/शब्दकोश में कुंजी के रूप में माना जा रहा है।

6. क्या पीक और डेक्यू को टपल के बजाय तर्क देना चाहिए? <- मैं सभी पेशेवरों और विपक्षों के बारे में निश्चित नहीं हूं, खासकर प्रदर्शन। क्या हमें केवल वही चुनना चाहिए जो एक साधारण बेंचमार्क टेस्ट में बेहतर प्रदर्शन करता है?

7. क्या पीक और डेक्यू फेंकना उपयोगी है? <- हाँ... एल्गोरिदम के लिए यही होना चाहिए जो गलत तरीके से मानते हैं कि कतार में अभी भी आइटम हैं । यदि आप नहीं चाहते कि एल्गोरिदम कभी भी यह मान लें, तो सबसे अच्छी बात यह है कि पीक और डेक्यू एपिस बिल्कुल भी प्रदान नहीं किया जाता है, बल्कि केवल ट्राईपीक और ट्राईडेक्यू प्रदान करें। [मुझे लगता है कि ऐसे एल्गोरिदम हैं जो कुछ मामलों में सुरक्षित रूप से पीक या डेक्यू को सुरक्षित रूप से कॉल कर सकते हैं, और पीक/डेक्यू होने से उनके लिए थोड़ा सा प्रदर्शन + उपयोगिता सुधार होता है।]

इसके अलावा मेरे पास विचाराधीन प्रस्ताव को जोड़ने पर विचार करने के लिए कुछ सुझाव भी हैं:

1. प्राथमिकता कतारकेवल अद्वितीय वस्तुओं के साथ काम करना चाहिए, जो उनके अपने हैंडल हैं। इसे कस्टम IEqualityComparer का समर्थन करना चाहिए, यदि वह गैर-एक्सटेंसिबल ऑब्जेक्ट्स (जैसे स्ट्रिंग्स) की तुलना प्राथमिकता अपडेट करने के लिए विशिष्ट तरीकों से करना चाहता है।

2. प्राथमिकता कतारग्राफ़ खोज परिदृश्यों को कुशलतापूर्वक और सरलता से लागू करने के लिए 'निकालें', 'प्राथमिकता कम करें यदि छोटा हो', और विशेष रूप से 'एनक्यू आइटम या छोटे ऑपरेशन होने पर प्राथमिकता कम करें' जैसे विभिन्न प्रकार के संचालन का समर्थन करना चाहिए।

3. यह आलसी प्रोग्रामर के लिए सुविधाजनक होगा यदि प्रायोरिटीक्यूमौजूदा वस्तुओं की प्राथमिकता प्राप्त/सेट करने के लिए इंडेक्स ऑपरेटर [] प्रदान करता है। यह प्राप्त करने के लिए O(1), सेट के लिए O(log n) होना चाहिए।

4. सबसे छोटी प्राथमिकता सबसे अच्छी है। क्योंकि प्राथमिकता कतारों का उपयोग 'न्यूनतम लागत' के साथ अनुकूलन समस्याओं के लिए किया जाता है।

5. गणना को कोई आदेश देने की गारंटी नहीं देनी चाहिए।

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

इसे तेजी से आगे बढ़ाने में मदद करने के लिए एक विचार, इस प्रकार को "सामुदायिक संग्रह" पुस्तकालय में ले जाने के लिए https://github.com/dotnet/runtime/discussions/42205 में चर्चा की जा रही है।

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

हम इसे जल्द से जल्द एपीआई समीक्षा के लिए लाने पर विचार कर रहे हैं (हालांकि हम अभी तक .NET 6 समय सीमा के भीतर कार्यान्वयन देने के लिए प्रतिबद्ध नहीं हैं)।

लेकिन इससे पहले कि हम इसे समीक्षा के लिए भेजें, हमें कुछ उच्च-स्तरीय खुले प्रश्नों को हल करना होगा। मुझे लगता है कि @TimLovellSmith का लेखन उस लक्ष्य तक पहुंचने की दिशा में एक अच्छा प्रारंभिक बिंदु है।

उन बिंदुओं पर कुछ टिप्पणियाँ:

• प्रश्नों 1-3 पर सहमति लंबे समय से स्थापित है, मुझे लगता है कि हम उन्हें हल कर सकते हैं।

• _चयनकर्ता का उपयोग करें (मूल्य के अंदर संग्रहीत प्राथमिकता का) या नहीं_ -- आपकी टिप्पणियों से सहमत हूं। उस डिज़ाइन के साथ एक और समस्या यह है कि चयनकर्ता वैकल्पिक हैं, जिसका अर्थ है कि आपको सावधान रहने की आवश्यकता है कि आप गलत Enqueue ओवरलोड (या InvalidOperationException प्राप्त करने का जोखिम) न कहें।

• मैं KeyValuePair से अधिक टपल का उपयोग करने का पक्ष लेता हूं। एक .Key संपत्ति का उपयोग करने के लिए एक TPriority मूल्य तक पहुँचने के लिए मुझे अजीब लगता है। एक टपल आपको .Priority उपयोग करने देता है जिसमें बेहतर स्व-दस्तावेजीकरण गुण होते हैं।

• _क्या पीक और डेक्यू को टपल के बजाय तर्क करना चाहिए?_ - मुझे लगता है कि हमें अन्य जगहों पर इसी तरह के तरीकों में स्थापित सम्मेलन का पालन करना चाहिए। तो शायद out तर्क का उपयोग करें।

• _क्या पीक और डेक्यू फेंकना बिल्कुल उपयोगी है?_ -- आपकी टिप्पणियों से 100% सहमत हैं।

• _सबसे छोटी प्राथमिकता सबसे अच्छी है_ -- सहमत।

• _गणना को कोई आदेश देने की गारंटी नहीं देनी चाहिए_ -- क्या यह उपयोगकर्ता की अपेक्षाओं का उल्लंघन नहीं कर सकता है? सौदेबाजी क्या हैं? एनबी हम शायद एपीआई समीक्षा चर्चा के लिए इस तरह के विवरण को स्थगित कर सकते हैं।

मैं कुछ अन्य खुले प्रश्नों को भी दोहराना चाहूंगा:

• क्या हम PriorityQueue<T> , PriorityQueue<TElement, TPriority> या दोनों को शिप करते हैं? - व्यक्तिगत रूप से मुझे लगता है कि हमें केवल बाद वाले को लागू करना चाहिए, क्योंकि ऐसा लगता है कि यह एक क्लीनर और अधिक सामान्य-उद्देश्य समाधान प्रदान करता है। सिद्धांत रूप में प्राथमिकता कतारबद्ध तत्व की आंतरिक संपत्ति नहीं होनी चाहिए, इसलिए हमें उपयोगकर्ताओं को इसे आवरण प्रकारों में समाहित करने के लिए बाध्य नहीं करना चाहिए।

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

  1. मूल तत्व (समानता तक) को पारित करके विशिष्टता/समानता और समर्थन अद्यतन परिदृश्य की आवश्यकता है।
  2. हैंडल का उपयोग करके विशिष्टता/समानता और समर्थन अद्यतन परिदृश्य की आवश्यकता नहीं है। इन्हें उन उपयोगकर्ताओं के लिए वैकल्पिक Enqueue विधि रूपों का उपयोग करके प्राप्त किया जा सकता है जिन्हें इनकी आवश्यकता है। यदि हैंडल आवंटन एक बड़ी चिंता है, तो मैं सोच रहा हूं कि क्या उन्हें ला वैल्यू टास्क में परिशोधित किया जा सकता है?
  3. विशिष्टता/समानता की आवश्यकता नहीं है और अद्यतन प्राथमिकताओं का समर्थन नहीं करते हैं।

• क्या हम कतारों को मर्ज करने का समर्थन करते हैं? - आम सहमति नहीं लगती है, क्योंकि हम केवल एक कार्यान्वयन (संभवतः सरणी ढेर का उपयोग करके) शिपिंग कर रहे हैं जहां विलय कुशल नहीं है।

• इसे किस इंटरफेस को लागू करना चाहिए? -- मैंने IQueue<T> की अनुशंसा करते हुए कुछ प्रस्ताव देखे, लेकिन यह एक टपका हुआ सार जैसा लगता है। मैं व्यक्तिगत रूप से इसे सरल रखना पसंद करूंगा और केवल ICollection<T> लागू करूंगा।

cc @layomia @safern

@eiriktsarpalis इसके विपरीत - अपडेट का समर्थन करने के लिए बाधा के बारे में कुछ भी कृत्रिम नहीं है!

प्राथमिकता कतार वाले एल्गोरिदम अक्सर तत्वों की प्राथमिकताओं
a) हैंडल मॉडल को समझें
बी) स्मृति में अतिरिक्त डेटा रखें, जैसे अतिरिक्त गुण या बाहरी शब्दकोश, वस्तुओं के हैंडल का ट्रैक रखने के लिए, उनकी तरफ, बस वे अपडेट कर सकते हैं (उन कक्षाओं के लिए शब्दकोश के साथ जाना चाहिए जिन्हें वे बदल नहीं सकते हैं? या वस्तुओं को टुपल्स आदि में अपग्रेड करें)
सी) 'स्मृति प्रबंधन', या 'कचरा संग्रह' बाहरी संरचनाएं यानी डिक्शनरी दृष्टिकोण का उपयोग करते समय उन वस्तुओं के लिए हैंडल साफ़ करें जो अब कतार में नहीं हैं
डी) कई कतारों के संदर्भ में अपारदर्शी हैंडल को भ्रमित न करें क्योंकि वे केवल एक प्राथमिकता कतार के संदर्भ में सार्थक हैं

साथ ही यह दार्शनिक प्रश्न पूरे कारण से है कि कोई भी एक कतार चाहेगा जो _वस्तुओं को प्राथमिकता से ट्रैक करे_ इस तरह से व्यवहार करने के लिए: एक ही वस्तु (सत्य रिटर्न के बराबर) में दो _भिन्न_ प्राथमिकताएं क्यों होनी चाहिए? अगर उन्हें वास्तव में अलग-अलग प्राथमिकताएं माना जाता है, तो उन्हें अलग-अलग वस्तुओं के रूप में क्यों नहीं बनाया जाता है? (या डिफरेंशियल के साथ टुपल्स में परिवर्तित?)

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

पुनश्च: प्रत्येक .net ऑब्जेक्ट पहले से ही समानता/विशिष्टता की अवधारणाओं का समर्थन करता है, इसलिए इसकी 'आवश्यकता' करने के लिए कोई बड़ी बात नहीं है।

KeyValuePair , मैं सहमत हूं कि यह आदर्श नहीं है (हालांकि प्रस्ताव में, Key तत्व के लिए है, Value प्राथमिकता के लिए है, जो विभिन्न Sorted अनुरूप है struct पसंद करूंगा, खासकर इनपुट के लिए।

विशिष्टता के संबंध में, यह एक मौलिक चिंता है, और मुझे नहीं लगता कि तब तक कुछ और तय किया जा सकता है। मैं (वैकल्पिक) तुलनित्र (मौजूदा प्रस्तावों और सुझाव i दोनों के अनुसार) द्वारा परिभाषित तत्व विशिष्टता का समर्थन करूंगा यदि लक्ष्य एक उपयोग में आसान और सामान्य उद्देश्य एपीआई है। अद्वितीय बनाम गैर-अद्वितीय एक बड़ी दरार है, और मैं विभिन्न उद्देश्यों के लिए दोनों प्रकारों का उपयोग करता हूं। पूर्व लागू करने के लिए 'कठिन' है, और गलत उपयोग के लिए कठिन होने के दौरान सबसे अधिक (और अधिक सामान्य) उपयोग मामलों (केवल मेरा अनुभव) को कवर करता है। वे मामलों का उपयोग करते हैं कि _require_ गैर-विशिष्टता (आईएमओ) को एक अलग प्रकार (उदाहरण के लिए एक सादा पुराना बाइनरी ढेर) द्वारा सेवित किया जाना चाहिए, और मैं दोनों उपलब्ध होने की सराहना करता हूं। यह अनिवार्य रूप से @pgolebiowski द्वारा लिंक किया गया मूल प्रस्ताव प्रदान करता है (जैसा कि मैं इसे समझता हूं) मॉड्यूलो ए (सरल) रैपर। _संपादित करें: नहीं, यह बंधी हुई प्राथमिकताओं का समर्थन नहीं करेगा_

इसके विपरीत - अपडेट का समर्थन करने के लिए बाधा के बारे में कुछ भी कृत्रिम नहीं है!

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

पुनश्च: प्रत्येक .net ऑब्जेक्ट पहले से ही समानता/विशिष्टता की अवधारणाओं का समर्थन करता है, इसलिए इसकी 'आवश्यकता' करने के लिए कोई बड़ी बात नहीं है

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

@eiriktsarpalis इसे स्पष्ट करने के लिए धन्यवाद। लेकिन क्या यह वाकई कृत्रिम है? मुझे नहीं लगता कि यह है। यह सिर्फ एक और प्राकृतिक समाधान है।

एपीआई को _अच्छी तरह से परिभाषित_ होना चाहिए। आप उपयोगकर्ता को इस बारे में विशिष्ट होने की आवश्यकता के बिना एक अपडेट एपीआई प्रदान नहीं कर सकते कि वे क्या अपडेट करना चाहते हैं । अच्छी तरह से परिभाषित एपीआई के निर्माण के लिए हैंडल और ऑब्जेक्ट समानता केवल दो अलग-अलग दृष्टिकोण हैं।

हैंडल दृष्टिकोण: हर बार जब आप संग्रह में कोई वस्तु जोड़ते हैं, तो आपको उसे एक 'नाम' देना होगा, यानी एक 'हैंडल', ताकि आप बातचीत में बाद में अस्पष्टता के बिना उस सटीक वस्तु को संदर्भित कर सकें।

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

दुर्भाग्य से, केवल ऑब्जेक्ट दृष्टिकोण वास्तव में आपको कुछ सबसे उपयोगी उच्च-स्तरीय API विधियों की संपत्ति का समर्थन करने की अनुमति देता है, जैसे 'EnqueueIfNotExists' या 'EnqueueOrDecreasePriroity(item)' - वे हैंडल-केंद्रित डिज़ाइन में प्रदान करने का कोई मतलब नहीं रखते हैं, क्योंकि आप यह नहीं पता कि क्या आइटम पहले से ही कतार में मौजूद है (चूंकि यह आपका काम है, उस पर नज़र रखना, हैंडल के साथ)।

हैंडल दृष्टिकोण की सबसे अधिक आलोचनाओं में से एक, या मेरे लिए विशिष्टता की कमी को छोड़ना, यह है कि यह सभी प्रकार के परिदृश्यों को अद्यतन करने योग्य प्राथमिकता के साथ लागू करने के लिए और अधिक जटिल बनाता है:

जैसे

1. प्राथमिकता कतार का उपयोग करेंसंदेशों/भावनाओं/टैग/उपयोगकर्ता नाम का प्रतिनिधित्व करने वाले तारों के लिए जो ऊपर/स्कोरअपडेटेड हो जाते हैं, अद्वितीय मानों की प्राथमिकता बदल रही है
2. प्राथमिकता कतार का उपयोग करें, डबल> अद्वितीय टुपल्स को ऑर्डर करने के लिए [चाहे उनकी प्राथमिकता में बदलाव हो या नहीं] - कहीं न कहीं अतिरिक्त हैंडल का ट्रैक रखना चाहिए
3. PriroityQueue का उपयोग करेंग्राफ इंडेक्स, या डेटाबेस ऑब्जेक्ट आईडी को प्राथमिकता देने के लिए, अब आपको अपने कार्यान्वयन के माध्यम से हैंडल छिड़कना होगा

पी.एस.

ज़रूर, लेकिन कभी-कभी समानता शब्दार्थ जो प्रकार के साथ आते हैं वे वांछनीय नहीं हो सकते हैं

IEqualityComparer जैसे एस्केप हैच होंगे, या एक समृद्ध प्रकार में अपवर्तन होंगे।

प्रतिक्रिया के लिए धन्यवाद सभी नए इनपुट को ध्यान में रखते हुए, सप्ताहांत में प्रस्ताव को अपडेट करेगा, और दूसरे दौर के लिए एक नया संशोधन साझा करेगा। ईटीए 2020-09-20।

प्राथमिकता कतार प्रस्ताव (v2.0)

सारांश

.NET कोर समुदाय सिस्टम लाइब्रेरी _priority queue_ कार्यक्षमता में जोड़ने का प्रस्ताव करता है, एक डेटा संरचना जिसमें प्रत्येक तत्व की इसके साथ एक प्राथमिकता भी जुड़ी होती है। विशेष रूप से, हम PriorityQueue<TElement, TPriority> को System.Collections.Generic नेमस्पेस में जोड़ने का प्रस्ताव करते हैं।

सिद्धांतों

हमारे डिजाइन में, हमें निम्नलिखित सिद्धांतों द्वारा निर्देशित किया गया था (जब तक कि आप बेहतर नहीं जानते):

• विस्तृत कवरेज। हम .NET कोर ग्राहकों को एक मूल्यवान डेटा संरचना की पेशकश करना चाहते हैं जो विभिन्न प्रकार के उपयोग के मामलों का समर्थन करने के लिए पर्याप्त बहुमुखी है।
• ज्ञात गलतियों से सीखें। हम प्राथमिकता कतार कार्यक्षमता प्रदान करने का प्रयास करते हैं जो अन्य ढांचे और भाषाओं, जैसे जावा, पायथन, सी ++, जंग में मौजूद ग्राहक-सामना करने वाले मुद्दों से मुक्त होगी। हम ऐसे डिज़ाइन विकल्प बनाने से बचेंगे जो ग्राहकों को नाखुश करने और प्राथमिकता वाली कतारों की उपयोगिता को कम करने के लिए जाने जाते हैं।
• एकतरफा निर्णय के साथ अत्यधिक सावधानी। एक बार एपीआई पेश करने के बाद, इसे संशोधित या हटाया नहीं जा सकता, केवल बढ़ाया जा सकता है। हम उप-इष्टतम समाधानों से बचने के लिए डिज़ाइन विकल्पों का सावधानीपूर्वक विश्लेषण करेंगे, जिससे हमारे ग्राहक हमेशा के लिए फंस जाएंगे।
• डिजाइन पक्षाघात से बचें। हम स्वीकार करते हैं कि कोई भी सही समाधान नहीं हो सकता है। हम ट्रेड-ऑफ को संतुलित करेंगे और डिलीवरी के साथ आगे बढ़ेंगे, अंत में अपने ग्राहकों को वह कार्यक्षमता प्रदान करने के लिए जिसका वे वर्षों से इंतजार कर रहे थे।

पृष्ठभूमि

एक ग्राहक के नजरिए से

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

कंप्यूटर विज्ञान पृष्ठभूमि

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

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

अद्यतन तंत्र प्रमुख डिजाइन चुनौती है

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

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

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

विकल्प (ए): हैंडल। इस दृष्टिकोण में, हर बार कतार में एक तत्व जोड़ा जाता है, डेटा संरचना अपना अनूठा हैंडल प्रदान करती है। यदि ग्राहक अद्यतन तंत्र का उपयोग करना चाहता है, तो उन्हें ऐसे हैंडल का ट्रैक रखने की आवश्यकता है ताकि वे बाद में स्पष्ट रूप से निर्दिष्ट कर सकें कि वे किस तत्व को अपडेट करना चाहते हैं। इस समाधान की प्राथमिक लागत यह है कि ग्राहकों को इन संकेतकों को प्रबंधित करने की आवश्यकता है। हालांकि, इसका मतलब यह नहीं है कि प्राथमिकता कतार के भीतर हैंडल का समर्थन करने के लिए किसी भी आंतरिक आवंटन की आवश्यकता है - कोई भी गैर-सरणी-आधारित ढेर नोड्स पर आधारित होता है, जहां प्रत्येक नोड स्वचालित रूप से अपना स्वयं का हैंडल होता है। उदाहरण के तौर पर, PairingHeap.Update विधि का API देखें।

विकल्प (बी): विशिष्टता। यह दृष्टिकोण ग्राहक पर दो अतिरिक्त बाधाएं डालता है: i) प्राथमिकता कतार के तत्वों को कुछ समानता शब्दार्थ के अनुरूप होना चाहिए, जो संभावित उपयोगकर्ता बग का एक नया वर्ग लाता है; ii) दो समान तत्वों को एक ही कतार में संग्रहीत नहीं किया जा सकता है। इस लागत का भुगतान करके, हम हैंडल दृष्टिकोण का सहारा लिए बिना अद्यतन तंत्र का समर्थन करने का लाभ प्राप्त करते हैं। हालांकि, अद्यतन करने के लिए तत्व को निर्धारित करने के लिए विशिष्टता/समानता का लाभ उठाने वाले किसी भी कार्यान्वयन के लिए अतिरिक्त आंतरिक मैपिंग की आवश्यकता होगी, ताकि यह ओ (1) में किया जा सके और ओ (एन) में नहीं।

अनुशंसा

हम सिस्टम लाइब्रेरी में एक PriorityQueue<TElement, TPriority> वर्ग जोड़ने की अनुशंसा करते हैं जो हैंडल के माध्यम से अद्यतन तंत्र का समर्थन करता है। अंतर्निहित कार्यान्वयन एक जोड़ी ढेर होगा।

public class PriorityQueueNode<TElement, TPriority>
{
    public TElement Element { get; }
    public TPriority Priority { get; }
}

public class PriorityQueue<TElement, TPriority> :
    IEnumerable<PriorityQueueNode<TElement, TPriority>>
{
    public PriorityQueue();
    public PriorityQueue(IComparer<TPriority> comparer);

    public IComparer<TPriority> Comparer { get; }
    public int Count { get; }

    public bool IsEmpty { get; }
    public void Clear();
    public bool Contains(TElement element); // O(n)
    public bool TryGetNode(TElement element, out PriorityQueueNode<TElement, TPriority> node); // O(n)

    public PriorityQueueNode<TElement, TPriority> Enqueue(TElement element, TPriority priority); //O(log n)

    public PriorityQueueNode<TElement, TPriority> Peek(); // O(1)
    public bool TryPeek(out PriorityQueueNode<TElement, TPriority> node); // O(1)

    public void Dequeue(out TElement element); // O(log n)
    public bool TryDequeue(out TElement element, out TPriority priority); // O(log n)

    public void Update(PriorityQueueNode<TElement, TPriority> node, TPriority priority); // O(log n)
    public void Remove(PriorityQueueNode<TElement, TPriority> node); // O(log n)

    public void Merge(PriorityQueue<TElement, TPriority> other) // O(1)

    public IEnumerator<PriorityQueueNode<TElement, TPriority>> GetEnumerator();
    IEnumerator IEnumerable.GetEnumerator();

    public struct Enumerator : IEnumerator<PriorityQueueNode<TElement, TPriority>>
    {
        public PriorityQueueNode<TElement, TPriority> Current { get; }
        object IEnumerator.Current { get; }
        public bool MoveNext() => throw new NotImplementedException();
        public void Reset() => throw new NotImplementedException();
        public void Dispose() => throw new NotImplementedException();
    }
}

उदाहरण उपयोग

1) ग्राहक जो अद्यतन तंत्र की परवाह नहीं करता

var queue = new PriorityQueue<Job, double>();
queue.Enqueue(firstJob, 10);
queue.Enqueue(secondJob, 5);
queue.Enqueue(thirdJob, 40);

var withHighestPriority = queue.Peek(); // { element: secondJob, priority: 5 }

2) ग्राहक जो अद्यतन तंत्र की परवाह करता है

var queue = new PriorityQueue<Job, double>();
var mapping = new Dictionary<Job, PriorityQueueNode<Job, double>>();

mapping[job] = queue.Enqueue(job, priority);

queue.Update(mapping[job], newPriority);

सामान्य प्रश्न

प्राथमिकता कतार किस क्रम में तत्वों की गणना करती है?

अपरिभाषित क्रम में, ताकि गणना ओ (एन) में हो सके, इसी तरह HashSet । कोई भी कुशल कार्यान्वयन यह सुनिश्चित करते हुए रैखिक समय में एक ढेर की गणना करने की क्षमता प्रदान नहीं करेगा कि तत्वों की गणना क्रम में की गई है - इसके लिए O (n लॉग n) की आवश्यकता होगी। क्योंकि संग्रह पर ऑर्डर करना .OrderBy(x => x.Priority) साथ मामूली रूप से प्राप्त किया जा सकता है और प्रत्येक ग्राहक इस आदेश के साथ गणना की परवाह नहीं करता है, हम मानते हैं कि अपरिभाषित गणना आदेश प्रदान करना बेहतर है।

परिशिष्ट

परिशिष्ट ए: प्राथमिकता कतार कार्यक्षमता वाली अन्य भाषाएं

| भाषा | प्रकार | नोट्स |
|:-:|:-:|:-:|
| जावा | प्राथमिकता कतार | अमूर्त वर्ग AbstractQueue और इंटरफ़ेस Queue लागू करता है। |
| जंग | बाइनरीहीप | |
| स्विफ्ट | सीएफबीनरीहीप | |
| सी++ | प्राथमिकता_क्यू | |
| अजगर | ढेर | |
| जाओ | ढेर | एक ढेर इंटरफ़ेस है। |

परिशिष्ट बी: खोज योग्यता

ध्यान दें कि डेटा संरचनाओं पर चर्चा करते समय, _heap_ शब्द का उपयोग _priority queue_ की तुलना में 4 गुना अधिक बार किया जाता है।

• "array" AND "data structure" — 17.400,000 परिणाम
• "stack" AND "data structure" — 12.100.000 परिणाम
• "queue" AND "data structure" — 3.850.000 परिणाम
• "heap" AND "data structure" — 1.830.000 परिणाम
• "priority queue" AND "data structure" — 430.000 परिणाम
• "trie" AND "data structure" — 335.000 परिणाम

कृपया समीक्षा करें, प्रतिक्रिया प्राप्त करने और पुनरावृति करने में प्रसन्नता हो रही है :) मुझे लगता है कि हम अभिसरण कर रहे हैं! प्रश्न प्राप्त करने में भी प्रसन्नता हो रही है - उन्हें अक्सर पूछे जाने वाले प्रश्नों में जोड़ दिया जाएगा!

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

• यह अजीब लगता है कि TryDequeue एक नोड लौटाता है, क्योंकि यह वास्तव में उस बिंदु पर एक हैंडल नहीं है (मैं दो अलग-अलग पैरामीटर पसंद करूंगा)
• क्या यह स्थिर होगा कि यदि दो तत्वों को एक ही प्राथमिकता के साथ कतारबद्ध किया जाता है तो वे एक अनुमानित क्रम में कम हो जाते हैं? (पुनरुत्पादन के लिए अच्छा है; अन्यथा उपभोक्ता द्वारा आसानी से लागू किया जा सकता है)
• Merge लिए पैरामीटर PriorityQueue'2 नहीं PriorityQueueNode'2 , और क्या आप व्यवहार को स्पष्ट कर सकते हैं? मैं युग्मन ढेर से परिचित नहीं हूँ, लेकिन संभवतः दो ढेर उसके बाद ओवरलैप हो जाते हैं
• मैं 2-पैरामीटर विधि के लिए Contains नाम का प्रशंसक नहीं हूं: यह एक ऐसा नाम नहीं है जिसका अनुमान मैं TryGet शैली पद्धति के लिए लगाऊंगा
• वर्ग एक कस्टम का समर्थन करना चाहिए IEqualityComparer<TElement> के प्रयोजन के लिए Contains ?
• ऐसा प्रतीत नहीं होता है कि कोई नोड अभी भी ढेर में है या नहीं (सुनिश्चित नहीं है कि मैं इसका उपयोग कब करूंगा, सोचा)
• यह अजीब है कि Remove रिटर्न एक bool ; मुझे उम्मीद है कि इसे TryRemove कहा जाता था या इसे फेंक दिया जाता था (जो मैं Update मान रहा हूं यदि नोड ढेर में नहीं है)।

@VisualMelon प्रतिक्रिया के लिए बहुत बहुत धन्यवाद! इनका शीघ्र समाधान करेंगे, निश्चित रूप से सहमत:

• यह अजीब लगता है कि TryDequeue एक नोड लौटाता है, क्योंकि यह वास्तव में उस बिंदु पर एक हैंडल नहीं है (मैं दो अलग-अलग पैरामीटर पसंद करूंगा)
• Merge लिए पैरामीटर PriorityQueue'2 नहीं PriorityQueueNode'2 , और क्या आप व्यवहार को स्पष्ट कर सकते हैं? मैं युग्मन ढेर से परिचित नहीं हूँ, लेकिन संभवतः दो ढेर उसके बाद ओवरलैप हो जाते हैं
• यह अजीब है कि Remove रिटर्न एक bool ; मुझे उम्मीद है कि इसे TryRemove कहा जाता था या इसे फेंक दिया जाता था (जो मैं मान रहा हूं Update अगर नोड ढेर में नहीं है)।
• मैं 2-पैरामीटर विधि के लिए Contains नाम का प्रशंसक नहीं हूं: यह एक ऐसा नाम नहीं है जिसका अनुमान मैं TryGet शैली पद्धति के लिए लगाऊंगा

इन दोनों के लिए स्पष्टीकरण:

• क्या यह स्थिर होगा कि यदि दो तत्वों को एक ही प्राथमिकता के साथ कतारबद्ध किया जाता है तो वे एक अनुमानित क्रम में कम हो जाते हैं? (पुनरुत्पादन के लिए अच्छा है; अन्यथा उपभोक्ता द्वारा आसानी से लागू किया जा सकता है)
• ऐसा प्रतीत नहीं होता है कि कोई नोड अभी भी ढेर में है या नहीं (सुनिश्चित नहीं है कि मैं इसका उपयोग कब करूंगा, सोचा)

पहले बिंदु के लिए, यदि लक्ष्य प्रतिलिपि प्रस्तुत करने योग्य है, तो कार्यान्वयन नियतात्मक होगा, हाँ। यदि लक्ष्य _if दो तत्व हैं जिन्हें समान प्राथमिकता के साथ कतार में रखा गया है, तो यह इस प्रकार है कि वे उसी क्रम में बाहर आएंगे जिसमें उन्हें कतार में रखा गया था_ - मुझे यकीन नहीं है कि कार्यान्वयन को समायोजित किया जा सकता है या नहीं इस संपत्ति को प्राप्त करने के लिए, एक त्वरित उत्तर "शायद नहीं" होगा।

दूसरे बिंदु के लिए, हाँ, संग्रह में कोई तत्व मौजूद है या नहीं, यह जांचने के लिए ढेर अच्छे नहीं हैं, ग्राहक को ओ (1) में इसे प्राप्त करने के लिए अलग से इसका ट्रैक रखना होगा या मैपिंग का पुन: उपयोग करना होगा जो वे हैंडल के लिए उपयोग करते हैं, यदि वे अद्यतन तंत्र का उपयोग करते हैं। अन्यथा, ओ (एन)।

• क्या कक्षा को Contains के उद्देश्य से एक कस्टम IEqualityComparer<TElement> समर्थन करना चाहिए?

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

@pgolebiowski स्पष्टीकरण के लिए धन्यवाद

पहले बिंदु के लिए, यदि लक्ष्य प्रतिलिपि प्रस्तुत करने योग्य है, तो कार्यान्वयन नियतात्मक होगा, हाँ

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

दूसरे बिंदु के लिए, हाँ, संग्रह में कोई तत्व मौजूद है या नहीं, यह जांचने के लिए ढेर अच्छे नहीं हैं, ग्राहक को ओ (1) में इसे प्राप्त करने के लिए अलग से इसका ट्रैक रखना होगा या मैपिंग का पुन: उपयोग करना होगा जो वे हैंडल के लिए उपयोग करते हैं, यदि वे अद्यतन तंत्र का उपयोग करते हैं। अन्यथा, ओ (एन)।

क्या इसे Remove लिए आवश्यक कार्य के सबसेट की आवश्यकता नहीं है? मैं स्पष्ट नहीं हो सकता था: मेरा मतलब PriorityQueueNode , यह जांच रहा था कि यह ढेर में है या नहीं ( TElement )।

हम्म ... मुझे लगता है कि शायद इस प्राथमिकता कतार की ज़िम्मेदारी में शामिल होना बहुत अधिक हो सकता है

अगर Contains नहीं होता तो मैं शिकायत नहीं करता: यह उन लोगों के लिए भी एक जाल है जो नहीं जानते कि उन्हें हैंडल का उपयोग करना चाहिए।

@pgolebiowski आप हैंडल के पक्ष में बहुत दृढ़ता से प्रतीत होते हैं, क्या मैं इसे दक्षता कारणों से सोचने में सही हूं?

दक्षता के दृष्टिकोण से, मुझे संदेह है कि अद्वितीयता के साथ और बिना दोनों परिदृश्यों के लिए हैंडल वास्तव में सबसे अच्छे हैं, इसलिए मैं इसके साथ ठीक हूं क्योंकि ढांचे द्वारा पेश किया गया प्राथमिक समाधान है।

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

वर्तमान एपीआई के लिए खुद को प्रस्तावित किया, कुछ विचार/प्रश्न:

• TryPeek(out TElement element, out TPriority priority) का अधिभार प्रदान करने के बारे में कैसे?
• यदि आपके पास अद्यतन करने योग्य डुप्लिकेट कुंजियाँ हैं, तो मुझे एक चिंता है कि यदि 'डेक्यू' प्राथमिकता कतार नोड वापस नहीं करता है, तो आप अपने हैंडल ट्रैकिंग सिस्टम से सही सटीक नोड को कैसे हटा रहे हैं, इसकी जांच कैसे करेंगे? चूंकि आपके पास समान प्राथमिकता वाले तत्व की एक से अधिक प्रति हो सकती है।
• क्या नोड नहीं मिलने पर Remove(PriorityQueueNode) फेंक देता है? या झूठी वापसी?
• क्या कोई TryRemove() संस्करण होना चाहिए जो फेंकता है तो फेंकता नहीं है?
• मुझे यकीन नहीं है कि Contains() एपीआई ज्यादातर समय उपयोगी है? देखने वाले की नज़र में 'कंटेन्स' लगता है, विशेष रूप से विशिष्ट प्राथमिकताओं वाले 'डुप्लिकेट' तत्वों या अन्य विशिष्ट विशेषताओं वाले परिदृश्यों के लिए! इस मामले में अंतिम उपयोगकर्ता को शायद वैसे भी अपनी खुद की खोज करनी चाहिए। लेकिन कम से कम यह बिना किसी डुप्लीकेट वाले परिदृश्य के लिए उपयोगी हो सकता है।

@pgolebiowski नए प्रस्ताव का मसौदा तैयार करने के लिए समय निकालने के लिए धन्यवाद! मेरी तरफ से कुछ टिप्पणियाँ:

• @TimLovellSmith की टिप्पणी को प्रतिध्वनित Contains() या TryGetNode() वर्तमान में प्रस्तावित रूप में एपीआई में मौजूद होना चाहिए। उनका मतलब है कि TElement लिए समानता महत्वपूर्ण है, जो संभवत: उन चीजों में से एक है जो एक हैंडल-आधारित दृष्टिकोण से बचने की कोशिश कर रहा था।
• मैं शायद public void Dequeue(out TElement element); को public TElement Dequeue(); रूप में फिर से लिखूंगा
• TryDequeue() विधि को प्राथमिकता वापस करने की आवश्यकता क्यों है?
• क्या कक्षा को ICollection<T> या IReadOnlyCollection<T> भी लागू नहीं करना चाहिए?
• यदि मैं किसी भिन्न प्रायोरिटी क्यू इंस्टेंस से लौटाए गए प्रायोरिटी क्यूयूएनओडी को अपडेट करने का प्रयास करता हूं तो क्या होगा?
• क्या हम एक कुशल मर्ज ऑपरेशन का समर्थन करना चाहते हैं? AFAICT इसका तात्पर्य है कि हम सरणी-आधारित प्रतिनिधित्व का उपयोग नहीं कर सकते हैं। यह आवंटन के संदर्भ में कार्यान्वयन को कैसे प्रभावित करेगा?

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

बाद के तरीकों को चुनने के लिए ट्रेड-ऑफ क्या हैं? क्या उनके लिए सरणी-आधारित कार्यान्वयन का उपयोग करना संभव है?

यह ICollection<T> या IReadOnlyCollection<T> लागू नहीं कर सकता जब उसके पास 'जोड़ें' और 'निकालें' आदि के लिए सही हस्ताक्षर नहीं हैं।

यह आत्मा/आकार में ICollection<KeyValuePair<T,Priority>> . के बहुत करीब है

यह आत्मा/आकार में ICollection<KeyValuePair<T,Priority>> . के बहुत करीब है

क्या यह KeyValuePair<TPriority, TElement> , क्योंकि आदेश TP प्राथमिकता द्वारा किया जाता है, जो प्रभावी रूप से एक कुंजीयन तंत्र है?

ठीक है, ऐसा लगता है कि हम कुल मिलाकर Contains और TryGet विधियों को छोड़ने के पक्ष में हैं। अगले संशोधन में उन्हें हटा देंगे और अक्सर पूछे जाने वाले प्रश्न में निष्कासन का कारण बताएंगे।

लागू किए गए इंटरफेस के लिए — क्या IEnumerable<PriorityQueueNode<TElement, TPriority>> पर्याप्त नहीं है? किस प्रकार की कार्यक्षमता गुम है?

KeyValuePair - कुछ आवाजें थीं कि .Element और .Priority साथ एक टपल या एक संरचना अधिक वांछनीय है। मुझे लगता है कि मैं इनके पक्ष में हूं।

क्या यह KeyValuePair<TPriority, TElement> , क्योंकि आदेश TP प्राथमिकता द्वारा किया जाता है, जो प्रभावी रूप से एक कुंजीयन तंत्र है?

दोनों पक्षों के लिए अच्छे तर्क हैं। एक ओर, हाँ, ठीक वही जो आपने अभी कहा। दूसरी ओर, केवीपी संग्रह में चाबियों के अद्वितीय होने की अपेक्षा की जाती है, और समान प्राथमिकता वाले कई तत्वों का होना पूरी तरह से मान्य है।

दूसरी ओर, केवीपी संग्रह में चाबियों के अद्वितीय होने की अपेक्षा की जाती है

मैं इस कथन से असहमत हूं - कुंजी-मूल्य जोड़े का संग्रह बस यही है; किसी भी विशिष्टता की आवश्यकता उसके ऊपर स्तरित होती है।

IEnumerable<PriorityQueueNode<TElement, TPriority>> पर्याप्त नहीं है? किस प्रकार की कार्यक्षमता गुम है?

मैं व्यक्तिगत रूप से IReadOnlyCollection<PQN<TElement, TPriority>> को लागू करने की अपेक्षा करता हूं, क्योंकि प्रदान किया गया एपीआई पहले से ही उस इंटरफ़ेस को संतुष्ट करता है। साथ ही, यह अन्य संग्रह प्रकारों के अनुरूप होगा।

इंटरफ़ेस के संबंध में:

```
सार्वजनिक बूल TryGetNode (TElement तत्व, प्रायोरिटी क्यूयूएनोड से बाहर)नोड); // पर)

What's the point of it if I can just do enumerate collection and do comparison of elements? And why only Try version?

public PriorityQueueNode<TElement, TPriority> Peek(); // O(1)
public void Dequeue(out TElement element); // O(log n)

I find it a bit strange to have discrepancy between Dequeue and Peek. They do pretty much same thing expect one is removing element from queue and other is not, it's looks weird for me if one returns priority and element and other just element.

public void Remove(PriorityQueueNode<TElement, TPriority> node); // O(log n)

`Queue` doesn't have `Remove` method, why `PriorityQueue` should ?


I would also like to see constructor

सार्वजनिक प्राथमिकता कतार(IEnumerable> संग्रह);
```

मैं PriorityQueue को IReadonlyCollection<> इंटरफ़ेस को लागू करने के लिए भी चाहूंगा।

सार्वजनिक एपीआई सतह के अलावा अन्य चीजों पर कूदना।

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

मैं असहमत होना चाहूंगा। पिछली बार मैंने सी ++ में डिजस्ट्रा लिखा था std::priority_queue पर्याप्त था और यह प्राथमिकता अद्यतन को संभालता नहीं है। उस मामले के लिए AFAIK आम सहमति नकली तत्व को परिवर्तित प्राथमिकता और मूल्य के साथ कतार में जोड़ने के लिए है और हमारे पास मूल्य की प्रक्रिया है या नहीं। जॉब शेड्यूलर के साथ भी ऐसा ही किया जा सकता है।

ईमानदार होने के लिए मुझे यकीन नहीं है कि वर्तमान कतार प्रस्ताव के साथ दिज्क्स्ट्रा कैसा दिखेगा। मुझे लगता है कि नोड्स का ट्रैक रखने के लिए मुझे अद्यतन प्राथमिकता की आवश्यकता है? TryGetNode () के साथ? या नोड्स का एक और संग्रह है? वर्तमान प्रस्ताव के लिए कोड देखना अच्छा लगेगा।

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

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

मैंने कागज में देखा है और यह उसमें से उद्धरण है:

परिणाम बताते हैं कि कार्यान्वयन का इष्टतम विकल्प अत्यधिक इनपुट-निर्भर है। इसके अलावा, यह दर्शाता है कि कैश प्रदर्शन के अनुकूलन के लिए देखभाल की जानी चाहिए, मुख्य रूप से L1-L2 बैरियर पर। इससे पता चलता है कि जटिल, कैशे-अनभिज्ञ संरचनाओं के सरल, कैशे-जागरूक संरचनाओं की तुलना में अच्छा प्रदर्शन करने की संभावना नहीं है।

ऐसा लगता है कि वर्तमान कतार प्रस्ताव सरणी के बजाय पेड़ कार्यान्वयन के पीछे बंद कर दिया जाएगा, और कुछ मुझे बताता है कि स्मृति के चारों ओर बिखरे हुए पेड़ नोड्स तत्वों की सरणी के रूप में प्रदर्शनकारी नहीं होंगे।

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

किसी अन्य विषय पर जाते हुए, मैं व्यक्तिगत रूप से KeyValuePair रखना पसंद करूंगानए कस्टम वर्ग की तुलना में।

• कम एपीआई सतह
• मैं ऐसा कुछ कर सकता हूं: 'नई प्राथमिकता कतार'(नया शब्दकोश() {{ 1, 1}, {2, 2}, {3, 3}, {4, 4}, {5, 5}}); मुझे पता है कि यह कुंजी की विशिष्टता से सीमित है। इसके अलावा, मुझे लगता है कि यह IDictionary आधारित संग्रहों का उपभोग करने के लिए अच्छा तालमेल लाएगा।
• यह वर्ग के बजाय एक संरचना है इसलिए कोई NullReference अपवाद नहीं है
• किसी बिंदु पर PrioirtyQueue को क्रमबद्ध/deserialized करने की आवश्यकता होगी और मुझे लगता है कि पहले से मौजूद वस्तु के साथ ऐसा करना आसान होगा।

नकारात्मक पक्ष TPriority Key पर मिश्रित भावनाएं हैं लेकिन मुझे लगता है कि अच्छा दस्तावेज इसे हल कर सकता है।
`

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

मैं IReadOnlyCollection करने में सक्षम नहीं होने के बारे में गलत था, यह ठीक होना चाहिए। उस इंटरफ़ेस में कोई जोड़ें() और निकालें() नहीं, हैह! (मैं क्या सोच रहा था...)

@ Ivanidzo4ka आपकी टिप्पणियां मुझे और भी अधिक आश्वस्त करती हैं कि यह दो अलग-अलग प्रकारों के लिए समझ में आता है: एक साधारण बाइनरी ढेर (यानी बिना किसी अद्यतन के), और प्रस्तावों में से एक द्वारा वर्णित दूसरा:

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

अतीत में, मैं ज्यादातर एक द्विआधारी ढेर से दूर हो गया हूं जिसे मैंने एक दशक पहले लिखा था, और एक SortedSet / Dictionary संयोजन, और ऐसे परिदृश्य हैं जहां मैंने उपयोग किया है दोनों प्रकार अलग-अलग भूमिकाओं में (केएसएसपी स्प्रिंग्स टू माइंड)।

यह वर्ग के बजाय एक संरचना है इसलिए कोई NullReference अपवाद नहीं है

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

मैं सुझाव देने के लिए ललचा रहा हूं कि तत्व के साथ-साथ हैंडल आधारित प्रस्ताव में प्राथमिकता को अपडेट करना संभव होना चाहिए। आप केवल एक हैंडल को हटाकर और एक नया जोड़कर समान प्रभाव प्राप्त कर सकते हैं, लेकिन यह एक उपयोगी ऑपरेशन है, और कार्यान्वयन के आधार पर प्रदर्शन लाभ हो सकते हैं (उदाहरण के लिए कुछ ढेर अपेक्षाकृत सस्ते में कुछ की प्राथमिकता को कम कर सकते हैं)। इस तरह के बदलाव से कई चीजों को लागू करना आसान हो जाएगा (उदाहरण के लिए मौजूदा AlgoKit ParingHeap पर आधारित यह कुछ हद तक दुःस्वप्न उत्प्रेरण उदाहरण), विशेष रूप से वे जो राज्य अंतरिक्ष के अज्ञात क्षेत्र में काम करते हैं।

प्राथमिकता कतार प्रस्ताव (v2.1)

सारांश

.NET कोर समुदाय सिस्टम लाइब्रेरी _priority queue_ कार्यक्षमता में जोड़ने का प्रस्ताव करता है, एक डेटा संरचना जिसमें प्रत्येक तत्व की इसके साथ एक प्राथमिकता भी जुड़ी होती है। विशेष रूप से, हम PriorityQueue<TElement, TPriority> को System.Collections.Generic नेमस्पेस में जोड़ने का प्रस्ताव करते हैं।

सिद्धांतों

हमारे डिजाइन में, हमें निम्नलिखित सिद्धांतों द्वारा निर्देशित किया गया था (जब तक कि आप बेहतर नहीं जानते):

• विस्तृत कवरेज। हम .NET कोर ग्राहकों को एक मूल्यवान डेटा संरचना की पेशकश करना चाहते हैं जो विभिन्न प्रकार के उपयोग के मामलों का समर्थन करने के लिए पर्याप्त बहुमुखी है।
• ज्ञात गलतियों से सीखें। हम प्राथमिकता कतार कार्यक्षमता प्रदान करने का प्रयास करते हैं जो अन्य ढांचे और भाषाओं, जैसे जावा, पायथन, सी ++, जंग में मौजूद ग्राहक-सामना करने वाले मुद्दों से मुक्त होगी। हम ऐसे डिज़ाइन विकल्प बनाने से बचेंगे जो ग्राहकों को नाखुश करने और प्राथमिकता वाली कतारों की उपयोगिता को कम करने के लिए जाने जाते हैं।
• एकतरफा निर्णय के साथ अत्यधिक सावधानी। एक बार एपीआई पेश करने के बाद, इसे संशोधित या हटाया नहीं जा सकता, केवल बढ़ाया जा सकता है। हम उप-इष्टतम समाधानों से बचने के लिए डिज़ाइन विकल्पों का सावधानीपूर्वक विश्लेषण करेंगे, जिससे हमारे ग्राहक हमेशा के लिए फंस जाएंगे।
• डिजाइन पक्षाघात से बचें। हम स्वीकार करते हैं कि कोई भी सही समाधान नहीं हो सकता है। हम ट्रेड-ऑफ को संतुलित करेंगे और डिलीवरी के साथ आगे बढ़ेंगे, अंत में अपने ग्राहकों को वह कार्यक्षमता प्रदान करने के लिए जिसका वे वर्षों से इंतजार कर रहे थे।

पृष्ठभूमि

एक ग्राहक के नजरिए से

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

कंप्यूटर विज्ञान पृष्ठभूमि

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

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

अद्यतन तंत्र प्रमुख डिजाइन चुनौती है

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

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

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

विकल्प (ए): हैंडल। इस दृष्टिकोण में, हर बार कतार में एक तत्व जोड़ा जाता है, डेटा संरचना अपना अनूठा हैंडल प्रदान करती है। यदि ग्राहक अद्यतन तंत्र का उपयोग करना चाहता है, तो उन्हें ऐसे हैंडल का ट्रैक रखने की आवश्यकता है ताकि वे बाद में स्पष्ट रूप से निर्दिष्ट कर सकें कि वे किस तत्व को अपडेट करना चाहते हैं। इस समाधान की प्राथमिक लागत यह है कि ग्राहकों को इन संकेतकों को प्रबंधित करने की आवश्यकता है। हालांकि, इसका मतलब यह नहीं है कि प्राथमिकता कतार के भीतर हैंडल का समर्थन करने के लिए किसी भी आंतरिक आवंटन की आवश्यकता है - कोई भी गैर-सरणी-आधारित ढेर नोड्स पर आधारित होता है, जहां प्रत्येक नोड स्वचालित रूप से अपना स्वयं का हैंडल होता है। उदाहरण के तौर पर, PairingHeap.Update विधि का API देखें।

विकल्प (बी): विशिष्टता। यह दृष्टिकोण ग्राहक पर दो अतिरिक्त बाधाएं डालता है: i) प्राथमिकता कतार के तत्वों को कुछ समानता शब्दार्थ के अनुरूप होना चाहिए, जो संभावित उपयोगकर्ता बग का एक नया वर्ग लाता है; ii) दो समान तत्वों को एक ही कतार में संग्रहीत नहीं किया जा सकता है। इस लागत का भुगतान करके, हम हैंडल दृष्टिकोण का सहारा लिए बिना अद्यतन तंत्र का समर्थन करने का लाभ प्राप्त करते हैं। हालांकि, अद्यतन करने के लिए तत्व को निर्धारित करने के लिए विशिष्टता/समानता का लाभ उठाने वाले किसी भी कार्यान्वयन के लिए अतिरिक्त आंतरिक मैपिंग की आवश्यकता होगी, ताकि यह ओ (1) में किया जा सके और ओ (एन) में नहीं।

अनुशंसा

हम सिस्टम लाइब्रेरी में एक PriorityQueue<TElement, TPriority> वर्ग जोड़ने की अनुशंसा करते हैं जो हैंडल के माध्यम से अद्यतन तंत्र का समर्थन करता है। अंतर्निहित कार्यान्वयन एक जोड़ी ढेर होगा।

public class PriorityQueueNode<TElement, TPriority>
{
    public TElement Element { get; }
    public TPriority Priority { get; }
}

public class PriorityQueue<TElement, TPriority> :
    IEnumerable<PriorityQueueNode<TElement, TPriority>>,
    IReadOnlyCollection<PriorityQueueNode<TElement, TPriority>>
{
    public PriorityQueue();
    public PriorityQueue(IComparer<TPriority> comparer);

    public IComparer<TPriority> Comparer { get; }
    public int Count { get; }

    public bool IsEmpty { get; }
    public void Clear();

    public PriorityQueueNode<TElement, TPriority> Enqueue(TElement element, TPriority priority); //O(log n)

    public PriorityQueueNode<TElement, TPriority> Peek(); // O(1)
    public bool TryPeek(out PriorityQueueNode<TElement, TPriority> node); // O(1)
    public bool TryPeek(out TElement element, out TPriority priority); // O(1)
    public bool TryPeek(out TElement element); // O(1)

    public PriorityQueueNode<TElement, TPriority> Dequeue(); // O(log n)
    public void Dequeue(out TElement element, out TPriority priority); // O(log n)
    public bool TryDequeue(out PriorityQueueNode<TElement, TPriority> node); // O(log n)
    public bool TryDequeue(out TElement element, out TPriority priority); // O(log n)
    public bool TryDequeue(out TElement element); // O(log n)

    public void Update(PriorityQueueNode<TElement, TPriority> node, TPriority priority); // O(log n)
    public void Remove(PriorityQueueNode<TElement, TPriority> node); // O(log n)

    public void Merge(PriorityQueue<TElement, TPriority> other) // O(1)

    public IEnumerator<PriorityQueueNode<TElement, TPriority>> GetEnumerator();
    IEnumerator IEnumerable.GetEnumerator();

    public struct Enumerator : IEnumerator<PriorityQueueNode<TElement, TPriority>>
    {
        public PriorityQueueNode<TElement, TPriority> Current { get; }
        object IEnumerator.Current { get; }
        public bool MoveNext() => throw new NotImplementedException();
        public void Reset() => throw new NotImplementedException();
        public void Dispose() => throw new NotImplementedException();
    }
}

उदाहरण उपयोग

1) ग्राहक जो अद्यतन तंत्र की परवाह नहीं करता

var queue = new PriorityQueue<Job, double>();
queue.Enqueue(firstJob, 10);
queue.Enqueue(secondJob, 5);
queue.Enqueue(thirdJob, 40);

var withHighestPriority = queue.Peek(); // { element: secondJob, priority: 5 }

2) ग्राहक जो अद्यतन तंत्र की परवाह करता है

var queue = new PriorityQueue<Job, double>();
var mapping = new Dictionary<Job, PriorityQueueNode<Job, double>>();

mapping[job] = queue.Enqueue(job, priority);

queue.Update(mapping[job], newPriority);

सामान्य प्रश्न

1. प्राथमिकता कतार किस क्रम में तत्वों की गणना करती है?

अपरिभाषित क्रम में, ताकि गणना ओ (एन) में हो सके, इसी तरह HashSet । कोई भी कुशल कार्यान्वयन यह सुनिश्चित करते हुए रैखिक समय में एक ढेर की गणना करने की क्षमता प्रदान नहीं करेगा कि तत्वों की गणना क्रम में की गई है - इसके लिए O (n लॉग n) की आवश्यकता होगी। क्योंकि संग्रह पर ऑर्डर करना .OrderBy(x => x.Priority) साथ मामूली रूप से प्राप्त किया जा सकता है और प्रत्येक ग्राहक इस आदेश के साथ गणना की परवाह नहीं करता है, हम मानते हैं कि अपरिभाषित गणना आदेश प्रदान करना बेहतर है।

2. कोई Contains या TryGet पद्धति क्यों नहीं है?

ऐसी विधियों को प्रदान करना नगण्य मूल्य है, क्योंकि ढेर में एक तत्व खोजने के लिए पूरे संग्रह की गणना की आवश्यकता होती है, जिसका अर्थ है कि कोई भी Contains या TryGet विधि गणना के चारों ओर एक आवरण होगी। इसके अलावा, यह जाँचने के लिए कि क्या संग्रह में कोई तत्व मौजूद है, प्राथमिकता कतार को इस बात की जानकारी होनी चाहिए कि TElement वस्तुओं की समानता जाँच कैसे की जाती है, जो कि ऐसा कुछ नहीं है जिसे हम मानते हैं कि प्राथमिकता कतार की जिम्मेदारी में आना चाहिए।

3. Dequeue और TryDequeue ओवरलोड क्यों हैं जो PriorityQueueNode लौटाते हैं?

यह उन ग्राहकों के लिए है जो Update या Remove पद्धति का उपयोग करना चाहते हैं और हैंडल का ट्रैक रखना चाहते हैं। प्राथमिकता कतार से एक तत्व को हटाने के दौरान, उन्हें एक हैंडल प्राप्त होगा जिसका उपयोग वे अपने हैंडल ट्रैकिंग सिस्टम की स्थिति को समायोजित करने के लिए कर सकते हैं।

4. क्या होता है जब Update या Remove विधि एक अलग कतार से एक नोड प्राप्त करती है?

प्राथमिकता कतार एक अपवाद फेंक देगी। प्रत्येक नोड उस प्राथमिकता कतार के बारे में जानता है जिससे वह संबंधित है, उसी तरह जैसे LinkedListNode<T> को LinkedList<T> बारे में पता होता है।

परिशिष्ट

परिशिष्ट ए: प्राथमिकता कतार कार्यक्षमता वाली अन्य भाषाएं

| भाषा | प्रकार | नोट्स |
|:-:|:-:|:-:|
| जावा | प्राथमिकता कतार | अमूर्त वर्ग AbstractQueue और इंटरफ़ेस Queue लागू करता है। |
| जंग | बाइनरीहीप | |
| स्विफ्ट | सीएफबीनरीहीप | |
| सी++ | प्राथमिकता_क्यू | |
| अजगर | ढेर | |
| जाओ | ढेर | एक ढेर इंटरफ़ेस है। |

परिशिष्ट बी: खोज योग्यता

ध्यान दें कि डेटा संरचनाओं पर चर्चा करते समय, _heap_ शब्द का उपयोग _priority queue_ की तुलना में 4 गुना अधिक बार किया जाता है।

• "array" AND "data structure" — 17.400,000 परिणाम
• "stack" AND "data structure" — 12.100.000 परिणाम
• "queue" AND "data structure" — 3.850.000 परिणाम
• "heap" AND "data structure" — 1.830.000 परिणाम
• "priority queue" AND "data structure" — 430.000 परिणाम
• "trie" AND "data structure" — 335.000 परिणाम

आपके सभी फ़ीडबैक के लिए धन्यवाद! मैंने प्रस्ताव को v2.1 में अपडेट कर दिया है। चेंजलॉग:

• Contains और TryGet विधियों को हटा दिया।
• एक एफएक्यू जोड़ा गया #2: _कोई Contains या TryGet विधि क्यों नहीं है?_
• इंटरफ़ेस जोड़ा गया IReadOnlyCollection<PriorityQueueNode<TElement, TPriority>> ।
• bool TryPeek(out TElement element, out TPriority priority) का एक अधिभार जोड़ा गया।
• bool TryPeek(out TElement element) का एक अधिभार जोड़ा गया।
• void Dequeue(out TElement element, out TPriority priority) का एक अधिभार जोड़ा गया।
• void Dequeue(out TElement element) से PriorityQueueNode<TElement, TPriority> Dequeue() बदला गया।
• bool TryDequeue(out TElement element) का एक अधिभार जोड़ा गया।
• bool TryDequeue(out PriorityQueueNode<TElement, TPriority> node) का एक अधिभार जोड़ा गया।
• एक एफएक्यू जोड़ा गया #3: _ Dequeue और TryDequeue ओवरलोड क्यों हैं जो PriorityQueueNode लौटाते हैं?_
• एक एफएक्यू जोड़ा गया #4: _क्या होता है जब Update या Remove विधि एक अलग कतार से एक नोड प्राप्त करती है?_

नोट बदलने के लिए धन्यवाद;)

स्पष्टीकरण के लिए छोटे अनुरोध:

• क्या हम अक्सर पूछे जाने वाले प्रश्न 4 को अर्हता प्राप्त कर सकते हैं जैसे कि यह उन तत्वों के लिए है जो कतार में नहीं हैं? (अर्थात हटाए गए)
• क्या हम स्थिरता के बारे में अक्सर पूछे जाने वाले प्रश्न जोड़ सकते हैं, यानी गारंटी (यदि कोई हो) जब समान प्राथमिकता वाले तत्वों को हटाते हैं (मेरी समझ यह है कि कोई गारंटी देने की कोई योजना नहीं है, जिसे जानना महत्वपूर्ण है उदाहरण के लिए शेड्यूलिंग)।

@pgolebiowski प्रस्तावित Merge विधि के बारे में:

public void Merge(PriorityQueue<TElement, TPriority> other); // O(1)

स्पष्ट रूप से इस तरह के एक ऑपरेशन में कॉपी सेमेन्टिक्स नहीं होगा, इसलिए मैं सोच रहा हूं कि क्या this और other _after_ में परिवर्तन करने के लिए कोई गॉचास होगा एक विलय किया गया है (उदाहरण के लिए या तो उदाहरण विफल ढेर संपत्ति को संतुष्ट करने के लिए)।

@eiriktsarpalis @VisualMelon - धन्यवाद! उठाए गए बिंदुओं को संबोधित करेंगे, ईटीए 2020-10-04।

यदि दूसरों के पास कोई और प्रतिक्रिया/प्रश्न/चिंता/विचार हैं - कृपया साझा करें

प्राथमिकता कतार प्रस्ताव (v2.2)

सारांश

.NET कोर समुदाय सिस्टम लाइब्रेरी _priority queue_ कार्यक्षमता में जोड़ने का प्रस्ताव करता है, एक डेटा संरचना जिसमें प्रत्येक तत्व की इसके साथ एक प्राथमिकता भी जुड़ी होती है। विशेष रूप से, हम PriorityQueue<TElement, TPriority> को System.Collections.Generic नेमस्पेस में जोड़ने का प्रस्ताव करते हैं।

सिद्धांतों

हमारे डिजाइन में, हमें निम्नलिखित सिद्धांतों द्वारा निर्देशित किया गया था (जब तक कि आप बेहतर नहीं जानते):

• विस्तृत कवरेज। हम .NET कोर ग्राहकों को एक मूल्यवान डेटा संरचना की पेशकश करना चाहते हैं जो विभिन्न प्रकार के उपयोग के मामलों का समर्थन करने के लिए पर्याप्त बहुमुखी है।
• ज्ञात गलतियों से सीखें। हम प्राथमिकता कतार कार्यक्षमता प्रदान करने का प्रयास करते हैं जो अन्य ढांचे और भाषाओं, जैसे जावा, पायथन, सी ++, जंग में मौजूद ग्राहक-सामना करने वाले मुद्दों से मुक्त होगी। हम ऐसे डिज़ाइन विकल्प बनाने से बचेंगे जो ग्राहकों को नाखुश करने और प्राथमिकता वाली कतारों की उपयोगिता को कम करने के लिए जाने जाते हैं।
• एकतरफा निर्णय के साथ अत्यधिक सावधानी। एक बार एपीआई पेश करने के बाद, इसे संशोधित या हटाया नहीं जा सकता, केवल बढ़ाया जा सकता है। हम उप-इष्टतम समाधानों से बचने के लिए डिज़ाइन विकल्पों का सावधानीपूर्वक विश्लेषण करेंगे, जिससे हमारे ग्राहक हमेशा के लिए फंस जाएंगे।
• डिजाइन पक्षाघात से बचें। हम स्वीकार करते हैं कि कोई भी सही समाधान नहीं हो सकता है। हम ट्रेड-ऑफ को संतुलित करेंगे और डिलीवरी के साथ आगे बढ़ेंगे, अंत में अपने ग्राहकों को वह कार्यक्षमता प्रदान करने के लिए जिसका वे वर्षों से इंतजार कर रहे थे।

पृष्ठभूमि

एक ग्राहक के नजरिए से

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

कंप्यूटर विज्ञान पृष्ठभूमि

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

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

अद्यतन तंत्र प्रमुख डिजाइन चुनौती है

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

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

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

विकल्प (ए): हैंडल। इस दृष्टिकोण में, हर बार कतार में एक तत्व जोड़ा जाता है, डेटा संरचना अपना अनूठा हैंडल प्रदान करती है। यदि ग्राहक अद्यतन तंत्र का उपयोग करना चाहता है, तो उन्हें ऐसे हैंडल का ट्रैक रखने की आवश्यकता है ताकि वे बाद में स्पष्ट रूप से निर्दिष्ट कर सकें कि वे किस तत्व को अपडेट करना चाहते हैं। इस समाधान की प्राथमिक लागत यह है कि ग्राहकों को इन संकेतकों को प्रबंधित करने की आवश्यकता है। हालांकि, इसका मतलब यह नहीं है कि प्राथमिकता कतार के भीतर हैंडल का समर्थन करने के लिए किसी भी आंतरिक आवंटन की आवश्यकता है - कोई भी गैर-सरणी-आधारित ढेर नोड्स पर आधारित होता है, जहां प्रत्येक नोड स्वचालित रूप से अपना स्वयं का हैंडल होता है। उदाहरण के तौर पर, PairingHeap.Update विधि का API देखें।

विकल्प (बी): विशिष्टता। यह दृष्टिकोण ग्राहक पर दो अतिरिक्त बाधाएं डालता है: i) प्राथमिकता कतार के तत्वों को कुछ समानता शब्दार्थ के अनुरूप होना चाहिए, जो संभावित उपयोगकर्ता बग का एक नया वर्ग लाता है; ii) दो समान तत्वों को एक ही कतार में संग्रहीत नहीं किया जा सकता है। इस लागत का भुगतान करके, हम हैंडल दृष्टिकोण का सहारा लिए बिना अद्यतन तंत्र का समर्थन करने का लाभ प्राप्त करते हैं। हालांकि, अद्यतन करने के लिए तत्व को निर्धारित करने के लिए विशिष्टता/समानता का लाभ उठाने वाले किसी भी कार्यान्वयन के लिए अतिरिक्त आंतरिक मैपिंग की आवश्यकता होगी, ताकि यह ओ (1) में किया जा सके और ओ (एन) में नहीं।

अनुशंसा

हम सिस्टम लाइब्रेरी में एक PriorityQueue<TElement, TPriority> वर्ग जोड़ने की अनुशंसा करते हैं जो हैंडल के माध्यम से अद्यतन तंत्र का समर्थन करता है। अंतर्निहित कार्यान्वयन एक जोड़ी ढेर होगा।

public class PriorityQueueNode<TElement, TPriority>
{
    public TElement Element { get; }
    public TPriority Priority { get; }
}

public class PriorityQueue<TElement, TPriority> :
    IEnumerable<PriorityQueueNode<TElement, TPriority>>,
    IReadOnlyCollection<PriorityQueueNode<TElement, TPriority>>
{
    public PriorityQueue();
    public PriorityQueue(IComparer<TPriority> comparer);

    public IComparer<TPriority> Comparer { get; }
    public int Count { get; }

    public bool IsEmpty { get; }
    public void Clear();

    public PriorityQueueNode<TElement, TPriority> Enqueue(TElement element, TPriority priority); //O(log n)

    public PriorityQueueNode<TElement, TPriority> Peek(); // O(1)
    public bool TryPeek(out PriorityQueueNode<TElement, TPriority> node); // O(1)
    public bool TryPeek(out TElement element, out TPriority priority); // O(1)
    public bool TryPeek(out TElement element); // O(1)

    public PriorityQueueNode<TElement, TPriority> Dequeue(); // O(log n)
    public void Dequeue(out TElement element, out TPriority priority); // O(log n)
    public bool TryDequeue(out PriorityQueueNode<TElement, TPriority> node); // O(log n)
    public bool TryDequeue(out TElement element, out TPriority priority); // O(log n)
    public bool TryDequeue(out TElement element); // O(log n)

    public void Update(PriorityQueueNode<TElement, TPriority> node, TPriority priority); // O(log n)
    public void Remove(PriorityQueueNode<TElement, TPriority> node); // O(log n)

    public IEnumerator<PriorityQueueNode<TElement, TPriority>> GetEnumerator();
    IEnumerator IEnumerable.GetEnumerator();

    public struct Enumerator : IEnumerator<PriorityQueueNode<TElement, TPriority>>
    {
        public PriorityQueueNode<TElement, TPriority> Current { get; }
        object IEnumerator.Current { get; }
        public bool MoveNext() => throw new NotImplementedException();
        public void Reset() => throw new NotImplementedException();
        public void Dispose() => throw new NotImplementedException();
    }
}

उदाहरण उपयोग

1) ग्राहक जो अद्यतन तंत्र की परवाह नहीं करता

var queue = new PriorityQueue<Job, double>();
queue.Enqueue(firstJob, 10);
queue.Enqueue(secondJob, 5);
queue.Enqueue(thirdJob, 40);

var withHighestPriority = queue.Peek(); // { element: secondJob, priority: 5 }

2) ग्राहक जो अद्यतन तंत्र की परवाह करता है

var queue = new PriorityQueue<Job, double>();
var mapping = new Dictionary<Job, PriorityQueueNode<Job, double>>();

mapping[job] = queue.Enqueue(job, priority);

queue.Update(mapping[job], newPriority);

सामान्य प्रश्न

1. प्राथमिकता कतार किस क्रम में तत्वों की गणना करती है?

अपरिभाषित क्रम में, ताकि गणना ओ (एन) में हो सके, इसी तरह HashSet । कोई भी कुशल कार्यान्वयन यह सुनिश्चित करते हुए रैखिक समय में एक ढेर की गणना करने की क्षमता प्रदान नहीं करेगा कि तत्वों की गणना क्रम में की गई है - इसके लिए O (n लॉग n) की आवश्यकता होगी। क्योंकि संग्रह पर ऑर्डर करना .OrderBy(x => x.Priority) साथ मामूली रूप से प्राप्त किया जा सकता है और प्रत्येक ग्राहक इस आदेश के साथ गणना की परवाह नहीं करता है, हम मानते हैं कि अपरिभाषित गणना आदेश प्रदान करना बेहतर है।

2. कोई Contains या TryGet पद्धति क्यों नहीं है?

ऐसी विधियों को प्रदान करना नगण्य मूल्य है, क्योंकि ढेर में एक तत्व खोजने के लिए पूरे संग्रह की गणना की आवश्यकता होती है, जिसका अर्थ है कि कोई भी Contains या TryGet विधि गणना के चारों ओर एक आवरण होगी। इसके अलावा, यह जाँचने के लिए कि क्या संग्रह में कोई तत्व मौजूद है, प्राथमिकता कतार को इस बात की जानकारी होनी चाहिए कि TElement वस्तुओं की समानता जाँच कैसे की जाती है, जो कि ऐसा कुछ नहीं है जिसे हम मानते हैं कि प्राथमिकता कतार की जिम्मेदारी में आना चाहिए।

3. Dequeue और TryDequeue ओवरलोड क्यों हैं जो PriorityQueueNode लौटाते हैं?

यह उन ग्राहकों के लिए है जो Update या Remove पद्धति का उपयोग करना चाहते हैं और हैंडल का ट्रैक रखना चाहते हैं। प्राथमिकता कतार से एक तत्व को हटाने के दौरान, उन्हें एक हैंडल प्राप्त होगा जिसका उपयोग वे अपने हैंडल ट्रैकिंग सिस्टम की स्थिति को समायोजित करने के लिए कर सकते हैं।

4. क्या होता है जब Update या Remove विधि एक अलग कतार से एक नोड प्राप्त करती है?

प्राथमिकता कतार एक अपवाद फेंक देगी। प्रत्येक नोड उस प्राथमिकता कतार के बारे में जानता है जिससे वह संबंधित है, उसी तरह जैसे LinkedListNode<T> को LinkedList<T> बारे में पता होता है। इसके अलावा, यदि एक नोड को कतार से हटा दिया गया है, तो उस पर Update या Remove का आह्वान करने का प्रयास भी एक अपवाद के साथ होगा।

5. कोई Merge पद्धति क्यों नहीं है?

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

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

6. क्या संग्रह स्थिरता की गारंटी देता है?

संग्रह बॉक्स से बाहर एक स्थिरता गारंटी प्रदान नहीं करेगा, अर्थात यदि दो तत्व समान प्राथमिकता के साथ कतारबद्ध हैं, तो ग्राहक यह मानने में सक्षम नहीं होगा कि उन्हें एक निश्चित क्रम में हटा दिया जाएगा। हालांकि, यदि कोई ग्राहक हमारे PriorityQueue का उपयोग करके स्थिरता प्राप्त करना चाहता है, तो वे TPriority और संबंधित IComparer<TPriority> को परिभाषित कर सकते हैं जो इसे सुनिश्चित करेगा। इसके अलावा, डेटा संग्रह नियतात्मक होगा, अर्थात संचालन के दिए गए अनुक्रम के लिए, यह हमेशा उसी तरह व्यवहार करेगा, जिससे पुनरुत्पादन की अनुमति मिलती है।

परिशिष्ट

परिशिष्ट ए: प्राथमिकता कतार कार्यक्षमता वाली अन्य भाषाएं

| भाषा | प्रकार | नोट्स |
|:-:|:-:|:-:|
| जावा | प्राथमिकता कतार | अमूर्त वर्ग AbstractQueue और इंटरफ़ेस Queue लागू करता है। |
| जंग | बाइनरीहीप | |
| स्विफ्ट | सीएफबीनरीहीप | |
| सी++ | प्राथमिकता_क्यू | |
| अजगर | ढेर | |
| जाओ | ढेर | एक ढेर इंटरफ़ेस है। |

परिशिष्ट बी: खोज योग्यता

ध्यान दें कि डेटा संरचनाओं पर चर्चा करते समय, _heap_ शब्द का उपयोग _priority queue_ की तुलना में 4 गुना अधिक बार किया जाता है।

• "array" AND "data structure" — 17.400,000 परिणाम
• "stack" AND "data structure" — 12.100.000 परिणाम
• "queue" AND "data structure" — 3.850.000 परिणाम
• "heap" AND "data structure" — 1.830.000 परिणाम
• "priority queue" AND "data structure" — 430.000 परिणाम
• "trie" AND "data structure" — 335.000 परिणाम

चेंजलॉग:

• void Merge(PriorityQueue<TElement, TPriority> other) // O(1) विधि को हटा दिया।
• एक सामान्य प्रश्न जोड़ा गया #5: कोई Merge पद्धति क्यों नहीं है?
• संशोधित एफएक्यू #4 उन नोड्स के लिए भी है जिन्हें प्राथमिकता कतार से हटा दिया गया है।
• एक सामान्य प्रश्न जोड़ा गया #6: क्या संग्रह स्थिरता की गारंटी प्रदान करता है?

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

ऐसा करने से मुझे जो एक छोटी सी सीख मिली वह यह थी कि विधि नाम/अधिभार का वर्तमान सेट out चर के निहित टाइपिंग के लिए इतनी अच्छी तरह से काम नहीं करता है। क्या मैं सी # कोड के साथ करना चाहता था TryDequeue(out var node) - लेकिन दुर्भाग्य से मैं का स्पष्ट प्रकार देने की जरूरत out के रूप में चर PriorityQueueNode<> अन्यथा संकलक नहीं पता था कि अगर मैं एक प्राथमिकता कतार नोड या एक तत्व चाहता था।

    var shortestDistances = new Dictionary<int, int>();
    var queue = new PriorityQueue<int, int>();
    var handles = new Dictionary<int, PriorityQueueNode<int, int>>();
    handles[startNode] = queue.Enqueue(startNode, 0);
    while (queue.TryDequeue(out PriorityQueueNode<int, int> nextQueueNode))
    {
        int nodeToExploreFrom = nextQueueNode.Element, minDistance = nextQueueNode.Priority;
        shortestDistances.Add(nodeToExploreFrom, minDistance);
        handles[nodeToExploreFrom] = null; // so it is clearly already visited
        foreach (int nextNode in nodes)
        {
            int candidatePathDistance = minDistance + edgeDistances[nodeToExploreFrom, nextNode];
            if (handles.TryGetValue(nextNode, out var nextNodeHandle))
            {
                if (nextNodeHandle != null && candidatePathDistance < nextNodeHandle.Priority)
                {
                    queue.Update(nextNodeHandle, candidatePathDistance);
                }
                // or else... we already got there
            }
            else
            {
                handles[nextNode] = queue.Enqueue(nextNode, candidatePathDistance);
            }
        }
    }

मेरे विचार में मुख्य अनसुलझा डिज़ाइन प्रश्न यह है कि कार्यान्वयन को प्राथमिकता अद्यतनों का समर्थन करना चाहिए या नहीं। मैं यहां तीन संभावित पथ देख सकता हूं:

1. मूल तत्व को पारित करके विशिष्टता/समानता और समर्थन अपडेट की आवश्यकता है।
2. हैंडल का उपयोग करके प्राथमिकता अपडेट का समर्थन करें।
3. प्राथमिकता अपडेट का समर्थन न करें।

ये दृष्टिकोण परस्पर अनन्य हैं और क्रमशः ट्रेड-ऑफ के अपने सेट हैं:

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

सामान्य प्राथमिकता कतार अनुप्रयोगों की पहचान करना

यह महत्वपूर्ण है कि हम यह पहचानें कि उपरोक्त में से कौन सा दृष्टिकोण हमारे अधिकांश उपयोगकर्ताओं के लिए सर्वोत्तम मूल्य प्रदान कर सकता है। इसलिए मैं सबसे आम उपयोग पैटर्न क्या हैं, यह बेहतर ढंग से समझने के लिए हीप/प्राथमिकता क्यू कार्यान्वयन के उदाहरणों के लिए, माइक्रोसॉफ्ट आंतरिक और सार्वजनिक दोनों, .NET कोडबेस के माध्यम से जा रहा हूं:

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

उसी समय, पायथन, जावा, सी ++, गो, स्विफ्ट, या रस्ट कोर पुस्तकालयों में से कोई भी हीप/प्राथमिकता क्यू कार्यान्वयन उनके एपीआई में प्राथमिकता अपडेट का समर्थन नहीं करता है।

सिफारिशों

इस डेटा के प्रकाश में, मेरे लिए यह स्पष्ट है कि .ΝΕΤ को एक आधारभूत प्रायोरिटी क्यू कार्यान्वयन की आवश्यकता है जो आवश्यक एपीआई (हेपिफाई/पुश/पीक/पॉप) को उजागर करता है, कुछ प्रदर्शन गारंटी प्रदान करता है (उदाहरण के लिए प्रति एनक्यू में कोई अतिरिक्त आवंटन नहीं) और लागू नहीं करता है विशिष्टता की कमी। इसका तात्पर्य है कि कार्यान्वयन _O(log n) प्राथमिकता अद्यतन_ का समर्थन नहीं करेगा।

हमें एक अलग ढेर कार्यान्वयन के साथ अनुसरण करने पर भी विचार करना चाहिए जो _O(log n)_ अपडेट/निष्कासन का समर्थन करता है, और समानता-आधारित दृष्टिकोण का उपयोग करता है। चूंकि यह एक विशेष प्रकार का होगा, इसलिए विशिष्टता की आवश्यकता अधिक समस्या नहीं होनी चाहिए।

मैं दोनों कार्यान्वयनों के प्रोटोटाइप पर काम कर रहा हूं, और शीघ्र ही एक एपीआई प्रस्ताव का पालन करूंगा।

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

हैंडल आधारित दृष्टिकोण प्रति संलग्न तत्व में कम से कम एक अतिरिक्त आवंटन का संकेत देगा।

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

80 प्रायोरिटी क्यू कार्यान्वयनों की जाँच की गई, उनमें से केवल 9 को प्राथमिकता अद्यतनों के किसी न किसी रूप को लागू करते पाया गया।

यहां तक ​​​​कि इस छोटे से नमूने को देखते हुए, यह सभी उपयोगों का 11-12% है। साथ ही, इसे कुछ डोमेन जैसे वीडियो गेम में कम प्रस्तुत किया जा सकता है, जहां मैं इस प्रतिशत के अधिक होने की अपेक्षा करता हूं।

इन आंकड़ों के आलोक में, मेरे लिए यह स्पष्ट है कि […]

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

मूल रूप से:

| | 11-12% उपयोग के मामले | 88-89% मामलों का उपयोग करें |
|:-:|:-:|:-:|
| अपडेट की परवाह करता है | हाँ | नहीं |
| हैंडल से नकारात्मक रूप से प्रभावित होता है | एन/ए (वे वांछित हैं) | नहीं |
| हैंडल से सकारात्मक रूप से प्रभावित है | हाँ | नहीं |

मेरे लिए, यह केवल 88-89% ही नहीं, 100% उपयोग के मामलों का समर्थन करने के पक्ष में है।

यह धारणा गलत है, आपको नोड-आधारित ढेर में अतिरिक्त आवंटन की आवश्यकता नहीं है

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

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

मैं कह रहा हूं कि हम किसी भी एनक्यू ऑपरेशन से बचना चाहते हैं, जिसके लिए आवंटन की आवश्यकता होती है, चाहे वह कॉलर की ओर से हो या कार्यान्वयन के हिस्से में (अमूर्त आंतरिक आवंटन ठीक है, उदाहरण के लिए कार्यान्वयन में उपयोग की जाने वाली सरणी का विस्तार करना)। मैं यह समझने की कोशिश कर रहा हूं कि नोड-आधारित ढेर के साथ यह कैसे संभव है (उदाहरण के लिए यदि उन नोड ऑब्जेक्ट्स को कॉलर के संपर्क में लाया जाता है, जो अनुचित पुन: उपयोग/एलियासिंग के आसपास की चिंताओं के कारण कार्यान्वयन द्वारा पूलिंग को प्रतिबंधित करता है)। मैं लिखने में सक्षम होना चाहता हूँ:
C# pq.Enqueue(42, 84);
और क्या वह आवंटित नहीं किया गया है। आप इसे प्राप्त करने के लिए कार्यान्वयन का उल्लेख कैसे करते हैं?

या बस वही कहो जो तुम कहना चाह रहे हो

मैंने सोचा मैं था।

हम आवंटन की आवश्यकता वाले किसी भी एनक्यू ऑपरेशन से बचना चाहते हैं [...] मैं लिखने में सक्षम होना चाहता हूं: pq.Enqueue(42, 84); और इसे आवंटित नहीं किया है।

यह इच्छा कहाँ से आती है? समाधान का साइड इफेक्ट होना अच्छा है, न कि ऐसी आवश्यकता जिसे 99.9% ग्राहकों को संतुष्ट करने की आवश्यकता है। मैं यह नहीं देखता कि आप समाधानों के बीच डिज़ाइन विकल्प बनाने के लिए इस कम प्रभाव वाले आयाम को क्यों चुनेंगे।

हम 0.1% ग्राहकों के लिए अनुकूलन के आधार पर डिज़ाइन विकल्प नहीं बना रहे हैं यदि ये किसी अन्य आयाम में 12% ग्राहकों को नकारात्मक रूप से प्रभावित करते हैं। "बिना आवंटन की परवाह करना" + "दो मूल्य प्रकारों से निपटना" एक बढ़त का मामला है।

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

यह इच्छा कहाँ से आती है?

प्रदर्शन के बारे में परवाह करने वाले परिदृश्यों में मुख्य संग्रह प्रकारों को प्रयोग करने योग्य बनाना चाहते हैं। आप कहते हैं कि नोड-आधारित समाधान 100% उपयोग के मामलों का समर्थन करेगा: ऐसा नहीं है यदि प्रत्येक एनक्यू आवंटित करता है, जैसे List<T> , Dictionary<TKey, TValue> , HashSet<T> , और इसी तरह चालू कई स्थितियों में अनुपयोगी हो जाएगा यदि वे प्रत्येक ऐड पर आवंटित किए जाते हैं।

आप क्यों मानते हैं कि यह केवल "0.1%" है जो इन विधियों के आवंटन ओवरहेड्स की परवाह करता है? वह डेटा कहां से आ रहा है?

"बिना आवंटन की परवाह करना" + "दो मूल्य प्रकारों से निपटना" एक बढ़त का मामला है

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

@eiriktsarpalis
इसलिए आप किसी भी विकल्प को न भूलें, मुझे लगता है कि आपकी सूची में विकल्प 1, 2, और 3 में जोड़ने के लिए एक व्यवहार्य विकल्प 4 है जो एक समझौता है:

1. एक कार्यान्वयन जो 12% उपयोग के मामले का समर्थन करता है, जबकि अन्य 88% के लिए लगभग-अनुकूलन करने योग्य तत्वों को अद्यतन करने की अनुमति देता है, और केवल _lazily_ उन अद्यतनों को करने के लिए आवश्यक लुकअप तालिका का निर्माण करता है जिसे पहली बार अद्यतन विधि कहा जाता है ( और बाद के अपडेट + निष्कासन पर इसे अपडेट करना)। इसलिए उन ऐप्स के लिए कम लागत खर्च करना जो कार्यक्षमता का उपयोग नहीं करते हैं।

हम अभी भी यह तय कर सकते हैं कि क्योंकि कार्यान्वयन से 88% या 12% के लिए अतिरिक्त प्रदर्शन उपलब्ध है, जिसके लिए अद्यतन करने योग्य डेटा संरचना की आवश्यकता नहीं है, या पहली जगह में एक के लिए अनुकूलित है, विकल्प 2 और 3 प्रदान करना बेहतर है। विकल्प 4. लेकिन मैंने सोचा कि हमें यह नहीं भूलना चाहिए कि एक और विकल्प मौजूद है।

[या मुझे लगता है कि आप इसे केवल एक बेहतर विकल्प 1 के रूप में देख सकते हैं और यह कहने के लिए 1 के विवरण को अपडेट कर सकते हैं कि बहीखाता पद्धति मजबूर नहीं है, लेकिन आलसी, और सही समान व्यवहार केवल तभी आवश्यक है जब अपडेट का उपयोग किया जाता है ...]

@stephentoub ठीक यही कहने के बारे में मेरे मन में था कि आप क्या कहना चाहते हैं, धन्यवाद :)

आप क्यों मानते हैं कि यह केवल 0.1% है जो इन विधियों के आवंटन ओवरहेड्स की परवाह करता है? वह डेटा कहां से आ रहा है?

अंतर्ज्ञान से, यानी वही स्रोत जिसके आधार पर आप मानते हैं कि "अपडेट करने की क्षमता" पर "कोई अतिरिक्त आवंटन नहीं" को प्राथमिकता देना अधिक महत्वपूर्ण है। कम से कम अद्यतन तंत्र के लिए, हमारे पास डेटा है कि 11-12% ग्राहकों को इस व्यवहार का समर्थन करने की आवश्यकता है। मुझे नहीं लगता कि दूर से करीबी ग्राहक "कोई अतिरिक्त आवंटन नहीं" की परवाह करेंगे।

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

आइए एक कदम पीछे हटें और इस बात पर ध्यान दें कि ग्राहक क्या चाहते हैं। हमारे पास एक डिज़ाइन विकल्प है जो 12% ग्राहकों के लिए डेटा संरचना को अनुपयोगी बना सकता है या नहीं भी कर सकता है। मुझे लगता है कि हमें इनका समर्थन न करने के लिए कारण बताने में बहुत सावधानी बरतने की आवश्यकता होगी।

"कोई अतिरिक्त आवंटन नहीं" प्रदान करने वाला एक सरणी-आधारित कार्यान्वयन नोड-आधारित कार्यान्वयन से धीमा होगा।

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

कृपया उन दो सी # कार्यान्वयनों को साझा करें जिनका उपयोग आप उस तुलना को करने के लिए कर रहे हैं और बेंचमार्क उस निष्कर्ष पर आने के लिए उपयोग किए जाते हैं

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

@pgolebiowski मुझे आपकी आपत्ति की प्रकृति को बेहतर ढंग से समझने में दिलचस्पी होगी। प्रस्ताव दो अलग-अलग प्रकारों की वकालत करता है, क्या यह आपकी आवश्यकताओं को पूरा नहीं करेगा?

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

मैं शायद इसे विकल्प 1 के प्रदर्शन अनुकूलन के रूप में वर्गीकृत करूंगा, हालांकि मुझे उस विशेष दृष्टिकोण के साथ कुछ समस्याएं दिखाई देती हैं:

• अपडेट अब _O(n)_ हो जाता है, जिसके परिणामस्वरूप उपयोग पैटर्न के आधार पर अप्रत्याशित प्रदर्शन हो सकता है।
• अद्वितीयता की पुष्टि के लिए लुकअप टेबल की भी आवश्यकता होती है। एक ही तत्व को दो बार _before_ कॉल करने के अपडेट को स्वीकार किया जाएगा और यकीनन कतार को असंगत स्थिति में लाया जाएगा।

@eiriktsarpalis इसका केवल ओ (एन) एक बार, और ओ (1) बाद में, जो ओ (1) परिशोधित है। और आप पहले अपडेट तक वैलिडेटिंग यूनिकनेस को स्थगित कर सकते हैं। लेकिन शायद यह अति चतुर है। दो वर्गों की व्याख्या करना आसान है।

मैंने पिछले कुछ दिनों में दो प्रायोरिटीक्यू कार्यान्वयनों को प्रोटोटाइप किया है: अद्यतन समर्थन के बिना एक बुनियादी कार्यान्वयन और एक कार्यान्वयन जो तत्व समानता का उपयोग करके अद्यतनों का समर्थन करता है। मैंने पूर्व का नाम PriorityQueue और बाद वाले को, बेहतर नाम की कमी के लिए, PrioritySet । मेरा लक्ष्य एपीआई एर्गोनॉमिक्स को मापना और प्रदर्शन की तुलना करना है।

कार्यान्वयन इस रेपो में पाया जा सकता है। दोनों वर्गों को सरणी-आधारित क्वाड हीप्स का उपयोग करके कार्यान्वित किया जाता है। अद्यतन करने योग्य कार्यान्वयन एक शब्दकोश का भी उपयोग करता है जो तत्वों को आंतरिक ढेर सूचकांकों में मैप करता है।

मूल प्राथमिकता कतार

namespace System.Collections.Generic
{
    public class PriorityQueue<TElement, TPriority> : IReadOnlyCollection<(TElement Element, TPriority Priority)>
    {
        // Constructors
        public PriorityQueue();
        public PriorityQueue(int initialCapacity);
        public PriorityQueue(IComparer<TPriority>? comparer);
        public PriorityQueue(int initialCapacity, IComparer<TPriority>? comparer);
        public PriorityQueue(IEnumerable<(TElement Element, TPriority Priority)> values);
        public PriorityQueue(IEnumerable<(TElement Element, TPriority Priority)> values, IComparer<TPriority>? comparer);

        // Properties
        public int Count { get; }
        public IComparer<TPriority> Comparer { get; }

        // O(log(n)) push operation
        public void Enqueue(TElement element, TPriority priority);
        // O(1) peek operations
        public TElement Peek();
        public bool TryPeek(out TElement element, out TPriority priority);
        // O(log(n)) pop operations
        public TElement Dequeue();
        public bool TryDequeue(out TElement element, out TPriority priority);
        // Combined push/pop, generally more efficient than sequential Enqueue();Dequeue() calls.
        public TElement EnqueueDequeue(TElement element, TPriority priority);

        public void Clear();

        public Enumerator GetEnumerator();
        public struct Enumerator : IEnumerator<(TElement Element, TPriority Priority)>, IEnumerator;
    }
}

यहाँ प्रकार का उपयोग करते हुए एक मूल नमूना है

var queue = new PriorityQueue<string, int>();

queue.Enqueue("John", 1940);
queue.Enqueue("Paul", 1942);
queue.Enqueue("George", 1943);
queue.Enqueue("Ringo", 1940);

Assert.Equal("John", queue.Dequeue());
Assert.Equal("Ringo", queue.Dequeue());
Assert.Equal("Paul", queue.Dequeue());
Assert.Equal("George", queue.Dequeue());

अद्यतन करने योग्य प्राथमिकता कतार

namespace System.Collections.Generic
{
    public class PrioritySet<TElement, TPriority> : IReadOnlyCollection<(TElement Element, TPriority Priority)> where TElement : notnull
    {
        // Constructors
        public PrioritySet();
        public PrioritySet(int initialCapacity);
        public PrioritySet(IComparer<TPriority> comparer);
        public PrioritySet(int initialCapacity, IComparer<TPriority>? priorityComparer, IEqualityComparer<TElement>? elementComparer);
        public PrioritySet(IEnumerable<(TElement Element, TPriority Priority)> values);
        public PrioritySet(IEnumerable<(TElement Element, TPriority Priority)> values, IComparer<TPriority>? comparer, IEqualityComparer<TElement>? elementComparer);

        // Members shared with baseline PriorityQueue implementation
        public int Count { get; }
        public IComparer<TPriority> Comparer { get; }
        public void Enqueue(TElement element, TPriority priority);
        public TElement Peek();
        public bool TryPeek(out TElement element, out TPriority priority);
        public TElement Dequeue();
        public bool TryDequeue(out TElement element, out TPriority priority);
        public TElement EnqueueDequeue(TElement element, TPriority priority);

        // Update methods and friends
        public bool Contains(TElement element); // O(1)
        public bool TryRemove(TElement element); // O(log(n))
        public bool TryUpdate(TElement element, TPriority priority); // O(log(n))
        public void EnqueueOrUpdate(TElement element, TPriority priority); // O(log(n))

        public void Clear();
        public Enumerator GetEnumerator();
        public struct Enumerator : IEnumerator<(TElement Element, TPriority Priority)>, IEnumerator;
    }
}

प्रदर्शन तुलना

मैंने एक साधारण हीपसॉर्ट बेंचमार्क लिखा है जो दो कार्यान्वयनों की तुलना उनके सबसे बुनियादी अनुप्रयोग में करता है। मैंने एक प्रकार का बेंचमार्क भी शामिल किया है जो तुलना के लिए लिंक का उपयोग करता है:

BenchmarkDotNet=v0.12.1, OS=ubuntu 20.04
AMD EPYC 7452, 1 CPU, 4 logical and 2 physical cores
.NET Core SDK=5.0.100-rc.2.20479.15
  [Host]     : .NET Core 5.0.0 (CoreCLR 5.0.20.47505, CoreFX 5.0.20.47505), X64 RyuJIT
  DefaultJob : .NET Core 5.0.0 (CoreCLR 5.0.20.47505, CoreFX 5.0.20.47505), X64 RyuJIT

| विधि | आकार | मतलब | त्रुटि | एसटीडीदेव | अनुपात | अनुपात एसडी | जनरल 0 | जनरल 1 | जनरल 2 | आवंटित |
|-------------- |------ |---------------:|----------: |----------:|------:|----------:|--------:|-------- :|----------:|----------:|
| लिंकसॉर्ट | 30 | 1.439 यूएस | 0.0072 यूएस | 0.0064 यूएस | 1.00 | 0.00 | 0.0095 | - | - | 672 बी |
| प्राथमिकता कतार | 30 | 1.450 यूएस | 0.0085 यूएस | 0.0079 हमें | 1.01 | 0.01 | - | - | - | - |
| प्रायोरिटीसेट | 30 | 2.778 यूएस | 0.0217 हमें | 0.0192 यूएस | 1.93 | 0.02 | - | - | - | - |
| | | | | | | | | | | |
| लिंकसॉर्ट | 300 | 24.727 यूएस | 0.1032 यूएस | 0.0915 हमें | 1.00 | 0.00 | 0.0305 | - | - | 3912 बी |
| प्राथमिकता कतार | 300 | 29.510 हमें | 0.0995 हमें | 0.0882 हमें | 1.19 | 0.01 | - | - | - | - |
| प्रायोरिटीसेट | 300 | 47.715 हमें | 0.4455 हमें | 0.4168 हमें | 1.93 | 0.02 | - | - | - | - |
| | | | | | | | | | | |
| लिंकसॉर्ट | 3000 | 412.015 हमें | 1.5495 यूएस | 1.3736 यूएस | 1.00 | 0.00 | 0.4883 | - | - | 36312 बी |
| प्राथमिकता कतार | 3000 | 491.722 हमें | 4.1463 हमें | 3.8785 यूएस | 1.19 | 0.01 | - | - | - | - |
| प्रायोरिटीसेट | 3000 | 677.959 यूएस | 3.1996 हमें | 2.4981 यूएस | 1.64 | 0.01 | - | - | - | - |
| | | | | | | | | | | |
| लिंकसॉर्ट | 30000 | 5,223.560 यूएस | 11.9077 यूएस | 9.9434 यूएस | 1.00 | 0.00 | 93.7500 | 93.7500 | 93.7500 | 360910 बी |
| प्राथमिकता कतार | 30000 | 5,688.625 हमें | 53.0746 यूएस | 49.6460 यूएस | 1.09 | 0.01 | - | - | - | 2 बी |
| प्रायोरिटीसेट | 30000 | 8,124.306 यूएस | 39.9498 यूएस | 37.3691 यूएस | 1.55 | 0.01 | - | - | - | 4 बी |

जैसा कि उम्मीद की जा सकती है, ट्रैकिंग तत्व स्थानों का ओवरहेड एक महत्वपूर्ण प्रदर्शन हिट जोड़ता है, बेसलाइन कार्यान्वयन की तुलना में लगभग 40-50% धीमा।

मैं सभी प्रयासों की सराहना करता हूं, मैं देखता हूं कि इसमें बहुत समय और ऊर्जा लगी है।

1. मैं वास्तव में 2 लगभग समान डेटा संरचनाओं का कारण नहीं देखता, जहां एक दूसरे का निम्न संस्करण है।
2. इसके अलावा, यदि आप प्राथमिकता कतार के ऐसे 2 संस्करण चाहते हैं, तो भी मैं यह नहीं देखता कि 20 दिन पहले के प्राथमिकता कतार प्रस्ताव (v2.2) से "बेहतर" संस्करण कैसे बेहतर है।

टीएल; डॉ:

• यह प्रस्ताव रोमांचक है !! लेकिन यह अभी तक मेरे उच्च-पूर्ण उपयोग-मामलों में फिट नहीं है।
• > मेरे कंप्यूटेशनल ज्योमेट्री/मोशन प्लानिंग परफॉर्मेंस लोड का 90% PQ एनक्यू/डेक्यू है क्योंकि यह एल्गोरिथम में प्रमुख N^m LogN है।
• मैं अलग पीक्यू कार्यान्वयन के पक्ष में हूं। मुझे आमतौर पर प्राथमिकता अपडेट की आवश्यकता नहीं होती है, और 2x बदतर perf अस्वीकार्य है।
• प्रायोरिटीसेट एक भ्रमित करने वाला नाम है और प्रायोरिटी क्यू बनाम खोजने योग्य नहीं है
• दो बार प्राथमिकता संग्रहित करना (एक बार मेरे तत्व में, एक बार कतार में) महंगा लगता है। स्ट्रक्चर कॉपी और मेमोरी उपयोग।
• यदि कंप्यूटिंग प्राथमिकता महंगी होती, तो मैं बस एक टपल (priority: ComputePriority(element), element) को एक PQ में संग्रहीत करता, और मेरा प्राथमिकता-प्राप्तकर्ता फ़ंक्शन केवल tuple => tuple.priority ।
• प्रदर्शन को प्रति-ऑपरेशन या वैकल्पिक रूप से वास्तविक दुनिया के उपयोग-मामलों पर बेंचमार्क किया जाना चाहिए (उदाहरण के लिए ग्राफ़ पर अनुकूलित मल्टी-स्टार्ट मल्टी-एंड सर्च)
• अनियंत्रित गणना व्यवहार अप्रत्याशित है। कतार-जैसी Dequeue () - ऑर्डर सेमेन्टिक्स को प्राथमिकता दें?
• क्लोन ऑपरेशन और मर्ज ऑपरेशन का समर्थन करने पर विचार करें।
• स्थिर-अवस्था के उपयोग में मूल संचालन 0-आवंटन होना चाहिए। मैं इन कतारों को पूल करूंगा।
• EnqueueMany का समर्थन करने पर विचार करें जो पूलिंग में सहायता के लिए हीपिफाई करता है।

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

दो-कार्यान्वयन (हाँ बनाम नहीं अद्यतन समर्थन) बहस के बारे में कुछ प्रतिक्रिया।

नामकरण:

• प्रायोरिटीसेट का अर्थ है सेट सेमेन्टिक्स, लेकिन क्यू आईसेट को लागू नहीं करता है।
• आप UpdatablePriorityQueue नाम का उपयोग कर रहे हैं जिसे खोजना आसान है यदि मैं प्रायोरिटी क्यू खोजता हूँ।

प्रदर्शन:

• मेरी ज्यामिति/योजना एल्गोरिदम में प्राथमिकता कतार का प्रदर्शन लगभग हमेशा मेरा प्रदर्शन अड़चन (>90%) होता है
• Func . पास करने पर विचार करेंया तुलनाTP प्राथमिकता को कॉपी करने के बजाय (महंगा!) यदि कंप्यूटिंग प्राथमिकता महंगी है, तो मैं एक पीक्यू में (प्राथमिकता, तत्व) डालूंगा और एक तुलना पास करूंगा जो मेरी कैश्ड प्राथमिकता को देखता है।
• मेरे एल्गोरिदम की एक बड़ी संख्या को PQ अपडेट की आवश्यकता नहीं है। मैं एक अंतर्निहित पीक्यू का उपयोग करने पर विचार करता हूं जो अपडेट का समर्थन नहीं करता है, लेकिन अगर किसी ऐसी सुविधा का समर्थन करने के लिए 2x perf लागत है जिसकी मुझे आवश्यकता नहीं है (अपडेट करना) तो यह मेरे लिए बेकार है।
• प्रदर्शन विश्लेषण/ ट्रेडऑफ के लिए, प्रति ऑपरेशन डेक्यू की सापेक्ष दीवार-समय लागत जानना महत्वपूर्ण होगा
• आपके कंस्ट्रक्टर्स को Heapify करते हुए देखकर मुझे खुशी हुई। एक निर्माता पर विचार करें जो गणना आवंटन से बचने के लिए एक IList, सूची या सरणी लेता है।
• एक EnqueueMany को उजागर करने पर विचार करें जो PQ शुरू में खाली होने पर Heapify करता है, क्योंकि हाई-परफ में यह पूल संग्रह के लिए आम है।
• यदि तत्वों में संदर्भ नहीं हैं, तो स्पष्ट शून्य नहीं सरणी बनाने पर विचार करें।
• एनक्यू/डेक्यू में आवंटन अस्वीकार्य हैं। पूल किए गए थ्रेड-स्थानीय संग्रह के साथ, मेरे एल्गोरिदम प्रदर्शन कारणों से शून्य-आवंटित हैं।

एपीआई:

• प्राथमिकता कतार को क्लोन करना आपके कार्यान्वयन के साथ एक छोटा ऑपरेशन है और अक्सर उपयोगी होता है।
  
  
  
  • संबंधित: क्या प्राथमिकता कतार की गणना में कतार की तरह शब्दार्थ होना चाहिए? मैं कतार के समान एक डेक्यू-ऑर्डर संग्रह की अपेक्षा करता हूं। मैं उम्मीद करता हूं कि नई सूची (myPriorityQueue) प्राथमिकता क्यू को न बदलें, लेकिन जैसा कि मैंने अभी वर्णन किया है, काम करने के लिए।
  
  
• जैसा कि ऊपर उल्लेख किया गया है, प्राथमिकता के साथ डालने के बजाय Func<TElement, TPriority> लेना बेहतर है। यदि कंप्यूटिंग प्राथमिकता महंगी है, तो मैं बस (priority, element) सम्मिलित कर सकता हूं और एक func tuple => tuple.priority प्रदान कर सकता हूं
• दो प्राथमिकता कतारों को मिलाना कभी-कभी उपयोगी होता है।
• यह अजीब बात है कि पीक एक टीआइटम लौटाता है लेकिन एन्यूमरेशन एंड एनक्यू में (टीआइटम, टीप्रियोरिटी) है।

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

अंत में, यह ध्यान देने योग्य है कि मैं अक्सर सरणी तत्वों के बजाय एक सरणी के सूचकांकों को प्राथमिकता कतार में सम्मिलित करता (x, isStartElseEnd, intervalId) और x द्वारा ऑर्डर कर सकते हैं, फिर isStartElseEnd द्वारा। ऐसा अक्सर इसलिए होता है क्योंकि मेरे पास अन्य डेटा संरचनाएं होती हैं जो किसी इंडेक्स से कुछ गणना किए गए डेटा पर मैप करती हैं।

@pgolebiowski मैंने आपके प्रस्तावित युग्मन ढेर कार्यान्वयन को बेंचमार्क में शामिल करने की स्वतंत्रता ली, बस इसलिए हम सीधे तीनों दृष्टिकोणों के उदाहरणों की तुलना कर सकते हैं। यहाँ परिणाम हैं:

| विधि | आकार | मतलब | त्रुटि | एसटीडीदेव | माध्यिका | जनरल 0 | जनरल 1 | जनरल 2 | आवंटित |
|-------------- |---------- |---------------------:|---- -------------:|-----------------:|---------------- ---:|----------:|------:|------:|-----------:|
| प्राथमिकता कतार | 10 | 774.7 एनएस | 3.30 एनएस | 3.08 एनएस | 773.2 एनएस | - | - | - | - |
| प्रायोरिटीसेट | 10 | 1,643.0 एनएस | 3.89 एनएस | 3.45 एनएस | 1,642.8 एनएस | - | - | - | - |
| पेयरिंगहीप | 10 | 1,660.2 एनएस | 14.11 एनएस | 12.51 एनएस | 1,657.2 एनएस | 0.0134 | - | - | 960 बी |
| प्राथमिकता कतार | 50 | 6,413.0 एनएस | 14.95 एनएस | 13.99 एनएस | 6,409.5 एनएस | - | - | - | - |
| प्रायोरिटीसेट | 50 | 12,193.1 एनएस | 35.41 एनएस | 29.57 एनएस | 12,188.3 एनएस | - | - | - | - |
| पेयरिंगहीप | 50 | 13,955.8 एनएस | 193.36 एनएस | 180.87 एनएस | 13,989.2 एनएस | 0.0610 | - | - | 4800 बी |
| प्राथमिकता कतार | 150 | 27,402.5 एनएस | 76.52 एनएस | 71.58 एनएस | 27,410.2 एनएस | - | - | - | - |
| प्रायोरिटीसेट | 150 | 48,485.8 एनएस | 160.22 एनएस | 149.87 एनएस | 48,476.3 एनएस | - | - | - | - |
| पेयरिंगहीप | 150 | 56,951.2 एनएस | 190.52 एनएस | 168.89 एनएस | 56,953.6 एनएस | 0.1831 | - | - | 14400 बी |
| प्राथमिकता कतार | 500 | 124,933.7 एनएस | 429.20 एनएस | 380.48 एनएस | 124,824.4 एनएस | - | - | - | - |
| प्रायोरिटीसेट | 500 | 206,310.0 एनएस | 433.97 एनएस | 338.81 एनएस | 206,319.0 एनएस | - | - | - | - |
| पेयरिंगहीप | 500 | 229,423.9 एनएस | 3,213.33 एनएस | 2,848.53 एनएस | 230,398.7 एनएस | 0.4883 | - | - | 48000 बी |
| प्राथमिकता कतार | 1000 | 284,481.8 एनएस | 475.91 एनएस | 445.16 एनएस | 284,445.6 एनएस | - | - | - | - |
| प्रायोरिटीसेट | 1000 | 454,989.4 एनएस | 3,712.11 एनएस | 3,472.31 एनएस | 455,354.0 एनएस | - | - | - | - |
| पेयरिंगहीप | 1000 | 459,049.3 एनएस | 1,706.28 एनएस | 1,424.82 एनएस | 459,364.9 एनएस | 0.9766 | - | - | 96000 बी |
| प्राथमिकता कतार | 10000 | 3,788,802.4 एनएस | 11,715.81 एनएस | 10,958.98 एनएस | 3,787,811.9 एनएस | - | - | - | 1 बी |
| प्रायोरिटीसेट | 10000 | 5,963,100.4 एनएस | 26,669.04 एनएस | 22,269.86 एनएस | 5,950,915.5 एनएस | - | - | - | 2 बी |
| पेयरिंगहीप | 10000 | 6,789,719.0 एनएस | 134,453.01 एनएस | 265,397.13 एनएस | 6,918,392.9 एनएस | 7.8125 | - | - | 960002 बी |
| प्राथमिकता कतार | 1000000 | 595,059,170.7 एनएस | 4,001,349.38 एनएस | 3,547,092.00 एनएस | 595,716,610.5 एनएस | - | - | - | 4376 बी |
| प्रायोरिटीसेट | 1000000 | 1,592,037,780.9 एनएस | 13,925,896.05 एनएस | 12,344,944.12 एनएस | 1,591,051,886.5 एनएस | - | - | - | 288 बी |
| पेयरिंगहीप | 1000000 | 1,858,670,560.7 एनएस | 36,405,433.20 एनएस | 59,815,170.76 एनएस | 1,838,721,629.0 एनएस | 1000000 | - | - | 96000376 बी |

चाबी छीन लेना

• ~ पेयरिंग हीप कार्यान्वयन अपने सरणी-समर्थित समकक्षों की तुलना में असम्बद्ध रूप से बहुत बेहतर प्रदर्शन करता है। हालांकि यह छोटे ढेर आकारों (<50 तत्वों) के लिए 2x तक धीमा हो सकता है, लगभग 1000 तत्वों को पकड़ सकता है, लेकिन आकार 10^6~ के ढेर के लिए 2x तक तेज है।
• जैसा कि अपेक्षित था, युग्मन ढेर ढेर आवंटन की एक बड़ी मात्रा का उत्पादन करता है।
• "प्राथमिकतासेट" कार्यान्वयन लगातार धीमा है ~ तीनों दावेदारों में सबसे धीमा ~, इसलिए हम उस दृष्टिकोण को आगे बढ़ाना नहीं चाहते हैं।

~उपरोक्त के आलोक में मुझे अभी भी विश्वास है कि बेसलाइन सरणी ढेर और युग्मन ढेर दृष्टिकोण के बीच वैध व्यापार-बंद हैं ~।

संपादित करें: मेरे बेंचमार्क में बगफिक्स के बाद परिणाम अपडेट किया गया, धन्यवाद @VisualMelon

@eiriktsarpalis PairingHeap लिए आपका बेंचमार्क, मुझे लगता है, गलत है: Add के पैरामीटर गलत तरीके से हैं। जब आप उनकी अदला-बदली करते हैं, तो यह एक अलग कहानी होती है: https://gist.github.com/VisualMelon/00885fe50f7ab0f4ae5cd1307312109f

(जब मैंने इसे पहली बार लागू किया था तो मैंने वही किया था)

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

@eiriktsarpalis फिर से: प्रायोरिटीसेट की उपयोगिता ...
हमें उम्मीद नहीं करनी चाहिए कि अपडेट करने योग्य हीपसॉर्ट के लिए धीमे होने के अलावा कुछ भी हो, क्योंकि इसमें परिदृश्य में कोई प्राथमिकता अपडेट नहीं है। (हेपसॉर्ट के लिए भी, इसकी संभावना है कि आप डुप्लीकेट भी रखना चाहते हैं, एक सेट उपयुक्त नहीं है।)

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

धन्यवाद @VisualMelon , मैंने आपके सुझाए गए फ़िक्स के बाद अपने परिणाम और टिप्पणियों को अपडेट किया।

बल्कि यह आपूर्ति किए गए डेटा के वितरण/आदेश पर बहुत अधिक निर्भर करता है।

मेरा मानना ​​है कि यह इस तथ्य से लाभान्वित हो सकता है कि कतारबद्ध प्राथमिकताएं एकरस थीं।

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

@TimLovellSmith यहां मेरा लक्ष्य सबसे आम प्रायोरिटी

@miyu आपकी विस्तृत प्रतिक्रिया के लिए धन्यवाद, इसकी बहुत सराहना की जाती है!

@TimLovellSmith मैंने एक साधारण बेंचमार्क लिखा है जो अपडेट का उपयोग करता है:

| विधि | आकार | मतलब | त्रुटि | एसटीडीदेव | माध्यिका | जनरल 0 | जनरल 1 | जनरल 2 | आवंटित |
|--------------- |----------- |---------------:|---------- -----:|---------------:|---------------:|-------:| ------:|------:|-----------:|
| प्रायोरिटीसेट | 10 | 1.052 यूएस | 0.0106 यूएस | 0.0099 हमें | 1.055 यूएस | - | - | - | - |
| पेयरिंगहीप | 10 | 1.055 यूएस | 0.0042 यूएस | 0.0035 यूएस | 1.055 यूएस | 0.0057 | - | - | 480 बी |
| प्रायोरिटीसेट | 50 | 7.394 यूएस | 0.0527 यूएस | 0.0493 हमें | 7.380 यूएस | - | - | - | - |
| पेयरिंगहीप | 50 | 8.587 हमें | 0.1678 यूएस | 0.1570 यूएस | 8.634 यूएस | 0.0305 | - | - | 2400 बी |
| प्रायोरिटीसेट | 150 | 27.522 यूएस | 0.0459 यूएस | 0.0359 यूएस | 27.523 हमें | - | - | - | - |
| पेयरिंगहीप | 150 | 32.045 यूएस | 0.1076 हमें | 0.1007 यूएस | 32.019 यूएस | 0.0610 | - | - | 7200 बी |
| प्रायोरिटीसेट | 500 | 109.097 यूएस | 0.6548 यूएस | 0.6125 यूएस | 109.162 हमें | - | - | - | - |
| पेयरिंगहीप | 500 | 131.647 हमें | 0.5401 यूएस | 0.4510 हमें | 131.588 हमें | 0.2441 | - | - | 24000 बी |
| प्रायोरिटीसेट | 1000 | 238.184 यूएस | 1.0282 हमें | 0.9618 यूएस | 238.457 यूएस | - | - | - | - |
| पेयरिंगहीप | 1000 | 293.236 यूएस | 0.9396 हमें | 0.8889 हमें | 293.257 हमें | 0.4883 | - | - | 48000 बी |
| प्रायोरिटीसेट | 10000 | 3,035.982 हमें | 12.2952 यूएस | 10.8994 यूएस | 3,036.985 यूएस | - | - | - | 1 बी |
| पेयरिंगहीप | 10000 | 3,388.685 हमें | 16.0675 यूएस | 38.1861 यूएस | 3,374.565 हमें | - | - | - | 480002 बी |
| प्रायोरिटीसेट | 1000000 | 841,406.888 हमें | 16,788.4775 यूएस | 15,703.9522 हमें | 840,888.389 यूएस | - | - | - | 288 बी |
| पेयरिंगहीप | 1000000 | 989,966.501 यूएस | 19,722.687 हमें | 30,705.8191 यूएस | 996,075.410 यूएस | - | - | - | 48000448 बी |

एक अलग नोट पर, क्या स्थिरता की कमी पर लोगों के उपयोग के मामलों के लिए एक मुद्दा (या गैर-मुद्दा) होने पर उनकी चर्चा/प्रतिक्रिया रही है?

लोगों के उपयोग के मामले में स्थिरता की कमी (या गैर-मुद्दा) होने पर उनकी चर्चा/प्रतिक्रिया रही है

कोई भी कार्यान्वयन स्थिरता की गारंटी नहीं देता है, हालांकि उपयोगकर्ताओं के लिए सम्मिलन आदेश के साथ क्रमिक वृद्धि करके स्थिरता प्राप्त करना बहुत सरल होना चाहिए:

var pq = new PriorityQueue<string, (int priority, int insertionCount)>();
int insertionCount = 0;

foreach (string element in elements)
{
    int priority = 42;
    pq.Enqueue(element, (priority, insertionCount++));
}

मेरी पिछली कुछ पोस्टों को संक्षेप में प्रस्तुत करने के लिए, मैं यह पहचानने की कोशिश कर रहा हूं कि एक लोकप्रिय .NET प्राथमिकता कतार कैसी दिखेगी, इसलिए मैंने निम्नलिखित डेटा का अध्ययन किया:

• .NET स्रोत कोड में सामान्य प्राथमिकता कतार उपयोग पैटर्न।
• प्रतिस्पर्धी ढांचे के मुख्य पुस्तकालयों में प्राथमिकता कतार कार्यान्वयन।
• विभिन्न .NET प्राथमिकता कतार प्रोटोटाइप के बेंचमार्क।

जिससे निम्नलिखित टेकअवे मिले:

• प्राथमिकता कतार उपयोग के 90% मामलों में प्राथमिकता अद्यतन की आवश्यकता नहीं होती है।
• प्राथमिकता अपडेट का समर्थन करने से अधिक जटिल एपीआई अनुबंध होता है (या तो हैंडल या तत्व विशिष्टता की आवश्यकता होती है)।
• मेरे बेंचमार्क में, प्राथमिकता अपडेट का समर्थन करने वाले कार्यान्वयन उन लोगों की तुलना में 2-3x धीमे होते हैं जो नहीं करते हैं।

अगला कदम

आगे बढ़ते हुए, मेरा प्रस्ताव है कि हम .NET 6 के लिए निम्नलिखित कार्रवाई करें:

1. एक System.Collections.Generic.PriorityQueue वर्ग का परिचय दें जो सरल हो, हमारी अधिकांश उपयोगकर्ता आवश्यकताओं को पूरा करता हो और जितना संभव हो उतना कुशल हो। यह एक सरणी-समर्थित चतुर्धातुक ढेर का उपयोग करेगा और प्राथमिकता अद्यतनों का समर्थन नहीं करेगा। कार्यान्वयन का एक प्रोटोटाइप यहां पाया जा सकता

2. हम कुशल प्राथमिकता अद्यतनों का समर्थन करने वाले ढेर की आवश्यकता को पहचानते हैं, इसलिए इस आवश्यकता को पूरा करने वाले एक विशेष वर्ग को शुरू करने की दिशा में काम करना जारी रखेंगे। हम कुछ प्रोटोटाइप [ 1 , 2 ] का मूल्यांकन कर रहे हैं, जिनमें से प्रत्येक के अपने-अपने ट्रेड-ऑफ़ सेट हैं। मेरी सिफारिश इस प्रकार को बाद के चरण में पेश करने की होगी, क्योंकि डिजाइन को अंतिम रूप देने के लिए और अधिक काम करने की आवश्यकता है।

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

आगे बढ़ते हुए, मेरा प्रस्ताव है कि हम .NET 6 के लिए निम्नलिखित कार्रवाई करें: [...]

बढ़िया है :)

एक System.Collections.Generic.PriorityQueue वर्ग का परिचय दें जो सरल हो, हमारी अधिकांश उपयोगकर्ता आवश्यकताओं को पूरा करता हो और जितना संभव हो उतना कुशल हो। यह एक सरणी-समर्थित चतुर्धातुक ढेर का उपयोग करेगा और प्राथमिकता अद्यतनों का समर्थन नहीं करेगा।

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

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

यह काफी यात्रा थी :D

System.Collections.Generic.PriorityQueue<TElement, TPriority> लिए API को अभी-अभी स्वीकृत किया गया है। मैंने एक संभावित ढेर कार्यान्वयन पर अपनी बातचीत जारी रखने के लिए एक अलग मुद्दा बनाया है जो प्राथमिकता अपडेट का समर्थन करता है।

मैं इस मुद्दे को बंद करने जा रहा हूँ, आपके योगदान के लिए आप सभी का धन्यवाद!

हो सकता है कि कोई इस यात्रा पर कुछ लिख सके! एक एपीआई के लिए पूरे 6 साल। :) गिनीज जीतने का कोई मौका?