| 운영 | 복잡성 |
| --- | --- |
| IEnumerable을 사용하여 구성하기 | Θ(로그 n) |

나는 이것이 Θ(n)이어야 한다고 생각한다. 최소한 입력을 반복해야 합니다.

+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 ...
    }

나는 초기 구현의 사본을 여기에 던졌다. 테스트 범위는 아직 완전하지 않지만 궁금한 사람이 있으면 살펴보고 어떻게 생각하는지 알려주세요. System.Collections 클래스의 기존 코딩 규칙을 최대한 따르려고 했습니다.

멋있는. 일부 초기 피드백:

• 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> 등)은 null을 허용합니다. 비교자를 위해 전달되며 이 경우 Comparer<T>.Default 가 사용됩니다.

또한...

• ToArray 는 새 배열을 할당하기 전에 _size == 0 를 확인하여 최적화할 수 있습니다. 이 경우 Array.Empty<T>() 반환하면 됩니다.

@justinvp 좋은 피드백, 감사합니다!

• 열거자를 구현했습니다..Reset은 열거자의 더 이상 사용되지 않는 핵심 기능이므로 명시적으로 재설정합니다. 노출 여부는 컬렉션 유형 간에 일관성이 없는 것으로 보이며 소수만이 명시적 변형을 사용합니다.
• _index를 위해 _disposed 필드를 제거했습니다. 감사합니다! 그날 밤 마지막 순간에 그것을 던졌고 명백한 것을 놓쳤습니다. 이전 System.Collections.Generic 형식에서 사용하지 않는 경우에도 최신 컬렉션 형식의 정확성을 위해 ObjectDisposedException을 유지하기로 결정했습니다.
• Array.Empty는 F# 기능이므로 슬프게도 여기에서 사용할 수 없습니다!
• null을 허용하도록 비교기 매개변수를 수정했습니다. 잘 찾았습니다!
• ToArray 최적화는 까다롭습니다. _기술적으로_ 말해서 배열은 길이가 0인 경우에도 C#에서 변경할 수 있습니다. 실제로는 할당이 필요하지 않으며 최적화할 수 있습니다. 생각하지 못한 부작용이 있는 경우를 대비하여 좀 더 신중하게 구현하려고 합니다. 의미상 호출자는 여전히 해당 할당을 기대하며 이는 사소한 할당입니다.

@에비클

Array.Empty는 F# 기능이므로 슬프게도 여기에서 사용할 수 없습니다!

더 이상: https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/Array.cs#L1060 -L1069

issue-574 브랜치의 eickle/corefx 로 코드를 마이그레이션했습니다.

Array.Empty 구현() 변경하고 모든 것을 일반 빌드 파이프라인에 연결했습니다. 내가 도입해야 하는 약간의 일시적인 문제는 System.Collections 프로젝트가 Comparer로 System.Collections nuget 패키지에 종속되도록 하는 것이었습니다.아직 오픈 소스가 아닙니다.

dotnet/corefx#966 문제가 완료되면 수정됩니다.

피드백을 찾고 있는 한 가지 핵심 영역은 ToArray, CopyTo 및 열거자를 처리하는 방법입니다. 현재 성능에 최적화되어 있습니다. 즉, 대상 배열이 힙이고 비교자에 의해 정렬되지 않습니다.

세 가지 옵션이 있습니다.
1) 그대로 두고 반환된 배열이 정렬되지 않았음을 문서화합니다. (정렬된 대기열이 아니라 우선순위 대기열입니다)
2) 반환된 항목/배열을 정렬하는 메서드를 수정합니다. 더 이상 O(n) 작업이 아닙니다.
3) 메소드와 열거 가능한 지원을 모두 제거하십시오. 이것은 "순수한" 옵션이지만 우선 순위 대기열이 더 이상 필요하지 않을 때 나머지 대기열 항목을 빠르게 잡는 기능을 제거합니다.

피드백을 받고 싶은 또 다른 사항은 우선 순위가 동일한 두 항목에 대해 대기열이 안정적이어야 하는지 여부입니다(결과 비교 0). 일반적으로 우선 순위 대기열은 동일한 우선 순위를 가진 두 항목이 대기열에 추가된 순서대로 대기열에서 제거된다는 보장은 없지만 System.Reactive.Core에서 사용되는 내부 우선 순위 대기열 구현은 이 속성을 보장하기 위해 약간의 추가 오버헤드가 필요하다는 것을 알았습니다. 내 취향은 이것을하지 않는 것이지만 개발자의 기대치 측면에서 어떤 옵션이 더 나은지 완전히 확신하지 못합니다.

나도 .NET에 우선 순위 대기열을 추가하는 데 관심이 있었기 때문에 이 PR을 보게 되었습니다. 누군가가 이 제안을 하기 위해 노력한 것을 보게 되어 기쁩니다. :). 코드를 검토한 후 다음 사항을 확인했습니다.

• IComparer 순서가 Equals 와 일치하지 않으면 이 Contains 구현의 동작( IComparer )은 다음과 같이 일부 사용자에게 놀랄 수 있습니다. 본질적으로 _우선순위가 같은 항목을 포함합니다_.
• Dequeue 에서 배열을 축소하는 코드를 보지 못했습니다. 1/4이 가득 찼을 때 힙 배열을 절반으로 줄이는 것이 일반적입니다.
• Enqueue 메서드가 null 인수를 수락해야 합니까?
• Clear 의 복잡성은 System.Array.Clear 의 복잡성이기 때문에 Θ(n) 이어야 한다고 생각합니다. https://msdn.microsoft.com/en-us/library/system.array.clear%28v=vs.110%29.aspx

Dequeue 에서 배열을 축소하는 코드를 보지 못했습니다. 1/4이 가득 찼을 때 힙 배열을 절반으로 줄이는 것이 일반적입니다.

Queue<T> 및 Stack<T> 도 배열을 축소하지 않습니다( 참조 소스 기반, 아직 CoreFX에 없음).

@mbeidler 대기열에서 자동 배열 축소의 일부 형태를 추가하는 것을 고려했지만 @svick이 지적했듯이 유사한 데이터 구조의 참조 구현에는 존재하지 않습니다. .NET Core/BCL 팀에서 이러한 스타일의 구현을 선택한 특별한 이유가 있는지 궁금합니다.

업데이트: 목록을 확인했습니다., 대기 줄, Queue 및 ArrayList - 제거/대기열에서 내부 배열의 크기를 축소하지 않습니다.

Enqueue는 null을 지원해야 하며 허용하는 것으로 문서화되어 있습니다. 버그가 발생했습니까? 나는 아직 그 지역에서 단위 테스트 영역이 얼마나 견고한지 기억나지 않는다.

흥미롭게도 @svick 이 링크한 참조 소스에서 Queue<T> _ShrinkThreshold 라는 이름의 사용되지 않은 개인 상수가 있음을 알았습니다. 아마도 그 동작은 이전 버전에 존재했을 것입니다.

Contains 구현에서 Equals IComparer 대신 https://gist.github. com/mbeidler/9e9f566ba7356302c57e

@mbeidler 좋은 지적입니다. MSDN에 따르면 IComparer/ I비교 가능값이 0인 경우에만 정렬 순서가 동일함을 보장합니다.

그러나 다른 컬렉션 클래스에도 동일한 문제가 있는 것 같습니다. SortedList에서 작동하도록 코드를 수정하면, 테스트 케이스는 여전히 ContainsKey에서 실패합니다. SortedList의 구현.ContainsKey는 Array.BinarySearch를 호출합니다. 이 호출은 IComparer에 의존하여 같음을 확인합니다. SortedSet도 마찬가지입니다..

틀림없이 기존 컬렉션 클래스의 버그이기도 합니다. 나머지 컬렉션 클래스를 살펴보고 IComparer를 허용하지만 동등성을 별도로 테스트하는 다른 데이터 구조가 있는지 확인합니다. 당신 말이 맞아요. 우선 순위 대기열의 경우 평등과 완전히 독립적인 사용자 지정 순서 지정 동작을 기대할 수 있습니다.

내 포크 분기에 수정 사항과 테스트 케이스를 커밋했습니다. Contains의 새로운 구현은 List의 동작을 직접 기반으로 합니다..포함. 목록 이후IEqualityComparer를 허용하지 않는 경우 동작은 기능적으로 동일합니다.

오늘 나중에 시간이 되면 다른 내장 컬렉션에 대한 버그 보고서를 제출할 것입니다. 회귀 동작으로 인해 수정할 수는 없지만 최소한 문서를 업데이트해야 합니다.

ContainsKey 가 IComparer<TKey> 구현을 사용하는 것이 합리적이라고 생각합니다. 이것이 키를 지정하는 것이기 때문입니다. 그러나 ContainsValue 가 선형 검색에서 IComparable<TValue> 대신 Equals 를 사용하는 것이 더 논리적이라고 생각합니다. 이 경우 유형의 자연스러운 순서가 equals와 일치하지 않을 가능성이 훨씬 적기 때문에 범위가 크게 줄어듭니다.

에 대한 MSDN 설명서에이 나타납니다 SortedList<TKey, TValue> 에 대한 설명 부분 ContainsValue TValue의 정렬 순서가 평등 대신에 사용되는 것을 나타냅니다 않습니다.

@terrajobst 지금까지의 API 제안에 대해 어떻게 생각하십니까? 이것이 CoreFX에 적합하다고 생각하십니까?

:+1:

신고해 주셔서 감사합니다. 이 제안을 공식적으로 검토하기에 충분한 데이터가 있다고 생각하므로 'API 검토 준비 완료'로 레이블을 지정했습니다.

Dequeue 및 Peek 메서드가 발생하므로 호출자는 각 호출 전에 카운트를 확인해야 합니다. 대신(또는 추가로) 동시 수집 패턴에 따라 TryDequeue 및 TryPeek 제공하는 것이 합리적입니까? 기존의 제네릭 컬렉션에 non-throwing 메서드를 추가할 수 있는 문제가 있으므로 이러한 메서드가 없는 새 컬렉션을 추가하는 것은 비생산적으로 보입니다.

@andrewgmorris 관련 https://github.com/dotnet/corefx/issues/4316 "대기열에 TryDequeue 추가"

우리는 이에 대한 기본적인 검토를 받았고 프레임워크에 ProrityQueue가 필요하다는 데 동의합니다. 그러나 우리는 이를 위한 설계 및 구현을 추진하는 데 도움을 줄 누군가를 구해야 합니다. 문제를 파악 하는 사람은

그렇다면 API에는 어떤 작업이 남아 있습니까?

이것은 위의 API 제안에서 누락되었습니다. PriorityQueue<T> 는 IReadOnlyCollection<T> 와 일치하도록 Queue<T> IReadOnlyCollection<T> 를 구현해야 합니다( Queue<T> 이제 .NET에서 IReadOnlyCollection<T> 를 구현합니다. 4.6).

배열 기반 우선 순위 대기열이 가장 좋은지 모르겠습니다. .NET의 메모리 할당은 정말 빠릅니다. 우리는 이전 malloc이 처리했던 것과 동일한 검색-작은 블록 문제가 없습니다. 여기에서 내 우선 순위 대기열 코드를 사용할 수 있습니다. 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 메서드에 대한 문서를 수정했습니다. 감사합니다!

얼마 전에 저는 이 시점에서 공유하기로 결정한 Skip List 데이터 구조를 기반으로 하는 우선 순위 대기열과 유사한 복잡성을 가진 데이터 구조를 만들었습니다. https://gist.github.com/bbarry/5e0f3cc1ac7f7521fe6ea25947f48ace

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

건너뛰기 목록은 포함이 평균 사례 O(log(n)) 라는 점을 제외하고는 평균 사례에서 위의 우선 순위 대기열의 복잡성과 일치합니다. 또한 첫 번째 또는 마지막 요소에 대한 액세스는 상수 시간 작업이며 순방향 및 역방향 모두의 반복은 PQ의 순방향 복잡도와 일치합니다.

이러한 구조에는 메모리 비용이 더 많이 드는 형태의 단점이 분명히 있으며 O(n) 최악의 경우 삽입 및 제거로 넘어가므로 장단점이 있습니다...

이것은 이미 어딘가에 구현되어 있습니까? 출시 예정일은 언제인가요?
또한 기존 항목의 우선 순위를 업데이트하는 것은 어떻습니까?

@Priya91 @ianhays 이 리뷰를 위해 준비된 것으로 표시될 준비가 되었습니까?

이것은 위의 API 제안에서 누락되었습니다: PriorityQueueIReadOnlyCollection을 구현해야 합니다.대기열과 일치시키기 위해(대기 줄이제 IReadOnlyCollection을 구현합니다..NET 4.6).

나는 여기서 @justinvp에 동의합니다.

@Priya91 @ianhays 이 리뷰를 위해 준비된 것으로 표시될 준비가 되었습니까?

나는 그렇게 말할 것입니다. 이것은 잠시 동안 앉아 있었습니다. 이동해 봅시다.

@justinvp @ianhays IReadOnlyCollection 을 구현하도록 사양을 업데이트했습니다.. 감사합니다!

클래스의 전체 구현이 있으며 배열 기반 구현을 사용하는 연결된 PriorityQueueDebugView입니다. 단위 테스트가 아직 100% 적용되지는 않았지만 관심이 있다면 약간의 작업을 수행하고 포크에서 먼지를 털어낼 수 있습니다.

@NKnusperer 는 기존 항목의 우선 순위 업데이트에 대해 좋은 지적을 했습니다. 지금은 생략하지만 사양 검토 중에 고려해야 할 사항입니다.

전체 프레임워크에는 가능한 대안이 2가지 구현되어 있습니다.
https://referencesource.microsoft.com/#q =우선순위 큐

참고로 여기에 stackoverflow http://stackoverflow.com/questions/683041/java-how-do-i-use-a-priorityqueue 의 Java PriorityQueue에 대한 질문이

API 검토:
CoreFX에서 이 유형을 사용할 것으로 예상하기 때문에 CoreFX에서 이 유형을 사용하는 것이 유용하다는 데 동의합니다.

API 형태의 최종 검토를 위해 샘플 코드 PriorityQueue<Thread> 및 PriorityQueue<MyClass> 를 보고 싶습니다.

1. 우선 순위를 어떻게 유지합니까? 지금은 T 로만 암시됩니다.
2. 항목을 추가할 때 우선 순위를 전달할 수 있기를 원하십니까? (꽤 편리한 것 같습니다)

노트:

• 우선 순위가 자체적으로 변경되지 않을 것으로 예상합니다. 이를 위한 API가 필요하거나 대기열에 Remove 및 Add 필요합니다.
• 여기에 명확한 고객 코드가 없다는 점을 감안할 때(유형을 원하는 일반적인 바람) 성능, 사용성, 다른 무엇을 위해 최적화할지 결정하기 어렵습니다.

이것은 CoreFX에 있으면 정말 유용한 유형입니다. 누구든지 이것을 잡는 데 관심이 있습니까?

나는 우선순위 큐를 바이너리 힙에 고정시키는 아이디어가 마음에 들지 않는다. 자세한 내용은 AlgoKit 위키 페이지 를 참조하십시오. 빠른 생각:

• 구현을 특정 유형의 힙으로 수정하는 경우 4-ary 힙으로 만듭니다.
• 일부 시나리오에서 일부 유형의 힙이 다른 유형보다 성능이 우수하므로 힙 구현을 수정해서는 안 됩니다. 따라서 구현을 특정 힙 유형으로 수정하고 고객이 더 나은 성능을 위해 다른 유형을 필요로 하는 경우 고객은 처음부터 전체 우선 순위 대기열을 구현해야 합니다. 그건 틀렸어요. 우리는 여기서 더 유연해야 하고 그가 CoreFX 코드의 일부(적어도 일부 인터페이스)를 재사용할 수 있도록 해야 합니다.

작년에 몇 가지 힙 유형을 구현했습니다. 특히, 우선순위 큐로 사용할 수 있는 IHeap 인터페이스가 있습니다.

• 왜 그냥 힙이라고 하지...? 힙을 사용하는 것 외에 우선순위 큐를 구현하는 올바른 방법을 알고 있습니까?

저는 IHeap 인터페이스와 가장 성능이 좋은 구현(적어도 해당 어레이 기반)을 소개하는 데 찬성합니다. API 및 구현은 위에서 링크한 저장소에 있습니다.

따라서 _우선순위 대기열_이 없습니다. 힙 .

어떻게 생각하나요?

@karelz @safern @danmosemsft

@pgolebiowski 사용하기 쉬우면서도 성능이 좋은 API를 설계하고 있음을 잊지 마십시오. PriorityQueue (컴퓨터 과학 용어로 정립된)를 원하면 문서에서 / 인터넷 검색을 통해 찾을 수 있어야 합니다.
기본 구현이 힙(개인적으로 왜 그런지 궁금함)이거나 다른 것이라면 그다지 중요하지 않습니다. 구현이 더 간단한 대안보다 측정 가능하게 더 낫다는 것을 입증할 수 있다고 가정하면(코드의 복잡성도 어느 정도 중요한 메트릭입니다).

따라서 여전히 힙 기반 구현( IHeap API 제외)이 일부 간단한 목록 기반 또는 배열 목록 청크 기반 구현보다 낫다고 생각한다면 이유를 설명하십시오(몇 문장/단락 이상적으로는 ), 구현 접근 방식에 대한 동의를 얻을 수 있습니다(PR 검토 시 거절될 수 있는 복잡한 구현에 시간 낭비를 방지).

드롭 ICollection , IEnumerable ? 일반 버전만 있으면 됩니다(일반 IEnumerable<T> 는 IEnumerable ).

@pgolebiowski 구현이 외부 API를 변경하지 않는 방법. PriorityQueue 는 행동/계약을 정의합니다. 반면 Heap 는 특정 구현입니다.

우선 순위 대기열 대 힙

기본 구현이 힙(개인적으로 왜 그런지 궁금함)이거나 다른 것이라면 그다지 중요하지 않습니다. 구현이 더 간단한 대안보다 측정 가능하게 더 낫다는 것을 입증할 수 있다고 가정하면(코드의 복잡성도 어느 정도 중요한 메트릭입니다).

따라서 여전히 힙 기반 구현이 단순한 목록 기반 또는 배열 목록 청크 기반 구현보다 낫다고 생각한다면 이유를 설명하여(이상적으로는 몇 문장/단락으로) 구현 방식 [...]

좋아요. 우선 순위 대기열은 어떤 방식으로든 구현할 수 있는 추상 데이터 구조입니다. 물론 힙과 다른 데이터 구조로 구현할 수도 있습니다. 그러나 이보다 더 효율적인 방법은 없습니다. 결과적으로:

• 우선 순위 큐와 힙은 종종 동의어로 사용됩니다 (이에 대한 가장 명확한 예는 아래 Python 문서 참조).
• 일부 라이브러리에서 "우선순위 큐" 지원이 있을 때마다 힙을 사용합니다 (아래의 모든 예 참조).

내 말을 뒷받침하기 위해 이론적 지원부터 시작하겠습니다. 알고리즘 소개 , Cormen:

[...] 우선 순위 대기열은 최대 우선 순위 대기열과 최소 우선 순위 대기열의 두 가지 형태로 제공됩니다. 여기서는 max-heap을 기반으로 하는 max-priority 큐를 구현하는 방법에 초점을 맞출 것입니다.

우선 순위 대기열이 힙임을 분명히 명시했습니다. 이것은 물론 지름길이지만 아이디어를 얻습니다. 이제 더 중요한 것은 다른 언어와 표준 라이브러리가 논의 중인 작업에 대한 지원을 추가하는 방법을 살펴보겠습니다.

• Java: PriorityQueue<T> — 힙으로 구현된 우선 순위 대기열.
• Rust: BinaryHeap — API에서 명시적으로 힙입니다. 문서 에서 바이너리 힙으로 구현된 우선 순위 대기열 이라고 말합니다
• Swift: CFBinaryHeap — 다시 말하지만 "우선순위 큐"라는 추상적 용어의 사용을 피하면서 데이터 구조가 무엇인지 명시적으로 말합니다. 클래스를 설명하는 문서: 이진 힙은 우선 순위 큐로 유용할 수 있습니다. 접근 방식이 마음에 듭니다.
• C++: priority_queue — 다시 한 번, 배열의 맨 위에 빌드된 바이너리 힙으로 정식 구현되었습니다.
• Python: heapq — 힙이 API에 명시적으로 노출됩니다. 우선순위 대기열은 문서에서만 언급됩니다. 이 모듈은 우선순위 대기열 알고리즘이라고도 하는 힙 대기열 알고리즘의 구현을 제공합니다.
• Go: heap package — 힙 인터페이스도 있습니다. 명시적인 우선 순위 대기열은 없지만 다시 문서에서만 가능합니다. 힙은 우선 순위 대기열을 구현하는 일반적인 방법입니다.

나는 우리가 Rust/Swift/Python/Go 방식으로 가서 명시적으로 힙을 노출 해야 한다고 강력하게 믿으며 문서에서 우선 순위 큐로 사용할 수 있다고 명확하게 명시합니다. 저는 이 접근 방식이 매우 깨끗하고 간단하다고 강력하게 믿습니다.

• 우리는 데이터 구조에 대해 명확하고 API가 미래에 향상되도록 합니다. 누군가가 어떤 측면에서 더 나은 우선 순위 대기열을 구현하는 새롭고 혁신적인 방법을 생각해낸다면(그리고 선택 힙 대 새로운 유형은 다음에 따라 달라집니다. 시나리오), API는 여전히 손상되지 않을 수 있습니다. 라이브러리를 향상시키는 새로운 혁신적인 유형을 추가하기만 하면 힙 클래스가 여전히 존재합니다.
• 사용자가 우리가 선택한 데이터 구조가 안정적인지 궁금해한다고 상상해 보세요. 우리가 따르는 솔루션이 우선순위 큐인 경우 이는 명확하지 않습니다. 이 용어는 추상적이며 모든 것이 아래에 있을 수 있습니다. 따라서 사용자가 문서를 검색하고 내부적으로 힙을 사용하고 있으므로 안정적이지 않다는 것을 확인하는 데 약간의 시간이 손실됩니다. 이것은 API를 통해 이것이 힙임을 명시적으로 명시함으로써 피할 수 있었습니다.

힙 데이터 구조를 명확하게 노출하고 문서에서만 우선 순위 큐 참조를 만드는 접근 방식을 좋아하기를 바랍니다.

API 및 구현

우리는 위의 문제에 동의해야 하지만 다른 주제를 시작하겠습니다. 이것을 구현하는 방법 . 여기에서 두 가지 솔루션을 볼 수 있습니다.

• ArrayHeap 클래스만 제공합니다. 이름을 보면 어떤 종류의 힙을 다루고 있는지 즉시 알 수 있습니다(다시 말하지만 수십 가지 힙 유형이 있음). 배열 기반임을 알 수 있습니다. 당신은 당신이 상대하고 있는 짐승을 즉시 알 수 있습니다.
• 내가 훨씬 더 좋아하는 또 다른 가능성은 IHeap 인터페이스를 제공하고 하나 이상의 구현을 제공하는 것입니다. 고객은 인터페이스에 의존하는 코드를 작성할 수 있습니다. 이를 통해 복잡한 알고리즘의 정말 명확하고 읽기 쉬운 구현을 제공할 수 있습니다. DijkstraAlgorithm 클래스를 작성한다고 상상해보십시오. IHeap 인터페이스(매개변수화된 생성자 하나)에 의존하거나 ArrayHeap (기본 생성자)를 사용할 수 있습니다. "우선순위 대기열" 용어 사용으로 인해 명확하고 단순하며 명시적이며 모호함이 없습니다. 그리고 이론적으로 매우 의미가 있는 멋진 인터페이스.

위의 접근 방식에서 ArrayHeap 는 배열로 저장된 암시적 힙 순서의 완전한 d-ary 트리를 나타냅니다. 예를 들어 BinaryHeap 또는 QuaternaryHeap 를 만드는 데 사용할 수 있습니다.

결론

추가 토론을 위해 이 문서를 살펴보길 강력히 권장합니다. 당신은 그것을 알게 될 것입니다:

• 4-ary 힙(quaternary)은 2-ary 힙(binary)보다 단순히 빠릅니다. 이 백서에는 많은 테스트가 수행되었습니다. implicit_4 및 implicit_2 (때로는 implicit_simple_4 및 implicit_simple_2 )의 성능을 비교하는 데 관심이 있을 것입니다.

• 최적의 구현 선택은 입력에 따라 크게 달라집니다. 암시적 d-ary 힙, 페어링 힙, 피보나치 힙, 이항 힙, 명시적 d-ary 힙, 순위 쌍 힙, 지진 힙, 위반 힙, 순위 완화된 약한 힙 및 엄격한 피보나치 힙 중에서 다음 유형이 나타납니다. 다양한 시나리오에 대한 거의 모든 요구 사항을 충족합니다.

  • 암시적 d-ary 힙(ArrayHeap), <- 확실히 이것이 필요합니다.
  • 힙 페어링, <- 멋지고 깔끔한 IHeap 접근 방식을 사용하면 많은 경우 어레이 기반 솔루션보다 빠르고 빠르기 때문에 이것을 추가할 가치가 있습니다 .

  둘 다 프로그래밍 노력이 놀라울 정도로 낮습니다. 내 구현을 살펴보십시오.

@karelz @benaadams

이것은 CoreFX에 있으면 정말 유용한 유형입니다. 누구든지 이것을 잡는 데 관심이 있습니까?

@safern 지금부터 이것을 잡게 되어 매우 기쁩니다.

알겠습니다. 제 키보드와 의자 사이에 문제가 있었습니다. PriorityQueue 는 물론 Heap -- Queue 에 대해 말이 안 되는 부분만 생각하고 있었습니다. 그리고 힙이 '정렬'된다는 사실을 잊었습니다. 논리, 알고리즘, 튜링 기계 등을 좋아하는 나와 같은 사람에게는 매우 창피한 사고 프로세스 중단입니다. 죄송합니다. (BTW: Java 문서 링크에서 몇 문장을 읽자 마자 불일치가 즉시 클릭되었습니다.)

그런 관점에서 보면 Heap 위에 API를 빌드하는 것이 합리적입니다. 하지만 해당 클래스를 아직 공개해서는 안 됩니다. CoreFX에서 필요한 경우 자체 API 검토와 자체 토론이 필요합니다. 우리는 구현으로 인한 API 표면 크리프를 원하지 않지만 그것이 옳은 일일 수 있습니다. 따라서 논의가 필요합니다.
그런 관점에서 저는 아직 IHeap 를 만들 필요가 없다고 생각합니다. 나중에 좋은 결정이 될 수 있습니다.
특정 힙(예: 위에서 언급한 4-ary)이 일반 임의 입력에 가장 적합하다는 연구 결과가 있으면 이를 선택해야 합니다. @safern @ianhays @stephentoub 가 의견을 확인/음성할 때까지 기다리자.

여러 구현 옵션이 있는 기본 힙의 매개변수화는 IMO가 CoreFX에 속하지 않는 것입니다(여기서 내가 틀릴 수도 있습니다. 다른 사람들이 어떻게 생각하는지 봅시다).
제 이유는 IMO에서 사람들(알고리즘의 뉘앙스에 대한 강력한 배경 지식이 없는 평균 개발자)이 선택하기 매우 어려운 수많은 전문 컬렉션을 곧 출하할 것이기 때문입니다. 그러나 이러한 라이브러리는 사용자/커뮤니티가 소유한 해당 분야의 전문가를 위한 훌륭한 NuGet 패키지가 될 것입니다. 앞으로는 PowerCollections에 추가하는 것을 고려할 수 있습니다(지난 4개월 동안 GitHub에 이 라이브러리를 넣을 위치와 소유해야 하는지 또는 커뮤니티가 소유하도록 권장해야 하는지에 대해 적극적으로 논의 중입니다. 이 문제에 대해 다른 의견이 있습니다. , 나는 우리가 2.0 이후에 그 운명을 마무리 지을 것으로 예상합니다)

작업하고 싶은 대로 할당...

@pgolebiowski 공동 작업자 초대가 전송되었습니다. ping을 수락하면 그때 할당할 수 있습니다(GitHub 제한).

@benaadams 나는 ICollection 유지할 것입니다(약간의 선호도). CoreFX의 다른 ds와의 일관성을 위해. IMO 여기에 하나의 이상한 짐승을 가질 가치가 없습니다 ... 소수의 새 항목(예: PowerCollections를 다른 저장소에도 추가)을 추가하는 경우 일반이 아닌 항목을 포함하지 않아야 합니다... 생각?

네, 제 키보드와 의자 사이의 문제였습니다.

ㅎㅎ 😄 걱정마세요.

힙 위에 API를 빌드하는 것이 좋습니다. 우리는 아직 그 클래스를 공개해서는 안되지만 [...] 우리는 구현으로 인한 API 표면 크립을 원하지 않지만 그것이 옳은 일일 수 있습니다. 따라서 논의가 필요합니다. [...] 아직 IHeap을 만들 필요가 없다고 생각합니다. 나중에 좋은 결정이 될 수 있습니다.

그룹의 결정이 PriorityQueue 로 가는 것이라면 저는 그냥 디자인을 돕고 이것을 구현하겠습니다. 그러나 지금 PriorityQueue 를 추가하면 나중에 Heap 를 추가하는 것이 API에서 지저분해질 수 있다는 사실을 고려하십시오. 둘 다 기본적으로 동일하게 동작하기 때문입니다. 일종의 중복성 IMO일 것입니다. 이것은 나에게 디자인 냄새가 될 것입니다. 나는 우선 순위 대기열을 추가하지 않을 것입니다. 도움이 되지 않습니다.

또한, 한 가지 더 생각합니다. 실제로 페어링 힙 데이터 구조는 꽤 자주 유용할 수 있습니다. 배열 기반 힙은 병합에 끔찍합니다. 이 작업은 기본적으로 선형 입니다. 병합 힙이 많으면 성능이 저하됩니다. 그러나 배열 힙 대신 페어링 힙을 사용하는 경우 병합 작업은 일정합니다 (상각). 이것은 내가 멋진 인터페이스와 두 가지 구현을 제공하고 싶은 또 다른 주장입니다. 하나는 일반 입력을 위한 것이고 두 번째는 특히 힙 병합과 관련된 일부 특정 시나리오를 위한 것입니다.

IHeap + ArrayHeap + PairingHeap 투표하세요! 😄 (Rust / Swift / Python / Go에서와 같이)

페어링 힙이 너무 많은 경우 -- 좋습니다. 그러나 적어도 IHeap + ArrayHeap 로 가자. PriorityQueue 클래스를 사용하는 것이 미래의 가능성을 잠그고 API를 덜 명확하게 만든다고 생각하지 않습니까?

하지만 제가 말했듯이 -- 여러분 모두가 제안된 솔루션에 대해 PriorityQueue 클래스에 투표한다면 -- 좋습니다.

공동 작업자 초대가 전송되었습니다. ping을 수락하면 그때 할당할 수 있습니다(GitHub 제한 사항).

@karelz 핑 :)

지금 PriorityQueue를 추가하면 나중에 힙을 추가하는 것이 API에서 지저분해질 것이라는 사실을 고려하십시오. 둘 다 기본적으로 동일하게 동작하기 때문입니다. 일종의 중복성 IMO일 것입니다. 이것은 나에게 디자인 냄새가 될 것입니다. 나는 우선 순위 대기열을 추가하지 않을 것입니다. 도움이 되지 않습니다.

나중에 왜 지저분해지는지 자세히 설명해주실 수 있나요? 당신의 관심사는 무엇입니까?
PriorityQueue 는 사람들이 사용하는 개념입니다. 그런 식으로 이름이 지정된 유형이 있으면 유용합니다. 맞죠?
Heap 대한 논리 연산(적어도 해당 이름)이 다를 수 있다고 생각합니다. 동일하다면 최악의 경우(이상적이지는 않지만 세상의 종말은 아님)에서 동일한 코드의 2가지 다른 구현을 가질 수 있습니다. 또는 PriorityQueue 부모로 Heap 클래스를 삽입할 수 있습니다. 맞습니까? (API 검토 관점에서 허용된다고 가정 - 지금 당장은 이유를 알 수 없지만 API 검토에 대한 수년간의 경험이 없으므로 다른 사람들이 확인하기를 기다릴 것입니다)

투표 및 추가 설계 논의가 어떻게 진행되는지 봅시다 ... 저는 IHeap + ArrayHeap 에 대한 아이디어로 천천히 워밍업하고 있지만 아직 완전히 확신하지 못하고 있습니다 ...

소수의 새 항목을 추가하는 경우 ... 일반이 아닌 항목은 포함하지 않아야 합니다.

황소에 빨간 걸레. ICollection 삭제할 수 있도록 추가할 다른 컬렉션이 있는 사람이 있습니까?

원형/링 버퍼; 일반 및 동시?

@karelz 명명 문제에 대한 솔루션은 DataFlow가 생산/소비자 패턴에 대해 수행하는 것처럼 IPriorityQueue 와 같은 것일 수 있습니다. 우선 순위 대기열을 구현하는 여러 가지 방법과 이에 대해 신경 쓰지 않는다면 인터페이스를 사용하십시오. 구현에 신경을 쓰거나 구현 클래스를 사용하여 인스턴스를 만들고 있습니다.

나중에 왜 지저분해지는지 자세히 설명해주실 수 있나요? 당신의 관심사는 무엇입니까?
PriorityQueue 는 사람들이 사용하는 개념입니다. 그런 식으로 이름이 지정된 유형이 있으면 유용합니다. 맞죠? [...] 나는 천천히 IHeap + ArrayHeap 에 대한 아이디어를 준비하고 있지만 아직 완전히 확신하지 못하고 있습니다 ...

@karelz 내 경험에 따르면 추상화( IPriorityQueue 또는 IHeap )를 갖는 것이 정말 중요합니다. 이러한 접근 방식 덕분에 개발자는 분리된 코드를 작성할 수 있습니다. 특정 구현이 아닌 인터페이스에 대해 작성되었기 때문에 유연성과 IoC 정신이 더 많이 있습니다. 그러한 코드에 대한 단위 테스트를 작성하는 것은 매우 쉽습니다(Dependency Injection을 사용하면 자신의 조롱 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 는 그것이 가치가 없다고 생각하며("우리는 생태계에서 더 좋고 더 영향력 있는 일을 해야 합니다") 커뮤니티가 이를 완전히 추진하고(기존 PowerCollection으로 시작하는 것을 포함하여) 우리의 하나가 되지 않도록 권장해야 합니다. repos - 일부는 우리 앞에서 논의 및 결정을 내립니다.
// 우리가 결정하기 전에 커뮤니티가 이 솔루션에 뛰어들 기회가 있다고 생각합니다 ;-). 그러면 토론(및 내 선호도)이 음소거됩니다 ;-)

@pgolebiowski 당신은 Heap 가 PriorityQueue 보다 낫다는 것을 서서히 확신 시키고 있습니다 -- 우리는 강력한 지침과 문서가 필요할 것입니다 " PriorityQueue - Heap 사용

그러나 CoreFX에 2개 이상의 힙 구현을 포함하는 것을 매우 주저합니다. 98% 이상의 '일반' C# 개발자는 신경 쓰지 않습니다. 그들은 어느 것이 가장 좋은지 생각조차 하고 싶지 않습니다. 그들은 단지 일을 완수하는 무언가가 필요합니다. 모든 SW의 모든 부분이 고성능을 염두에 두고 설계된 것은 아닙니다. 모든 일회용 도구, UI 앱 등에 대해 생각해 보십시오. 이 ds가 중요한 경로에 있는 고성능 확장 시스템을 설계하지 않는 한 신경 쓰지 않아야 합니다.

같은 방식으로 SortedDictionary 또는 ArrayList 또는 기타 ds가 구현되는 방식에는 관심이 없습니다. 나는 (다른 많은 사람들과 마찬가지로) 내 시나리오에 대해 이러한 ds에서 고성능이 필요한 경우 성능을 측정하고 구현을 확인하고 내 시나리오에 충분한지 또는 필요한지 결정해야 함을 이해합니다. 내 요구 사항에 맞게 조정된 최상의 성능을 얻기 위해 나만의 특수 구현을 롤아웃합니다.

2%가 아닌 98%의 사용 사례에 대해 사용성을 최적화해야 합니다. 너무 많은 옵션(구현)을 출시하고 모든 사람이 결정하도록 강요하면 98%의 사용 사례에 대해 불필요한 혼란을 야기할 뿐입니다. 그만한 가치가 없다고 생각합니다...
IMO .NET 에코시스템은 대부분의 사용 사례에 유용한 매우 적절한 성능 특성을 가진 많은 API(컬렉션뿐만 아니라)의 단일 선택을 제공하는 데 큰 가치가 있습니다. 그리고 그것을 필요로 하고 더 깊이 파고들고 더 많이 배우고자 하는 사람들을 위해 고성능 확장을 허용하는 생태계를 제공하고/교양 있는 선택과 절충안을 만듭니다.

즉, IHeap 인터페이스(예 IDictionary 및 IReadOnlyDictionary )가 있는 것이 합리적일 수 있습니다. 우주 ...

우리는 이미 (어느 정도) @pgolebiowski 가 ISet<T> 및 HashSet<T> 대해 이야기하고 있습니다. 그냥 미러링 하라고 합니다. 따라서 위의 API는 인터페이스( 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]입니다(2진수에서는 4진수로 다를 수 있음).

• 인덱스 i 에서 내부 숫자를 반환하는 것은 거의 임의적이므로 사용자의 관점에서 실제로 의미가 없습니다.
• 순서대로(우선순위에 따라) 숫자를 반환하는 것은 비용이 너무 많이 듭니다. 이것은 선형적입니다.
• 이들 중 하나를 반환하는 것은 다른 구현에서 실제로 의미가 없습니다. 종종 i 요소를 팝하고 i 번째 요소를 가져온 다음 다시 한 번 푸시합니다.

IList<T> 는 일반적으로 다음과 같은 건방진 해결 방법입니다. 내 API가 허용하는 컬렉션을 유연하게 사용하고 열거하고 싶지만 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 에 대해 합의하지 않았습니다. 이것은 방법의 이름과 논리에 약간의 영향을 미칩니다. 그러나 어느 쪽이든 현재 API 제안에는 다음이 누락되어 있습니다.

• 대기열에서 특정 요소를 제거하는 기능
• 요소의 우선 순위를 업데이트하는 기능
• 이러한 구조를 병합하는 기능

이러한 작업은 특히 요소 업데이트 가능성이 매우 중요합니다. 이것이 없으면 많은 알고리즘을 간단히 구현할 수 없습니다. 핸들 유형을 도입해야 합니다. 여기 API에서 핸들은 IHeapNode 입니다. 이것은 IHeap 방식으로 가는 또 다른 주장입니다. 그렇지 않으면 항상 힙 노드가 되는 PriorityQueueHandle 유형을 도입해야 하기 때문입니다... 😜 게다가 그것이 의미하는 바가 막연합니다... 반면에, 힙 노드는 -- 모두가 물건을 알고 있고 그들이 다루고 있는 것을 상상할 수 있습니다.

실제로 API 제안에 대해 간단히 말해서 이 디렉토리를 살펴보십시오. 우리는 아마도 그 중 일부만 필요할 것입니다. 그러나 그럼에도 불구하고 그것은 우리가 IMO에 필요한 것만 포함하고 있으므로 시작점으로 살펴볼 가치가 있습니다.

여러분의 생각은 어떻습니까?

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);
        }

그러나 이제 힙의 모든 요소는 추가 개체입니다. PriorityQueue 동작을 원하지만 이러한 추가 할당을 원하지 않으면 어떻게 합니까?

그러면 요소를 업데이트/제거할 수 없습니다. DecreaseKey 연산에 의존하는 알고리즘을 구현하는 것을 허용하지 않는 베어 구현이 될 것입니다(매우 일반적임). 예를 들어 Dijkstra의 알고리즘, Prim의 알고리즘. 또는 일종의 스케줄러를 작성 중이고 일부 프로세스(또는 무엇이든)가 우선 순위를 변경한 경우 이를 해결할 수 없습니다.

또한 다른 모든 힙 구현에서 요소는 명시적으로 노드일 뿐입니다. 다른 경우에는 완벽하게 자연스럽고 여기에서는 약간 인위적이지만 업데이트/제거에 필요합니다.

Java에서 우선 순위 대기열에는 요소를 업데이트하는 옵션이 없습니다. 결과:

• Java의 우선 순위 대기열에 우선 순위 변경 방법이 없는 이유는 무엇입니까?
• 자바 우선순위 큐 업데이트 문제
• PriorityQueue/힙 업데이트

AlgoKit 프로젝트를 위해 힙을 구현하고 이러한 모든 설계 문제를 만났을 때 .NET 작성자가 힙(또는 우선 순위 큐)과 같은 기본 데이터 구조를 추가하지 않기로 결정한 이유가 바로 이것이라고 생각했습니다. 어느 쪽 디자인도 좋지 않기 때문입니다. 각각의 단점이 있습니다.

간단히 말해서 -- 우선 순위에 따라 요소의 효율적인 순서를 지원하는 데이터 구조를 추가하려면 올바른 방법으로 수행하고 요소 업데이트/제거와 같은 기능을 추가하는 것이 좋습니다.

배열의 요소를 다른 개체로 래핑하는 것이 좋지 않다고 느낀다면, 이것이 유일한 문제는 아닙니다. 다른 하나는 병합입니다. 어레이 기반 힙에서는 완전히 비효율적입니다. 그러나... 페어링 힙 데이터 구조( pairing heap: A new form of self-adjusting heap )를 사용하는 경우:

• 요소에 대한 핸들은 멋진 노드입니다. 어쨌든 할당되어야 하므로 지저분한 것은 없습니다.
• 병합이 일정함(배열 기반 솔루션의 선형 대비)

실제로 다음과 같은 방법으로 해결할 수 있습니다.

• 모든 메소드를 지원하는 IHeap 인터페이스 추가
• 모든 핸들과 함께 ArrayHeap 및 PairingHeap , 업데이트, 제거, 병합
• ArrayHeap 주위의 래퍼인 PriorityQueue 를 추가하여 API를 단순화합니다.

PriorityQueue 는 System.Collections.Generic 있고 모든 힙은 System.Collections.Specialized 있습니다.

공장?

API 검토를 통해 세 가지 새로운 데이터 구조를 얻을 가능성은 거의 없습니다. 대부분의 경우 적은 양의 API가 더 좋습니다. 나중에 부족할 경우 언제든지 추가할 수 있지만 API를 제거할 수는 없습니다.

이것이 내가 HeapNode 클래스의 팬이 아닌 이유 중 하나입니다. 그런 종류의 것은 내부 전용이어야 하고 API는 가능한 경우 이미 존재하는 유형을 노출해야 합니다. 이 경우 KVP일 것입니다.

@ianhays 이것이 내부 전용으로 유지되면 사용자는 데이터 구조에서 요소의 우선 순위를 업데이트할 수 없습니다. 이것은 거의 쓸모가 없을 것이고 우리는 모든 Java 문제로 끝날 것입니다. 사람들은 이미 기본 라이브러리에 있는 데이터 구조를 다시 구현합니다... 나에게는 좋지 않은 것 같습니다. 노드를 나타내는 간단한 클래스를 갖는 것보다 훨씬 나쁩니다.

BTW: 연결 목록에는 사용자가 적절한 기능을 사용할 수 있도록 노드 클래스가 있습니다. 이것은 거의 미러링입니다.

사용자는 데이터 구조에 있는 요소의 우선 순위를 업데이트할 수 없습니다.

그것이 반드시 사실은 아닙니다. 우선 순위는 다음과 같은 추가 데이터 구조가 필요하지 않은 방식으로 노출될 수 있습니다.

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

        }

당신은 예를 들어

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

        }

나는 우선 순위를 유형 매개 변수로 노출하는 것에 대해 아직 확신하지 못합니다. 대부분의 사람들은 기본 우선 순위 유형을 사용할 것이며 TValue는 불필요한 특이성이 될 것입니다.

void Update(TKey item, TValue priority)

먼저 -- 코드에서 TKey 및 TValue 는 무엇입니까? 어떻게 작동해야 합니까? 컴퓨터 과학의 규칙은 다음과 같습니다.

• 키 = 우선순위
• 값 = 요소에 저장하려는 모든 것

두번째:

대부분의 사람들은 기본 우선 순위 유형을 사용할 것이며 TValue는 불필요한 특이성이 될 것입니다.

"기본 우선순위 유형"을 정의하십시오. PriorityQueue<T> 갖고 싶다는 느낌이 드는데 맞나요? 이 경우 사용자가 우선 순위와 값을 둘러싼 래퍼인 새 클래스를 만들고 IComparable 와 같은 것을 구현하거나 사용자 지정 비교기를 제공해야 한다는 사실을 고려하십시오. 꽤 가난한.

첫 번째 -- 코드에서 TKey와 TValue는 무엇입니까?

항목 및 항목의 우선 순위입니다. 그것들을 우선순위 및 해당 우선순위와 연관된 항목으로 전환할 수 있지만 TKey가 반드시 고유하지 않은(즉, 중복 우선순위 허용) 컬렉션이 있습니다. 나는 그것에 반대하지 않지만 나에게 TKey는 일반적으로 고유성을 의미합니다.

요점은 Node 클래스를 노출하는 것이 Update 메서드를 노출하기 위한 요구 사항이 아니라는 것입니다.

"기본 우선순위 유형"을 정의하십시오. 나는 당신이 PriorityQueue를 갖고 싶어한다는 것을 느낄 수 있습니다., 그렇지?

예. 이 스레드를 다시 읽어보긴 하지만, 나는 그것이 사실인지 완전히 확신하지 못합니다.

이 경우 사용자가 우선 순위와 값에 대한 래퍼인 새 클래스를 만들고 IComparable과 같은 것을 구현하거나 사용자 지정 비교기를 제공해야 한다는 사실을 고려하십시오. 꽤 가난한.

당신은 틀리지 않았다. 상당한 양의 사용자 가 사용자 지정 비교기 논리를 사용하여 래퍼 유형을 만들어야 한다고 생각합니다. 나는 또한 우선순위 큐에 넣고 싶은 비교 가능한 유형이나 정의된 비교기가 있는 유형을 이미 가지고 있는 상당한 양의 사용자가 있다고 상상합니다. 문제는 둘 중 어느 캠프가 더 큰가입니다.

.Net의 나머지 부분과 일관성을 유지하려면 유형을 Heap<T> , ArrayHeap<T> 또는 QuaternaryHeap<T> 가 아니라 PriorityQueue<T> 라고 해야 한다고 생각합니다.

• List<T> 가 아니라 ArrayList<T> 있습니다.
• Dictionary<K, V> 가 아니라 HashTable<K, V> 있습니다.
• ImmutableList<T> 가 아니라 ImmutableAVLTreeList<T> 있습니다.
• 우리는이 Array.Sort() 하지 Array.IntroSort() .

이러한 유형의 사용자는 일반적으로 구현 방법에 관심이 없으며 유형에 대해 가장 눈에 띄는 것이 아니어야 합니다.

이 경우 사용자가 우선 순위와 값에 대한 래퍼인 새 클래스를 만들고 IComparable과 같은 것을 구현하거나 사용자 지정 비교기를 제공해야 한다는 사실을 고려하십시오.

당신은 틀리지 않았다. 상당한 양의 사용자가 사용자 지정 비교기 논리를 사용하여 래퍼 유형을 만들어야 한다고 생각합니다.

요약 API에서 비교는 제공된 비교자 IComparer<T> comparer 의해 제공되며 래퍼가 필요하지 않습니다. 종종 우선 순위는 유형의 일부가 될 것입니다. 예를 들어 시간 스케줄러는 유형의 속성으로 실행 시간을 갖습니다.

사용자 정의 IComparer 와 함께 KeyValuePair 사용하면 추가 할당이 추가되지 않습니다. 항목이 아닌 값을 비교해야 하므로 업데이트에 대한 간접 참조가 하나 추가됩니다.

항목이 ref 반환을 통해 얻은 다음 ref에 의해 업데이트되어 업데이트 메서드로 다시 전달되고 참조가 비교되지 않는 한 업데이트는 구조체 항목에 문제가 될 수 있습니다. 하지만 그건 좀 끔찍합니다.

@svic

.Net의 나머지 부분과 일관성을 유지하려면 유형을 Heap<T> , ArrayHeap<T> 또는 QuaternaryHeap<T> 가 아니라 PriorityQueue<T> 라고 해야 한다고 생각합니다.

나는 인간에 대한 믿음을 잃어가고 있다.

• PriorityQueue 데이터 구조를 호출하는 것은 .NET의 나머지 부분과 일치하고 Heap 호출하는 것은 그렇지 않습니까? 힙에 문제가 있습니까? 스택과 큐에도 동일하게 적용되어야 합니다.
• ArrayHeap -> QuaternaryHeap 대한 기본 클래스 . 엄청난 차이.
• 토론은 멋진 이름을 고르는 문제가 아닙니다. 특정 디자인 경로를 따른 결과 많은 것들이 나옵니다. 스레드를 다시 읽으십시오.
• 해시 테이블 , ArrayList . 그들은 존재하는 것 같습니다. BTW, "목록"은 IMO 이름 지정에 있어 매우 잘못된 선택입니다. 사용자의 첫 번째 생각은 List 이 목록이지만 목록이 아니기 때문입니다. 😜
• 재미를 느끼고 구현 방법을 말하는 것이 아닙니다. 사용자가 무엇을 다루고 있는지 즉시 보여주는 의미 있는 이름을 지정하는 것입니다.

.NET의 나머지 부분과 일관성을 유지하고 이와 같은 문제를 겪고 싶습니까?

• SortedList와 SortedDictionary의 차이점은 무엇입니까? .

그리고 거기에서 무엇을 볼 수 있습니까? Jon Skeet은 SortedDictionary 를 SortedTree 로 불러야 한다고 말했습니다. 이는 구현을 더 자세히 반영하기 때문입니다.

@pgolebiowski

힙에 문제가 있습니까?

예, 사용법이 아닌 구현을 설명합니다.

스택과 큐에도 동일하게 적용되어야 합니다.

둘 다 실제로 구현을 설명하지 않습니다. 예를 들어 이름이 배열 기반임을 알려주지 않습니다.

ArrayHeap -> QuaternaryHeap 대한 기본 클래스 . 엄청난 차이.

예, 귀하의 디자인을 이해합니다. 내 말은 이 중 어느 것도 사용자에게 노출되어서는 안 된다는 것입니다.

특정 디자인 경로를 따른 결과 많은 것들이 나옵니다. 스레드를 다시 읽으십시오.

실을 읽었습니다. 나는 그 디자인이 BCL에 속한다고 생각하지 않는다. 사람들이 "4차 힙"이 무엇인지 또는 사용해야 하는지 궁금해하게 만드는 내용이 아니라 사용하고 이해하기 쉬운 내용을 포함해야 한다고 생각합니다.

기본 구현이 충분하지 않은 경우 다른 라이브러리(예: 자신의 라이브러리)가 들어옵니다.

해시테이블, ArrayList. 그들은 존재하는 것 같습니다.

예, 아무도 더 이상 사용하지 않는 .Net Framework 1.0 클래스입니다. 내가 말할 수 있는 한, 그들의 이름은 Java에서 복사되었으며 .Net Framework 2.0 디자이너는 해당 규칙을 따르지 않기로 결정했습니다. 제 생각에는 그것이 옳은 결정이었습니다.

BTW, "목록"은 IMO 이름 지정에 있어 매우 잘못된 선택입니다. 사용자의 첫 번째 생각은 List 가 목록이지만 목록이 아니기 때문입니다.

그것은이다. 연결된 목록은 아니지만 동일한 것은 아닙니다. 그리고 ArrayList 또는 ResizeArray ( List<T> 대한 F#의 이름)를 어디에나 쓰지 않아도 되는 것을 좋아합니다.

사용자가 무엇을 다루고 있는지 즉시 보여주는 의미 있는 이름을 지정하는 것입니다.

대부분의 사람들은 QuaternaryHeap 표시되면 자신이 무엇을 다루고 있는지 모를 것입니다. 반면에 PriorityQueue 되면 CS 배경이 없더라도 무엇을 다루고 있는지 명확해야 합니다. 그들은 구현이 무엇인지 알지 못하지만 그것이 문서화를 위한 것입니다.

@ianhays

첫 번째 -- 코드에서 TKey와 TValue는 무엇입니까?

항목 및 항목의 우선 순위입니다. 그것들을 우선순위 및 해당 우선순위와 연관된 항목으로 전환할 수 있지만 TKey가 반드시 고유하지 않은(즉, 중복 우선순위 허용) 컬렉션이 있습니다. 나는 그것에 반대하지 않지만 나에게 TKey는 일반적으로 고유성을 의미합니다.

키 -- 우선 순위 지정에 사용되는 항목입니다. 키는 고유할 필요가 없습니다. 우리는 그런 가정을 할 수 없습니다.

요점은 Node 클래스를 노출하는 것이 Update 메서드를 노출하기 위한 요구 사항이 아니라는 것입니다.

내 생각에는 기본 라이브러리에서 키 감소/키 증가 지원입니다 . 또한 이 주제에서는 데이터 구조를 다루는 데 관련된 도우미 클래스가 있습니다.

• LinkedListNode
• DictionaryEntry

상당한 양의 사용자가 사용자 지정 비교기 논리를 사용하여 래퍼 유형을 만들어야 한다고 생각합니다. 나는 또한 우선순위 큐에 넣고 싶은 비교 가능한 유형이나 정의된 비교기가 있는 유형을 이미 가지고 있는 상당한 양의 사용자가 있다고 상상합니다. 문제는 둘 중 어느 캠프가 더 큰가입니다.

나는 다른 사람들에 대해서는 모르지만 우선 순위 대기열을 꽤 끔찍하게 사용하고 싶을 때마다 사용자 정의 비교기 논리로 래퍼를 만드는 것을 발견했습니다 ...

또 다른 생각 - 래퍼를 만들었다고 가정해 보겠습니다.

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

나는 이 유형으로 PriorityQueue<T> 를 먹인다. 따라서 이를 기반으로 요소의 우선 순위를 지정합니다. 키 선택기를 정의했다고 가정해 보겠습니다. 이러한 디자인은 힙의 내부 작업을 중단시킬 수 있습니다. 당신은 요소의 소유자로서 당신은 우선 순위 언제든지 변경할 수 있습니다. 힙 업데이트에 대한 알림 메커니즘이 없습니다. 당신은 그 모든 것을 처리하고 그것을 호출할 책임이 있습니다. 꽤 위험하고 나에게 직설적이지 않습니다.

내가 제안한 핸들의 경우 -- 사용자의 관점에서 유형이 변경되지 않았습니다. 그리고 독창성에는 문제가 없었습니다.

IMO IHeap 인터페이스를 가진 다음 해당 인터페이스를 구현하는 클래스 API가 있다는 아이디어가 마음에 듭니다. 나는 우리가 API 검토 과정이있을 필요로 고객에게 힙의 다른 종류를 제공하기 위해 3 개의 새 API를 노출 가고 있지 않은지 우리가에 초점을하려는이에 @ianhays '함께 해요 PriorityQueue 이름이 무엇이든 상관 없습니다.

두 번째로 대기열에 값을 저장하기 위해 Node 내부/공용 클래스를 가질 필요가 없다고 생각합니다. 추가 할당이 필요하지 않습니다. 우리는 IDictionary가 하는 것과 같은 것을 따를 수 있고 KeyValuePair를 생성하는 Enumerable에 대한 값을 산출할 때우리가 저장하는 각 항목에 대한 우선 순위를 갖는 옵션을 선택하는 경우 개체를 선택합니다(이것이 가장 좋은 방법은 아니라고 생각합니다. 항목당 우선 순위를 저장하는 것에 대해 완전히 확신하지 못합니다). 내가 원하는 가장 좋은 방법은 PriorityQueue<T> (이 이름은 단지 하나를 주기 위한 것입니다). 이 접근 방식을 사용하면 전체 BCL이 IComparer<T> 로 수행하는 작업을 따르고 해당 비교기와 비교하여 우선 순위를 부여하는 생성자를 가질 수 있습니다. 우선순위를 매개변수로 전달하는 API를 노출할 필요가 없습니다.

일부 API에 우선 순위를 부여하면 기본 우선 순위를 원하는 일반 고객에게 "사용성이 떨어지거나" 더 복잡해질 것이라고 생각합니다. IComparer<T> 사용자 지정 옵션이 가장 합리적이며 BCL 전반에 걸쳐 있는 지침을 따릅니다.

이름은 어떻게 하는 것이 아니라 하는 것입니다.

그것들의 이름은 추상적인 개념과 그 구현과 그것을 달성하는 방법보다는 사용자를 위해 달성한 것의 이름을 따서 명명되었습니다. (이는 또한 더 나은 것으로 판명되면 다른 구현을 사용하도록 구현을 개선할 수 있음을 의미합니다)

스택과 큐에도 동일하게 적용되어야 합니다.

Stack 는 무한 크기 조정 배열이고 Queue 는 무한 크기 조정 순환 버퍼로 구현됩니다. 그것들은 추상적 개념의 이름을 따서 명명되었습니다. 스택(추상 자료형) : 후입선출(LIFO), 큐(추상 자료형) : 선입선출(FIFO)

해시테이블, ArrayList. 그들은 존재하는 것 같습니다.

사전 항목

네, 하지만 그렇지 않은 척 합시다. 그것들은 덜 문명화된 시대의 인공물입니다. 프리미티브 또는 구조체를 사용하는 경우에는 유형 안전 및 상자가 없습니다. 따라서 모든 추가에 할당하십시오.

@terrajobst 의 플랫폼 호환성 분석기를 사용할 수 있으며 "하지 마십시오"라고 알려줍니다.

목록은 목록이지만 목록이 아닙니다.

실제로 시퀀스라고도 하는 목록(추상 데이터 유형) 입니다.

동등 우선 순위 대기열 은 사용 시 달성한 내용을 알려주는 추상 유형입니다. 구현 시 수행 방식이 아님(다양한 구현이 있을 수 있음)

많은 훌륭한 토론!

원래 사양은 몇 가지 핵심 원칙을 염두에 두고 설계되었습니다.

• 범용 - CPU와 메모리 소비 간의 균형으로 대부분의 사용 사례를 다룹니다.
• System.Collections.Generic의 기존 패턴 및 규칙에 최대한 맞춰 정렬합니다.
• 동일한 요소의 여러 항목을 허용합니다.
• 기존 BCL 비교 인터페이스 및 클래스(예: Comparer).*
• 높은 수준의 추상화 - 이 사양은 기본 구현 기술로부터 소비자를 보호하도록 설계되었습니다.

@karelz @pgolebiowski
"힙"으로 이름을 바꾸거나 데이터 구조 구현에 맞춰 정렬된 다른 용어는 컬렉션에 대한 대부분의 BCL 규칙과 일치하지 않습니다. 역사적으로 .NET 컬렉션 클래스는 특정 데이터 구조/패턴에 중점을 두지 않고 범용으로 설계되었습니다. 내 원래 생각은 .NET 에코시스템 초기에 API 디자이너가 의도적으로 "ArrayList"에서 "List"로 이동했다는 것입니다.". 변경 사항은 어레이와의 혼동으로 인한 것일 수 있습니다. 일반 개발자는 "ArrayList? 나는 배열이 아닌 목록을 원합니다."

힙을 사용하는 경우에도 동일한 일이 발생할 수 있습니다. 많은 중급 개발자는 (슬프게도) "힙"을 보고 "일반화된 데이터 구조를 힙"하는 대신 응용 프로그램의 메모리 힙(예: 힙 및 스택)으로 혼동합니다. System.Collections.Generic의 보급으로 인해 거의 모든 .NET 개발자의 지능적인 제안에 나타나며 새 메모리 힙을 할당할 수 있는 이유를 궁금해할 것입니다. :)

이에 비해 PriorityQueue는 훨씬 더 쉽게 검색할 수 있고 혼동을 일으킬 가능성이 적습니다. "Queue"를 입력하고 PriorityQueue에 대한 제안을 받을 수 있습니다.

정수 우선 순위 또는 우선 순위에 대한 일반 매개 변수(TKey, Tpriority 등)에 대한 몇 가지 제안 및 질문이 있습니다. 명시적 우선 순위를 추가하려면 소비자가 우선 순위를 매핑하고 API의 복잡성을 증가시키는 자체 논리를 작성해야 합니다. 내장 IComparer 사용기존 BCL 기능을 활용하고 Comparer에 오버로드를 추가하는 것도 고려했습니다.임시 람다 식/익명 함수를 우선 순위 비교로 더 쉽게 제공할 수 있도록 사양에 추가합니다. 슬프게도 그것은 BCL의 일반적인 규칙이 아닙니다.

항목이 고유해야 하는 경우 Enqueue()는 ArgumentException을 발생시키기 위해 고유성 조회를 요구합니다. 또한 항목을 두 번 이상 대기열에 넣을 수 있는 유효한 시나리오가 있을 수 있습니다. 이 비고유성 디자인은 어떤 객체가 업데이트되고 있는지 알 수 있는 방법이 없기 때문에 Update() 작업을 제공하는 것을 어렵게 만듭니다. 몇 가지 의견에서 알 수 있듯이 이것은 "노드" 참조를 반환하는 API에 들어가기 시작하며, 그러면 가비지 수집이 필요한 할당이 필요할 수 있습니다. 이 문제가 해결된 경우에도 우선 순위 대기열의 요소당 메모리 소비가 증가합니다.

한 때 사양을 게시하기 전에 API에 사용자 지정 IpriorityQueue 인터페이스가 있었습니다. 궁극적으로 나는 그것에 반대하기로 결정했습니다. 제가 목표로 했던 사용 패턴은 Enqueue, Dequeue 및 Iterate였습니다. 기존 인터페이스 세트에서 이미 다루었습니다. 이것을 내부적으로 정렬된 대기열로 생각하십시오. 항목이 IComparer를 기반으로 대기열에서 자체(초기) 위치를 유지하는 한, 호출자는 우선 순위가 표시되는 방식에 대해 걱정할 필요가 없습니다. 내가 한 이전 참조 구현에서 (제 기억이 맞다면!) 우선 순위는 전혀 표시되지 않습니다. 그것은 모두 IComparer를 기반으로 한 상대적입니다.또는 비교.

일부 고객 코드 예제는 모두 귀하에게 빚지고 있습니다. 원래 계획은 예제의 기초로 사용하기 위해 PriorityQueue의 기존 BCL 구현을 살펴보는 것이었습니다.

요약 API에서 비교는 제공된 비교자 IComparer에 의해 제공됩니다.비교자, 래퍼가 필요하지 않습니다. 종종 우선 순위는 유형의 일부가 될 것입니다. 예를 들어 시간 스케줄러는 유형의 속성으로 실행 시간을 갖습니다.

제안된 OP API에서 클래스를 사용하려면 다음 중 하나를 충족해야 합니다.

• 원하는 방식으로 이미 비교 가능한 유형이 있습니다.
• 우선 순위 값이 포함된 다른 클래스로 유형을 래핑하고 원하는 방식과 비교합니다.
• 형식에 대한 사용자 지정 IComparer를 만들고 생성자를 통해 전달합니다. 우선 순위를 나타내려는 값이 이미 유형에 의해 공개적으로 노출되어 있다고 가정합니다.

이중형 API는 두 번째 두 가지 옵션의 부담을 줄이는 것을 목표로 하고 있지 않습니까? 이미 우선 순위 가 포함된 유형이 있는 경우 새 PriorityQueue/Heap 생성은 어떻게 작동합니까? API는 어떻게 생겼나요?

내 생각에는 기본 라이브러리에서 키 감소/키 증가 지원입니다.

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를 직접 사용하여 수행할 수 없는 작업은 무엇입니까?

적어도 이진 힙(내가 가장 잘 알고 있는 것)을 사용하여 일부 값의 우선 순위를 업데이트하고 힙에서 해당 위치를 알고 있다면 신속하게 수행할 수 있습니다(O(log n) 시간).

그러나 값과 우선 순위만 알고 있다면 먼저 값을 찾아야 하는데, 이는 느린 값(O(n))입니다.

반면에 효율적으로 업데이트할 필요가 없는 경우 힙의 항목당 하나의 할당은 순수한 오버헤드입니다.

필요할 때만 오버헤드를 지불하지만 구현이 불가능하고 결과 API가 좋지 않을 수 있는 솔루션을 보고 싶습니다.

이중형 API는 두 번째 두 가지 옵션의 부담을 줄이는 것을 목표로 하고 있지 않습니까? 이미 우선 순위가 포함된 유형이 있는 경우 새 PriorityQueue/Heap 생성은 어떻게 작동합니까? API는 어떻게 생겼나요?

좋은 점입니다. 소비자가 이미 값과 별도로 유지 관리되는 우선 순위 값(즉, 정수)을 갖고 있는 시나리오의 경우 원래 API에 간격이 있습니다. 그 반대면은API 스타일은 본질적으로 비교 가능한 모든 유형을 복잡하게 만듭니다. 몇 년 전에 내부 ScheduledTask 클래스가 있는 매우 가벼운 스케줄러 구성 요소를 작성했습니다. 각 ScheduledTask는 IComparer를 구현했습니다. 우선 순위 대기열에 던지십시오. 좋습니다.

정렬된 목록키/값 디자인을 사용하고 결과적으로 그것을 사용하지 않는 자신을 발견했습니다. 고유한 키가 필요하며 일반적인 요구 사항은 "목록에 정렬된 상태로 유지해야 하는 N개의 값이 있고 추가하는 가끔 값이 정렬된 상태로 유지되도록 해야 합니다"입니다. "키"는 해당 방정식의 일부가 아니며 목록은 사전이 아닙니다.

나에게 동일한 원칙이 대기열에 적용됩니다. 큐는 역사적으로 1차원 데이터 구조입니다.

내 현대 C++ std 라이브러리 지식은 약간 녹슬었지만 std::priority_queue조차도 푸시, 팝 및 비교자를 템플릿(일반) 매개변수로 사용하는 것으로 보입니다. C++ 표준 라이브러리 팀은 가능한 한 성능에 민감합니다. :)

방금 몇 가지 프로그래밍 언어로 우선순위 큐와 힙 구현을 매우 빠르게 스캔했습니다. C++, Java, Rust 및 Go는 모두 단일 유형으로 작동합니다(여기에 게시된 원래 API와 유사). NPM에서 가장 널리 사용되는 힙/우선순위 큐 구현을 얼핏 보아도 마찬가지입니다.

@pgolebiowski 는 특정 구현에 따라 명시적으로 명명된 특정 구현이 있어야 한다고 오해하지 않습니다.

그러나 이는 원하는 성능 목표와 일치하는 특정 데이터 구조가 무엇인지 알고 있고 수용할 수 있는 절충안이 있는 경우를 위한 것입니다.

일반적으로 프레임워크 컬렉션은 일반적인 동작을 원하는 용도의 90%를 다룹니다. 그런 다음 매우 구체적인 동작이나 구현을 원할 경우 타사 라이브러리로 이동합니다. 구현 이름을 따서 이름을 지정하면 필요에 맞는지 알 수 있습니다.

일반적인 동작 유형을 특정 구현에 묶고 싶지는 않습니다. 유형 이름이 동일하게 유지되어야 하고 일치하지 않기 때문에 구현이 변경되면 이상합니다.

논의가 필요한 많은 문제가 있지만 현재 우리가 동의하지 않는 부분에 가장 큰 영향을 미치는 문제부터 시작하겠습니다. 요소 업데이트 및 제거 .

그렇다면 이러한 작업을 어떻게 지원하시겠습니까? 우리는 그것들을 포함시켜야 합니다. 그것들은 기본입니다. 자바에서 디자이너들은 그것들을 생략했고 결과적으로:

1. 누락된 기능으로 인해 해결 방법을 수행하는 방법에 대한 포럼에 대한 질문이 많이 있습니다.
2. 자체 구현을 대체할 힙/우선 순위 대기열의 타사 구현이 있습니다. 왜냐하면 거의 쓸모가 없기 때문입니다.

이것은 단지 한심합니다. 정말 그런 길을 가고 싶은 사람이 있을까? 그런 비활성화된 데이터 구조를 공개하는 것이 부끄럽습니다.

@pgolebiowski 는 여기 있는 모든 사람들이 플랫폼에 대한 최선의 의도를 가지고 있다고 확신합니다. 아무도 깨진 API를 제공하고 싶어하지 않습니다. 우리는 다른 사람들의 실수로부터 배우고 싶기 때문에 그러한 유용한 관련 정보(예: 자바 이야기)를 계속 가져오세요.

그러나 몇 가지를 지적하고 싶습니다.

• 하룻밤 사이에 변화를 기대하지 마십시오. 이것은 디자인 토론입니다. 합의점을 찾아야 합니다. 우리는 API를 서두르지 않습니다. 모든 의견을 경청하고 고려해야 하지만 모든 사람의 의견이 실행/수용된다는 보장은 없습니다. 정보가 있으면 제공하고 데이터와 증거로 뒷받침하십시오. 또한 다른 사람의 주장을 듣고 인정하십시오. 당신이 동의하지 않는 경우 다른 사람의 의견에 반대하는 증거를 제공하십시오. 때로는 어떤 점에서 이견이 있다는 사실에 동의하십시오. SW, 다음을 포함합니다. API 디자인은 흑백/옳고 그름의 문제가 아닙니다.
• 토론을 시민으로 합시다. 강한 말과 말을 사용하지 맙시다. 은혜에 동의하지 않고 논의를 기술적으로 유지합시다. 누구나 기여자 행동 강령 을 참조할 수 있습니다. 우리는 .NET에 대한 열정을 인식하고 장려하지만 서로의 기분을 상하게 하지 않도록 합시다.
• 디자인 토론의 속도, 반응 등에 관한 우려/질문이 있으면 언제든지 저에게 직접 연락하십시오(제 이메일은 제 GH 프로필에 있습니다). 필요한 경우 공개적으로 또는 오프라인에서 기대, 가정 및 우려 사항을 명확히 하는 데 도움을 줄 수 있습니다.

방금 제안된 접근 방식이 마음에 들지 않으면 업데이트/제거를 어떻게 설계하고 싶으냐고 물었습니다... 이것은 다른 사람들의 의견을 듣고 합의를 찾는 것입니다.

나는 당신의 좋은 의도를 의심하지 않습니다! 때로는 질문하는 방법이 중요합니다. 사람들이 상대방의 텍스트를 인식하는 방식에 영향을 미칩니다. 텍스트는 감정이 없기 때문에 글로 적으면 다르게 이해할 수 있습니다. 제2외국어로서의 영어는 훨씬 더 혼란스럽고 우리 모두는 그것을 인식할 필요가 있습니다. 관심이 있는 경우 오프라인에서 세부 사항에 대해 채팅할 수 있어 기쁩니다... 여기에서 논의를 기술 토론으로 다시 돌리겠습니다...

Heap vs. PriorityQueue 논쟁에 대한 나의 2센트: 두 접근 방식 모두 유효하며 분명히 장점과 단점이 있습니다.

즉, "PriorityQueue"는 기존 .NET 접근 방식과 훨씬 더 일치하는 것 같습니다. 오늘의 핵심 컬렉션은 List입니다., 사전, 스택, 대기 줄, 해시셋, SortedDictionary, 및 SortedSet. 이것들은 알고리즘이 아니라 기능과 의미를 따서 명명되었습니다. 해시셋유일한 이상값이지만 이것조차도 집합 평등 의미론(SortedSet과 비교하여)과 관련하여 합리화될 수 있습니다.). 결국 이제 ImmutableHashSet이 있습니다.이것은 후드 아래의 나무를 기반으로 합니다.

하나의 컬렉션이 여기에서 추세를 거스르는 것은 이상하게 느껴질 것입니다.

추가 생성자가 있는 PriorityQueue 생각: PriorityQueue(아이힙)가 해결책이 될 수 있습니다. IHeap 매개변수가 없는 생성자는 기본 힙을 사용할 수 있습니다.
이 경우 PrioriryQueue(대부분의 C# 컬렉션으로) 추상 데이터 유형을 나타내고 IpriorityQueue를 구현합니다.인터페이스이지만 @pgolebiowski가 제안한 것과 같은 다른 힙 구현을 사용할 수 있습니다.

클래스 ArrayHeap : IHeap {}
클래스 PairingHeap : IHeap {}
클래스 피보나치 힙: IHeap {}
클래스 BinomialHeap : IHeap {}

좋아요. 다양한 목소리가 있습니다. 나는 다시 토론을 통해 접근 방식을 수정했습니다. 또한 일반적인 문제를 해결합니다. 아래 텍스트는 위의 게시물에서 인용한 내용을 사용합니다.

우리의 목표

이 전체 토론의 궁극적인 목표는 사용자를 행복하게 만드는 특정 기능 세트를 제공하는 것입니다. 사용자에게 많은 요소가 있고 그 중 일부는 다른 요소보다 우선 순위가 더 높은 경우가 많습니다. 결국, 그들은 다음 작업을 효율적으로 수행할 수 있도록 이 요소 묶음을 특정 순서로 유지하기를 원합니다.

• 우선 순위가 가장 높은 요소를 검색하고 제거할 수 있습니다.
• 컬렉션에 새 요소를 추가합니다.
• 컬렉션에서 요소를 제거합니다.
• 컬렉션의 요소를 수정합니다.
• 두 컬렉션을 병합합니다.

기타 표준 라이브러리

다른 표준 라이브러리의 작성자도 이 기능을 지원하려고 했습니다. 이 섹션에서는 Python , Java , C++ , Go , Swift 및 Rust 에서 해결된 방법을 참조합니다.

컬렉션에 이미 삽입된 요소 수정을 지원 하지 않습니다 . 컬렉션의 수명 동안 해당 요소의 우선 순위가 변경될 가능성이 매우 높기 때문에 매우 놀라운 일입니다. 특히 그러한 컬렉션이 서비스의 전체 수명 동안 사용되도록 의도된 경우. 요소를 업데이트하는 바로 이 기능을 활용하는 알고리즘도 많이 있습니다. 따라서 이러한 설계는 단순히 잘못된 것 입니다. 결과적으로 고객이 손실되기 때문입니다.

주목할 가치가 있는 또 다른 점은 모든 단일 라이브러리가 바이너리 힙 구현을 통해 이러한 부분적인 기능을 제공한다는 것입니다. 글쎄, 그것은 일반적인 경우(무작위 입력)에서 가장 성능이 좋은 구현이 아닌 것으로 나타 났습니다. 일반적인 경우에 가장 적합한 것은 4차 힙 (배열로 저장된 암시적 힙 순서의 완전한 4항 트리)입니다. 훨씬 덜 알려져 있으며 이것이 아마도 디자이너가 대신 바이너리 힙을 사용하는 이유일 것입니다. 그러나 여전히 - 덜 심각하지만 또 다른 잘못된 선택입니다.

그로부터 무엇을 배울 수 있습니까?

• 고객이 만족하고 우리의 멋진 데이터 구조를 무시하면서 이 기능을 스스로 구현하지 못하도록 하려면 컬렉션에 이미 삽입된 요소를 수정하는 지원을 제공해야 합니다.
• 일부 기능이 일부 표준 라이브러리에서 어떤 식으로든 전달되었기 때문에 동일한 작업을 수행해야 한다고 가정해서는 안

제안된 접근 방식

저는 우리가 다음을 제공해야 한다고 강력하게 생각합니다.

• IHeap<T> 인터페이스
• Heap<T> 클래스

IHeap 인터페이스에는 이 게시물의 시작 부분에서 설명한 모든 작업을 수행하기 위한 메서드가 분명히 포함되어 있습니다. 4차 힙으로 구현된 Heap 클래스는 98%의 경우에 적합한 솔루션입니다. 요소의 순서는 생성자에 전달된 IComparer<T> 또는 유형이 이미 비교 가능한 경우 기본 순서를 기반으로 합니다.

정당화

• 개발자는 인터페이스에 대해 논리를 작성할 수 있습니다. 나는 그것이 얼마나 중요한지 모두가 알고 있다고 가정하고 자세히 설명하지 않을 것입니다. 읽기: 종속성 역전 원리 , 종속성 주입 , 계약에 따른 설계 , 제어 역전 .
• 개발자는 다른 힙 구현을 제공하여 사용자 정의 요구 사항을 충족하도록 이 기능을 확장할 수 있습니다. 이러한 구현은 PowerCollections 와 같은 타사 라이브러리에 포함될 수 있습니다. 이러한 라이브러리를 참조하기 IHeap 하면 페어링 힙 , 이항 힙, 그리고 우리의 사랑하는 바이너리 힙.
• 개발자가 어떤 유형이 가장 좋은지 생각할 필요 없이 작업을 완료하는 도구가 필요한 경우 범용 Heap 구현을 사용하면 됩니다. 이것은 사용 사례의 98%에 최적화되어 있습니다.
• 우리는 대부분의 사용 사례에 유용한 매우 적절한 성능 특성을 가진 단일 선택을 제공하는 것과 관련하여 .NET 에코시스템의 큰 가치를 추가하는 동시에 이를 필요로 하고 발굴할 의향이 있는 사람들을 위한 고성능 확장을 허용합니다. 더 깊이 배우고 더 많은 것을 배우십시오 / 교육받은 선택과 절충안을 만드십시오.
• 제안된 접근 방식은 현재 규칙을 반영합니다.
  
  
  
  • ISet 및 HashSet
  
  
  • IList 및 List
  
  
  • IDictionary 및 Dictionary
  
  
• 어떤 사람들은 인스턴스가 수행하는 방식이 아니라 인스턴스가 수행하는 작업에 따라 클래스 이름을 지정해야 한다고 말했습니다. 이것은 완전히 사실이 아닙니다. 우리가 클래스의 행동에 따라 이름을 지정해야 한다고 말하는 것은 일반적인 지름길입니다. 실제로 많은 경우에 적용됩니다. 그러나 이것이 적절한 접근 방식이 아닌 경우가 있습니다. 가장 주목할만한 예는 기본 유형, 열거 유형 또는 데이터 구조와 같은 기본 빌딩 블록입니다. 원칙은 단순히 의미 있는 이름을 선택하는 것입니다(즉, 사용자에게 모호하지 않음). 우리가 논의하고 있는 기능은 Python, Java, C++, Go, Swift 또는 Rust와 같이 항상 힙으로 제공된다는 사실을 고려하십시오. 힙은 가장 기본적인 데이터 구조 중 하나입니다. Heap 는 실제로 명확하고 명확합니다. Stack , Queue , List 및 Array 와도 조화를 이룹니다. 가장 현대적인 표준 라이브러리(Go, Swift, Rust)에서도 이름 지정과 동일한 접근 방식이 사용되었습니다. 이들은 명시적으로 힙을 노출합니다.

@pgolebiowski Heap<T> / IHeap<T> 이름이 Stack<T> , Queue<T> 및/또는 List<T> 않습니까? 이러한 이름 중 어느 것도 내부적으로 구현되는 방식을 설명하지 않습니다(발생하는 T 배열).

@SamuelEnglard

Heap 내부적으로 구현되는 방법도 말하지 않습니다. 왜 그렇게 많은 사람들 에게 힙 이 특정 구현을 즉시 따르는지 이해하지 못합니다. 먼저 동일한 API를 공유하는 힙의 변형이 많이 있습니다.

• d-ary 힙,
• 2-3 힙,
• 좌파 더미,
• 부드러운 힙,
• 약한 더미,
• B-힙,
• 기수 힙,
• 비뚤어진 더미,
• 페어링 힙,
• 피보나치 힙,
• 이항 힙,
• 순위 페어링 힙,
• 지진 더미,
• 위반 더미.

우리가 힙을 다루고 있다고 말하는 것은 여전히 ​​매우 추상적입니다. 사실, 우리가 4차 힙을 다루고 있다고 말하는 것은 추상적입니다. T 배열을 기반으로 하는 암시적 데이터 구조로 구현될 수도 있습니다(예 Stack<T> , Queue<T> 및 List<T> ) 또는 명시적(노드 및 포인터 사용).

간단히 말해서 Heap<T> 는 Stack<T> , Queue<T> 및 List<T> 와 매우 유사합니다. 이는 기본 데이터 구조, 기본 추상 빌딩 블록이기 때문에 여러 가지 방법으로 구현할 수 있습니다. 또한, 발생하는 대로 모두 아래에 T 배열을 사용하여 구현됩니다. 저는 이 유사성이 정말 강하다고 생각합니다.

말이 돼?

참고로 저는 네이밍에 무관심합니다. C++ 표준 라이브러리 사용에 익숙한 사람들은 아마도 _priority_queue_를 선호할 것입니다. 데이터 구조에 대해 교육을 받은 사람들은 _Heap_을 선호할 수 있습니다. 투표를 해야 한다면 _heap_을 선택할 것입니다. 비록 그것이 저에게는 동전 던지기에 가깝지만 말입니다.

@pgolebiowski 내 질문을 잘못 표현했습니다. 그건 내 잘못입니다. 예, Heap<T> 는 내부적으로 구현되는 방법을 말하지 않습니다.

예 힙은 유효한 데이터 구조이지만 힙 != 우선 순위 큐입니다. 둘 다 서로 다른 API 표면을 노출하고 서로 다른 아이디어에 사용됩니다. Heap<T> / IHeap<T> 는 (이론적인 이름만) PriorityQueue<T> / IPriorityQueue<T> 내부적으로 사용되는 데이터 유형이어야 합니다.

@SamuelEnglard
컴퓨터 과학의 세계가 어떻게 구성되어 있는지에 관해서는 그렇습니다. 다음은 추상화 수준입니다.

• 구현 : 배열을 기반으로 하는 암시적 4차 힙
• 추상화 : 4차 힙
• 추상화 : 힙 패밀리
• 추상화 : 우선순위 큐의 계열

그리고 예, 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 인터페이스를 위한 공간 없이 우선순위 큐를 4차 힙의 특정 구현으로 수정하는 한 가지 솔루션이 남아 있습니다. 나는 그것이 너무 많은 추상화 수준을 통과하고 인터페이스를 갖는 모든 놀라운 이점을 죽인다고 생각합니다.

우리는 토론의 중간에서 디자인 선택으로 돌아왔습니다 -- PriorityQueue 및 IPriorityQueue 있습니다. 그러나 기본적으로 다음을 수행합니다.

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

보기 흉할 뿐만 아니라 개념적으로도 잘못된 것 같습니다. 이는 우선 순위 대기열 유형이 아니며 동일한 API를 공유하지 않습니다(

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

그리고 우리가 제공한 class Heap : IHeap {} .

BTW, 누군가는 다음이 도움이 될 수 있습니다.

| 구글 쿼리 | 결과 |
| :----------------------------------------------------: | ::----: |
| "데이터 구조" "우선순위 큐" | 172,000 |
| "데이터 구조" "힙" | 430,000 |
| "데이터 구조" "대기열" -"우선순위 대기열" | 496,000 |
| "데이터 구조" "대기열" | 530,000 |
| "데이터 구조" "스택" | 577,000 |

@pgolebiowski 여기에서 왔다 갔다 하는 것 같아서 인정합니다.

@karelz @safern 위의 내용에 대해 어떻게 생각하십니까? 특정 API 제안을 제시할 수 있도록 IHeap + Heap 접근 방식을 수정할 수 있습니까?

여기에 인터페이스가 필요한지 궁금합니다( IHeap 또는 IPriorityQueue ). 예, 이론적으로 이 데이터 구조를 구현하는 데 사용할 수 있는 다양한 알고리즘이 있습니다. 그러나 프레임워크가 둘 이상과 함께 제공될 것 같지는 않으며 라이브러리 작성자가 여러 당사자가 상호 호환 가능한 힙 구현을 작성하는 데 조정할 수 있도록 정식 인터페이스가 실제로 필요하다는 생각은 그럴 가능성이 없어 보입니다.

또한 인터페이스가 출시되면 호환성으로 인해 절대 변경할 수 없습니다. 이는 인터페이스가 기능 측면에서 구체적인 클래스보다 뒤처지는 경향이 있음을 의미합니다(오늘날 IList 및 IDictionary의 문제). 반대로 Heap 클래스가 출시되고 IHeap 인터페이스에 대한 심각한 요구가 있었다면 문제 없이 인터페이스를 라인에 추가할 수 있었다고 생각합니다.

@madelson 프레임워크가 힙의 단일 구현 이상을 제공할 필요가 없다는 데 동의합니다. 그러나 인터페이스로 해당 구현을 지원함으로써 다른 구현에 관심이 있는 우리는 다른 구현(자체 생성 또는 외부 라이브러리에서)으로 쉽게 교체할 수 있으며 인터페이스를 허용하는 코드와 여전히 호환될 수 있습니다.

인터페이스 코딩에 대한 부정적인 점은 실제로 보지 못했습니다. 신경쓰지 않는 사람은 무시하고 바로 구체적인 구현을 하면 된다. 돌보는 사람들은 자신이 선택한 모든 구현을 사용할 수 있습니다. 선택입니다. 그리고 제가 원하는 선택입니다.

@pgolebiowski가 물었더니 제 개인적인 의견이 있습니다(몇몇 의견을 확인한 후 다른 API 검토자/건축가가 이를 공유할 것이라고 어느 정도 확신합니다).
이름은 PriorityQueue 이어야 하며 IHeap 인터페이스를 도입해서는 안 됩니다. 정확히 하나의 구현이 있어야 합니다(일부 힙을 통해).
IHeap 인터페이스는 매우 고급 전문가 시나리오입니다. PowerCollections 라이브러리(최종 생성 예정) 또는 다른 라이브러리로 옮기는 것이 좋습니다.
라이브러리와 IHeap 인터페이스가 정말 유명해지면 나중에 마음을 바꿔 수요에 따라 IHeap 를 추가할 수 있지만(생성자 오버로드를 통해) 유용/정렬되지는 않습니다. BCL의 나머지 부분은 지금 새 인터페이스를 추가하는 복잡성을 정당화하기에 충분합니다. 단순하게 시작하여 정말로 필요한 경우에만 복잡하게 확장하십시오.
... 내 2(개인) 센트

의견의 차이를 감안할 때 제안을 진전시키기 위해 다음과 같은 접근 방식을 제안합니다(이번 주 초에 @ianhays에 제안했고 따라서 간접적으로 @safern에 제안했습니다).

• 2개의 대안 제안을 만드십시오. 하나는 위에서 설명한 대로 간단하고 다른 하나는 제안한 대로 힙이 포함된 것입니다. API 검토에 가져오고 거기에서 토론하고 결정을 내리도록 하겠습니다.
• 해당 그룹에서 Heaps 제안에 투표하는 사람이 한 명이라도 있다면 기꺼이 제 관점을 재고하겠습니다.

... 내 의견(귀하가 요청한)에 대해 완전히 투명하려고 노력하고 있습니다. 낙담하거나 미루지 마십시오. API 제안이 어떻게 진행되는지 봅시다.

@karelz

이름은 PriorityQueue 여야 합니다.

어떤 주장? 그냥 아니오 라고 말하는 대신 위에 내가 쓴 것을 해결해 주시면 적어도 좋을 것입니다 .

이전에 이름을 꽤 잘 지었다고 생각합니다. _입력이 있으면 제공하고 데이터와 증거로 뒷받침하십시오. 또한 다른 사람의 주장을 듣고 인정하십시오. 당신이 동의하지 않는 경우 다른 사람의 의견에 반대하는 증거를 제공하십시오._

게다가, 그것은 단지 이름에 관한 것이 아닙니다 . 그렇게 얕지 않습니다. 제가 쓴 글을 읽어주세요. 추상화 수준 사이에서 작업하고 그 위에 코드를 향상/구축할 수 있는 것입니다.

아, 이 토론에서 논쟁이 있었던 이유는 다음과 같습니다.

힙을 사용하면 많은 중급 개발자가 (슬프게도) "힙"을 보고 "일반화된 데이터 구조 힙" 대신 애플리케이션의 메모리 힙(예: 힙 및 스택)으로 혼동할 것입니다. [...] 그들은 왜 새로운 메모리 힙을 할당할 수 있는지 궁금해 할 것입니다.

😛

우리는 IHeap 인터페이스를 도입해서는 안됩니다. IHeap 인터페이스는 매우 고급 전문가 시나리오입니다. PowerCollections 라이브러리로 옮기는 것이 좋습니다.

@bendono 가 이에 대해 아주 좋은 댓글을 작성했습니다. @safern 은 또한 인터페이스로 구현을 지원하기를 원했습니다. 그리고 몇 가지 더.

또 다른 참고 사항 -- 인터페이스를 타사 라이브러리로 이동하는 것을 상상할 수 있는지 잘 모르겠습니다. 어떻게 개발자는 아마도 그 인터페이스에 대한 자신의 코드를 작성하고 우리의 기능을 사용할 수 있을까? 그들은 우리의 비 인터페이스 기능을 고수하거나 완전히 무시해야 할 것입니다. 다른 옵션은 없으며 상호 배타적입니다. 다시 말해, 우리 솔루션은 전혀 확장할 수 없어 사람들 이 두 경우 모두 동일한 아키텍처 코어에 의존하는 대신 비활성화된 솔루션이나 일부 타사 라이브러리를 사용하게 됩니다. 이것이 Java의 표준 라이브러리와 타사 솔루션에 있는 것입니다.

그러나 다시, 당신은 이것에 대해 훌륭하게 언급했습니다. 아무도 깨진 API를 제공하고 싶어하지 않습니다.

의견의 차이를 고려하여 제안을 진행하기 위해 다음과 같은 접근 방식을 제안합니다. [...] 2개의 대안을 제안합니다 [...] API 검토에 가져오고 거기에서 논의하고 결정을 내리자. 해당 그룹에서 Heaps 제안에 투표하는 사람이 한 명이라도 있다면 기꺼이 제 관점을 재고하겠습니다.

위에서 API의 다양한 부분에 대해 많은 논의가 있었습니다. 다음과 같은 문제를 해결했습니다.

• PriorityQueue 대 Heap
• 인터페이스 추가
• 컬렉션에서 요소 업데이트/제거 지원

당신이 생각하는 사람들 이 이 토론에 참여할 수 없는 이유는 무엇입니까? 왜 다시 시작해야 합니까?

힙을 사용하면 많은 중급 개발자가 (슬프게도) "힙"을 보고 "일반화된 데이터 구조 힙" 대신 애플리케이션의 메모리 힙(예: 힙 및 스택)으로 혼동할 것입니다.

그래, 나야. 저는 프로그래밍을 독학으로 배웠기 때문에 " Heap "이(가) 토론에 들어갔을 때 무슨 말을 했는지 모릅니다. 말할 것도 없이 컬렉션의 관점에서 "사물 더미"가 모든 방식으로 정렬되지 않은 것을 더 직관적으로 암시할 것입니다.

정말 이런 일이 일어나고 있다는게 믿기지 않습니다...

어떤 주장? 그냥 아니오라고 말하는 대신 위에 내가 쓴 것을 해결했다면 적어도 좋을 것입니다.

내 대답을 읽으면 내 입장에 대한 주요 주장을 언급했음을 알 수 있습니다.

• IHeap 인터페이스는 매우 고급 전문가 시나리오입니다.
• 지금 새 인터페이스를 추가하는 복잡성을 정당화할 만큼 BCL의 나머지 부분과 유용/정렬되지 않는다고 생각합니다.

스레드에서 IMO에 여러 번 반복된 동일한 인수입니다. 나는 그것들을 요약했을 뿐이다.

. 제가 쓴 글을 읽어주세요.

이 스레드를 항상 적극적으로 모니터링했습니다. 나는 모든 주장과 요점을 읽었습니다. 이것은 귀하와 다른 사람들의 모든 요점을 읽고 이해했음에도 불구하고 요약된 의견입니다.
당신은 분명히 그 주제에 대해 열정적입니다. 그거 좋다. 그러나 나는 우리가 양쪽에서 비슷한 주장을 반복할 때 입장이 된 것 같은 느낌이 듭니다. 그러면 더 이상 진행되지 않을 것입니다. 그래서 제가 2개의 제안을 추천하고 더 큰 경험 그룹에서 더 많은 피드백을 받는 이유입니다. BCL API 리뷰어(BTW: 저는 아직 경험이 풍부한 API 리뷰어라고 생각하지 않습니다).

개발자가 어떻게 해당 인터페이스에 대해 코드를 작성하고 우리의 기능을 사용할 수 있습니까?

IHeap 고급 시나리오에 관심이 있는 개발자는 타사 라이브러리의 인터페이스와 구현을 참조합니다. 내가 말했듯이, 인기가 있는 것으로 판명되면 나중에 CoreFX로 옮기는 것을 고려할 수 있습니다.
좋은 소식은 IHeap 나중에 추가하는 것이 완전히 가능하다는 것입니다. 기본적으로 PriorityQueue 에 하나의 생성자 오버로드만 추가합니다.
네, 귀하의 관점에서 이상적이지는 않지만, 귀하가 미래에 중요하다고 생각하는 혁신을 방해하지는 않습니다. 합리적인 중도라고 생각합니다.

당신이 생각하는 사람들이 이 토론에 참여할 수 없는 이유는 무엇입니까?

API 검토는 활발한 토론, 브레인스토밍, 모든 각도의 가중치 부여가 있는 회의입니다. 많은 경우 GitHub 문제에 대해 앞뒤로 논의하는 것보다 더 생산적/효율적입니다. dotnet/corefx#14354 및 그 이전 버전인 dotnet/corefx#8034를 참조하세요. 너무 긴 토론, 추적하기 어려운 엄청난 조정에 대한 여러 다른 의견, 결론이 없습니다. 훌륭한 토론, 또한 꽤 많은 사람들의 사소하지 않은 낭비 시간, 우리가 앉아서 그것에 대해 이야기하고 합의에 이를 때까지.
API 검토자가 모든 단일 API 문제를 모니터링하도록 하거나 수다스러운 문제만 모니터링하는 것은 잘 확장되지 않습니다.

왜 다시 시작해야 합니까?

우리는 다시 시작하지 않을 것입니다. 왜 그렇게 생각할까요?
다음 API 리뷰 레벨로 가장 인기 있는 2개 제안을 찬반 양론으로 보내 첫 번째 레벨(영역 소유자 레벨)에서 API 검토를 완료합니다.
계층적 승인/검토 방식입니다. 비즈니스 검토와 유사합니다. 의사 결정 권한이 있는 VP/CEO는 회사의 모든 프로젝트에 대한 모든 토론을 감독하지 않으며 팀/보고서에 가장 영향력 있고 전염성이 있는 결정에 대한 제안을 가져와 추가 토론을 하도록 요청합니다. 팀/보고서는 문제를 요약하고 대안 솔루션의 장단점을 제시해야 합니다.

아직 이 스레드에서 언급되지 않은 사항이 있기 때문에 장단점이 있는 최종 2개의 제안을 제시할 준비가 되지 않았다고 생각하신다면 다음 시간에 검토할 최고 후보자가 몇 명 남을 때까지 계속 논의합시다. API 검토 수준.
내가 말해야 할 모든 것을 말했다는 느낌을 받았습니다.
맞는 말이다?

이름은 PriorityQueue 여야 합니다.

어떤 주장?

내 대답을 읽으면 내 입장에 대한 핵심 주장을 언급했음을 알 수 있습니다.

이런... 내가 인용한 것을 언급하고 있었습니다. ( 분명히 ) -- 당신은 힙 대신 우선순위 큐를 사용하기로 결정했습니다. 그리고 예, 귀하의 답변을 읽었습니다. 여기에는 이에 대한 주장의 정확히 0%가 포함되어 있습니다.

이 스레드를 항상 적극적으로 모니터링했습니다. 나는 모든 주장과 요점을 읽었습니다. 이것은 귀하와 다른 사람들의 모든 요점을 읽고 이해했음에도 불구하고 요약된 의견입니다.

당신은 쌍곡선을 좋아합니다, 나는 전에 그것을 알아차렸습니다. 당신은 단지 포인트의 존재를 인정합니다.

개발자가 어떻게 해당 인터페이스에 대해 코드를 작성하고 우리의 기능을 사용할 수 있습니까?

IHeap 고급 시나리오에 관심이 있는 개발자는 타사 라이브러리의 인터페이스와 구현을 참조합니다. 내가 말했듯이, 인기가 있는 것으로 판명되면 나중에 CoreFX로 옮기는 것을 고려할 수 있습니다.

당신은 당신이 위의 결과 로 내가 제시한 문제를 전혀 다루지 않고 여기서 내 말을 반복한다는 것을 알고 있습니까? 나는 썼다:

그들은 우리의 비 인터페이스 기능을 고수하거나 완전히 무시해야 할 것입니다. 다른 옵션은 없으며 상호 배타적입니다.

나는 당신을 위해 이것을 매우 명확하게 할 것입니다. 두 개의 분리된 그룹의 사람들이 있을 것입니다.

1. 우리의 기능을 사용하는 하나의 그룹입니다. 인터페이스가 없고 확장할 수 없으므로 타사 라이브러리에서 제공하는 것과 연결되지 않습니다.
2. 우리의 기능을 완전히 무시하고 순전히 타사 솔루션을 사용하는 두 번째 그룹입니다.

여기서 문제는 내가 말했듯이, 그것들이 분리된 사람들의 그룹이라는 것 입니다. 그리고 그들은 공통 아키텍처 코어가 없기 때문에 코드베이스가 호환되지 않습니다 _. 나중에 취소할 수 없습니다.

좋은 소식은 나중에 IHeap을 추가하는 것이 완전히 가능하다는 것입니다. 기본적으로 PriorityQueue에 하나의 생성자 오버로드만 추가합니다.

나는 그것이 왜 짜증나는지 이미 썼습니다: 이 포스트를 보세요.

당신이 생각하는 사람들이 이 토론에 참여할 수 없는 이유는 무엇입니까?

API 검토자가 모든 단일 API 문제를 모니터링하도록 하거나 수다스러운 문제만 모니터링하는 것은 잘 확장되지 않습니다.

예, API 검토자가 모든 단일 API 문제를 모니터링할 수 없는 이유를 묻고 있었습니다. 정확하게, 당신은 실제로 그에 따라 응답했습니다.

맞는 말이다?

아니요. 저는 이 토론이 정말 지겹습니다. 여러분 중 일부는 그것이 여러분의 일이고 여러분이 지시를 받았기 때문에 분명히 참여하고 있습니다. 여러분 중 일부는 항상 안내가 필요합니다. 이는 매우 피곤합니다. 당신은 나에게 왜 우선순위 대기열이 내부적으로 힙으로 구현되어야 하는지, 분명히 컴퓨터 과학 배경 지식이 부족하다는 것을 증명해달라고 요청했습니다. 여러분 중 일부는 힙이 실제로 무엇인지조차 이해하지 못하여 토론을 더욱 혼란스럽게 만듭니다.

요소 업데이트 및 제거를 허용하지 않는 비활성화된 PriorityQueue를 사용하십시오. 건전한 OO 접근을 허용하지 않는 디자인을 사용하십시오. 확장을 작성할 때 표준 라이브러리의 재사용을 허용하지 않는 솔루션을 사용하십시오. 자바 방식으로 이동합니다.

그리고 이것은... 정말 놀랍습니다.

힙을 사용하면 많은 중급 개발자가 (슬프게도) "힙"을 보고 "일반화된 데이터 구조 힙" 대신 애플리케이션의 메모리 힙(예: 힙 및 스택)으로 혼동할 것입니다.

귀하의 접근 방식으로 API를 제시하십시오. 궁금해.

정말 이런 일이 일어나고 있다는게 믿기지 않습니다...

글쎄요, Heap 가 메모리 힙과 다른 일종의 데이터 구조라는 것을 배우기 위해 적절한 컴퓨터 과학 교육을 받을 기회가 없었던 것에 대해 실례합니다.

그러나 요점은 여전히 ​​유효합니다. 무언가의 힙은 어떤 종류의 주문에 대해 아무 것도 의미 Heap 라는 것을 검색하지 않을 것입니다. 반면에 PriorityQueue 는 정확히 그렇게 하고 있음을 완벽하게 전달합니다.

지원 구현으로? 물론 구현 세부 사항은 내 관심사가 아닙니다.
IHeap 추상화? API의 저자와 그것을 사용 있는지 알아야 할 CS 주요 있나요 명에 대 한 좋은 이유가 없습니다 없습니다.
의도를 잘 나타내지 않고 검색 가능성을 제한하는 비밀스러운 이름을 지정하시겠습니까? 👎

글쎄, 힙이 메모리 힙과 다른 일종의 데이터 구조라는 것을 배우기 위해 적절한 컴퓨터 과학 교육을 받을 기회가 없었던 것에 대해 실례합니다.

이건 말도 안돼. 동시에 그러한 기능을 추가하는 것과 관련된 토론에 참여하고 싶습니다. 마치 트롤링처럼 들립니다.

무언가의 힙은 어떤 종류의 주문에 대해 아무 것도 의미하지 않습니다.

당신은 잘못. 힙으로 주문됩니다. 당신이 링크 한 사진에서처럼.

지원 구현으로? 물론 구현 세부 사항은 내 관심사가 아닙니다.

나는 이미 그것에 대해 언급했습니다. 힙 패밀리는 거대하며 구현 위에 두 가지 수준의 추상화가 있습니다. 우선순위 큐는 세 번째 추상화 계층입니다.

나중에 들어오는 일부 인스턴스가 더 빨리 처리되어야 하는 처리할 개체를 저장할 수 있는 컬렉션이 필요한 경우 힙이라고 하는 것을 검색하지 않을 것입니다. 반면에 PriorityQueue는 정확히 그렇게 하고 있음을 완벽하게 전달합니다.

그리고 배경 없이 우선 순위 대기열에 대한 기사를 제공하도록 Google에 요청하시겠습니까? 글쎄, 우리는 우리의 의견에서 어느 정도 가능성이 있는지 논쟁할 수 있습니다. 그러나 매우 훌륭하게 말했듯이 :

정보가 있으면 제공하고 데이터와 증거로 뒷받침하십시오. 당신이 동의하지 않는 경우 다른 사람의 의견에 반대하는 증거를 제공하십시오.

그리고 데이터에 따르면 당신은 틀렸습니다.

쿼리 | 조회수
:----: |:----:|
| "데이터 구조" "우선순위 큐" | 172,000 |
| "데이터 구조" "힙" | 430,000 |

데이터 구조에 대해 읽는 동안 힙을 접할 가능성이 거의 3배 더 높습니다. 또한 표준 라이브러리에서 이러한 데이터 구조를 제공하기 때문에 Swift, Go, Rust 및 Python 개발자에게 친숙한 이름입니다.

쿼리 | 조회수
:----: |:----:|
| "golang" "우선순위 큐" | 3.390 |
| "녹" "우선순위 큐" | 8.630 |
| "신속한" "우선 순위 큐" | 18:600 |
| "파이썬" "우선순위 큐" | 72.800 |
| "골랑" "힙" | 79.000 |
| "녹" "힙" | 492.000 |
| "신속한" "힙" | 551.000 |
| "파이썬" "힙" | 555.000 |

실제로 힙 데이터 구조가 이전 세기에 도입되었기 때문에 C++에서도 유사합니다.

의도를 잘 나타내지 않고 검색 가능성을 제한하는 비밀스러운 이름을 지정하시겠습니까? 👎

의견이 없습니다. 데이터. 위 참조. 특히 배경이 없는 사람의 의견은 없습니다. 이전에 데이터 구조에 대해 읽지 않고는 우선 순위 대기열을 검색하지 않을 것입니다. 그리고 힙은 많은 데이터 구조 101 에서 다루어집니다.

컴퓨터 과학의 기초입니다. 초급입니다. 여러 학기의 알고리즘과 데이터 구조가 있는 경우 처음에 힙이 보입니다.

하지만 여전히:

• 먼저 -- 위의 숫자를 보십시오.
• 두 번째 -- 힙이 표준 라이브러리의 일부인 다른 모든 언어에 대해 생각해 보십시오.

편집: Google 트렌드를 참조하십시오.

또 다른 독학 개발자로서 저는 _heap_에 문제가 없습니다. 항상 개선하기 위해 노력하는 개발자로서 데이터 구조에 대한 모든 것을 배우고 이해하는 시간을 가졌습니다. 요컨대, 나는 명명 규칙이 자신이 속한 분야의 사전을 이해하는 데 시간을 들이지 않은 사람들을 대상으로 해야 한다는 의미에 동의하지 않습니다.

또한 "이름 은 PriorityQueue

API 이름 지정에 대해 어떻게 생각하는지 설명하겠습니다.

1. 우리는 거의 모든 것보다 .NET 플랫폼 내에서 일관성을 선호하는 경향이 있습니다. 이는 API가 친숙하고 예측 가능하게 보이도록 하는 데 중요합니다. 때때로 이것은 우리가 전에 사용한 용어라면 그 이름이 100% 정확하지 않다는 것을 인정한다는 의미입니다.

2. 우리의 목표는 다양한 개발자가 접근할 수 있는 플랫폼을 설계하는 것입니다. 이들 중 일부는 컴퓨터 과학에 대한 정식 교육을 받지 않았습니다. 우리는 .NET이 일반적으로 매우 생산적이고 사용하기 쉬운 것으로 인식되는 이유 중 일부는 부분적으로는 해당 디자인 포인트 때문이라고 믿습니다.

우리는 일반적으로 이름이나 용어가 얼마나 잘 알려져 있고 확립되어 있는지 확인할 때 "검색 엔진 테스트"를 사용합니다. @pgolebiowski 가 수행한 연구에 감사드립니다. 나는 직접 조사를 해보지는 않았지만 내 직감에 따르면 "힙"은 도메인이 아닌 많은 전문가들이 찾는 용어가 아닙니다.

따라서 PriorityQueue 가 더 나은 선택으로 @karelz의 의견에 동의하는 경향이 있습니다. 기존 개념(대기열)을 결합하고 원하는 기능을 표현하는 비틀기를 추가합니다. 그러나 우리는 그 이름에 흔들리지 않고 집착하지 않습니다. 우리는 종종 고객 피드백을 기반으로 데이터 구조 및 기술의 이름을 변경했습니다.

그러나 다음과 같이 지적하고 싶습니다.

사람들의 의견을 듣고 싶지 않다면 그것을 오픈 소스로 만들거나 요구하지 마십시오.

잘못된 이분법이다. 우리가 생태계와 기여자들로부터 피드백을 원하지 않는다는 것은 아닙니다(당연히 그렇게 합니다). 그러나 동시에 우리는 고객 기반이 매우 다양하고 GitHub 기여자(또는 우리 팀의 개발자)가 항상 모든 고객을 위한 최고의 대리자가 아니라는 점을 인식해야 합니다. 사용성은 어렵고 특히 컬렉션과 같이 인기 있는 영역에서 .NET에 새로운 개념을 추가하려면 약간의 반복이 필요할 것입니다.

@pgolebiowski :

귀하의 통찰력, 데이터 및 제안을 높이 평가합니다. 그러나 나는 당신의 논증 스타일에 절대 감사하지 않습니다. 이 스레드의 커뮤니티 구성원뿐만 아니라 내 팀 구성원 모두에게 개인적으로 대했습니다. 당신이 우리와 동의하지 않는다고 해서 그것이 "그냥 우리의 일"이기 때문에 전문 지식이 없거나 관심이 없다고 비난할 수 있는 것은 아닙니다. 우리 중 많은 사람들이 문자 그대로, 전 세계 이동 우리가이 일을하고 싶어 때문 뒤 가족과 친구를 떠난 것을 고려하십시오. 귀하와 같은 의견은 매우 불공평할 뿐만 아니라 디자인을 발전시키는 데에도 도움이 되지 않습니다.

그래서 제가 피부가 두꺼운 편이라고 생각하고 싶지만 그런 행동은 별로 용납하지 않습니다. 우리 도메인은 이미 충분히 복잡합니다. 우리는 대립 및 적대적 의사 소통을 추가할 필요가 없습니다.

예의를 지켜주세요. 열정적으로 아이디어를 비판하는 것은 공정한 게임이지만 사람들을 공격하는 것은 그렇지 않습니다. 감사합니다.

마음이 아프신 모든 분들,

저의 가혹한 태도로 여러분의 행복지수를 낮추게 된 점 사과드립니다.

@karelz

기술적인 실수를 저질러서 스스로를 바보로 만들었습니다. 나는 사과했다. 받아들여졌다. 그러나 나중에 나에게 던졌다. 멋진 IMO가 아닙니다.

제가 쓴 글이 당신을 불쾌하게 해서 죄송합니다. 당신이 묘사한 것처럼 그렇게 나쁘지 는 않았지만 -- 나는 단지 피로감을 느끼게 하는 많은 요인 중 하나로 이것을 제공했을 뿐입니다. 덜 심각하다고 생각합니다. 하지만 그래도 미안합니다.

그리고 그렇습니다. 누구나 실수를 합니다. 괜찮아요. 나도, 예를 들어 때때로 도취되어.

나를 가장 사로잡은 것은 "당신은 이것을 하라는 말을 들었을 뿐인데, 당신은 그것을 믿지 않습니다" - 예, 그것이 바로 제가 주말에도 그것을 하는 이유입니다.

죄송합니다. 열심히 하는 모습을 보니 너무 고맙고 감사합니다. 당신이 5/10 이정표에 의해 얼마나 특히 헌신했는지 나는 나에게 보였다.

@terrajobst

당신이 우리와 동의하지 않는다고 해서 그것이 "그냥 우리의 일"이기 때문에 전문 지식이 없거나 관심이 없다고 비난할 수 있는 것은 아닙니다.

• 전문 지식이 없음 -- 컴퓨터 과학 배경이 없고 ​​힙/우선 순위 대기열의 개념을 이해하지 못하는 사람들을 대상으로 합니다. 그러한 설명이 누군가에게 적용된다면 -- 글쎄요, 적용됩니다. 그것은 제 잘못이 아닙니다.
• 관심 없음 -- 일부 기술적인 요점을 무시하는 경향이 있는 사람들을 대상으로 하여 반복적인 주장을 강요하여 토론을 혼란스럽게 만들고 다른 사람들이 따르기 어렵게 만듭니다(결과적으로 더 적은 입력으로 이어짐).

귀하와 같은 의견은 매우 불공평하며 또한 디자인을 발전시키는 데 도움이 되지 않습니다.

• 나의 가혹한 논평은 이 토론의 비효율적인 결과였습니다. 비효율 = 논의의 혼란스러운 방식, 문제가 해결/해결되지 않고 그럼에도 불구하고 더 나아가는 => 지루함.
• 또한 토론의 핵심 동인 중 한 명으로서 디자인을 발전시키는 데 많은 도움을 주었다고 생각합니다. 여기와 소셜 미디어에서 하려고 하는 것처럼 저를 악마화하지 마십시오.

"나를 핥아"고 싶은 아픈 사람이 있으면 부담없이 주십시오.

문제가 발생하여 해결했습니다. 모두가 그것에서 뭔가를 배웠습니다. 여기 있는 모든 사람들이 프레임워크의 품질에 대해 걱정하고 있다는 것을 알 수 있습니다. 이는 절대적으로 훌륭하고 제가 기여하고 싶은 동기를 부여합니다. CoreFX에서 계속해서 여러분과 함께 작업하기를 기대합니다. 즉, 나는 아마도 내일 귀하의 새로운 기술 입력에 대해 다룰 것입니다.

@pgolebiowski

언젠가는 직접 만날 수 있기를 바랍니다. 나는 솔직히 모든 것을 온라인으로 하는 도전의 일부는 성격이 때때로 양쪽의 의도 없이 나쁜 방식으로 섞일 수 있다는 것입니다.

CoreFX에서 계속해서 여러분과 함께 작업하기를 기대합니다. 즉, 나는 아마도 내일 귀하의 새로운 기술 입력에 대해 다룰 것입니다.

여기도 마찬가지입니다. 이곳은 흥미로운 공간이고 우리가 함께 할 수 있는 놀라운 일들이 많이 있습니다 :-)

@pgolebiowski 먼저 답변해 주셔서 감사합니다. 그것은 당신이 관심을 갖고 있다는 것을 보여주고 당신의 뜻이 좋습니다(이것은 세상의 모든 사람/개발자가 하기를 비밀리에 바라는 것입니다. 모든 갈등은 단지 오해/잘못된 의사소통일 뿐입니다). 그리고 그것은 저를 정말로 행복하게 만듭니다. 그것은 저를 계속 흥분시키고 흥분시킵니다.
나는 우리의 관계를 다시 시작하는 것이 좋습니다. 논의를 기술로 다시 돌아가서 이 스레드에서 모두 배우고 앞으로 유사한 상황을 처리하는 방법을 배우고 상대방이 플랫폼에 대한 최선의 이익만을 염두에 두고 있다고 다시 가정해 보겠습니다.
BTW: 이것은 지난 9개월 동안 CoreFX 리포지토리에 대한 몇 가지 더 어려운 만남/토론 중 하나이며, 보시다시피 우리(나를 포함하여)는 여전히 이를 잘 처리하는 방법을 배우고 있습니다. 우리에게도 이익이 되고 앞으로 더 나아질 것이며 열정적인 커뮤니티 구성원의 다양한 관점을 더 잘 이해하는 데 도움이 될 것입니다. 아마도 기여 문서에 대한 업데이트를 형성할 것입니다 ...

나의 가혹한 논평은 이 토론의 비효율적인 결과였습니다. 비효율 = 논의의 혼란스러운 방식, 문제가 해결/해결되지 않고 그럼에도 불구하고 더 나아가는 => 지루함.

당신의 좌절을 이해했습니다! 흥미롭게도 비슷한 좌절감이 같은 이유로 반대편에도 있었습니다 😉 ... 세상이 어떻게 돌아가는지 거의 우스꽝스럽습니다. :).
불행히도, 어려운 토론은 설계 결정을 내릴 때 작업의 일부입니다. 많은 작업입니다. 많은 사람들이 그것을 과소평가합니다. 필요한 핵심 기술은 모든 사람에 대한 인내심과 자신의 의견을 뛰어넘는 능력과 뜻대로 되지 않더라도 합의를 이끌어내는 방법을 생각하는 능력입니다. 그렇기 때문에 2개의 제안을 갖고 기술 토론을 API 검토자 그룹으로 "에스컬레이션"할 것을 제안했습니다(주로 제가 옳다는 확신이 없기 때문입니다. 비록 제가 비밀리에 세계의 다른 모든 개발자가 하는 것처럼 옳기를 희망하지만 😉 ).

한 주제에 대한 의견을 갖고 같은 스레드에 대한 토론을 CONSENSUS로 이끄는 것은 매우 어렵습니다. 그런 관점에서 당신과 나는 이 스레드에서 가장 공통적입니다. 우리 둘 다 의견이 있지만 둘 다 토론을 종결 및 결정으로 이끌려고 합니다. 그러니 긴밀히 협력합시다.

나의 일반적인 접근 방식은 다음과 같습니다. 누군가가 나를 공격하고 있다고 생각할 때마다, 사악하거나, 게으르거나, 나를 좌절시키는 것입니다. 나는 먼저 나 자신과 특정 사람에게 묻습니다. 왜? 왜 그렇게 말했어? 무슨 뜻이었습니까?
일반적으로 동기에 대한 이해/커뮤니케이션 부족의 표시입니다. 또는 줄 사이를 너무 많이 읽고 모욕/고발/나쁜 의도가 없는 곳에서 보는 징후.

이제 기술적인 질문에 대해 계속 토론하는 것을 두려워하지 않으므로 이전에 묻고 싶었던 내용은 다음과 같습니다.

요소 업데이트 및 제거를 허용하지 않는 비활성화된 PriorityQueue를 사용하십시오.

이해가 안되는 부분입니다. IHeap (내 / 원래 제안서에서)를 생략하면 왜 그것이 불가능할까요?
IMO 클래스 기능의 관점에서 두 제안 사이에는 차이가 없습니다. 유일한 차이점은 -- PriorityQueue(IHeap) 생성자 오버로드를 추가하는지 여부입니다(클래스 이름 분쟁은 해결해야 할 독립적인 문제로 남겨둠) .

면책 조항(오해를 피하기 위해): 기사를 읽고 조사할 시간이 없습니다. 기술 토론을 주도하고 싶은 사람의 엘리베이터 피치 주장을 제시하는 짧은 답변을 기대합니다. 참고: 내가 트롤링하는 것이 아닙니다. 나는 이 주장을 하는 팀의 누구에게나 같은 질문을 할 것입니다. 설명할 힘이 없거나 토론을 주도할 힘이 없다면(당신 측의 어려움과 시간 투자를 감안할 때 완전히 이해할 수 있음) 그냥 그렇게 말하십시오. 힘든 감정은 없습니다. 저나 다른 사람에 의해 압박감을 느끼지 마십시오. 이는 해당 스레드의 모든 사람에게 적용됩니다.

여기에 불필요한 설명을 하나 더 추가하려고 하지 않습니다. 이 스레드는 너무 길었습니다. 인터넷 시대의 제1원칙은 인간관계를 중시한다면 문자를 피하는 것입니다. (글쎄, 나는 그것을 만들었습니다). 다른 오픈 소스 커뮤니티에서 이러한 종류의 토론이 필요하다면 Google 행아웃으로 전환할 것이라고 생각합니다. 다른 사람의 얼굴을 볼 때 "모욕"하는 말은 절대 하지 않으며, 사람들은 서로를 매우 빨리 친해집니다. 우리도 시도해 볼 수 있지 않을까요?

@karelz 위의 논의가

• 근본적인 부분에 대해 차례로 투표를 진행하겠습니다. 우리는 커뮤니티로부터 명확한 의견을 받을 것입니다. 이상적으로는 API 검토자가 여기에 와서 곧 의견을 제시할 것입니다.
• "투표 게시물"에는 위의 전체 텍스트 벽을 무시할 수 있을 만큼 충분한 정보가 포함됩니다.
• 이 투표 세션이 끝나면 API 검토자들에게 무엇을 기대해야 하는지 알게 될 것이며 특정 접근 방식을 진행할 수 있을 것입니다. 근본적인 측면에 동의하면 이 문제가 닫히고 다른 문제가 열립니다(이 문제를 참조할 것). 이번 호에서는 우리의 결론을 요약하고 이러한 결정을 반영한 API 제안을 제공할 것입니다. 그리고 우리는 거기에서 그것을 가져갈 것입니다.

그것이 의미가있을 가능성이 있습니까?

요소 업데이트 및 제거를 허용하지 않는 PriorityQueue입니다.

이러한 기능이 없는 원래 제안에 관한 것이었습니다. 명확히 하지 못해 죄송합니다.

설명할 힘이 없거나 토론을 주도할 힘이 없다면(당신 측의 어려움과 시간 투자를 감안할 때 완전히 이해할 수 있음) 그냥 그렇게 말하십시오. 힘든 감정은 없습니다. 저나 다른 사람에 의해 압박감을 느끼지 마십시오. 이는 해당 스레드의 모든 사람에게 적용됩니다.

나는 포기하지 않을 것이다. 고통 없음 이득 없음 xD

@xied75

다른 오픈 소스 커뮤니티에서 이러한 종류의 토론이 필요하다면 Google 행아웃으로 전환할 것이라고 생각합니다. 우리도 시도해 볼 수 있지 않을까요?

좋아보이네요 ;)

인터페이스 제공

Heap / IHeap 또는 PriorityQueue / IPriorityQueue (또는 다른 것)를 사용하든 상관없이 우리가 제공하려는 기능에 대해...

_구현과 함께 인터페이스를 원하십니까?_

을위한

• 개발자는 인터페이스에 대해 논리를 작성할 수 있습니다. 읽기: 종속성 역전 원리 , 종속성 주입 , 계약에 따른 설계 , 제어 역전 .
• 개발자는 다른 구현을 제공하여 사용자 정의 요구 사항을 충족하도록 이 기능을 확장할 수 있습니다. 이러한 구현은 PowerCollections 와 같은 타사 라이브러리에 포함될 수 있습니다.

@벤도노

인터페이스로 해당 구현을 지원함으로써 다른 구현에 관심이 있는 우리는 다른 구현(자체 생성 또는 외부 라이브러리에서)으로 쉽게 교체할 수 있으며 인터페이스를 허용하는 코드와 여전히 호환될 수 있습니다.

신경쓰지 않는 사람은 무시하고 바로 구체적인 구현을 하면 된다. 돌보는 사람들은 자신이 선택한 모든 구현을 사용할 수 있습니다.

에 맞서

@madelson

이 데이터 구조를 구현하는 데 이론적으로 사용할 수 있는 다양한 알고리즘이 있습니다. 그러나 프레임워크가 둘 이상과 함께 제공될 것 같지는 않으며 라이브러리 작성자가 여러 당사자가 상호 호환 가능한 힙 구현을 작성하는 데 조정할 수 있도록 정식 인터페이스가 실제로 필요하다는 생각은 그럴 가능성이 없어 보입니다.

또한 인터페이스가 출시되면 호환성으로 인해 절대 변경할 수 없습니다. 이는 인터페이스가 기능 측면에서 구체적인 클래스보다 뒤처지는 경향이 있음을 의미합니다(오늘날 IList 및 IDictionary의 문제).

@karelz

인터페이스는 매우 고급 전문가 시나리오입니다.

라이브러리와 IHeap 인터페이스가 정말 유명해지면 나중에 마음을 바꿔서 수요에 따라 IHeap 를 추가할 수 있지만(생성자 오버로드를 통해) 유용/정렬되지는 않습니다. BCL의 나머지 부분은 지금 새 인터페이스를 추가하는 복잡성을 정당화하기에 충분합니다. 단순하게 시작하여 정말로 필요한 경우에만 복잡하게 확장하십시오.

잠재적인 결정 영향

• 인터페이스를 포함한다는 것은 향후 변경할 수 없음을 의미합니다.
• 인터페이스를 포함하지 않는다는 것은 사람들이 우리의 표준 라이브러리 솔루션을 사용하거나 타사 라이브러리에서 제공하는 솔루션에 대해 작성된 코드를 작성한다는 것을 의미합니다(교차 호환성을 가능하게 하는 공통 인터페이스가 없음).

👍 및 👎를 사용하여 이 항목에 투표하세요(각각 인터페이스에 대해 찬성 및 반대). 또는 의견을 작성하십시오. 이상적으로는 API 검토자가 참여합니다.

인터페이스를 변경하는 것은 어렵지만 확장 메서드(및 속성이 추가됨)를 사용하면 인터페이스를 확장 및/또는 작업하기가 더 쉽다고 덧붙이고 싶습니다(LINQ 참조).

인터페이스를 변경하는 것은 어렵지만 확장 메서드(및 속성이 추가됨)를 사용하면 인터페이스를 확장 및/또는 작업하기가 더 쉽다고 덧붙이고 싶습니다(LINQ 참조).

인터페이스에서 공개적으로 정의된 메서드로만 작업할 수 있습니다. 그래서 그것은 처음으로 그것을 바로잡는 것을 의미합니다.

클래스가 사용 중이고 안정될 때까지 인터페이스를 잠시 보류한 다음 인터페이스를 도입하는 것이 좋습니다. (인터페이스의 형태에 대한 논쟁은 별개의 문제임)

솔직히 말해서, 내가 신경 쓰는 유일한 것은 인터페이스입니다. 견고한 구현이 좋겠지만 나(또는 다른 사람)는 항상 나만의 것을 만들 수 있습니다.

몇 년 전 HashSet<T> 와 똑같은 대화를 나눈 것을 기억합니다. Microsoft는 HashSet<T> 를 원했지만 커뮤니티는 ISet<T> . 제 기억이 맞다면 HashSet<T> 먼저 받고 ISet<T> 두 번째로 받았습니다. 인터페이스가 없으면 HashSet<T> 은 공개 API를 변경하는 것이 어렵기 때문에(종종 불가능하지는 않더라도) 상당히 제한적이었습니다.

SortedSet<T> 수많은 비 BCL 구현은 말할 것도 없고 현재 ISet<T> 있습니다. 나는 공개 API에서 ISet<T> 했고 그것에 대해 감사합니다. 내 개인 구현은 내가 옳다고 생각하는 구체적인 구현을 사용할 수 있습니다. 또한 아무 것도 중단하지 않고 다른 구현으로 쉽게 교체할 수 있습니다. 이것은 인터페이스 없이는 불가능합니다.

우리는 항상 우리 자신의 인터페이스를 정의할 수 있다고 말하는 사람들을 위해 이것을 고려하십시오. 잠시 동안 BCL의 ISet<T> 가 발생하지 않았다고 가정합니다. 이제 견고한 구현뿐만 아니라 나만의 인터페이스 IMySet<T> 를 만들 수 있습니다. 그러나 어느 날 BCL HashSet<T> 이 릴리스됩니다. ISet<T> 구현하거나 구현하지 않을 수 있지만 IMySet<T> 구현하지 않습니다. 그 결과, 나는에 교환 할 수 HashSet<T> 내의 구현으로 IMySet<T> .

나는 우리가 이 엉뚱한 짓을 다시 반복할까봐 두렵습니다.
인터페이스에 커밋할 준비가 되지 않았다면 구체적인 클래스를 도입하기에는 너무 이르다.

나는 의견의 차이가 중요하다고 생각합니다. 숫자만 보면 인터페이스에 대한 사람이 약간 더 많지만 많은 정보를 제공하지는 않습니다. 이전에 토론에 참여했지만 아직 인터페이스와 관련하여 의견을 표명하지 않은 다른 사람들에게 묻고자 합니다.

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

알림을 받은 경우: _여러분, 의견을 제공해 주시겠습니까? :+1:, :-1:으로 투표만 하셔도 큰 도움이 됩니다. 이 문제 댓글 (여기 위에 4개의 게시물)에서 읽기 시작할 수 있습니다. 인터페이스를 제공하는 것이 좋은 아이디어인지 여부에 대해 논의하고 있습니다(해결될 때까지 지금은 이 측면만)._

이 사람들 중 일부는 API 검토자일 수도 있지만 진행하기 전에 이 근본적인 결정에 대한 지원이 필요하다고 생각합니다. @karelz , @terrajobst , 이 문제를 해결하는 데 도움을 요청할 수 있습니까? 그들의 의견은 결국 검토할 사람이기 때문에 매우 귀중할 것입니다. 특정 접근 방식으로 커밋하기 전에(또는 지루할 1개 이상의 제안을 진행하기 전에 이 시점에서 그것을 아는 것이 매우 도움이 될 것입니다.) 그리고 우리는 그들의 결정을 더 일찍 알 수 있듯이 약간 무의미합니다).

개인적으로 저는 인터페이스에 찬성하지만, 결정이 다르다면 다른 길을 가도 행복합니다.

API 리뷰어를 토론에 끌어들이고 싶지 않습니다. 길고 지저분합니다. API 리뷰어가 모든 것을 다시 읽거나 마지막으로 중요한 답변이 무엇인지 결정하는 것은 효율적이지 않을 것입니다. ).
저는 우리가 2개의 공식 API 제안을 생성하고('좋은' 예시 참조) 각각의 장단점을 강조할 수 있는 시점에 있다고 생각합니다. 그런 다음 API 검토 회의에서 검토하고 투표를 고려하여 권장할 수 있습니다. 그곳의 토론에 따라(여러 의견이 있는 경우) 다시 돌아와 Twitter 투표/추가 GH 투표 등을 시작할 수 있습니다.

BTW: API 검토 회의는 거의 매주 화요일에 열립니다.

시작하는 데 도움이 되도록 제안서는 다음과 같이 표시됩니다.

제안 사례 / 시드

```c#
네임스페이스 System.Collections.Generic
{
공개 클래스 PriorityQueue
: IEnumerable, ICollection, IEnumerable, IReadOnlyCollection
{
공개 우선 순위 큐();
공개 PriorityQueue(int 용량);
공개 PriorityQueue(IComparer비교);
공개 PriorityQueue(IEnumerable수집);
공개 PriorityQueue(IEnumerable컬렉션, IComparer비교);
공개 PriorityQueue(int 용량, IComparer비교);

    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 좋아, 봐줘 ! :웃다:

괜찮은. 내가 말할 수 있는 한 인터페이스나 힙은 API 검토를 통과하지 못합니다. 따라서 예를 들어 4차 힙을 잊어버리고 약간 다른 솔루션을 제안하고 싶습니다. 아래의 데이터 구조는 Python , Java , C++ , Go , Swift 및 Rust (적어도 해당)에서 찾을 수 있는 것과 몇 가지 면에서 다릅니다.

주요 초점은 최적의 복잡성과 뛰어난 실제 성능을 유지하면서 정확성, 기능 측면의 완전성 및 직관성에 있습니다.

@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 */ ));

노트

• TKey 대한 비교자는 시나리오 1 에서와 같이 Comparer<TKey>.Default 로 간주됩니다.

시나리오 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 throw해야 합니다.
  
  
  • Enqueue(TValue) 가 처음 호출되면 키와 값이 동일한 객체로 간주되어 키 선택기가 유추됩니다( 시나리오 6 ). 그때부터 Enqueue(TKey, TValue) 메서드는 InvalidOperationException throw해야 합니다.
  
  

기타 기능

우리는 이미 우선순위 큐 생성을 다루었습니다. 또한 컬렉션에 요소를 추가하는 방법도 알고 있습니다. 이제 나머지 기능에 중점을 둘 것입니다.

가장 높은 우선 순위 요소

우선 순위가 가장 높은 요소에 대해 수행할 수 있는 두 가지 작업이 있습니다. 바로 가져오거나 제거하는 것입니다.

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 메서드에서 정확히 무엇을 반환하는지 나중에 설명합니다.

요소 수정

임의의 요소에 대해 수정하고 싶을 수 있습니다. 예를 들어 서비스의 전체 수명 동안 우선 순위 큐를 사용하는 경우 개발자가 우선 순위를 업데이트할 가능성이 높습니다.

놀랍게도 이러한 기능은 Python , Java , C++ , Go , Swift 및 Rust 에서 동일한 데이터 구조에서 제공되지 않습니다. 다른 것들도 있을 수 있지만, 나는 그것들만 확인했다. 결과? 실망한 개발자:

• Java의 우선 순위 대기열에 우선 순위 변경 방법이 없는 이유는 무엇입니까?
• Java priorityQueue 업데이트 문제
• PriorityQueue/힙 업데이트

여기에는 기본적으로 두 가지 옵션이 있습니다.

• Java 방식으로 수행하고 이 기능을 제공하지 마십시오. 나는 그것에 대해 강력히 반대합니다. 그것은 사용자가 컬렉션에서 요소를 제거하도록 강요합니다(이 단독으로는 잘 작동하지 않지만 나중에 설명하겠습니다). 그런 다음 다시 한 번 추가합니다. 매우 추하고 모든 경우에 작동하지 않으며 비효율적입니다.
• 새로운 개념의 핸들을 소개

핸들

사용자가 우선순위 큐에 요소를 추가할 때마다 핸들이 제공됩니다.

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

핸들은 다음 공개 API가 있는 클래스입니다.

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

우선 순위 대기열의 고유 요소에 대한 참조입니다. 효율성이 걱정된다면 FAQ 를 참조하세요(더 이상 걱정하지 않으셔도 됩니다).

이러한 접근 방식을 사용하면 매우 직관적이고 간단한 방식으로 우선 순위 대기열의 고유한 요소를 쉽게 수정할 수 있습니다.

/*
 * 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);

보시다시피, 이러한 접근 방식은 질문 없이 우선 순위 대기열의 고유한 요소를 참조하는 간단한 방법을 제공합니다. 키가 중복될 수 있는 시나리오에서 특히 유용합니다. 또한 이것은 매우 효율적입니다. 우리는 O(1)에서 업데이트할 요소를 알고 있으며 O(log n)에서 작업을 수행할 수 있습니다.

또는 사용자는 O(n)의 전체 구조를 검색한 다음 인수와 일치하는 첫 번째 요소를 업데이트하는 추가 메서드를 사용할 수 있습니다. 이것이 Java에서 요소를 제거하는 방법입니다. 완전히 정확하지도 효율적이지도 않지만 때로는 더 간단합니다.

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) vs O(n + log n)).

시나리오 8

• TKey 은 TValue 내에 포함됩니다.

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

/* adding some elements */

queue.Update(handle);

이 시나리오는 핸들 섹션에서 예로 제공된 것입니다.

위는 O(log n)에서 달성됩니다. 또는 사용자는 지정된 것과 동일한 첫 번째 요소를 찾고 내부 재정렬을 수행하는 Update(TValue) 메서드를 사용할 수 있습니다. 물론 이것은 O(n)입니다.

시나리오 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 입니다.

제안된 API

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 가 더 좋습니다. 키가 이미 업데이트되었고 수행해야 하는 작업은 우선 순위 대기열 내의 일부 요소를 재정렬하는 것입니다.

자주하는 질문

핸들이 비효율적이지 않습니까?

핸들을 사용하는 것과 관련하여 효율성에는 문제가 없습니다. 일반적인 두려움은 내부적으로 배열을 기반으로 하는 힙을 사용하기 때문에 추가 할당이 필요하다는 것입니다. 두려워하지 마십시오. 읽어.

그러면 어떻게 구현하시겠습니까?

우선 순위 대기열을 제공하는 완전히 다른 접근 방식이 될 것입니다. 처음으로 표준 라이브러리는 아래에 배열로 표시되는 이진 힙으로 구현된 이 기능을 제공하지 않습니다. 설계상 배열을 사용하지 않는 페어링 힙 으로 구현됩니다. 단순히 트리를 대신 나타냅니다.

얼마나 성능이 좋을까?

• 일반적인 임의 입력의 경우 4차 힙이 약간 더 빠릅니다.
• 그러나 더 빠르려면 어레이를 기반으로 해야 합니다. 그러면 핸들은 단순히 노드를 기반으로 할 수 없으며 추가 할당이 필요합니다. 그렇다면 — 우리는 합리적으로 요소를 업데이트하고 제거할 수 없었습니다.
• 현재 설계된 방식으로 우리는 사용하기 쉬운 API를 가지고 있으면서도 꽤 성능이 좋습니다.
• 아래에 페어링 힙이 있는 추가 이점은 이진/4차 힙에서와 같이 O(n) 대신 O(1)에서 두 개의 우선 순위 대기열을 병합할 수 있다는 것입니다.
• 힙 페어링은 여전히 ​​매우 빠릅니다. 참조를 참조하십시오. 때로는 4차 힙보다 빠릅니다(병합뿐만 아니라 수행된 작업 및 입력 데이터에 따라 다름).

참고문헌

• Michael L. Fredman, Robert Sedgewick, Daniel D. Sleator 및 Robert E. Tarjan(1986), 페어링 힙: 자체 조정 힙의 새로운 형태 , 알고리즘 1:111-129 .
• Daniel H. Larkin, Siddhartha Sen 및 Robert E. Tarjan(2014), 우선 순위 대기열에 대한 기초로 돌아가 경험적 연구 , arXiv:1403.0252v1 [cs.DS].

BTW, 첫 번째 API 검토 반복입니다. _열려 있는 질문_이 있는 섹션을 해결해야 합니다(여러분의 의견이 필요하며 [가능한 경우 API 검토자의 의견이 필요합니다]). 첫 번째 반복이 적어도 부분적으로 통과하면 나머지 토론에 대해 새 문제를 만들고 싶습니다(이 문제를 닫고 참조).

내가 말할 수 있는 한 인터페이스나 힙은 API 검토를 통과하지 못합니다.

@pgolebiowski : 그럼 그냥 문제를 종료하지 않겠습니까? 인터페이스가 없으면 이 클래스는 거의 쓸모가 없습니다. 내가 사용할 수 있는 유일한 장소는 비공개 구현입니다. 이 시점에서 필요할 때 나만의 우선 순위 대기열을 생성(또는 재사용)할 수 있습니다. 다른 구현으로 교체해야 하는 즉시 중단되므로 서명에 이 유형이 있는 내 코드에서 공개 API를 노출할 수 없습니다.

@벤도노
글쎄, Microsoft는 스레드에 대해 언급하는 소수의 사람들이 아니라 여기에 최종 단어를 가지고 있습니다. 그리고 우리는 다음을 알고 있습니다.

나는 다른 API 리뷰어/아키텍트가 그것을 공유할 것이라고 어느 정도 확신합니다. 몇 사람과 의견을 확인한 바 있습니다. 이름은 PriorityQueue여야 하고 IHeap 인터페이스를 도입해서는 안 됩니다. 정확히 하나의 구현이 있어야 합니다(일부 힙을 통해).

이것은 @karelz, 소프트웨어 엔지니어 관리자 및 @terrajobst, 프로그램 관리자 및이 저장소 + 일부 API 리뷰어의 소유자가 공유됩니다.

이전 게시물에서 분명히 언급했듯이 인터페이스를 사용한 접근 방식을 분명히 좋아하지만 이 토론에서 많은 권한이 없기 때문에 상당히 어렵다는 것을 알 수 있습니다. 우리는 우리의 요점을 제시했지만 우리는 단지 일부 논평자일 뿐입니다. 코드는 어쨌든 우리의 것이 아닙니다. 우리는 무엇을 더 할 수 있습니까?

그렇다면 왜 문제를 닫지 않습니까? 인터페이스가 없으면 이 클래스는 거의 쓸모가 없습니다.

나는 할 만큼 했다 -- 내 일을 미워하는 대신에 뭔가를 해라. 실제 작업을 수행합니다. 왜 아무렇게나 날 탓하려 하지? 다른 사람들을 당신의 관점으로 설득하는 데 성공하지 못한 자신을 비난하십시오.

그리고 제발, 저에게 그런 수사학을 아끼지 마십시오. 정말 유치합니다. 더 잘하십시오.

BTW, 제안은 인터페이스를 도입하는지 여부 또는 클래스 이름이 PriorityQueue 또는 Heap 인지 여부에 관계없이 일반적인 사항에 중점을 둡니다. 따라서 여기에서 정말로 중요한 것에 집중하고 원하는 것이 있으면 행동에 대한 편견을 보여주십시오.

@pgolebiowski 물론 Microsoft의 결정입니다. 하지만 자신의 필요에 맞는 사용하고자 하는 API를 제시하는 것이 좋습니다. 거부되면 그렇게 됩니다. 제안을 타협할 필요가 없다고 봅니다.

제 댓글을 님 탓으로 해석하셨다면 사과드립니다. 그것은 확실히 내 의도가 아니었다.

@pgolebiowski 핸들에 KeyValuePair<TKey,TValue> 를 사용하지 않는 이유는 무엇입니까?

@SamuelEnglard

핸들에 KeyValuePair<TKey,TValue> 를 사용하지 않는 이유는 무엇입니까?

• 음, PriorityQueueHandle 는 사실 _ 페어링 힙 노드 _입니다. TKey Key 및 TValue Value 두 가지 속성을 노출합니다. 그러나 내부에 훨씬 더 많은 논리가 있습니다. 이 구현을 참조하십시오. 예를 들어 트리의 다른 노드에 대한 포인터도 포함합니다(모든 것이 CoreFX 내부에 있음).
• KeyValuePair 는 구조체이므로 매번 복사되고 상속될 수 없습니다.
• 그러나 중요한 것은 PriorityQueueHandle 가 KeyValuePair 와 동일한 공개 API를 노출하는 다소 복잡한 클래스라는 것입니다.

@벤도노

하지만 자신의 필요에 맞는 사용하고자 하는 API를 제시하는 것이 좋습니다. 거부되면 그렇게 됩니다. 제안을 타협할 필요가 없다고 봅니다.

• 사실입니다. 나는 그것을 염두에두고 어떤 일이 일어나는지 지켜볼 것입니다. @karelz , 제안과 함께 우리가 인터페이스에 투표한 이전 게시물(제안 바로 앞에 있음)도 전달할 수 있습니까? API 검토의 첫 번째 반복 후에 나중에 다시 돌아올 수 있습니다.
• 그러나 우리가 어떤 솔루션을 사용하든 기능은 매우 유사할 것이며 검토를 받는 것이 도움이 될 것입니다. 핸들에 대한 아이디어가 거부되고 요소를 제대로 업데이트/제거할 수 없는 경우(또는 TKey 및 TValue 별도로 가질 수 없음) 이 클래스는 실제로 쓸모가 없습니다. - 현재 Java에서와 같이.
• 특히 인터페이스가 없으면 내 AlgoKit 라이브러리 는 CoreFX와 함께 힙에 대한 공통 코어를 가질 수 없습니다. 이는 저에게 정말 슬픈 일입니다.
• 그리고 예, 인터페이스를 추가하는 것이 Microsoft에서 단점으로 인식된다는 것은 정말 놀라운 일입니다.

그것은 확실히 내 의도가 아니었다.

미안, 그럼 내 실수.

디자인에 대한 내 질문(면책 조항: 이러한 질문 및 설명, 하드 푸시백 없음(아직)):

1. 정말 PriorityQueueHandle 합니까? 대기열에서 고유한 값을 기대하기만 하면 어떻게 될까요?
   
   
   
   • 동기: 다소 복잡한 개념인 것 같습니다. 가지고 있다면 왜 필요한지 이해하고 싶습니다. 어떻게 도움이 됩니까? 아니면 API 표면으로 누출되는 특정 구현 세부 정보입니까? API의 복잡성에 대한 비용을 지불하기 위해 그렇게 많은 성능을 얻을 수 있습니까?
   
   
2. Merge 가 필요합니까? 다른 컬렉션에도 있나요? 구현하기 쉽기 때문에 API를 추가해서는 안 됩니다. API에 대한 몇 가지 일반적인 사용 사례가 있어야 합니다.
   
   
   
   • IEnumerable<KeyValuePair<TKey, TValue>> 에서 초기화를 추가하는 것으로 충분할까요? + Linq에 의존
   
   
3. comparer 과부하가 필요합니까? 항상 기본값으로 돌아갈 수 있습니까? (면책 조항: 이 경우 지식/전문 지식이 부족하므로 질문만 합니다.)
4. keySelector 오버로드가 필요합니까? 우리가 가치의 일부로 우선순위를 가질 것인지, 아니면 별도의 것으로 결정할 것인지 결정해야 한다고 생각합니다. 분리 우선 순위가 좀 더 자연스러운 것 같지만 강한 의견이 없습니다. 우리는 장단점을 알고 있습니까?

개별/병렬 결정 사항:

1. 클래스 이름 PriorityQueue 대 Heap
2. IHeap 및 생성자 오버로드를 도입하시겠습니까?

IHeap 및 생성자 오버로드를 도입하시겠습니까?

2센트를 투자할 수 있을 만큼 상황이 해결된 것 같습니다. 개인적으로 인터페이스가 마음에 듭니다. 내 의견으로는 구조를 단순화하고 사용성을 최대한 높이는 방식으로 API(및 해당 API에서 설명하는 핵심 기능)에서 구현 세부 정보를 추상화합니다.

내가 PQueue/Heap/ILikeThisItemMoreThanThisItemList와 동시에 인터페이스를 수행할지 아니면 나중에 추가할지 여부에 대한 의견이 강력하지 않습니다. API가 "유동적"일 수 있으므로 피드백을 받을 때까지 먼저 클래스로 릴리스해야 한다는 주장은 동의하지 않는 유효한 주장입니다. 문제는 인터페이스를 추가하기에 충분히 "안정적"인 것으로 간주 될 때 입니다. 위의 스레드 IList 및 IDictionary 는 우리가 아주 오래전에 추가한 표준 구현의 API보다 뒤처지는 것으로 언급되었으므로 허용 가능한 휴식 기간으로 간주되는 기간은 무엇입니까?

합리적인 확신을 가지고 그 기간을 정의할 수 있고 그것이 허용할 수 없을 정도로 차단되지 않는다는 것을 확신할 수 있다면 인터페이스 없이 이 방대한 데이터 구조를 전달하는 데 문제가 없다고 봅니다. 그런 다음 그 기간이 지나면 사용법을 검토하고 인터페이스 추가를 고려할 수 있습니다.

그리고 예, 인터페이스를 추가하는 것이 Microsoft에서 단점으로 인식된다는 것은 정말 놀라운 일입니다.

여러모로 불리하기 때문 이다 . 인터페이스를 제공하면 거의 완료된 것입니다. 해당 API를 반복할 수 있는 여지가 많지 않으므로 처음에는 그것이 옳고 앞으로 몇 년 동안 계속 옳을 것이라고 확신하는 것이 좋습니다. 멋진--에이 기능을 누락하면 모두 더 잘 만들 것 그냥이 하나의 작은 변화를 가지고 오 - 그래서 - 좋은 것입니다 경우 잠재적으로 부적절한 인터페이스 붙어 것보다 될 수있는 방법 좋은 장소입니다.

@karelz 와 @ianhays를 입력해 주셔서 감사합니다!

중복 허용

정말 PriorityQueueHandle 합니까? 대기열에서 고유한 값을 기대하기만 하면 어떻게 될까요?

동기: 다소 복잡한 개념인 것 같습니다. 가지고 있다면 왜 필요한지 이해하고 싶습니다. 어떻게 도움이 됩니까? 아니면 API 표면으로 누출되는 특정 구현 세부 정보입니까? API의 복잡성에 대한 비용을 지불하기 위해 그렇게 많은 성능을 얻을 수 있습니까?

아니요, 우리는 필요하지 않습니다. 위에서 제안한 우선순위 큐 API는 매우 강력하고 매우 유연합니다. 요소와 우선 순위가 중복될 수 있다는 가정에 기반합니다. 이러한 가정 때문에 핸들이 있어야 올바른 노드를 제거하거나 업데이트할 수 있습니다. 그러나 요소가 고유해야 한다는 제한을 두면 내부 클래스( PriorityQueueHandle )를 노출하지 않고 더 간단한 API로 위와 동일한 결과를 얻을 수 있는데 이는 실제로 이상적이지 않습니다.

고유한 요소만 허용한다고 가정해 보겠습니다. 우리는 여전히 모든 이전 시나리오를 지원하고 최적의 성능을 유지할 수 있습니다. 더 간단한 API:

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 가 필요합니까? 다른 컬렉션에도 있나요? 구현하기 쉽기 때문에 API를 추가해서는 안 됩니다. API에 대한 몇 가지 일반적인 사용 사례가 있어야 합니다.

동의하다. 우리는 그것을 필요로하지 않습니다. 우리는 항상 API를 추가할 수 있지만 제거할 수는 없습니다. 이 방법을 제거하고 (잠재적으로) 나중에 (필요한 경우) 추가해도 괜찮습니다.

비교자

비교자 과부하가 필요합니까? 항상 기본값으로 돌아갈 수 있습니까? (면책 조항: 이 경우 지식/전문 지식이 부족하므로 질문만 합니다.)

이것은 두 가지 이유로 매우 중요하다고 생각합니다.

• 사용자는 요소가 오름차순 또는 내림차순으로 정렬되기를 원합니다. 가장 높은 우선순위 는 주문을 어떻게 해야 하는지 알려주지 않습니다.
• 비교자를 건너뛰면 사용자가 항상 IComparable 를 구현하는 클래스를 전달하도록 강제합니다.

또한 기존 API와 일치합니다. SortedDictionary 를 살펴보십시오.

선택자

keySelector 오버로드가 필요합니까? 우리가 가치의 일부로 우선순위를 가질 것인지, 아니면 별도의 것으로 결정할 것인지 결정해야 한다고 생각합니다. 분리 우선 순위가 좀 더 자연스러운 것 같지만 강한 의견이 없습니다. 우리는 장단점을 알고 있습니까?

나는 또한 별도의 우선 순위를 좋아합니다. 그 외에도 이것을 구현하는 것이 더 쉽고 성능 및 메모리 사용량이 더 좋고 API가 더 직관적이며 사용자의 작업량이 적습니다( IComparable 를 구현할 필요가 없음).

셀렉터에 대해 지금...

장점

이것이 이 우선순위 큐를 유연하게 만드는 것입니다. 사용자는 다음을 수행할 수 있습니다.

• 요소 및 해당 우선 순위를 별도의 요소로
• 내부 어딘가에 우선 순위가 있는 요소(복잡한 클래스)
• 주어진 요소에 대한 우선 순위를 검색하는 외부 논리
• IComparable 를 구현하는 요소

그것은 내가 생각할 수 있는 거의 모든 구성을 허용합니다. 사용자가 "플러그 앤 플레이"만 할 수 있기 때문에 유용하다고 생각합니다. 또한 다소 직관적입니다.

단점

• 배울 것이 더 있습니다.
• 더 많은 API. 두 개의 추가 생성자, 하나의 추가 Enqueue 및 Update 메서드.
• 요소와 우선 순위를 분리하거나 결합하기로 결정한 경우 일부 사용자(다른 형식의 데이터가 있는 사용자)가 이 데이터 구조를 사용하도록 코드를 조정하도록 강제합니다.

분리/병렬 결정 포인트

클래스 이름 PriorityQueue 대 Heap

IHeap 및 생성자 오버로드를 소개합니다.

• PriorityQueue 는 Heap 아니라 CoreFX의 일부여야 한다고 생각합니다.
• IHeap 인터페이스와 관련하여 — 우선 순위 큐는 힙과 다른 것으로 구현될 수 있기 때문에 아마도 이런 방식으로 노출하지 않는 것이 좋습니다. 그러나 IPriorityQueue 가 필요할 수 있습니다.

인터페이스를 제공하면 거의 완료된 것입니다. 해당 API를 반복할 수 있는 여지가 많지 않으므로 처음에는 그것이 옳고 앞으로 몇 년 동안 계속 옳을 것이라고 확신하는 것이 좋습니다. 있으면 좋은 기능을 놓치는 것이 잠재적으로 부적절할 수 있는 인터페이스에 갇히게 되는 것보다 훨씬 더 나은 위치에 있는 것입니다. 여기서 모든 것을 더 좋게 만드는 이 작은 변화만 있으면 정말 좋을 것입니다.

전적으로 동의합니다!

비교 가능한 요소

요소가 비교 가능해야 한다는 또 다른 가정을 추가하면 API가 훨씬 더 간단해집니다. 그러나 다시 말하지만 유연성이 떨어집니다.

장점

• 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 는 새 클래스 API가 사용될 때까지 기다려야 하고 실제로 인터페이스를 출시할 때까지 피드백을

또한 비교기에 관해서는 다른 BCL API를 따른다고 생각하며 사용자가 새로운 래퍼 클래스를 제공해야 한다는 사실이 마음에 들지 않습니다. 나는 비교자 접근 방식을 수신하고 내부적으로 수행해야 하는 모든 비교 내에서 해당 비교자를 사용하는 생성자 오버로드를 정말 좋아합니다. 비교자가 제공되지 않거나 비교자가 null인 경우 기본 비교자를 사용합니다.

@pgolebiowski 상세하고 설명적인 API 제안에 감사드립니다. 이 API를 승인하고 CoreFX에 추가하는 데 매우 적극적이고 적극적입니다 👍 이 논의가 완료되고 검토할 준비가 되었다고 생각하면 모든 입력과 최종 API 표면을 병합할 것입니다 하나의 댓글로 만들고 상단의 주요 이슈 댓글을 업데이트하면 리뷰어의 삶이 더 쉬워집니다.

좋아, 나는 비교기에 대해 확신한다. 그것은 말이 되고 일관성이 있다.
나는 여전히 선택기에 대해 고민하고 있습니다. IMO 없이 선택해야 합니다. 두 가지 변형으로 나누겠습니다.

```c#
공개 클래스 PriorityQueue
: IE숫자 가능,
IEnumerable<(TElement 요소, Tpriority 우선 순위)>,
IReadOnlyCollection<(TElement 요소, Tpriority 우선 순위)>
// ICollection은 의도적으로 포함되지 않음
{
공개 우선 순위 큐();
공개 PriorityQueue(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();

//
// 셀렉터 부분
//
공개 PriorityQueue(Func우선순위 선택기);
공개 PriorityQueue(Func우선순위 선택기, IComparer비교);

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개의 API 차이)
5. (TElement element, TPriority priority) 대 KeyValuePair<TPriority, TElement> 튜플 사용
   
   
   
   • Peek 및 Dequeue 에는 튜플 대신 out 인수가 있어야 합니까?
   
   

빠른 피드백을 위해 내일 API 검토 그룹에서 실행해 보겠습니다.

Peek 및 Dequeue 튜플 필드 이름을 priority (이를 지적해 주신 @pgolebiowski 에게 감사드립니다).
상단 게시물은 위의 최신 제안으로 업데이트되었습니다.

나는 @safern 의 코멘트를 두 번째로 - 앞으로 추진해 준 @pgolebiowski 에게

열린 질문:

여기에 하나 더 있을 수 있다고 생각합니다.

1. 고유한 요소만 사용하도록 제한합니다(중복 허용 안 함).

열린 질문이 아닌 상위 게시물의 '가정'으로 캡처된 좋은 점입니다. 그 반대는 API를 상당히 추하게 만듭니다.

우리가 반환해야합니다 bool 에서 Remove ? 또한 out priority 인수로 우선 순위를 지정합니까? (최근에 비슷한 오버로드를 다른 데이터 구조에 추가했다고 생각합니다)

Contains 와 유사 - 누군가가 우선 순위를 원할 것입니다. out priority 하여 오버로드를 추가할 수 있습니다.

나는 힙이 구현을 의미하고 이것을 PriorityQueue 호출하는 것을 정당하게 지원할 것이라는 의견(아직 목소리를 내지는 않았지만)을 유지합니다. (나는 중복 요소를 허용하고 업데이트 등을 허용하지 않는 더 슬림한 Heap 클래스에 대한 제안을 지지할 수도 있습니다. (원래 제안에 더 많이 부합함) 발생).

중복 우선 순위가 예상되므로 KeyValuePair<TPriority, TElement> 사용해서는 안 됩니다. 또한 KeyValuePair<TElement, TPriority> 도 혼란스러울 수 있으므로 KeyValuePair 를 전혀 사용하지 않는 것이 좋습니다 KeyValuePair<TElement, TPriority> 일반 튜플을 사용하거나 우선 순위에 대한 매개 변수를 사용합니다(개인적으로 매개 변수를 선호하지만 소란스럽지는 않습니다).

중복을 허용하지 않는 경우 우선 순위가 다르거나 변경된 항목을 다시 추가하려는 동작을 결정해야 합니다.

나는 선택자 제안을 지지하지 않습니다. 그것이 중복성을 의미하고 정당하게 혼란을 재창조할 것이라는 단순한 이유 때문입니다. 요소의 우선 순위가 함께 저장되면 두 곳에 저장되고 동기화되지 않으면(즉, 누군가 쓸모 없어 보이는 Update(TElement) 메서드를 호출하는 것을 잊음) 많은 고통을 겪습니다. 보장합니다. 선택기가 컴퓨터인 경우 의도적으로 요소를 추가한 다음 계산된 값을 변경하는 사람들에게 열려 있습니다. 이제 다시 추가하려고 하면 다음에 따라 잘못될 수 있는 많은 것들이 있습니다. 이것이 일어날 때 무슨 일이 일어나는지에 대한 결정에. 약간 더 높은 수준에서 시도하면 더 이상 이전과 같지 않기 때문에 요소의 변경된 복사본을 추가할 수 있습니다(이것은 변경 가능한 키의 일반적인 문제이지만 우선 순위와 요소를 분리하면 잠재적인 문제를 방지하는 데 도움이 됩니다).

선택기 자체는 행동을 변경하기 쉬우며, 이는 사용자가 생각 없이 모든 것을 깨뜨릴 수 있는 또 다른 방법입니다. 사용자가 우선 순위를 명시적으로 제공하도록 하는 것이 훨씬 더 낫다고 생각합니다. 내가 볼 수 있는 가장 큰 문제는 요소가 아닌 쌍을 선언하기 때문에 중복 항목이 허용된다는 것을 전달한다는 것입니다. 그러나, 재치있는 인라인 문서와 bool 수익 가치 Enqueue 하찮게이 문제를 해결해야한다. Boolean보다 더 나은 것은 요소의 이전/새 우선순위를 반환하는 것입니다(예: Enqueue 가 새로 제공된 우선순위, 또는 둘 중 최소값 또는 이전 우선순위를 사용하는 경우). 그러나 Enqueue 는 다시 추가하려고 하면 실패해야 하므로 성공을 나타내는 bool 를 반환해야 합니다. 이렇게 하면 Enqueue 및 Update 완전히 분리되고 잘 정의됩니다.

KeyValuePair를 전혀 사용하지 않고 일반 튜플을 사용하는 것을 지원합니다.

나는 당신과 함께 튜플에 있습니다.

중복을 허용하지 않는 경우 우선 순위가 다르거나 변경된 항목을 다시 추가하려는 동작을 결정해야 합니다.

• Dictionary 내에서 인덱서와 유사성을 봅니다. 거기에서 dictionary["something"] = 5 를 수행하면 "something" 가 이전에 키였던 경우 업데이트됩니다. 없으면 그냥 추가됩니다.
• 그러나 Enqueue 메소드는 사전에 있는 Add 메소드와 유사합니다. 즉, 예외가 발생해야 합니다.
• 위의 사항을 고려하여 염두에 두고 있는 동작을 지원하기 위해 우선 순위 대기열에 인덱서를 추가하는 것을 고려할 수 있습니다.
• 그러나 결과적으로 인덱서는 대기열 개념과 함께 작동하지 않을 수 있습니다.
• 따라서 Enqueue 메서드는 누군가가 중복된 요소를 추가하려는 경우 예외를 throw해야 한다는 결론으로 ​​이어집니다. 마찬가지로 Update 메서드는 존재하지 않는 요소의 우선 순위를 업데이트하려는 경우 예외를 throw해야 합니다.
• 이것은 우리를 새로운 솔루션으로 이끕니다 -- 실제로 bool 반환하는 TryUpdate 메소드를 추가하십시오.

나는 그것이 중복성을 의미한다는 단순한 이유로 선택자 제안을 지지하지 않습니다.

키가 물리적으로 복사되지 않고(존재하는 경우) 선택기는 우선 순위를 평가해야 할 때 호출되는 함수로 남아 있지 않습니까? 중복은 어디에 있습니까?

우선순위와 요소를 분리하면 잠재적인 문제를 방지하는 데 도움이 될 것이라고 생각합니다.

유일한 문제는 고객에게 물리적 우선순위가 없는 경우입니다. 그러면 그는 많은 것을 할 수 없습니다.

사용자가 우선 순위를 명시적으로 제공하도록 하는 것이 훨씬 더 낫다고 생각합니다. 내가 볼 수 있는 가장 큰 문제는 요소가 아닌 쌍을 선언하기 때문에 중복 항목이 허용된다는 것을 전달한다는 것입니다.

해당 솔루션에 몇 가지 문제가 있지만 중복 항목이 허용되는 이유가 반드시 그런 것은 아닙니다. "중복 없음" 논리는 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 던지는 것이 나에게 의미가 있습니다. 나는 Enqueue ( IDictionary 보다는)와 관련하여 ISet 라인을 따라 더 많이 생각하고 있었습니다. 던지는 것도 의미가 있을 것입니다. 저는 그 점을 놓쳤음에 틀림없지 bool 반환이 유형의 '확정성'을 전달한다고 생각합니다. 아마도 TryEnqueue 도 ( Add 던지기와 함께) 순서가 될까요? TryRemove 도 감사하겠습니다(비어 있으면 실패). 당신의 마지막 요점에 관해서는, 네, 저도 염두에 둔 행동입니다. 나는 IDictionary 와 유추하는 것이 ISet 보다 낫다고 생각하며 충분히 명확해야 합니다. (요약하자면: 나는 당신의 제안에 따라 던지는 모든 것을 지지하지만, 그럴 경우 Try* 를 갖는 것이 필수입니다. 또한 실패 조건에 관한 당신의 진술에 동의합니다).

인덱서와 관련하여 대기열 개념에 실제로 '적합'하지 않다는 귀하의 생각이 옳다고 생각합니다. 저는 그것을 지원하지 않을 것입니다. 만약 있다면 Queue 또는 Update에 대한 잘 명명된 메서드가 순서대로 있을 것입니다.

키가 물리적으로 복사되지 않고(존재하는 경우) 선택기는 우선 순위를 평가해야 할 때 호출되는 함수로 남아 있지 않습니까? 중복은 어디에 있습니까?

맞아요. 제안 업데이트를 잘못 읽었습니다(요소에 저장하는 방법에 대한 비트). Selector가 요청 시 호출된다는 점을 고려하면(성능에 영향을 미칠 수 있으므로 모든 문서에서 명확하게 설명해야 함) 데이터 구조가 응답하지 않고 함수의 결과가 변경될 수 있다는 점은 여전히 ​​유효합니다. Update 가 호출되지 않는 한 두 개는 동기화되지 않습니다. 설상가상으로 사용자가 여러 요소의 유효 우선 순위를 변경하고 그 중 하나만 업데이트하면 '업데이트되지 않은' 요소에서 선택될 때 '커밋되지 않은' 변경 사항에 따라 데이터 구조가 종료됩니다. 제안된 DataStructure 구현에 대해 자세히 설명하고 있지만 이것은 모든 업데이트 O(<n) 필연적으로 문제라고 생각합니다. 사용자가 우선 순위를 명시적으로 업데이트하도록 하면 이 문제가 해결되고 반드시 데이터 구조를 일관된 상태에서 다른 상태로 변경해야 합니다.

지금까지 선택기 제안에 대해 언급한 모든 불만 사항은 API의 견고성에 관한 것입니다. 선택기는 잘못 사용하기 쉽습니다. 그러나 사용성을 제쳐두고 개념적으로 대기열의 요소는 우선 순위를 알 필요가 없습니다. 그것은 잠재적으로 그들과 관련이 없으며 사용자가 struct Queable<T>{} 또는 다른 것으로 자신의 요소를 래핑하면 마찰 없는 API 제공에 실패한 것처럼 보입니다(이 용어를 사용하는 것이 나에게 상처를 주는 만큼).

물론 선택기가 없으면 사용자가 선택기를 호출해야 하는 부담이 있다고 주장할 수 있지만 요소가 우선 순위를 알면 (바람직하게는) 깔끔하게(즉, 속성) 노출되고 그렇지 않으면 t, 그러면 걱정할 선택기가 없습니다(즉석에서 우선 순위 생성 등). 선택기를 지원하지 않으려면 지원하고 이미 잘 정의된 '선택기'가 있는 경우 우선 순위를 전달하는 데 훨씬 더 무의미한 배관이 필요합니다. 선택기는 사용자가 이 정보를 노출하도록 유도하고(아마도 도움이 되지 않을 수 있음), 별도의 우선 순위는 디자인 결정에 영향을 미칠 것이라고 상상할 수 없는 매우 투명한 인터페이스를 제공합니다.

선택기에 대해 내가 정말로 생각할 수 있는 유일한 주장은 PriorityQueue 전달을 사용할 수 있고 프로그램의 다른 부분이 우선 순위가 계산되는 방법을 모른 채 사용할 수 있다는 것을 의미한다는 것입니다. 나는 이것에 대해 조금 더 생각해야 할 것이지만, '틈새' 적합성을 감안할 때 이것은 더 일반적인 경우에 합리적으로 무거운 오버헤드에 대한 작은 보상으로 생각합니다.

_편집: 그것에 대해 조금 더 알고 있으면, Elements를 던질 수 있는 자체 포함된 PriorityQueue 가 있으면 매우 좋겠지만 이 문제를 해결하는 데 드는 비용이 클 것이라고 생각합니다. 도입 비용은 상당히 낮을 것입니다._

저는 우선순위 큐가 어떻게 사용되는지에 대한 실제 사례를 보기 위해 오픈 소스 .NET 코드베이스를 살펴보며 약간의 작업을 했습니다. 까다로운 문제는 학생 프로젝트 및 교육 소스 코드를 필터링하는 것입니다.

사용법 1: Roslyn 알림 서비스
https://github.com/dotnet/roslyn/
Roslyn 컴파일러에는 "PriorityQueue"라는 개인 우선 순위 대기열 구현이 포함되어 있습니다. 이 대기열에는 매우 구체적인 최적화가 있는 것으로 보입니다. 즉, 대기열에 있는 개체를 재사용하여 가비지 수집되지 않도록 하는 개체 대기열입니다. Enqueue_NoLock 메서드는 current.Value.MinimumRunPointInMS < entry.Value.MinimumRunPointInMS에 대한 평가를 수행하여 큐에서 새 노드를 배치할 위치를 결정합니다. 여기에 제안된 두 가지 주요 우선 순위 대기열 디자인(비교 기능/대리자 대 명시적 우선 순위) 중 하나가 이 사용 시나리오에 적합합니다.

사용법 2: Lucene.net
https://github.com/apache/lucenenet
이것은 틀림없이 .NET에서 찾을 수 있는 PriorityQueue의 가장 큰 사용 예입니다. Apache Lucene.net은 인기 있는 Lucene 검색 엔진 라이브러리의 전체 .net 포트입니다. 우리는 우리 회사에서 Java 버전을 사용하고 Apache의 웹 사이트에 따르면 몇 가지 큰 이름이 .NET 버전을 사용합니다. Github에는 .NET 프로젝트의 많은 포크가 있습니다.

Lucene에는 HitQueue, TopOrdAndFloatQueue, PhraseQueue 및 SuggestWordQueue와 같은 여러 "특수" 우선 순위 대기열로 하위 분류되는 자체 PriorityQueue 구현이 포함되어 있습니다. 또한 프로젝트는 여러 위치에서 PriorityQueue를 직접 인스턴스화합니다.

위에 링크된 Lucene의 PriorityQueue 구현은 이번 호에 게시된 원래 우선 순위 대기열 API와 매우 유사합니다. "PriorityQueue" 및 IComparer를 허용합니다.생성자의 매개변수입니다. 메서드와 속성에는 Count, Clear, Offer(enqueue/push), Poll(dequeue/pop), Peek, Remove(대기열에서 찾은 첫 번째 일치 항목 제거), Add(Offer의 동의어)가 있습니다. 흥미롭게도 대기열에 대한 열거 지원도 제공합니다.

Lucene의 PriorityQueue에서 우선 순위는 생성자에 전달된 비교자에 의해 결정되며, 전달되지 않은 경우 비교된 개체가 IComparable을 구현한다고 가정합니다.비교를 수행하기 위해 해당 인터페이스를 사용합니다. 여기에 게시된 원래 API 디자인은 값 유형에서도 작동한다는 점을 제외하면 비슷합니다.

코드 기반을 통해 많은 사용 예가 있으며 SloppyPhraseScorer 가 그 중 하나입니다.

SloppyPhraseScorer의 생성자는 새로운 PhraseQueue(pq)를 인스턴스화합니다. 이는 PriorityQueue의 고유한 사용자 정의 하위 클래스 중 하나입니다. PhrasePositions 컬렉션이 생성되며, 이는 게시물 집합, 위치 및 용어 집합에 대한 래퍼로 표시됩니다. FillQueue 메서드는 구 위치를 열거하고 대기열에 넣습니다. PharseFreq()는 AdvancePP 함수를 호출하고 높은 수준에서 대기열에서 빼내고 항목의 우선 순위를 업데이트한 다음 다시 대기열에 넣는 것처럼 보입니다. 우선 순위는 명시적으로(우선 순위가 대기열에 넣는 동안 두 번째 매개 변수로 "전달"되지 않음) 상대적으로(비교자를 사용하여) 결정됩니다.

PhraseQueue 의 구현에 따라 생성자를 통해 전달된 비교 값(예: 정수)이 잘리지 않을 수 있음을 알 수 있습니다. 비교 기능("LessThan")은 PhrasePositions.doc, PhrasePositions.position 및 PhrasePositions.offset의 세 가지 필드를 평가합니다.

용법 3: 게임 개발
이 공간에서 사용 예제 검색을 완료하지는 않았지만 게임 개발에서 사용자 지정 .NET PriorityQueue가 사용되는 몇 가지 예제를 보았습니다. 매우 일반적인 의미에서 이들은 주요 사용 사례(Dijkstra's)로 경로 찾기를 중심으로 클러스터링되는 경향이 있습니다. Unity 3D 로 인해 .NET에서 경로 찾기 알고리즘을 구현하는 방법을 묻는 많은 사람들을 찾을 수 있습니다.

여전히 이 영역을 파헤쳐야 합니다. 명시적 우선 순위가 대기열에 포함된 몇 가지 예와 Comparer/IComparable을 사용하는 몇 가지 예를 보았습니다.

별도의 메모에서 고유 요소, 명시적 요소 제거 및 특정 요소의 존재 여부 확인에 대한 논의가 있었습니다.

큐는 데이터 구조로서 일반적으로 Enqueuing 및 Dequeuing을 지원합니다. 다른 집합/목록과 같은 작업을 제공하는 경로로 이동하면 실제로 튜플의 정렬된 목록과 유사한 다른 데이터 구조를 완전히 디자인하고 있는지 궁금합니다. 호출자가 Enqueue, Dequeue, Peek 이외의 다른 요구 사항이 있는 경우 우선 순위 큐 이외의 다른 것이 필요할 수 있습니까? 대기열은 정의에 따라 대기열에 삽입하고 대기열에서 순서대로 제거하는 것을 의미합니다. 별로.

@에비클

다른 리포지토리를 살펴보고 우선 순위 대기열 기능이 어떻게 전달되었는지 확인하는 귀하의 노력에 감사드립니다. 그러나 IMO에서 이 논의는 특정 설계 제안 을 제공함으로써 이익을 얻을 것입니다. 이 스레드는 이미 따라하기 어렵고 결론 없이 긴 이야기를 하면 더 어렵습니다.

대기열 [...]은 일반적으로 Enqueuing 및 Dequeuing을 지원합니다. [...] 호출자가 Enqueue, Dequeue, Peek 이외의 다른 요구 사항이 있는 경우 우선 순위 큐 이외의 다른 것이 필요할까요? 대기열은 정의에 따라 대기열에 삽입하고 대기열에서 순서대로 제거하는 것을 의미합니다. 별로.

• 결론은 무엇입니까? 제안?
• 그것은 진실과 매우 거리가 멉니다. 언급한 Dijkstra의 알고리즘도 요소의 우선 순위를 업데이트하는 방식을 사용합니다. 그리고 특정 요소를 업데이트하는 데 필요한 것은 특정 요소를 제거하는 데도 필요합니다.

훌륭한 토론입니다. @ebickle 의 연구는 매우 유용한 IMO입니다!
@ebickle [2] lucene.net에 대한 결론이 있습니까 - 우리의 최신 제안이 용도에 맞는지 아닌지? (자세한 설명에서 누락되지 않았으면 합니다.)

위의 Try* 변형 + IsEmpty + TryPeek / TryDequeue + EnqueueOrUpdate ? 생각?
```c#
공개 부울 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

```

@karelz

위의 Try* 변형이 필요한 것 같습니다.

네, 맞습니다.

enqueued vs. updated에 대해 bool 상태를 반환해야 합니까?

모든 곳에서 상태를 반환하려면 모든 곳에서. 이 특정 방법의 경우 두 작업 중 하나가 성공하면( Enqueue 또는 Update ) 사실이어야 한다고 생각합니다.

나머지는 -- 저는 단순히 동의합니다 :스마일:

그냥 하나 개의 질문 - 왜 ref 대신 out ? 잘 모르겠다:

• 함수를 입력하기 전에 초기화할 필요가 없습니다.
• 메서드에 사용되지 않습니다(그냥 꺼집니다).

모든 곳에서 상태를 반환하려면 모든 곳에서. 이 특정 방법의 경우 두 작업 중 하나가 성공하면( Enqueue 또는 Update ) 사실이어야 한다고 생각합니다.

항상 true를 반환합니다. 좋은 생각이 아닙니다. 이러한 경우 IMO에서 void 를 사용해야 합니다. 그렇지 않으면 사람들이 혼란스러워 하고 반환 값을 확인하고 쓸모없는 절대 실행되지 않는 코드를 추가할 것입니다. (제가 놓친 것이 없다면)

ref vs. out 동의, 내가 직접 토론했습니다. 나는 강한 의견이 없다 / 스스로 결정을 내리기에 충분한 경험이 없다. API 검토자에게 질문할 수 있습니다. / 더 많은 의견을 기다립니다.

항상 true를 반환합니다.

당신 말이 맞아, 내 나쁜. 죄송합니다.

나는 강한 의견이 없다 / 스스로 결정을 내리기에 충분한 경험이 없다.

어쩌면 내가 뭔가를 놓치고 있을지도 모르지만 나는 그것이 매우 간단하다고 생각합니다. ref 사용하는 경우 기본적으로 Peek 및 Dequeue 가 TElement 및 TPriority 전달된 방식을 사용하기를 원한다고 말합니다( 나는 그 필드를 읽는 것을 의미합니다). 실제로는 그렇지 않습니다. 우리의 메서드는 해당 변수에만 값을 할당해야 합니다(실제로 컴파일러에서 할당해야 함).

내 Try* API로 업데이트된 인기 게시물
2개의 공개 질문을 추가했습니다.

• [6] Peek 및 Dequeue 던지기가 전혀 유용합니까?
• [7] TryPeek 및 TryDequeue - ref 또는 out 인수를 사용해야 합니까?

ref 대 out - 당신이 옳습니다. false를 반환할 경우를 대비하여 초기화를 피하도록 최적화했습니다. 그것은 어리 석고 눈이 멀었습니다 - 조기 최적화. 나는 그것을 out으로 바꾸고 질문을 제거할 것이다.

6: 누락된 것이 있을 수 있지만 예외가 발생하지 않는 경우 대기열이 비어 있는 경우 Peek 또는 Dequeue 는 어떻게 해야 합니까? 나는 이것이 데이터 구조가 null 받아들여야 하는지 여부에 대한 질문을 던지기 시작한다고 생각합니다. null 허용하더라도 값 유형에는 null ( default 확실히 계산되지 않음)가 없으므로 Peek 및 Dequeue 는 의미 없는 결과를 전달할 방법이 없으며 당연히 예외를 throw해야 한다고 생각합니다(따라서 out 매개변수에 대한 우려를 제거합니다!). 기존 Queue.Dequeue 의 예를 따르지 않을 이유가 없습니다.

Dijkstra(휴리스틱이 없는 휴리스틱 검색이라고도 함)에는 우선 순위 변경이 필요하지 않습니다. 나는 어떤 것의 우선 순위를 업데이트하고 싶지 않았으며 항상 휴리스틱 검색을 강타했습니다. (알고리즘의 요점은 일단 상태를 탐색한 후에는 최상의 경로를 탐색했다는 것을 알 수 있다는 것입니다. 그렇지 않으면 최적이 아닌 위험이 있으므로 우선 순위를 결코 향상시킬 수 없으며 확실히 (즉, 더 나쁜 경로를 고려하십시오.) _의도적으로 휴리스틱을 선택하여 최적이 아닌 경우를 무시합니다. 이 경우에는 물론 최적이 아닌 결과를 얻을 수 있지만 여전히 우선 순위 업데이트_)

예외가 발생하지 않는 경우 대기열이 비어 있는 경우 Peek 또는 Dequeue는 무엇을 해야 합니까?

진실.

따라서 out 매개변수에 대한 우려를 제거합니다!

어떻게? out 매개변수는 TryPeek 및 TryDequeue 메소드용입니다. 예외를 발생시키는 것은 Peek 및 Dequeue 입니다.

Dijkstra는 우선 순위 변경이 필요하지 않다고 덧붙였습니다.

내가 틀릴 수도 있지만 내가 아는 한 Dijkstra의 알고리즘은 DecreaseKey 연산을 사용합니다. 예를 들어 이것을 참조하십시오. 이것이 효율적인지 아닌지는 다른 측면입니다. 사실, 피보나치 힙은 O(1)에서 DecreaseKey 연산을 점근적으로 달성하는 방식으로 설계되었습니다(Dijkstra를 개선하기 위해).

그러나 여전히 토론에서 중요한 것은 우선 순위 대기열의 요소를 업데이트할 수 있다는 점에서 매우 유용하며 이러한 기능을 검색하는 사람들이 있다는 것입니다(StackOverflow에서 이전에 링크된 질문 참조). 저도 몇번 사용해봤는데요.

죄송합니다. 예, 이제 out 매개변수에 문제가 있어 다시 잘못 읽습니다. 그리고 Dijkstra의 변형(내가 생각하는 것보다 더 광범위하게 적용되는 이름...)이 아마도 더 효율적으로 구현될 수 있는 것 같습니다(대기열에 이미 요소가 포함되어 있는 경우 반복 가능한 검색에 대한 이점이 있을 수 있음). 업데이트 가능한 우선 순위. 긴 단어와 이름을 사용하여 얻은 결과입니다. 나는 우리가 Update 을 떨어뜨릴 것을 제안하는 것이 아니라 이 기능이 부과하는 제한 없이 더 얇은 Heap 또는 다른 것(즉, 원래 제안)을 갖는 것도 좋을 것입니다. 내가 평가하는 능력).

7: out 이어야 합니다. 모든 입력은 의미를 가질 수 없으므로 존재하지 않아야 합니다(즉, ref 와 함께 사용해서는 안 됩니다). out 매개변수를 사용하면 default 값 반환을 개선하지 않을 것입니다. 이것이 Dictionary.TryGetValue 가 하는 일이며 달리 할 이유가 없습니다. _즉, ref 를 값이나 기본값으로 취급할 수 있지만 의미 있는 기본값이 없으면 문제를 좌절시킵니다._

API 검토 토론:

• 우리는 모든 찬반 양론을 논의하기 위해 적절한 디자인 회의(2시간) 를 해야 할 것입니다. 오늘 우리가 투자한 30분은 열린 질문에 대한 합의/마감에 충분하지 않았습니다.
  
  
  
  • 우리는 아마도 가장 많이 투자한 커뮤니티 회원을 초대할 것입니다. @pgolebiowski , 다른 사람이 있습니까?
  
  

다음은 주요 원시 메모입니다.

• 실험 - CoreFxLabs에서 실험을 수행하고 시험판 NuGet 패키지로 출시하고 소비자에게 피드백을 요청해야 합니다(블로그 게시물을 통해). 피드백 루프 없이 API를 못 박을 수 있다고 생각하지 않습니다.
  
  
  
  • 우리는 과거에 ImmutableCollections 에 대해 유사한 작업을 수행했습니다(빠른 미리 보기 릴리스 주기가 핵심이며 API를 형성하는 데 도움이 됨).
  
  
  • 이 실험을 이미 CoreFxLab에 있는 MultiValueDictionary 와 함께 묶을 수 있습니다. TODO: 후보자가 더 있는지 확인하십시오. 개별적으로 블로그에 게시하고 싶지 않습니다.
  
  
  • 실험적인 NuGet 패키지는 실험이 종료된 후 핵이 제거되며 소스 코드를 CoreFX 또는 CoreFXExtensions(나중에 결정됨)로 이동할 것입니다.
  
  
• 아이디어 : 반환 단지 TElement 에서 Peek & Dequeue , 반환하지 않는 TPriority (사용자가 사용할 수있는 Try* 그 방법).
• 안정성 (동일한 우선순위의 경우) - 우선순위가 동일한 항목은 대기열에 삽입된 순서대로 반환되어야 합니다(일반 대기열 동작).
• 복제 를
  
  
  
  • Update - 사용자는 Remove 한 다음 다른 우선순위로 다시 Enqueue 항목을 할 수 있습니다.
  
  
  • Remove 는 첫 번째 발견 항목만 제거해야 합니다( List 처럼).
  
  
• 아이디어 : 수 우리는 추상적 인 IQueue 인터페이스 추상적에 Queue 및 PriorityQueue ( Peek 및 Dequeue 반환은 TElement 데 도움이 여기)
  
  
  
  • 참고: 불가능한 것으로 판명될 수 있지만 API에 정착하기 전에 탐색해야 합니다.
  
  

우리는 선택기에 대해 오랫동안 논의했습니다. 아직 결정되지 않았습니다(위의 IQueue 요구할 수 있습니까?). 대다수가 선택기를 좋아하지 않았지만 향후 API 검토 회의에서 상황이 변경될 수 있습니다.

다른 열린 질문은 논의되지 않았습니다.

최신 제안은 나에게 꽤 좋아 보인다. 내 의견/질문:

1. Peek 및 Dequeue 가 priority 대해 out 매개변수를 사용한 경우 우선 순위를 전혀 반환하지 않는 오버로드가 있을 수 있으므로 단순화할 수 있습니다. 일반적인 사용법. 우선 순위는 폐기를 사용하여 무시할 수도 있으므로 덜 중요합니다.
2. 나는 선택기 버전이 다른 생성자를 사용하여 구별되고 다른 메소드 세트를 활성화하는 것을 좋아하지 않습니다. 별도의 PriorityQueue<T> 가 있어야 합니까? 또는 PriorityQueue<T, T> 와 함께 작동하는 정적 및 확장 메서드 세트?
3. 열거할 때 요소가 어떤 순서로 반환되는지 정의되어 있습니까? 내 생각 엔 효율적으로 만들기 위해 정의되지 않았다고 생각합니다.
4. 우선 순위를 무시하고 우선 순위 대기열의 항목만 열거하는 방법이 있어야 합니까? 아니면 priorityQueue.Select(t => t.element) 와 같은 것을 사용해야 합니까?
5. 우선 순위 큐가 내부적으로 요소 유형에 Dictionary 를 사용하는 경우 IEqualityComparer<TElement> 를 전달하는 옵션이 있어야 합니까?
6. 우선 순위를 업데이트할 필요가 없는 경우 Dictionary 사용하여 요소를 추적하는 것은 불필요한 오버헤드입니다. 비활성화하는 옵션이 있어야 합니까? 나중에 추가할 수 있지만 유용하다고 판명되면.

@karelz

안정성(동일한 우선순위의 경우) - 우선순위가 동일한 항목은 대기열에 삽입된 순서대로 반환되어야 합니다(일반 대기열 동작).

이것은 내부적으로 우선 순위가 (priority, version) 쌍과 같아야 함을 의미한다고 생각합니다. 여기서 version 는 추가할 때마다 증가합니다. 특히 version 가 64비트여야 한다는 점을 고려하면 우선 순위 대기열의 메모리 사용량이 크게 늘어날 것이라고 생각합니다. 그럴만한 가치가 있는지 잘 모르겠습니다.

중복 값을 방지하고 싶지 않습니다(다른 컬렉션과 유사).
Update - 사용자는 Remove 한 다음 다른 우선순위로 다시 Enqueue 항목을 할 수 있습니다.

구현에 따라 Update 는 Remove 다음에 Enqueue 오는 것보다 훨씬 더 효율적일 것입니다. 예를 들어, 바이너리 힙, (나는 급 힙이 동시에 복잡한 것 같아요) Update (고유 값과 사전) O (로그 n이)입니다 동안 Remove 중복 값 ( 사전 없음)은 O( n )입니다.

@pgolebiowski
여기에서 제안에 집중해야 한다는 데 전적으로 동의합니다. 원래 API 제안과 원래 게시물을 만들었습니다. 1월에 @karelz 는 몇 가지 구체적인 사용 예를 요청했습니다. PriorityQueue API의 특정 필요성과 사용법에 관한 훨씬 더 광범위한 질문을 던졌습니다. 나는 나만의 PriorityQueue 구현을 가지고 있고 몇몇 프로젝트에서 그것을 사용했고 BCL에서도 비슷한 것이 유용할 것이라고 느꼈습니다.

원래 게시물에서 내가 부족한 것은 기존 대기열 사용에 대한 광범위한 조사였습니다. 실제 사례는 설계를 기반으로 유지하고 광범위하게 사용할 수 있도록 하는 데 도움이 됩니다.

@karelz
Lucene.net에는 하나 이상의 우선 순위 대기열 비교 기능이 포함되어 있습니다(비교와 유사).) 우선 순위를 결정하기 위해 여러 필드를 평가합니다. Lucene의 "암시적" 비교 패턴은 현재 API 제안의 명시적 Tpriority 매개변수에 잘 매핑되지 않습니다. 여러 필드를 하나의 또는 Tpriority로 전달할 수 있는 '비교 가능한' 데이터 구조로 결합하는 일종의 매핑이 필요합니다.

제안:
1) 우선순위 큐위의 원래 제안(Original Proposal 제목 아래에 나열됨)을 기반으로 한 클래스입니다. Update(T), Remove(T) 및 Contains(T) 편의 기능을 잠재적으로 추가할 수 있습니다. 오픈 소스 커뮤니티의 기존 사용 사례 대부분에 맞습니다.
2) 우선순위 큐dotnet/corefx#1의 변형입니다. Dequeue() 및 Peek()는 튜플 대신 TElement를 반환합니다. Try* 기능 없음, Remove()는 List에 맞게 던지는 대신 bool을 반환합니다.무늬. '편의형' 역할을 하므로 명시적 우선순위 값을 가진 개발자는 자신의 비교 가능한 유형을 만들 필요가 없습니다.

두 유형 모두 중복 요소를 지원합니다. 동일한 우선순위의 요소에 대해 FIFO를 보장하는지 여부를 결정해야 합니다. 우선 순위 업데이트를 지원하는 경우에는 그렇지 않을 수 있습니다.

@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);

던져야 한다; 하지만 왜 Try 변형이 없고 확장 방법도 있습니까?

구조 기반 열거자?

@benaadams throw on

메소드를 유형에 추가할 수 있는 경우 확장 메소드로 메소드를 추가해서는 안됩니다. 확장 메서드는 유형에 추가할 수 없는 경우 백업입니다(예: 인터페이스이거나 .NET Framework에 더 빠르게 전달하려는 경우).

Dupes: 동일한 항목이 여러 개 있는 경우 하나만 업데이트하면 됩니까? 그러면 그들은 달라집니다?

던지는 방법: 기본적으로 래퍼이고 그럴까요?

public void Remove(TElement element)
{
    if (!TryRemove(element))
    {
        throw new Exception();
    }
}

예외를 통한 제어 흐름이지만?

@benaadams API 리뷰 노트로 내 답장을 확인 하세요 :

• 복제 를
  
  
  
  • Update - 사용자는 Remove 한 다음 다른 우선순위로 다시 Enqueue 항목을 할 수 있습니다.
  
  
  • Remove 는 첫 번째 발견 항목만 제거해야 합니다( List 처럼).
  
  

예외를 통한 제어 흐름이지만?

당신이 무슨 뜻인지 확실하지. BCL에서 꽤 흔한 패턴인 것 같습니다.

예외를 통한 제어 흐름이지만?

당신이 무슨 뜻인지 확실하지.

TryX 메서드만 있는 경우

• 결과에 관심이 있다면 당신은 그것을 확인
• 결과에 신경쓰지 않으면 확인하지 않는다

예외 개입 없음; 그러나 이름은 반품을 버리기로 결정하도록 권장합니다.

Try가 아닌 예외 발생 방법이 있는 경우

• 결과에 관심이 있다면 사전 확인하거나 try/catch를 사용하여 감지해야 합니다.
• 결과에 신경 쓰지 않는다면; catch 메서드를 비우거나 예기치 않은 예외를 가져와야 합니다.

따라서 흐름 제어에 대한 예외 처리를 사용 하는 안티 패턴에 있습니다. 그것들은 약간 불필요해 보입니다. 다시 생성하기 위해 false인 경우 항상 throw를 추가할 수 있습니다.

BCL에서 꽤 흔한 패턴인 것 같습니다.

TryX 메서드는 원래 BCL에서 일반적인 패턴이 아니었습니다. Concurrent 유형까지 (2.0의 Dictionary.TryGetValue 가 첫 번째 예일 수 있다고 생각하십니까?)

예를 들어 TryX 메서드는 Queue 및 Stack용 Core에만 추가되었으며 아직 Framework의 일부가 아닙니다.

안정

• 안정성은 공짜로 오는 것이 아닙니다. 이것은 성능과 메모리의 오버헤드를 수반합니다. 일반적인 사용의 경우 우선 순위 대기열의 안정성은 중요하지 않습니다.
• 우리는 IComparer 노출합니다. 고객이 안정성을 원하면 쉽게 추가할 수 있습니다. 우리의 구현 위에 StablePriorityQueue 를 구축하는 것은 쉬울 것입니다. 요소의 "나이"를 저장하고 비교하는 동안 이를 사용하는 일반적인 접근 방식을 사용합니다.

아이큐

그러면 API 충돌이 있습니다. 이제 기존 Queue<T> 와 함께 작동하도록 간단한 IQueue<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) 노출합니다. 우리는 본질적으로 그들로부터 생성된 튜플을 받아 두 개의 인수를 추가합니다. 아마도 이상적인 API가 아닙니다.

엿보기 및 대기열에서 빼기

이러한 메서드가 TElement 만 반환하기를 원했습니다.

1. 달성하고자 하는 것과 함께 작동합니다.
2. 달성하려는 것과 작동하지 않습니다 — (TElement, TPriority) 반환합니다.

세다

1. 고객은 요소의 우선 순위를 사용하는 LINQ 쿼리를 작성할 수 없습니다. 이것은 잘못된 것입니다.
2. 효과가있다.

물리적으로 별도의 우선 순위가 없는 PriorityQueue<T> 를 제공하여 일부 문제를 완화할 수 있습니다.

• 사용자는 본질적으로 코드가 우리 클래스를 사용할 수 있도록 래퍼 클래스를 작성해야 합니다. 이는 많은 경우에 IComparable 도 구현하기를 원한다는 것을 의미합니다. 상당히 많은 상용구 코드를 추가합니다(그리고 소스 코드에 새 파일이 있을 가능성이 높음).
• 원한다면 분명히 다시 논의할 수 있습니다. 나는 또한 아래에 대안적인 접근 방식을 제공합니다.

두 개의 우선 순위 대기열

두 개의 우선 순위 대기열을 제공하면 전체 솔루션이 더 강력하고 유연해질 것입니다. 몇 가지 참고 사항이 있습니다.

• 동일한 기능을 제공하기 위해 두 개의 클래스를 노출하지만 다양한 유형의 입력 형식에만 해당합니다. 기분이 좋지 않습니다.
• PriorityQueue<T> 는 잠재적으로 IQueue<T> 구현할 수 있습니다.
• PriorityQueue<TElement, TPriority> 는 IQueue 인터페이스를 구현하려고 하면 이상한 API를 노출합니다.

글쎄요... 효과 가 있을 것 입니다. 이상적이지는 않습니다.

업데이트 및 제거

중복을 허용하고 핸들 개념을 사용하고 싶지 않다고 가정하면 다음 과 같습니다.

• 요소의 우선 순위를 완전히 올바르게 업데이트하는 기능을 제공하는 것은 불가능
• 또한 두 작업을 모두 O(n)에서 수행해야 하는데, O(log n)에서 두 작업을 모두 수행할 수 있기 때문에 매우 안타까운 일입니다.

이것은 기본적으로 사용자가 매번 전체 컬렉션을 순진하게 반복하지 않고 우선 순위 대기열에서 우선 순위를 업데이트할 수 있기를 원하는 경우 전체 데이터 구조의 자체 구현을 제공해야 하는 Java에 있는 것으로 이어집니다.

대체 핸들

새로운 핸들 유형을 추가하고 싶지 않다는 가정 하에, 요소 업데이트 및 제거를 완벽하게 지원하기 위해(또한 효율적으로 수행하기 위해) 다르게 할 수 있습니다. 해결책은 대체 방법을 추가하는 것입니다.

void Enqueue(TElement element, TPriority priority, out object handle);

void Update(object handle, TPriority priority);

void Remove(object handle);

이 그것이 것처럼, 업데이트 및 요소를 제거 (에 적절한 제어를 할 및 O (N)에서 그것을하지 않는 사람들을위한 방법이 될 것입니다 List stuck_out_tongue_winking_eye : :).

그러나 더 나은 점을 고려해 봅시다 ...

대안적 접근

또는 우선 순위 대기열 에서 이 기능을 완전히 제거하고 대신 힙에 추가할 수 있습니다. 여기에는 많은 이점이 있습니다.

• Heap 를 사용하면 보다 강력하고 효율적인 작업을 수행할 수 있습니다.
• 간단한 API와 간단한 사용은 사용하여 볼 수 있습니다 PriorityQueue 바로 작업에 자신의 코드를 원하는 사람들을 위해 -.
• 우리는 Java의 문제에 부딪치지 않습니다.
• 이제 PriorityQueue 안정적으로 만들 수 있습니다. 더 이상 절충안이 아닙니다.
• 솔루션은 컴퓨터 과학 배경이 더 강한 사람들이 Heap 의 존재를 인식할 것이라는 느낌과 조화를 이룹니다. 그들은 또한 PriorityQueue 의 제한 사항을 알고 있으므로 대신 Heap 를 사용할 수 있습니다(예를 들어 요소 업데이트/제거에 대해 더 많은 제어 권한을 원하거나 데이터를 원하지 않는 경우). 속도와 메모리 사용량을 희생하여 안정적인 구조).
• 우선 순위 큐와 힙 모두 기능을 손상시키지 않으면서 복제를 쉽게 허용할 수 있습니다(목적이 다르기 때문에).
• 일반적인 IQueue 인터페이스를 만드는 것이 더 쉬울 것입니다. 왜냐하면 힘과 기능이 힙 필드에 던져지기 때문입니다. PriorityQueue 의 API는 추상화를 통해 Queue 와 호환되도록 하는 데 집중할 수 있습니다.
• 우리가 제공 할 필요가 없습니다 IPriorityQueue 이상 인터페이스를 (우리는 오히려의 기능 유지에 초점 PriorityQueue 및 Queue 유사한). 대신 힙 영역에 추가할 수 있으며 기본적으로 거기에 IHeap 가 있습니다. 이것은 사람들이 표준 라이브러리에 있는 것 위에 타사 라이브러리를 구축할 수 있게 해주기 때문에 훌륭합니다. 그리고 그것은 옳게 느껴집니다. 다시 말하지만, 우리는 힙 을 우선 순위 대기열 보다 더 발전된 것으로 간주하므로 해당 영역에서 확장이 제공될 것입니다. 이러한 확장은 PriorityQueue 에서 수행할 선택과 별개이기 때문에 문제가 되지 않습니다.
• 더 이상 PriorityQueue 대한 IHeap 생성자를 고려할 필요가 없습니다.
• 우선 순위 대기열은 CoreFX에서 내부적으로 사용하는 유용한 클래스입니다. 그러나 안정성과 같은 기능을 추가하고 다른 기능을 삭제하면 해당 솔루션보다 더 강력한 것이 필요하게 될 것입니다. 다행히 더 강력하고 성능이 뛰어난 Heap 가 우리의 명령에 따라 있을 것입니다!

기본적으로 우선 순위 대기열은 성능, 성능 및 유연성을 희생하면서 주로 사용 편의성에 중점을 둡니다. 힙은 우선 순위 대기열에서 결정의 성능과 기능적 의미를 알고 있는 사람들을 위한 것입니다. 우리는 절충안으로 많은 문제를 완화합니다.

실험을 위한 것이라면 지금은 가능하다고 생각합니다. 커뮤니티에 물어보자. 모든 사람이 이 스레드를 읽는 것은 아닙니다. 다른 귀중한 의견과 사용 시나리오를 생성할 수 있습니다. 어떻게 생각하나요? 개인적으로 나는 그러한 솔루션을 좋아합니다. 모두가 행복할 것 같아요.

중요 참고 사항: 이러한 접근 방식을 원하면 우선 순위 대기열과 힙을 함께 설계해야

그런 다음 IQueue 전달

위에 제시된 접근 방식을 사용하면 우선 순위 대기열이 IQueue<T> 를 구현하고 선택기에 대한 지원을 중단한다고 가정하면 하나의 제네릭 유형을 가져야 합니다. 이는 사용자가 (user data, priority) 별도로 가지고 있는 경우 래퍼를 제공해야 함을 의미하지만 이러한 솔루션은 여전히 ​​직관적입니다. 그리고 가장 중요한 것은 모든 입력 형식을 허용한다는 것입니다(그래서 선택기를 놓으면 이런 식으로 수행되어야 함). 선택기가 없으면 Enqueue(TElement, TPriority) 는 이미 비교 가능한 유형을 허용하지 않습니다. 단일 제네릭 형식은 열거에도 중요하므로 이 메서드를 IQueue<T> 포함할 수 있습니다.

여러 가지 잡다한

@svic

열거할 때 요소가 어떤 순서로 반환되는지 정의되어 있습니까? 내 생각 엔 효율적으로 만들기 위해 정의되지 않았다고 생각합니다.

열거하는 동안 순서를 가지려면 기본적으로 컬렉션을 정렬해야 합니다. 그렇기 때문에 고객이 단순히 OrderBy 를 실행하고 거의 동일한 성능을 달성할 수 있으므로 정의되지 않아야 합니다(그러나 일부 사람들은 필요하지 않음).

아이디어: 우선순위 큐에서 이것은 정렬되지 않은 힙에서 정렬될 수 있습니다. 기분이 좋아진다. 어떻게 든 우선 순위 대기열은 순서대로 반복하는 것처럼 느껴집니다. 힙은 확실히 아닙니다. 위 접근 방식의 또 다른 이점입니다.

@pgolebiowski
그 모든 것이 매우 제정신인 것 같습니다. Delivering IQueue then 섹션에서 중복 요소가 허용되는 경우 선택기의 대안으로 "하나의 일반 유형"에 대해 T : IComparable<T> 를 제안하시겠습니까?

나는 두 가지 별도의 유형을 갖는 것을 지지할 것입니다.

object 를 핸들 유형으로 사용하는 이유를 이해할 수 없습니다. 이것은 단지 새 유형을 생성하지 않기 위한 것입니까? 새 유형을 정의하면 구현 오버헤드를 최소화하면서 API를 오용하기 더 어렵게 만들고( string 를 Remove(object) 로 전달하려고 하지 않는 이유는 무엇입니까?) 요소 자체를 Remove(object) 에 전달하고 시도한 것에 대해 누가 나를 비난할 수 있습니까?).

보다 표현적인 인터페이스를 위해 핸들 메소드에서 object 를 대체하기 위해 적절하게 명명된 더미 유형의 추가를 제안합니다.

디버그 가능성이 메모리 오버헤드를 능가하는 경우 핸들 유형은 속하는 큐에 대한 정보를 포함할 수 있으며(인터페이스의 유형 안전성을 향상시키는 Generic이어야 함) ("Handle 공급이 생성되었습니다. 다른 대기열에 의해") 또는 이미 사용되었는지 여부("Handle에서 참조하는 요소가 이미 제거되었습니다").

핸들 아이디어가 계속 진행되면 이 정보가 유용하다고 생각되면 이러한 예외의 하위 집합도 해당 TryRemove 및 TryUpdate 메서드에 의해 throw됩니다. 요소가 대기열에서 제거되었거나 핸들에 의해 제거되었기 때문에 요소가 더 이상 존재하지 않습니다. 이것은 덜 지루하고 일반적이며 적절하게 명명된 핸들 유형을 수반합니다.

@비주얼멜론

Delivering IQueue then 섹션에서 중복 요소가 허용되는 경우 선택기의 대안으로 "하나의 일반 유형"에 대해 T : IComparable<T> 를 제안하시겠습니까?

이를 명확히 하지 못해 죄송합니다.

• T 에 대한 제약 없이 PriorityQueue<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 )에 이에 대한 추가 정보가 있습니다.

이제 더 명확해지기를 바랍니다.

BTW 이러한 솔루션을 가정하면 PriorityQueue<T> 및 IQueue<T> 의 API를 설계하는 것은 간단합니다. Queue<T> 의 메소드 중 일부를 IQueue<T> 집어넣고 PriorityQueue<T> 구현하도록 하십시오. 타다! 😄

object 를 핸들 유형으로 사용하는 이유를 이해할 수 없습니다. 이것은 단지 새 유형을 생성하지 않기 위한 것입니까?

• 예, 정확히. 이러한 유형을 노출하고 싶지 않다는 가정이 주어지면 핸들 개념을 계속 사용하는 유일한 솔루션입니다(따라서 더 많은 힘과 속도를 가짐). 우리가 현재의 접근 방식을 고수하고 (나는 반대입니다) 더 많은 전력 및 효율성을하려면 어떻게해야 무슨 설명이 오히려이었다 - 나는 비록 이상적인 아니에요 동의합니다.
• 대안적 접근 방식(별도의 우선 순위 대기열과 힙)을 사용한다는 점을 감안하면 이것이 더 쉽습니다. PriorityQueue<T> 는 System.Collections.Generic 에 있고 힙 기능은 System.Collections.Specialized 있습니다. 거기에서 우리는 그러한 유형을 도입할 더 높은 기회를 갖게 될 것이며, 결국 훌륭한 컴파일 시간 오류 감지를 갖게 될 것입니다.
• 그러나 다시 한 번 -- 우리가 그러한 접근 방식을 갖고 싶다면 우선 순위 큐 와 힙 기능을 함께 설계하는 것이 매우 중요합니다. 한 솔루션이 다른 솔루션이 제공하지 않는 것을 제공하기 때문입니다.

디버그 가능성이 메모리 오버헤드를 능가하는 경우 핸들 유형은 속하는 큐에 대한 정보를 포함할 수 있으며(인터페이스의 유형 안전성을 향상시키는 Generic이어야 함) ("Handle 공급이 생성되었습니다. 다른 대기열에 의해") 또는 이미 사용되었는지 여부("Handle에서 참조하는 요소가 이미 제거되었습니다").

핸들 아이디어가 계속 진행된다면 이 정보가 유용하다고 생각되면...

확실히 더 많은 것이 가능합니다 : 윙크 :. 특히 타사 라이브러리의 커뮤니티에서 이 모든 것을 확장합니다.

@karelz @safern @ianhays @terrajobst @bendono @svick @ 알렉세이-dvortsov @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 .
• 그것은 안정적이지 않을 것입니다 (그리고 메모리 측면에서 더 빠르고 효율적입니다).
• 지원, 적절한 업데이트 및 제거 처리
  
  
  
  • O(n) 대신 O(log n)에서 빠르게 완료
  
  
  • 올바르게 완료
  
  
• 열거가 정렬되지 않습니다(더 빠름).
• 중복을 허용합니다.

IQueue에 동의제안. 나는 오늘 같은 것을 발표하려고 했는데, 인터페이스 수준에서 가져야 할 올바른 추상화 수준처럼 느껴집니다. "항목을 추가하고 주문한 항목을 제거할 수 있는 데이터 구조에 대한 인터페이스입니다."

• IQueue의 사양좋아 보인다.

• IQueue에 "int Count { get; }" 추가 고려IReadOnlyCollection에서 상속하는지 여부에 관계없이 Count가 필요하다는 것이 분명하도록.

• IQueue의 TryPeek, TryDequeue에 관한 울타리에서대기열에 없는 것으로 간주하지만 이러한 도우미는 Queue 및 Stack에도 추가되어야 합니다.

• IsEmpty는 이상치처럼 보입니다. BCL의 다른 컬렉션 유형에는 많지 않습니다. 인터페이스에 추가하려면 Queue에 추가될 것이라고 가정해야 합니다., 그리고 Queue에 추가하는 것이 조금 이상해 보입니다.그리고 아무것도. 인터페이스와 클래스에서도 삭제할 것을 권장합니다.

• TryRemove를 삭제하고 Remove를 "bool Remove"로 변경합니다. 여기에서 다른 컬렉션 클래스와 정렬하는 것이 중요합니다. 개발자는 "컬렉션의 remove()는 throw하지 않습니다"라는 많은 근육 메모리를 갖게 됩니다. 많은 개발자가 잘 테스트하지 않는 영역이며 정상적인 동작이 변경되면 많은 놀라움을 유발할 것입니다.

이전 인용에서 @pgolebiowski

1. 사용자 데이터는 우선 순위와 별개입니다(물리적 인스턴스 2개).
2. 사용자 데이터에는 우선 순위가 포함됩니다.
3. 사용자 데이터가 우선입니다.
4. 드문 경우: 우선 순위는 다른 논리를 통해 얻을 수 있습니다(사용자 데이터와 다른 개체에 있음).

또한 고려하는 것이 좋습니다. 5. 사용자 데이터에는 여러 필드의 우선 순위가 포함됩니다(Lucene.net에서 본 것처럼).

TryPeek에 관한 울타리에서 IQueue의 TryDequeue는 대기열에 없는 것으로 간주합니다.

그들은 System/Collections/Generic/Queue.cs#L253-L295입니다.

반면 Queue에는
c# public void Remove(T element); public bool TryRemove(T element);

IReadOnlyCollection에서 상속하는지 여부에 관계없이 Count가 필요하다는 것을 분명히 하기 위해 IQueue에 "int Count { get; }"을 추가하는 것을 고려하십시오.

좋아요. 수정합니다.

IsEmpty는 이상치처럼 보입니다. BCL의 다른 컬렉션 유형에는 많지 않습니다.

이것은 @karelz 에 의해 추가되었으며 방금 복사했습니다. 나는 그것을 좋아하지만 API 검토에서 고려할 수 있습니다 :)

TryRemove를 삭제하고 Remove를 "bool Remove"로 변경합니다.

Remove 및 TryRemove 는 이와 같은 다른 방법과 일치한다고 생각합니다( Peek 및 TryPeek 또는 Dequeue 및 TryDequeue ).

1. 사용자 데이터에는 여러 필드의 우선 순위가 포함됩니다.

이것은 유효한 점이지만 사실 이것은 선택기로도 처리될 수 있습니다(결국 모든 함수임) -- 그러나 그것은 힙에 대한 것입니다.

IsEmpty는 이상치처럼 보입니다. BCL의 다른 컬렉션 유형에는 많지 않습니다.

FWIW, bool IsEmpty { get; } 는 IProducerConsumerCollection<T> 추가했으면 하는 것입니다. 그 이후로 여러 번 존재하지 않는 것이 아쉬웠습니다. 그것이 없으면 래퍼는 종종 Count == 0 와 동등한 작업을 수행해야 하며, 이는 일부 컬렉션, 특히 대부분의 동시 컬렉션에서 구현하는 것이 훨씬 비효율적입니다.

@pgolebiowski 현재 API 계약과 디자인 근거가 포함된 .md 파일 한두 개를 호스팅할 github 저장소를 만드는 아이디어에 대해 어떻게 생각하십니까? 일단 안정화되면 준비가 되면 CoreFxLabs까지 PR을 수행하기 전에 초기 구현을 구축하는 장소로 사용할 수 있습니까?

@svic

Peek 및 Dequeue 가 우선 순위에 대해 out 매개 변수를 사용했다면 우선 순위를 전혀 반환하지 않는 오버로드가 있을 수 있으므로 일반적인 사용법을 단순화할 수 있습니다.

동의. 추가해 보겠습니다.

우선 순위를 무시하고 우선 순위 대기열의 항목만 열거하는 방법이 있어야 합니까?

좋은 질문. 무엇을 제안하시겠습니까? IEnumerable<TElement> Elements { get; } ?

안정성 - 이것은 내부적으로 우선 순위가 (priority, version) 쌍과 같아야 함을 의미한다고 생각합니다.

Update 를 논리적인 Remove + Enqueue 로 고려하여 이를 피할 수 있다고 생각합니다. 우선 순위가 같은 항목의 끝에 항목을 항상 추가합니다(기본적으로 비교자 결과 0을 -1로 간주). 작동해야 하는 IMO.

@benaadams

TryX 메서드는 원래 BCL에서 일반적인 패턴이 아니었습니다. Concurrent 유형까지 (2.0의 Dictionary.TryGetValue 가 첫 번째 예일 수 있다고 생각하십니까?)
예를 들어 TryX 메서드는 Queue 및 Stack용 Core에만 추가되었으며 아직 Framework의 일부가 아닙니다.

나는 여전히 BCL에 익숙하지 않다는 것을 인정합니다. API 검토 회의와 최근에 많은 Try* 메서드를 추가했다는 사실에서 저는 이것이 훨씬 더 오랫동안 일반적인 패턴이라는 인상을 받았습니다 😉.
어느 쪽이든, 그것은 지금 일반적인 패턴이고 우리는 그것을 사용하는 것을 두려워해서는 안됩니다. 패턴이 아직 .NET Framework에 없다는 사실이 .NET Core의 혁신을 중단해서는 안 됩니다. 이것이 주요 목적인 더 빠른 혁신입니다.

@pgolebiowski

또는 우선 순위 대기열에서 이 기능을 완전히 제거하고 대신 힙에 추가할 수 있습니다. 이것은 많은 이점을 가지고 있습니다

흠, 여기 일정이 있을 수도 있다는 말이 있어요 😆
이제 진지하게, 이것은 우리가 항상 목표로 삼았던 좋은 방향입니다. PriorityQueue 는 Heap 를 하지 않는 이유가 결코 아닙니다. Heap 가 CoreFX에 포함되지 않고 CoreFXExtensions 리포지토리에 PowerCollections와 함께 고급 데이터 구조로 "그냥" 유지될 수 있다는 사실에 우리 모두 괜찮다면 저는 괜찮습니다.

중요 참고 사항: 이러한 접근 방식을 원하면 우선 순위 대기열과 힙을 함께 설계해야 합니다. 목적이 다르고 한 솔루션이 다른 솔루션이 제공하지 않는 것을 제공할 것이기 때문입니다.

왜 함께 해야 하는지 모르겠습니다. IMO 우리는 PriorityQueue 에 집중하고 "적절한" Heap 를 병렬/나중에 추가할 수 있습니다. 누군가 함께 하면 상관없지만 사용하기 쉬운 PriorityQueue 의 존재가 "적절한/고성능" 고급 Heap 디자인에 영향을 미치는 강력한 이유를 보지 못합니다.

IQueue

작성해주셔서 감사합니다. 귀하의 요점을 감안할 때 IQueue 을 추가하는 데 방해가 될 필요는 없다고 생각합니다. IMO 가지고 있는 것이 좋습니다. 선택자가 있다면 그것은 당연할 것입니다. 그러나 PriorityQueue ( Enqueue 및 Update 에만 해당)에서 선택기를 호출할 때 설명하는 데 이상함과 복잡함을 가져오기 때문에 선택기 접근 방식이 마음에 들지 않습니다.

대체(객체) 핸들

그러한 과부하 IMO를 갖는 것은 실제로 나쁜 생각이 아닙니다(약간 추악하긴 하지만). 핸들이 잘못된 PriorityQueue , 즉 O(log n)에서 온 것임을 감지할 수 있어야 합니다.
API 리뷰어가 거부할 것 같은 느낌이 들지만 IMO는 시도해 볼 가치가 있습니다...

안정

안정성이 성능/메모리 오버헤드와 함께 제공되지 않는다고 생각합니다( Update 이미 떨어뜨렸거나 Update 을 논리적인 Remove + Enqueue 취급한다고 가정). 그래서 우리는 기본적으로 요소의 나이를 재설정합니다). 비교자 결과 0을 -1로 처리하면 모든 것이 좋습니다 ... 아니면 내가 뭔가를 놓치고 있습니까?

선택기 및 IQueue<T>

2개의 제안을 하는 것이 좋습니다.

• PriorityQueue<T,U> 선택자와 IQueue 없이
• PriorityQueue<T> 선택기 및 IQueue

꽤 많은 사람들이 위에서 암시했습니다.

Re: @pgolebiowski의 최신 제안 - https://github.com/dotnet/corefx/issues/574#issuecomment -308427321

IQueue<T> - Remove 및 TryRemove 추가할 수 있지만 Queue<T> 에는 없습니다.

Queue<T> 추가하는 것이 의미가 있습니까? ( @eickle도 동의) 그렇다면 추가 항목도 번들로
인터페이스에 추가하고 의심스럽거나 Queue<T> 추가도 필요하다고 말합니다.
IsEmpty 대해 동일 -- Queue<T> 및 Stack<T> 추가가 필요한 것은 무엇이든 인터페이스에 표시합시다(검토 및 요약이 더 쉬울 것입니다).
@pgolebiowski IQueue<T> 에 구현될 클래스 목록과 함께 의견을 추가해 주시겠습니까?

PriorityQueue<T>

구조체 열거자를 추가해 보겠습니다( 요즘에는 일반적인 BCL 패턴이라고 생각합니다). 스레드에서 두 번 호출된 다음 삭제/잊혀졌습니다.

힙

네임스페이스 선택: 아직 네임스페이스 결정에 시간을 낭비하지 말자. Heap 가 CoreFxExtensions에서 끝나면 어떤 종류의 네임스페이스를 허용할지 아직 모릅니다. 아마도 Community.* 또는 이와 비슷한 것입니다. CoreFxExtensions 목적/동작 모드 논의 결과에 따라 다릅니다.
참고: CoreFxExtensions 리포지토리에 대한 한 가지 아이디어는 검증된 커뮤니티 구성원에게 쓰기 권한을 부여하고 필요할 때 .NET 팀/MS가 중재자가 되는 조언(API 검토 전문 지식 포함)만 제공하는 .NET 팀이 있는 커뮤니티에서 주로 주도하도록 하는 것입니다. 그것이 우리가 착륙하는 곳이라면 System.* 또는 Microsoft.* 네임스페이스에서 원하지 않을 것입니다. (면책 조항: 초기 생각, 아직 결론을 내리지 마십시오. 다른 대안 거버넌스 아이디어가 진행 중입니다.)

TryRemove 하고 Remove 를 bool Remove 합니다. 여기에서 다른 컬렉션 클래스와 정렬하는 것이 중요합니다. 개발자는 "컬렉션의 remove()는 throw하지 않습니다"라는 많은 근육 메모리를 갖게 됩니다. 많은 개발자가 잘 테스트하지 않는 영역이며 정상적인 동작이 변경되면 많은 놀라움을 유발할 것입니다.

👍 적어도 다른 컬렉션과 정렬하는 것을 고려해야 합니다. 누군가 다른 컬렉션의 Remove 패턴을 스캔할 수 있습니까?

@ebickle 현재 API 계약과 디자인 근거가 포함된 .md 파일 한두 개를 호스팅할 github 저장소를 만드는 아이디어에 대해 어떻게 생각하십니까?

CoreFxLabs 에서 직접 호스팅해 보겠습니다. 👍

@karelz

우선 순위를 무시하고 우선 순위 대기열의 항목만 열거하는 방법이 있어야 합니까?

좋은 질문. 무엇을 제안하시겠습니까? IEnumerable<TElement> Elements { get; } ?

예, 또는 ElementsCollection 반환하는 속성이 가장 좋은 옵션일 것입니다. 특히 Dictionary<K, V>.Values 와 유사하기 때문에.

우선 순위가 같은 항목의 끝에 항목을 항상 추가합니다(기본적으로 비교자 결과 0을 -1로 간주). 작동해야 하는 IMO.

그것은 힙이 작동하는 방식이 아니며 "같은 우선 순위 항목의 끝"이 없습니다. 동일한 우선 순위를 가진 항목은 힙 전체에 분산될 수 있습니다(현재 최소값에 가깝지 않은 경우).

다시 말해서, 안정성을 유지하기 위해서는 삽입할 때 뿐만 아니라 나중에 힙에서 항목을 이동할 때도 0의 비교자 결과를 -1로 고려해야 합니다. 그리고 제대로 하려면 version 와 priority 와 같은 것을 저장해야 한다고 생각합니다.

아이큐- Remove 및 TryRemove를 추가할 수 있지만 Queue그것들이 없습니다.

대기열에 추가하는 것이 의미가 있습니까?? ( @eickle도 동의) 그렇다면 추가 항목도 번들로

Remove 를 IQueue<T> 추가해서는 안 된다고 생각합니다. 그리고 Contains 가 이상하다고 제안할 수도 있습니다. NotSupportedException을 던지기 시작하지 않는 한 인터페이스의 유용성과 사용할 수 있는 Queue 유형을 제한합니다. 즉, 범위는 무엇입니까?

바닐라 대기열, 메시지 대기열, 분산 대기열, ServiceBus 대기열, Azure Storage 대기열, ServiceFabric Reliable Queues 등을 위한 것입니까? (비동기 방법을 선호하는 일부에 대해 설명)

그것은 힙이 작동하는 방식이 아니며 "같은 우선 순위 항목의 끝"이 없습니다. 동일한 우선 순위를 가진 항목은 힙 전체에 분산될 수 있습니다(현재 최소값에 가깝지 않은 경우).

공정한 포인트. 나는 그것을 이진 검색 트리로 생각하고 있었다. 내 ds 기본을 닦을 필요가 있습니다. :)
글쎄, 우리는 그것을 다른 ds(배열, 이진 검색 트리(또는 공식 이름이 무엇이든) - @stephentoub 에 아이디어/제안이 있음)로 구현하거나 임의의 순서로 정착합니다. version 또는 age 필드를 유지하는 것이 안정성을 보장할 가치가 있다고 생각하지 않습니다.

@ebickle 현재 API 계약과 디자인 근거가 포함된 .md 파일 한두 개를 호스팅할 github 저장소를 만드는 아이디어에 대해 어떻게 생각하십니까?

@karelz CoreFxLabs 에서 직접 호스팅해 보겠습니다.

이 문서를 살펴보십시오.

2개의 제안을 하는 것이 좋습니다.

• 우선순위 큐선택기 및 IQueue 없이(복잡할 수 있음)
• 우선순위 큐선택기 및 IQueue 사용

선택기를 아예 없앴습니다. 하나의 통합된 PriorityQueue<T, U> 원할 경우에만 필요합니다. 두 개의 클래스가 있는 경우 - 글쎄, 비교자로 충분합니다.

추가/변경/제거할 가치가 있는 것이 있으면 알려주십시오.

@pgolebiowski

문서가 좋아 보입니다. .NET 핵심 라이브러리에서 볼 것으로 기대되는 견고한 솔루션처럼 느껴지기 시작했습니다. :)

• 중첩된 Enumerator 클래스를 추가해야 합니다. 상황이 변경되었는지 확실하지 않지만 몇 년 전에 자식 구조를 사용하면 GetEnumerator() 결과를 boxing하여 발생하는 가비지 수집기 할당을 피할 수 있습니다. 예를 들어 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(); } }

• 우선순위 큐중첩된 Enumerator 구조체도 있어야 합니다.

• 저는 오랫동안 TryRemove 없이 "public bool Remove(T element)"를 사용하기 위해 여전히 투표하고 있으며 이를 변경하면 개발자 실수가 발생할 가능성이 높습니다. API 검토 팀이 차임벨을 울리도록 할 수는 있지만 내 마음에는 열린 질문입니다.

• 생성자에서 초기 용량을 지정하거나 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 마스터 브랜치에 대한 PR로 문서를 제출할 수 있습니까? @ianhays @safern에 태그를 지정 하면 PR을 병합할 수 있습니다.
그런 다음 CoreFxLab 문제를 사용하여 특정 디자인 포인트에 대한 추가 토론을 할 수 있습니다. 이 메가 문제보다 더 쉬울 것입니다(이곳에서 Area-PriorityQueue를 생성하기 위해 이메일을 시작했습니다).

CoreFxLab 풀 리퀘스트에 대한 링크를 여기에 넣으시겠습니까?

• @ebickle @jnm2 -- 추가됨
• @karelz @SamuelEnglad -- 참조

API가 현재 형식(2개 클래스)으로 승인되면 4차 힙을 사용하여 두 가지 모두에 대한 구현으로 CoreFXLab에 대한 또 다른 PR을 생성합니다( 구현 참조 ). PriorityQueue<T> 는 아래에 하나의 배열만 사용하고 PriorityQueue<TElement, TPriority> 는 두 개를 사용하고 요소를 함께 재배열합니다. 이렇게 하면 추가 할당을 절약하고 최대한 효율적으로 사용할 수 있습니다. 초록불이 들어오면 추가하겠습니다.

ConcurrentQueue와 같은 스레드로부터 안전한 버전을 만들 계획이 있습니까?

나는 :heart: 이것의 동시 버전을 보고 IProducerConsumerCollection<T> 구현하여 BlockingCollection<T> 등과 함께 사용할 수 있습니다.

@aobatact @khellang 완전히 다른 스레드처럼 들립니다.

• 검토할 다른 API,
• 아마도 다른 네임스페이스,
• 아마도 완전히 다른 구현도 마찬가지일 것 입니다.

나는 그것이 매우 가치 있다는 것에 동의합니다 :win:!

public bool IsEmpty();

이것이 왜 방법입니까? IsEmpty 가 있는 프레임워크의 다른 모든 컬렉션에는 속성으로 포함됩니다.

IsEmpty { get; } 으로 top-post 의 제안을 업데이트했습니다.
corefxlab repo에 최신 제안 문서에 대한 링크도 추가했습니다.

안녕하세요 여러분,
가능하면 업데이트를 지원하면 좋겠다는 의견이 많은 것 같아요. 아무도 이것이 그래프 검색에 유용한 기능이라는 것을 의심하지 않았다고 생각합니다.

하지만 여기저기서 반론이 제기됐다. 그래서 내 이해를 확인할 수 있습니다. 주요 반대 의견은 다음과 같습니다.
-중복 요소가 있을 때 업데이트가 어떻게 작동해야 하는지 명확하지 않습니다.
-중복 요소가 우선 순위 대기열에서 지원하는 것이 바람직한지 여부에 대한 몇 가지 논쟁이 있습니다.
- 우선 순위를 업데이트하기 위해 지원 데이터 구조에서 요소를 찾기 위한 추가 조회 데이터 구조를 갖는 것이 비효율적일 수 있다는 일부 우려가 있습니다. 특히 업데이트가 수행되지 않는 시나리오의 경우! 및/또는 최악의 경우 성능 보장에 영향을 미칩니다...

내가 놓친 것이 있습니까?

좋아, 하나 더 있었던 것 같은데 - 의미상 'updateFirst' 또는 'removeFirst'를 의미하는 업데이트/제거가 이상할 수 있다고 주장되었습니다. :)

어떤 버전의 .Net Core에서 PriorityQueue를 사용할 수 있습니까?

@memoryfraction .NET Core 자체에는 아직 PriorityQueue가 없습니다(제안이 있지만 최근에 시간이 없었습니다). 그러나 Microsoft .NET Core 배포판에 있어야 할 이유는 없습니다. 커뮤니티의 모든 사용자가 NuGet에 하나를 추가할 수 있습니다. 아마도 이 문제에 대해 누군가 제안할 수 있습니다.

@memoryfraction .NET Core 자체에는 아직 PriorityQueue가 없습니다(제안이 있지만 최근에 시간이 없었습니다). 그러나 Microsoft .NET Core 배포판에 있어야 할 이유는 없습니다. 커뮤니티의 모든 사용자가 NuGet에 하나를 추가할 수 있습니다. 아마도 이 문제에 대해 누군가 제안할 수 있습니다.

답장과 제안에 감사드립니다.
C#을 사용하여 leetcode를 연습하고 SortedSet을 사용하여 중복 요소가 있는 집합을 처리해야 할 때. 문제를 해결하려면 고유한 ID로 요소를 래핑해야 합니다.
그래서 앞으로는 .NET Core에 우선 순위 큐가 있으면 더 편리할 것이기 때문에 선호합니다.

이 문제의 현재 상태는 무엇입니까? 최근에 PriorityQueue가 필요하다는 것을 알게 되었습니다.

이 제안은 기본적으로 컬렉션 초기화를 활성화하지 않습니다. PriorityQueue<T> 에는 Add 메서드가 없습니다. 컬렉션 초기화는 중복 메서드를 추가할 만큼 충분히 큰 언어 기능이라고 생각합니다.

누군가가 공유하고 싶은 빠른 바이너리 힙을 가지고 있다면 내가 작성한 것과 비교하고 싶습니다.
제안한 대로 API를 완전히 구현했습니다. 그러나 힙이 아닌 단순한 정렬된 배열을 사용합니다. 나는 가장 낮은 값의 항목을 마지막에 유지하므로 일반적인 순서의 역순으로 정렬됩니다. 항목 수가 32개 미만이면 간단한 선형 검색을 사용하여 새 값을 삽입할 위치를 찾습니다. 그 후 이진 검색을 사용했습니다. 임의의 데이터를 사용하여 대기열을 채운 다음 비우는 간단한 경우에 이 방법이 바이너리 힙보다 빠르다는 것을 알았습니다.
시간이 있다면 공개 git repo에 저장하여 사람들이 이를 비판하고 이 댓글에 위치를 업데이트할 수 있도록 하겠습니다.

@SunnyWar 현재 사용하고 있습니다: https://github.com/BlueRaja/High-Speed-Priority-Queue-for-C-Sharp
좋은 성능을 가지고 있습니다. GenericPriorityQueue 에 대해 구현을 테스트하는 것이 합리적이라고 생각합니다.

제 이전 글은 무시해주세요. 테스트에서 오류를 발견했습니다. 일단 수정되면 바이너리 힙이 가장 잘 수행됩니다.

@karelz 이 제안은 현재 ICollection<T> 어디에 있습니까? 컬렉션이 분명히 읽기 전용이 아님에도 불구하고 지원되지 않는 이유를 이해하지 못했습니다.

@karelz re dequeue order의 미해결 질문: 나는 가장 낮은 우선순위 값이 먼저 제거되는 것에 찬성한다고 주장합니다. 최단 경로 알고리즘에 편리하고 타이머 대기열 구현에도 자연스럽습니다. 그리고 이것이 제가 생각하는 두 가지 주요 시나리오입니다. '높은' 우선 순위 및 '높은' 숫자 값과 관련된 언어적 주장이 아닌 한 반대 주장이 무엇인지 잘 모르겠습니다.

@karelz re enumeration order... 컬렉션의 내부 데이터 힙을 제자리 에 정렬된 순서 Sort() 메소드를 갖는 것은 어떻습니까 (O (n log n)). 그리고 호출 Enumerate() 후 Sort() O (N)에서 컬렉션을 열거합니다. 그리고 Sort()가 호출되지 않으면 O(n)에서 정렬되지 않은 순서로 요소를 반환합니까?

Triage: 이것을 구현해야 하는지 여부에 대한 합의가 없는 것 같아서 미래로 이동합니다.

듣기에 매우 실망스럽습니다. 이를 위해 여전히 타사 솔루션을 사용해야 합니다.

타사 솔루션을 사용하지 않는 주된 이유는 무엇입니까?

힙 데이터 구조는 leetcode를 수행하기 위한 필수 요소입니다.
더 많은 leetcode, 더 많은 C# 코드 인터뷰는 더 많은 C# 개발자를 의미합니다.
더 많은 개발자는 더 나은 생태계를 의미합니다.
더 나은 생태계는 우리가 내일 C#으로 프로그래밍할 수 있다는 것을 의미합니다.

요약하자면 이것은 기능일 뿐만 아니라 미래입니다. 이것이 이슈가 '미래'로 분류되는 이유입니다.

타사 솔루션을 사용하지 않는 주된 이유는 무엇입니까?

표준이 없을 때 모든 사람은 각자 고유한 특성이 있는 고유한 것을 발명하기 때문입니다.

내가 작업하고 있는 것과 관련이 있기 때문에 System.Collections.Generic.PriorityQueue<T> 원했던 적이 많이 있습니다. 이 제안은 이제 5년 동안 지속되었습니다. 왜 아직도 일어나지 않았습니까?

왜 아직도 일어나지 않았습니까?

우선 기아, 말장난이 없습니다. 컬렉션을 디자인하는 것은 작업입니다. 컬렉션을 BCL에 넣으면 컬렉션이 교환되는 방식, 구현하는 인터페이스, 의미가 무엇인지 등에 대해 생각해야 하기 때문입니다. 이 중 어느 것도 로켓 과학이 아니지만 시간이 걸립니다. 또한, 디자인을 판단할 구체적인 사용자 사례와 고객이 필요합니다. 이는 컬렉션이 점점 더 전문화될수록 더 어려워집니다. 지금까지 그보다 더 중요하게 여겨지는 다른 작업이 항상 있었습니다.

불변 컬렉션이라는 최근의 예를 살펴보겠습니다. 그들은 불변성에 관한 VS의 사용 사례를 위해 BCL 팀에서 일하지 않는 누군가에 의해 설계되었습니다. 우리는 그와 함께 API "BCL-ified"를 얻었습니다. 그리고 Roslyn이 온라인 상태가 되었을 때 우리는 가능한 한 많은 곳에서 그들의 사본을 우리 것으로 교체했으며 피드백을 기반으로 디자인(및 구현)을 많이 수정했습니다. "영웅" 시나리오 없이는 어렵습니다.

표준이 없을 때 모든 사람은 각자 고유한 특성이 있는 고유한 것을 발명하기 때문입니다.

@masonwheeler 가 PriorityQueue<T> 입니까? 호환되지 않고 "대부분을 위한 최고의 라이브러리"로 명확하게 인정되지 않는 여러 타사 옵션이 있습니까? (제가 조사를 안해봐서 답은 모르겠네요)

@eiriktsarpalis 구현 여부에 대한 합의가 어떻게 이루어지지 않습니까?

@terrajobst 잘 알려진 애플리케이션으로 잘 알려진 패턴인데 영웅 시나리오가 정말 필요한가요? 여기에는 거의 혁신이 필요하지 않습니다. 이미 완전히 개발된 인터페이스 사양도 있습니다. 제 생각에 이 유틸리티가 존재하지 않는 진짜 이유는 너무 어렵거나 수요나 사용 사례가 없기 때문이 아닙니다. 진짜 이유는 실제 소프트웨어 프로젝트의 경우 프레임워크 라이브러리에 넣을 정치 캠페인을 하는 것보다 직접 만드는 것이 더 쉽기 때문입니다.

타사 솔루션을 사용하지 않는 주된 이유는 무엇입니까?

@terrajobst
저는 개인적으로 타사 솔루션이 항상 예상대로 작동하지 않거나 현재 언어 기능을 사용하지 않는다는 경험을 했습니다. 표준화된 버전 i(사용자로서)를 사용하면 얻을 수 있는 최상의 성능을 확신할 수 있습니다.

@danmosemsft

@masonwheeler 가 PriorityQueue<T> 입니까? 호환되지 않고 "대부분을 위한 최고의 라이브러리"로 명확하게 인정되지 않는 여러 타사 옵션이 있습니까? (제가 조사를 안해봐서 답은 모르겠네요)

예. 그냥 구글 "C# 우선 순위 큐"; 첫 페이지는 다음으로 가득 차 있습니다.

1. Github 및 기타 호스팅 사이트의 우선 순위 대기열 구현
2. Collections.Generic에 공식 우선 순위 대기열이 없는 이유를 묻는 사람들
3. 고유한 우선 순위 대기열 구현을 구축하는 방법에 대한 자습서

@terrajobst 잘 알려진 애플리케이션으로 잘 알려진 패턴인데 영웅 시나리오가 정말 필요한가요? 여기에는 거의 혁신이 필요하지 않습니다.

제 경험상 그렇습니다. 악마는 세부 사항에 있으며 일단 API를 출시하면 실제로 큰 변화를 줄 수 없습니다. 그리고 사용자가 볼 수 있는 많은 구현 선택 사항이 있습니다. API를 잠시 동안 OOB로 미리 볼 수 있지만 피드백을 확실히 수집할 수는 있지만 영웅 시나리오가 없다는 것은 타이 브레이커가 없다는 것을 의미하므로 종종 영웅이 시나리오가 도착하면 데이터 구조가 요구 사항을 충족하지 않습니다.

분명히 우리는 영웅이 필요합니다. 😛

@masonwheeler 나는 당신의 링크가 이것으로 연결될 것이라고 생각했습니다 😄 이제 내 머리 속에 있습니다.

@terrajobst가 말했듯이 여기서 우리의 주요 문제는 리소스/주의였습니다(원하는 경우 우리를 비난할 수 있음). 대본.

[명확성을 위해 편집됨]

@danmosemsft 아니, 그 노래를

Hero 앱 후보 #1: TimerQueue.Portable에서 사용하는 것은 어떻습니까?

https://github.com/dotnet/runtime/blob/4f9ae42d861fcb4be2fcd5d3d55d5f227d30e723/src/libraries/System.Private.CoreLib/src/System/Threading/TimerQueue.Portable.cs

Hero 앱 후보 #1: TimerQueue.Portable에서 사용하는 것은 어떻습니까?

이미 고려하고 프로토타입을 만들고 폐기했습니다. 타이머가 빠르게 생성되고 소멸되는 매우 일반적인 경우(예: 타임아웃의 경우)는 덜 효율적입니다.

@stephentoub 타이머 수가 적은 일부 시나리오에서는 효율성이

타이머 수가 적은 일부 시나리오에서는 효율성이 떨어진다고 가정합니다. 그러나 어떻게 확장됩니까?

아니요, 일반적인 경우는 어떤 순간에도 많은 타이머가 있지만 아주 적은 수의 타이머가 발사된다는 것을 의미합니다. 타이머가 타임아웃에 사용될 때의 결과입니다. 그리고 중요한 것은 데이터 구조에서 추가 및 제거할 수 있는 속도입니다... 0(1)이고 매우 낮은 오버헤드를 원합니다. O(log N)가 되면 문제입니다.

우선 순위 대기열이 있으면 확실히 C#이 인터뷰에 더 친숙해집니다.

우선 순위 대기열이 있으면 확실히 C#이 인터뷰에 더 친숙해집니다.

네, 맞습니다.
저도 같은 이유로 찾고 있습니다.

@stephentoub 실제로 발생하지 않는 시간 초과의 경우 이는 나에게 완벽합니다. 그러나 갑자기 많은 시간 초과가 발생하기 시작하면 갑자기 패킷이 손실되거나 서버가 응답하지 않는 등의 이유로 시스템에 어떤 일이 발생합니까? 또한 System.Timer에서 반복 타이머가 동일한 구현을 사용합니까? 거기에서 만료되는 타임아웃은 '행복한 길'이 될 것입니다.

그러나 갑자기 많은 시간 초과가 발생하기 시작하면 시스템에 어떤 일이 발생하는지 궁금합니다.

시도 해봐. :)

우리는 이전 구현에서 많은 실제 워크로드가 어려움을 겪는 것을 보았습니다. 우리가 살펴본 모든 경우에 새로운 것(우선순위 대기열을 사용하지 않고 대신에 곧 타이머와 조만간 타이머가 간단하게 분할됨)이 문제를 해결했으며 그것.

또한 System.Timer에서 반복 타이머가 동일한 구현을 사용합니까?

예. 그러나 실제 응용 프로그램에서는 일반적으로 상당히 고르게 분포되어 있습니다.

5년이 지난 지금도 PriorityQueue는 없습니다.

Rx에는 고도로 프로덕션 테스트를 거친 우선 순위 대기열 클래스가 있습니다.

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

5년이 지난 지금도 PriorityQueue는 없습니다.

우선 순위가 높지 않아야합니다 ...

그들은 repo 레이아웃을 중심으로 변경되었습니다. 새 위치는 https://github.com/dotnet/reactive/blob/master/Rx.NET/Source/src/System.Reactive/Internal/PriorityQueue.cs입니다.

@stephentoub 하지만 실제로는 @eiriktsarpalis 일 수도 있습니다. 지금 우리는 실제로 이에 대한 관심이 있습니까? API 디자인이 완성되면 기꺼이 작업하겠습니다.

나는 이것이 아직 해결되었다는 선언을 보지 못했고 지정된 킬러 앱 없이 최종 API 디자인이 있을 수 있는지 확실하지 않습니다. 하지만...
최고의 킬러 앱 후보가 프로그래밍 경연/강의/인터뷰라고 가정하면 상단에 있는 Eric의 디자인은 충분히 유용해 보인다고 생각합니다... 그리고 여전히 제 반대 제안이 남아 있습니다(새로 수정되었지만 아직 철회되지 않았습니다!)

https://github.com/TimLovellSmith/corefxlab/blob/priorityQueueSpecSolved/docs/specs/priority-queue.md

내가 그들 사이에서 알아차린 주요 차이점은 사전처럼 말해야 하는지 여부와 선택자가 사물이어야 하는지 여부입니다.

왜 그것이 사전이 되고 싶었는지 정확히 잊어버리기 시작했습니다. 우선 순위를 업데이트하기 위해 색인화된 할당자가 있고 우선 순위가 있는 키를 열거할 수 있다는 것은 나에게 좋은 일처럼 보였고 매우 사전과 같았습니다. 디버거에서 사전으로 시각화할 수 있다는 것도 좋은 방법이 될 수 있습니다.

선택자는 실제로 예상되는 클래스 인터페이스인 FWIW를 대폭 변경한다고 생각합니다. 선택기는 생성 시 기본적으로 제공되는 것이어야 하며, 가지고 있다면 다른 사람에게 우선 순위 값을 전달할 필요가 없습니다. 우선 순위를 알고 싶으면 선택기를 호출하면 됩니다. 따라서 선택자를 제외하고는 모든 메소드 서명에 우선순위 매개변수를 갖고 싶지 않을 것입니다. 따라서 이 경우에는 일종의 보다 전문화된 'PrioritySet' 클래스가 됩니다. [불순한 선택자는 버그 문제일 가능성이 있습니다!]

@TimLovellSmith 이 동작에 대한 욕구를 이해하지만 5년 동안 요청했기 때문에 선택기로 배열 기반 바이너리 힙을 구현하고 Queue.cs 와 동일한 API 노출 영역을 공유하는 것이 합리적이지 않을까요 ? Queue.cs ? 나는 그것이 지금까지 대부분의 사용자에게 필요한 것이라고 생각합니다. 내 생각에 이 데이터 구조는 API 디자인에 동의할 수 없기 때문에 구현되지 않았지만 PriorityQueue 만드는 경우 Queue .

@Jlalond 그래서 여기에 제안, 응? 힙 기반 배열 구현에 이의가 없습니다. 이제 선택자에 대해 내가 가지고 있었던 가장 큰 이의를 기억합니다. 우선 순위 업데이트를 올바르게 수행하는 것이 쉽지 않다는 것입니다. 평범한 오래된 대기열에는 우선 순위 업데이트 작업이 없지만 요소 우선 순위 업데이트는 많은 우선 순위 대기열 알고리즘에서 중요한 작업입니다.
손상된 우선 순위 대기열 구조를 디버그할 필요가 없는 API를 사용하는 경우 사람들은 영원히 감사해야 합니다.

@TimLovellSmith 죄송합니다 Tim, IDictionary 의 상속을 명확히 했어야 했습니다.

우선 순위가 변경되는 사용 사례가 있습니까?

나는 당신의 구현을 좋아하지만 IDictionary Behavior의 복제를 줄일 수 있다고 생각합니다. 나는 우리가 IDictionary<> 에서 상속해서는 안 된다고 생각하지만 ICollection만 상속해서는 안 된다고 생각합니다. 사전 액세스 패턴이 직관적이지 않다고 생각하기 때문입니다.

그러나 T를 반환하는 것과 관련된 우선 순위가 의미가 있다고 생각하지만 대기열에 넣거나 대기열에서 제거할 때 데이터 구조 내 요소의 우선 순위를 알아야 하는 사용 사례를 모르겠습니다.

@Jlalond
우선 순위 대기열이 있는 경우 간단하고 효율적으로 수행할 수 있는 모든 작업을 지원해야 합니다.
이런 종류의 데이터 구조/추상화에 익숙한 사람들은 '기대'합니다.

업데이트 우선 순위는 두 범주에 모두 속하기 때문에 API에 속합니다. 업데이트 우선 순위는 힙 데이터 구조로 작업을 수행하는 복잡성이 전체 알고리즘의 복잡성에 영향을 미치고 정기적으로 측정된다는 많은 알고리즘에서 충분히 중요합니다. 다음을 참조하세요.
https://en.wikipedia.org/wiki/Priority_queue#Specialized_heaps

TBH는 주로 알고리즘과 효율성 측면에서 흥미롭고 측정된 reduce_key를 사용하므로 개인적으로 API에 DecreasePriority()만 있고 실제로 UpdatePriority가 없는 것이 좋습니다.
하지만 편의상 API 사용자에게 모든 변경 사항이 증가 또는 감소 여부에 대해 걱정하는 것을 귀찮게 하지 않는 것이 더 좋을 것 같습니다. joe 개발자가 왜 감소만 지원하고 증가는 지원하지 않는지 궁금하지 않고 즉시 '업데이트'할 수 있도록 일반 업데이트 우선 순위 API를 갖는 것이 가장 좋지만 문서 감소용으로 사용할 때는 비용 X, 증가용으로 사용할 때는 제거+추가와 동일하게 구현되기 때문에 비용이 Y입니다.

RE 사전 동의했습니다. 더 간단하다는 이름으로 내 제안에서 제거했습니다.
https://github.com/TimLovellSmith/corefxlab/blob/priorityQueueSpecSolved/docs/specs/priority-queue.md

큐에 넣거나 큐에서 뺄 때 데이터 구조 내 요소의 우선 순위를 알아야 하는 사용 사례를 모르겠습니다.

이 댓글이 무슨 내용인지 잘 모르겠습니다. 요소를 큐에서 빼기 위해 요소의 우선 순위를 알 필요는 없습니다. 그러나 대기열에 넣을 때 우선 순위를 알아야 합니다. 요소를 큐에서 제거할 때 요소의 최종 우선순위를 배우고 싶을 수도 있습니다. 그 값은 거리와 같은 의미를 가질 수 있기 때문입니다.

@TimLovellSmith

이 댓글이 무슨 내용인지 잘 모르겠습니다. 요소를 큐에서 빼기 위해 요소의 우선 순위를 알 필요는 없습니다. 그러나 대기열에 넣을 때 우선 순위를 알아야 합니다. 요소를 큐에서 제거할 때 요소의 최종 우선순위를 배우고 싶을 수도 있습니다. 그 값은 거리와 같은 의미를 가질 수 있기 때문입니다.

죄송합니다. 키 값 쌍에서 Tpriorty가 의미하는 바를 잘못 이해했습니다.

자, 마지막 두 질문은 왜 Tpriority가 있는 KeyValuePair인지, 그리고 재우선순위 지정을 위해 내가 볼 수 있는 가장 좋은 시간은 N log N입니다. 나는 그것이 가치 있다는 데 동의하지만 그 API는 어떻게 생겼을까요?

우선순위 재지정에 대해 내가 볼 수 있는 가장 좋은 시간은 N log N입니다.

한 항목이 아닌 N 항목의 우선 순위를 다시 정하는 것이 가장 좋은 시기죠?
문서를 명확히 하겠습니다. "UpdatePriority | O(log n)"은 "UpdatePriority(단일 항목) | O(log n)"로 읽어야 합니다.

@TimLovellSmith 의미가 있지만 요소를 제거한 다음 다시 삽입해야 하므로 우선 순위 업데이트가 실제로 ne O2 *(log n)가 되지 않습니까? 이것이 바이너리 힙이라는 가정을 바탕으로

@TimLovellSmith 의미가 있지만 요소를 제거한 다음 다시 삽입해야 하므로 우선 순위 업데이트가 실제로 ne O2 *(log n)가 되지 않습니까? 이것이 바이너리 힙이라는 가정을 바탕으로

2와 같은 상수 요인은 N의 크기가 커짐에 따라 대부분 무의미해지기 때문에 복잡도 분석에서 일반적으로 무시됩니다.

이해했습니다. 대부분 Tim이 할 수 있는 흥미로운 아이디어가 있는지 알고 싶었습니다.
한 번의 작업 :)

2020년 8월 18일 화요일 23:51 masonwheeler [email protected]이(가) 작성했습니다.

@TimLovellSmith https://github.com/TimLovellSmith 이해가 되지만
우선 순위 업데이트는 실제로 ne O2 * (log n)가 필요하지 않습니다.
요소를 제거한 다음 다시 삽입하시겠습니까? 내 가정을 기반으로
바이너리 힙

2와 같은 상수 요인은 일반적으로 복잡성 분석에서 무시됩니다.
N의 크기가 커짐에 따라 대부분 무의미해지기 때문입니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/dotnet/runtime/issues/14032#issuecomment-675887763 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AF76XTI3YK4LRUVTOIQMVHLSBNZARANCNFSM4LTSQI6Q
.

@Jlalond
참신한 아이디어가 없다, 나는 상수 요인을 무시했을뿐이지만 감소도 증가와 다릅니다.

우선 순위 업데이트가 감소하는 경우 제거하고 다시 추가할 필요가 없습니다. 거품만 발생하므로 1 * O(log n) = O(log n)입니다.
우선 순위 업데이트가 증가하는 경우 해당 업데이트를 제거하고 다시 추가해야 하므로 2 * O(log n) = 여전히 O(log n)입니다.

다른 사람이 제거 + 읽기보다 우선 순위를 높이기 위해 더 나은 데이터 구조/알고리즘을 발명했을 수도 있지만 나는 그것을 찾으려고 시도하지 않았습니다. O(log n) 충분히 좋은 것 같습니다.

KeyValuePair 는 사전인 동안 인터페이스에 몰래 들어왔지만 사전이 제거된 후에도 살아남았고, 주로 _요소 컬렉션을 우선 순위로 반복할 수 있도록 했습니다. 또한 우선 순위에 따라 요소를 큐에서 빼낼 수 있습니다. 그러나 다시 단순함을 위해 우선 순위가 있는 dequeue는 Dequeue API의 '고급' 버전에만 있어야 합니다. (TryDequeue :D)

변경하겠습니다.

@TimLovellSmith Cool, 수정된 제안을 기대합니다. 이 작업을 시작할 수 있도록 검토를 위해 제출할 수 있습니까? 또한, 병합 시간을 개선하기 위해 페어링 대기열에 약간의 자극이 있다는 것을 알고 있지만 여전히 어레이 기반 바이너리 힙이 가장 전반적인 성능이 될 것이라고 생각합니다. 생각?

@Jlalond
Peek + Dequeue API를 단순화하기 위해 약간의 변경을 했습니다.
일부 ICollectionKeyValuePair와 관련된 api는 여전히 남아 있습니다. 대체할 더 나은 것이 없기 때문입니다.
같은 홍보 링크입니다. 검토를 위해 제출해야 하는 다른 방법이 있습니까?

https://github.com/TimLovellSmith/corefxlab/blob/priorityQueueSpecSolved/docs/specs/priority-queue.md

배열 기반 힙만큼 빠르거나 그 이상인 한 어떤 구현을 사용하는지 신경쓰지 않습니다.

@TimLovellSmith 실제로 API 검토에 대해 아는 것이 없지만 @danmosemsft 가 우리를 올바른 방향으로

내 첫 번째 질문은이다? 나는 그것이 int 또는 부동 소수점 숫자라고 가정하지만 대기열에 "내부"인 숫자를 선언하는 것은 나에게 이상하게 보입니다.

그리고 저는 실제로 바이너리 힙을 선호하지만 우리 모두가 그 방향으로 가고 있는지 확인하고 싶었습니다.

@eiriktsarpalis @layomia 는 지역 소유자 이며 API 검토를 통해 이를 관리해야 합니다. 나는 토론을 따르지 않았습니다. 우리는 합의점에 도달했습니까?

과거에 논의한 바와 같이 핵심 라이브러리는 모든 컬렉션, 특히 독단적이거나 틈새 시장인 컬렉션에 가장 적합한 장소는 아닙니다. 예를 들어, 매년 배송합니다. 도서관만큼 빨리 이동할 수는 없습니다. 우리는 그 격차를 채우기 위해 컬렉션 팩을 중심으로 커뮤니티를 구축하는 것을 목표로 합니다. 그러나 이것에 대한 84개의 엄지손가락은 핵심 라이브러리에서 이에 대한 광범위한 필요성이 있음을 시사합니다.

@Jlalond 죄송합니다. 첫 번째 질문이 무엇인지 잘 이해하지 못했습니다. Tpriority가 일반적인 이유를 묻고 있습니까? 아니면 숫자여야 하나요? 많은 사람들이 숫자가 아닌 우선 순위 유형을 사용하게 될지 의심됩니다. 그러나 그들은 byte, int, long, float, double 또는 enum을 사용하는 것을 선호할 수 있습니다.

@TimLovellSmith 예, 그것이 일반적인 것인지 알고 싶었습니다.

@danmosemsft 감사합니다 Dan. 내 제안[1]에 대한 처리되지 않은 반대/댓글의 수는 대략 0이며 맨 위에 있는 @eickle 의 제안(점차 유사해지고 있음)에 의해 열린 상태로 남겨진 모든 중요한 질문을 해결합니다.

그래서 지금까지 건전성 검사를 통과했다고 주장합니다. 여전히 검토가 필요합니다. IReadOnlyCollection을 상속하는 것이 유용한지 여부에 대해 이야기할 수 있습니다(별로 유용하지는 않지만 전문가에게 맡겨야 합니다). @eiriktsarpalis @layomia 이거 좀 봐달라고 해도 될까요?

[1] https://github.com/TimLovellSmith/corefxlab/blob/priorityQueueSpecSolved/docs/specs/priority-queue.md

[추신 - 스레드 감정을 기반으로 현재 제안된 킬러 앱은 코딩 대회, 인터뷰 질문 등입니다. 여기서 클래스 또는 구조체와 함께 오늘의 좋아하는 숫자 유형을 올바른 O와 함께 작동하는 멋진 간단한 API를 사용하기만 하면 됩니다. (n) 구현 속도가 너무 느리지 않습니다. 그리고 몇 가지 문제에 적용할 수 있게 되어 기쁩니다. 더 흥미진진한 것이 아니라 죄송합니다.]

'실제' 프로젝트, 주로 그래프 검색(예: 문제 최적화, 경로 찾기) 및 정렬된 추출(청크별(예: 가장 가까운 이웃 쿼드 트리), 스케줄링(예: 위의 타이머 논의)). 도움이 되는 경우 온전성 검사/테스트를 위해 직접 구현에 연결할 수 있는 몇 가지 프로젝트가 있습니다. 현재 제안은 나에게 좋아 보입니다(이상적으로 적합하지 않은 경우 모든 목적에 사용할 수 있음). 몇 가지 작은 관찰이 있습니다.

• TElement 는 TKey 여야 하는 곳에 두 번 나타납니다.
• 내 자신의 구현에는 사용 용이성(그리고 어떤 경우에는 효율성)을 위해 종종 bool EnqueueOrUpdateIfHigherPriority 되며, 이는 종종 사용되는 유일한 대기열/업데이트 방법(예: 그래프 검색)으로 끝납니다. 분명히 그것은 필수적이지 않고 API에 추가적인 복잡성을 더할 것이지만, 이것은 매우 좋은 것입니다.
• Enqueue ( Add 의미하지 않음)의 사본이 두 개 있습니다. 하나는 bool TryEnqueue 입니까?
• "// 컬렉션을 임의의 순서로 열거하지만 가장 작은 요소를 먼저 사용합니다.": 마지막 비트가 유용하다고 생각하지 않습니다. 나는 열거자가 비교를 수행할 필요가 없는 것을 선호하지만 이것이 '무료'일 것이라고 가정하므로 귀찮게하지 않을 것입니다.
• EqualityComparer 의 이름은 약간 예상치 못한 것입니다. KeyComparer 가 PriorityComparer 와 함께 사용할 것으로 예상했습니다.
• CopyTo 및 ToArray 의 복잡성에 대한 메모를 이해하지 못합니다.

@비주얼멜론
리뷰 정말 감사합니다!

KeyComparer의 이름 지정 제안이 마음에 듭니다. 우선 순위 감소 API는 매우 유용합니다. 이러한 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

열거형이 가장 작은 요소를 먼저 반환한다고 생각한 이유는 Peek()이 컬렉션의 맨 앞에 요소를 반환하는 정신 모델과 일치하기 때문입니다. 또한 바이너리 힙인 경우 구현하기 위해 비교가 필요하지 않으므로 공짜처럼 보였습니다. 그러나 아마도 내가 생각하는 것보다 덜 자유롭습니다 - 부당한 복잡성? 그런 이유로 꺼내게 되어 기쁩니다.

두 개의 Enqueue는 우발적이었습니다. 우선 순위가 항상 업데이트되는 EnqueueOrUpdate가 있습니다. 나는 TryUpdate가 그것의 논리적 역이라고 생각합니다. 여기서 이미 컬렉션에 있는 항목에 대해 우선 순위가 업데이트되지 않아야 합니다. 나는 그것이 논리적 격차를 채우는 것을 볼 수 있지만 그것이 실제로 사람들이 원하는 API인지 확신할 수 없습니다.

감소하는 변형을 사용하는 것만 상상할 수 있습니다. 노드를 대기열에 추가하거나 기존 노드를 우선 순위가 낮은 노드로 교체하는 것은 경로 찾기에서 자연스러운 작업입니다. 나는 즉시 반대의 용도를 제안할 수 없었다. boolean 반환 매개변수는 항목이 대기열에 있거나 대기열에 있지 않을 때 작업을 수행해야 하는 경우 편리할 수 있습니다.

나는 바이너리 힙을 가정하지 않았지만 그것이 무료라면 첫 번째 요소가 항상 최소값인 문제가 없습니다. 단지 이상한 제약으로 보였습니다.

@VisualMelon @TimLovellSmith 하나의 API로 괜찮을까요?
EnqueueOrUpdatePriority ? 대기열 내에서 노드를 재배치하는 기능은 우선 순위를 높이거나 낮추더라도 순회 알고리즘에 유용하다고 생각합니다.

@Jlalond 예, 구현에 따라 효율성에 도움이 될 수 있기 때문에 언급하고 대기열에 이미 있는 것을 개선하는 경우에만 대기열에 넣고 싶은 사용 사례를 직접 인코딩합니다. 추가적인 복잡성이 그러한 범용 도구에 적합한지 여부를 말하지 않겠지만 확실히 필요한 것은 아닙니다.

EnqueueOrUpdate 및 EnqueueOrDecrease를 유지하면서 EnqueueOrIncreasePriority를 ​​제거하도록 업데이트되었습니다. HashSet.Add()와 같이 컬렉션에 항목이 새로 추가될 때 bool을 반환하도록 합니다.

@Jlalond 위의 오류에 대해 사과드립니다(이 문제가 언제 검토되는지 묻는 최근 댓글 삭제).

@eiriktsarpalis 가 다음 주에 다시 돌아올 것이며 이 기능의 우선 순위를 정하고 API를 검토할 때 논의할 예정입니다.

이것은 우리가 고려하고 있지만 아직 .NET 6에 대해 커밋되지 않은 것입니다.

이 스레드는 2017년에 이 주제에 대해 몇 달 동안(이 거대한 스레드의 대부분) 심층 토론을 하고 공동으로 이 제안을 생성했음에도 불구하고 처음부터 시작하고 분기하여 되살아났습니다. 위로 스크롤하여 확인하십시오. 이것은 가시성을 위해 @karelz가 첫 번째 게시물의 첫 번째 줄에 링크한 제안이기도 합니다.

corefxlab repo에서 최신 제안 을 참조하십시오.

2017년 6월 16일 현재 우리는 한 번도 발생한 적이 없는 API 검토를 기다리고 있었고 상태는 다음과 같습니다.

API가 현재 형식(2개 클래스)으로 승인되면 4차 힙을 사용하여 두 가지 모두에 대한 구현으로 CoreFXLab에 대한 또 다른 PR을 생성합니다( 구현 참조 ). PriorityQueue<T> 는 아래에 하나의 배열만 사용하고 PriorityQueue<TElement, TPriority> 는 두 개를 사용하고 요소를 함께 재배열합니다. 이렇게 하면 추가 할당을 절약하고 최대한 효율적으로 사용할 수 있습니다. 초록불이 들어오면 추가하겠습니다.

아직 발생하지 않은 공식 검토부터 시작하여 2017년에 제안한 내용을 계속 반복할 것을 권장합니다. 이렇게 하면 커뮤니티 구성원이 수백 개의 게시물을 교환한 후 작성된 제안서의 포크 및 반복을 방지할 수 있으며 관련된 모든 사람의 노력을 존중합니다. 피드백이 있으면 기꺼이 논의하겠습니다.

@pgolebiowski 토론에 다시 와주셔서 감사합니다. 가장 효과적인 협업 방법이 아닌 제안을 더욱 효과적으로 분기하여 죄송합니다. 나로서는 충동적인 행동이었다. (지금까지 제안서에 미해결 질문이 너무 많아 토론이 완전히 중단된 느낌이었고, 좀 더 자신 있는 제안이 필요했을 뿐입니다.)

적어도 일시적으로 내 PR의 코드 내용을 잊어버리고 여기에서 확인된 '미해결 문제'에 대해 다시 논의하여 이 문제를 해결하려고 하면 어떻습니까? 나는 그들 모두에 대한 나의 의견을 말하고 싶습니다.

1. 클래스 이름 PriorityQueue vs. Heap <-- 이미 논의되었으며 PriorityQueue가 더 낫다는 데 동의합니다.

2. IHeap 및 생성자 오버로드를 도입하시겠습니까? <-- 나는 많은 가치를 예상하지 않습니다. 나는 세계의 95%에 대해 다중 힙 구현이 있어야 하는 강력한 이유(예: 성능 델타)가 없다고 생각하고 나머지 5%는 아마도 자체적으로 작성해야 할 것입니다.

3. IpriorityQueue를 소개하시겠습니까? <-- 저도 필요 없다고 생각합니다. 다른 언어와 프레임워크는 표준 라이브러리에 이러한 인터페이스 없이도 잘 작동한다고 가정합니다. 그것이 잘못된 경우 알려주십시오.

4. 선택기(값 내부에 저장된 우선순위)를 사용하거나 사용하지 않음(5개의 API 차이) <-- 우선 순위 대기열에서 선택기를 지원하는 데 찬성하는 강력한 주장이 없습니다. IComparer<> 이미 항목 우선 순위를 비교하기 위한 정말 좋은 최소 확장성 메커니즘으로 사용되며 선택기는 큰 개선을 제공하지 않는다고 생각합니다. 또한 사람들은 변경 가능한 우선 순위가 있는 선택자를 사용하는 방법(또는 사용하지 않는 방법)에 대해 혼란스러워할 수 있습니다.

5. 튜플(TElement 요소, Tpriority 우선 순위) 대 KeyValuePair 사용<-- 개인적으로 KeyValuePair 는 항목이 세트/사전에서 키로 처리되기 때문에 항목이 업데이트 가능한 우선 순위를 갖는 우선 순위 대기열에 선호되는 옵션이라고 생각합니다.

6. Peek과 Dequeue는 튜플 대신에 out 인수를 가져야 합니까? <-- 모든 장단점, 특히 성능이 확실하지 않습니다. 간단한 벤치마크 테스트에서 더 나은 성능을 보이는 것을 선택해야 합니까?

7. Peek and Dequeue 던지기가 전혀 유용합니까? <-- 예... 대기열에 여전히 항목이 있다고 잘못 가정 하는 알고리즘에 대해 발생해야 하는 일입니다. 알고리즘이 이를 가정하지 않도록 하려면 Peek 및 Dequeue API를 전혀 제공하지 않고 TryPeek 및 TryDequeue만 제공하는 것이 가장 좋습니다. [특정 경우에 Peek 또는 Dequeue를 안전하게 호출할 수 있는 알고리즘이 있으며 Peek/Dequeue를 사용하면 성능과 사용성이 약간 향상됩니다.]

그 외에도 고려 중인 제안에 추가하는 것을 고려할 몇 가지 제안이 있습니다.

1. 우선순위 큐고유한 핸들이 있는 고유한 항목에서만 작동해야 합니다. 우선 순위 업데이트를 수행하기 위해 특정 방식으로 확장할 수 없는 개체(예: 문자열)를 비교하려는 경우 사용자 지정 IEqualityComparer를 지원해야 합니다.

2. 우선순위 큐그래프 검색 시나리오를 효율적이고 간단하게 구현하려면 '제거', '작은 경우 우선 순위 감소', 특히 '항목을 대기열에 추가하거나 작업이 작은 경우 우선 순위 감소'와 같은 다양한 작업을 지원해야 합니다. 모두 O(log n)입니다.

3. PriorityQueue가 있으면 게으른 프로그래머에게 편리합니다.기존 항목의 우선 순위 가져오기/설정을 위한 인덱스 연산자[]를 제공합니다. get의 경우 O(1), set의 경우 O(log n)이어야 합니다.

4. 가장 작은 우선 순위가 가장 좋습니다. 우선순위 대기열이 많이 사용되기 때문에 '최소 비용'으로 최적화 문제가 있습니다.

5. 열거형은 주문 보증을 제공해서는 안 됩니다.

미해결 문제 - 처리:
우선순위 큐항목 및 우선 순위는 중복 값으로 작업할 수 있도록 의도된 것 같습니다. 이러한 값은 '불변'으로 간주되어야 하거나 핸들을 사용하여 항목 우선 순위가 변경될 때 컬렉션을 알리기 위해 호출하는 메서드가 있어야 하므로 중복이 변경된 우선 순위에 대해 구체적일 수 있습니다(시나리오에서 수행해야 하는 작업 this??)... 이 모든 것이 유용한지, 이것이 좋은 생각인지 의심스럽습니다. 그러나 그러한 컬렉션에 업데이트 우선 순위가 있는 경우 해당 메서드로 인해 발생하는 비용이 느리게 발생할 수 있다면 좋을 것입니다. 변경할 수 없는 항목을 작업하고 사용하고 싶지 않을 때 추가 비용이 발생하지 않는다는 점을... 해결 방법은 무엇입니까? 핸들을 사용하는 오버로드된 메서드와 사용하지 않는 메서드를 사용하여 해결할 수 있습니까? 아니면 항목 자체와 구별되는 항목 핸들이 없어야 합니까(검색을 위한 해시 키로 사용됨)?

이 유형을 더 빠르게 이동하는 데 도움이 되도록 https://github.com/dotnet/runtime/discussions/42205 에서 논의 중인 "커뮤니티 컬렉션" 라이브러리로 이 유형을 이동하는 것이 합리적일 수 있습니다.

나는 가장 작은 우선 순위가 가장 좋다는 데 동의합니다. 우선 순위 대기열은 턴 기반 게임 개발에도 유용하며, 각 요소가 다음 차례를 가졌을 때 단조롭게 증가하는 카운터가 되도록 우선 순위를 가질 수 있는 것은 매우 유용합니다.

우리는 API 검토를 최대한 빨리 제공하기 위해 이것을 찾고 있습니다(아직 .NET 6 기간 내에 구현을 제공하기로 약속하지는 않았지만).

그러나 검토를 위해 이것을 보내기 전에 몇 가지 높은 수준의 공개 질문을 정리해야 합니다. @TimLovellSmith 의 글 이 그 목표를 달성하기 위한 좋은 출발점이라고 생각합니다.

그 점에 대한 몇 가지 언급:

• 질문 1-3에 대한 합의는 오랫동안 확립되어 있으며, 해결된 것으로 간주할 수 있다고 생각합니다.

• _선택자 사용(값 내부에 우선 순위가 저장됨) 여부_ -- 귀하의 의견에 동의합니다. 그 디자인의 또 다른 문제는 선택기가 선택 사항이라는 것입니다. 즉, 잘못된 Enqueue 오버로드를 호출하지 않도록 주의해야 합니다(또는 InvalidOperationException 받을 위험이 있음).

• 나는 KeyValuePair 보다 튜플을 사용하는 것을 선호합니다. .Key 속성을 사용하여 TPriority 값에 액세스하는 것은 저에게 이상하게 느껴집니다. 튜플을 사용하면 자체 문서화 속성이 더 나은 .Priority 를 사용할 수 있습니다.

• _Peek 및 Dequeue가 튜플 대신 out 인수를 사용해야 합니까?_ -- 다른 곳에서 유사한 방법으로 확립된 규칙을 따라야 한다고 생각합니다. 따라서 아마도 out 인수를 사용하십시오.

• _Peek 및 Dequeue 던지기가 전혀 유용합니까?_ -- 귀하의 의견에 100% 동의합니다.

• _가장 작은 우선 순위가 가장 좋은 것입니다_ -- 동의합니다.

• _열거는 주문 보장을 제공해서는 안 됩니다_ -- 이것이 사용자의 기대를 위반하지 않을까요? 장단점은 무엇입니까? NB API 검토 논의를 위해 이와 같은 세부 사항을 연기할 수 있습니다.

나는 또한 몇 가지 다른 열린 질문을 바꾸어 말하고 싶습니다.

• PriorityQueue<T> , PriorityQueue<TElement, TPriority> 또는 둘 다 배송합니까? -- 개인적으로 후자가 더 깨끗하고 범용적인 솔루션을 제공하기 때문에 후자만 구현해야 한다고 생각합니다. 원칙적으로 우선 순위는 대기 중인 요소에 고유한 속성이 되어서는 안 되므로 사용자가 이를 래퍼 유형으로 캡슐화하도록 강제해서는 안 됩니다.

• 평등까지 요소 고유성을 요구합니까? -- 내가 틀렸다면 정정해 주세요. 하지만 고유성은 인위적인 제약이라고 생각합니다. 핸들 접근 방식에 의존하지 않고 업데이트 시나리오를 지원해야 하는 요구 사항에 의해 강요된 것입니다. 그것은 또한 API 표면을 복잡하게 만듭니다. 이제 요소가 올바른 동등 의미를 갖는 것에 대해 걱정할 필요가 있기 때문입니다(요소가 큰 DTO일 때 적절한 동등성은 무엇입니까?). 여기에서 세 가지 가능한 경로를 볼 수 있습니다.

  1. 고유성/동등성을 요구하고 원본 요소를 전달하여 업데이트 시나리오를 지원합니다(최대 같음).
  2. 고유성/동등성을 요구하지 않으며 핸들을 사용하여 업데이트 시나리오를 지원합니다. 이는 필요한 사용자를 위해 선택적 Enqueue 메소드 변형을 사용하여 얻을 수 있습니다. 핸들 할당이 충분히 큰 문제라면 ValueTask로 상각할 수 있는지 궁금합니다.
  3. 고유성/동등성을 요구하지 않으며 우선 순위 업데이트를 지원하지 않습니다.

• 병합 대기열을 지원합니까? -- 병합이 효율적이지 않은 하나의 구현(아마도 배열 힙 사용)만 제공하기 때문에 합의는 그렇지 않은 것 같습니다.

• 어떤 인터페이스를 구현해야 합니까? -- IQueue<T> 추천하는 몇 가지 제안을 보았지만 이것은 추상화처럼 느껴집니다. 개인적으로 단순하게 유지하고 ICollection<T> 구현하는 것을 선호합니다.

cc @layomia @safern

@eiriktsarpalis 반대로 - 업데이트를 지원하기 위한 제약 조건에 대해 인위적인 것은 전혀 없습니다!

우선 순위 대기열이 있는 알고리즘은 종종 요소의 우선 순위를 업데이트합니다. 문제는 일반 객체의 우선 순위를 업데이트하기 위해 '그냥 작동'하는 객체 지향 API를 제공합니까? 아니면 사람들에게 강제로
a) 핸들 모델 이해
b) 업데이트를 수행할 수 있도록 추가 속성이나 외부 사전과 같은 추가 데이터를 메모리에 유지하여 개체 핸들을 추적합니다(변경할 수 없는 클래스의 사전과 함께 이동해야 합니까? 또는 개체를 튜플로 업그레이드 등)
c) '메모리 관리' 또는 '가비지 수집' 외부 구조, 즉 사전 접근 방식을 사용할 때 대기열에 더 이상 없는 항목에 대한 핸들 정리
d) 단일 우선순위 큐의 컨텍스트에서만 의미가 있으므로 여러 큐가 있는 컨텍스트에서 불투명 핸들을 혼동하지 마십시오.

게다가 누군가가 _우선순위에 따라 객체를 추적하는_ 큐가 이런 식으로 행동하기를 원하는 전체 이유에 대한 철학적인 질문이 있습니다. 왜 동일한 객체(같음은 true를 반환함)에 2개의 _다른_ 우선순위가 있어야 합니까? 그것들이 정말로 다른 우선 순위를 가져야 한다면 왜 다른 객체로 모델링되지 않습니까? (또는 구분자를 사용하여 튜플로 상향 변환하시겠습니까?)

또한 핸들의 경우 핸들이 실제로 작동하도록 우선 순위 큐에 내부 핸들 테이블이 있어야 합니다. 나는 이것이 대기열에서 객체를 찾기 위해 사전을 유지하는 것과 동일한 작업이라고 생각합니다.

추신: 모든 .net 객체는 이미 평등/고유성의 개념을 지원하므로 '요구'하는 것은 그리 큰 문제가 아닙니다.

KeyValuePair 와 관련하여 이상적이지 않다는 데 동의합니다(제안에서 Key 는 요소에 대한 것이고 Value 는 우선 순위에 대한 것이며 이는 다양한 Sorted 데이터 유형은 BCL)이며 적절성은 고유성에 대한 결정에 따라 달라집니다. 개인적으로 저는 공개 API의 튜플보다 이름이 잘 지정된 전용 struct 를 _많이_ 선호합니다. 특히 입력의 경우 그렇습니다.

독창성에 관해서는 그것이 근본적인 관심사이며, 그렇게 될 때까지 다른 어떤 것도 결정할 수 없다고 생각합니다. 목표가 사용하기 쉬운 단일 범용 API인 경우 (선택 사항) 비교기(기존 제안 및 제안 i에 따라)에 의해 정의된 요소 고유성을 선호합니다. 고유 대 비 고유는 큰 균열이며 두 유형을 다른 목적으로 사용합니다. 전자는 구현하기가 '더 어렵고' 가장 (그리고 더 일반적인) 사용 사례(내 경험일 뿐)를 다루지만 오용하기가 더 어렵습니다. 비고유성(IMO)이 다른 유형(예: 일반 이전 바이너리 힙)에 의해 _require__필요한_ 사용 사례를 처리해야 하며 둘 다 사용할 수 있게 해주시면 감사하겠습니다. 이것은 본질적으로 @pgolebiowski가 링크한 원래 제안이 모듈로(간단한) 래퍼를 제공하는 것입니다. _편집: 아니요, 묶인 우선 순위를 지원하지 않습니다_

반대로 업데이트를 지원하는 제약 조건은 인위적인 것이 전혀 없습니다!

죄송합니다. 업데이트 지원이 인위적이라는 뜻은 아닙니다. 오히려 업데이트를 지원하기 위해 고유성에 대한 요구 사항이 인위적으로 도입되었습니다.

추신: 모든 .net 객체는 이미 평등/고유성의 개념을 지원하므로 '요구'하는 것은 큰 문제가 아닙니다.

물론, 그러나 때때로 유형과 함께 제공되는 같음 의미 체계가 바람직한 것이 아닐 수도 있습니다(예: 참조 같음, 완전한 구조적 같음 등). 나는 평등이 어렵다는 것을 지적하고 그것을 디자인에 강요하는 것은 잠재적인 사용자 버그의 완전히 새로운 부류를 가져온다.

@eiriktsarpalis 명확히 해 주셔서 감사합니다. 하지만 정말 인공일까? 그렇지 않다고 생각합니다. 그것의 또 다른 자연적인 해결책입니다.

API는 _잘 정의_되어야 합니다. 사용자 가 업데이트하려는 항목에 대해 구체적으로 요구하지 않고는 업데이트 API를 제공할 수 없습니다. 핸들과 객체 동등성은 잘 정의된 API를 구축하기 위한 두 가지 다른 접근 방식일 뿐입니다.

핸들 접근 방식: 컬렉션에 개체를 추가할 때마다 '이름', 즉 '핸들'을 지정해야 나중에 대화에서 모호함 없이 정확한 개체를 참조할 수 있습니다.

개체 고유성 접근 방식: 컬렉션에 개체를 추가할 때마다 개체는 다른 개체여야 하거나 개체가 이미 있는 경우를 처리하는 방법을 지정해야 합니다.

불행히도 객체 접근 방식만이 'EnqueueIfNotExists' 또는 'EnqueueOrDecreasePriroity(item)'와 같은 가장 유용한 고수준 API 메서드 속성을 실제로 지원하도록 허용합니다. 항목이 이미 대기열에 있는지 여부를 알 수 없습니다(핸들을 사용하여 추적하는 작업이기 때문에).

핸들 접근 방식에 대한 가장 확실한 비판 중 하나는 업데이트 가능한 우선 순위가 있는 모든 종류의 시나리오를 구현하기가 훨씬 더 복잡하게 만든다는 것입니다.

예

1. PriorityQueue 사용지지/점수 업데이트되는 메시지/감정/태그/사용자 이름을 나타내는 문자열의 경우 고유 값의 우선 순위가 변경됩니다.
2. PriorityQueue 사용, double> 고유한 튜플을 주문하려면 [우선순위 변경 여부] - 어딘가에 추가 핸들을 추적해야 합니다.
3. 우선순위 큐 사용그래프 인덱스 또는 데이터베이스 개체 ID의 우선 순위를 지정하려면 이제 구현을 통해 핸들을 뿌려야 합니다.

추신

물론, 그러나 때때로 유형과 함께 제공되는 평등 의미 체계가 바람직하지 않을 수 있습니다.

IEqualityComparer와 같은 탈출 해치가 있거나 더 풍부한 유형으로 상향 변환됩니다.

피드백에 감사드립니다 🥳 모든 새로운 입력을 고려하여 주말 동안 제안을 업데이트하고 다른 라운드를 위해 새로운 수정본을 공유할 것입니다. 예정일 2020-09-20.

우선순위 대기열 제안(v2.0)

요약

.NET Core 커뮤니티는 시스템 라이브러리 _priority queue_ 기능을 추가할 것을 제안합니다. 이 기능은 각 요소에 추가로 연결된 우선 순위가 있는 데이터 구조입니다. 특히 System.Collections.Generic 네임스페이스에 PriorityQueue<TElement, TPriority> 를 추가할 것을 제안합니다.

신조

우리의 설계에서 우리는 다음과 같은 원칙에 따라 진행되었습니다(더 나은 원칙을 알고 있지 않는 한).

• 넓은 범위. 우리는 .NET Core 고객에게 다양한 사용 사례를 지원하기에 충분히 다재다능한 귀중한 데이터 구조를 제공하고자 합니다.
• 알려진 실수로부터 배우십시오. 우리는 Java, Python, C++, Rust와 같은 다른 프레임워크 및 언어에 존재하는 고객 대면 문제가 없는 우선 순위 대기열 기능을 제공하기 위해 노력합니다. 우리는 고객을 불행하게 만들고 우선 순위 대기열의 유용성을 줄이는 것으로 알려진 디자인 선택을 피합니다.
• 일방통행 결정으로 극도의 주의를 기울입니다. API는 한 번 도입되면 수정하거나 삭제할 수 없으며 확장만 가능합니다. 우리는 고객이 영원히 고착될 차선의 솔루션을 피하기 위해 설계 선택을 신중하게 분석할 것입니다.
• 디자인 마비를 피하십시오. 우리는 완벽한 솔루션이 없을 수 있음을 인정합니다. 우리는 절충안의 균형을 맞추고 납품을 계속 진행하여 마침내 고객이 수년 동안 기다려온 기능을 제공할 것입니다.

배경

고객의 입장에서

개념적으로 우선 순위 대기열은 각 요소에 연결된 우선 순위가 있는 요소 모음입니다. 우선 순위 대기열의 가장 중요한 기능은 컬렉션에서 우선 순위가 가장 높은 요소에 대한 효율적인 액세스와 해당 요소를 제거하는 옵션을 제공한다는 것입니다. 예상되는 동작에는 다음이 포함될 수도 있습니다. 1) 이미 컬렉션에 있는 요소의 우선 순위를 수정하는 기능; 2) 여러 우선 순위 대기열을 병합하는 기능.

컴퓨터 과학 배경

우선 순위 대기열은 추상 데이터 구조입니다. 즉, 이전 섹션에서 설명한 대로 특정 동작 특성을 가진 개념입니다. 우선 순위 대기열의 가장 효율적인 구현은 힙을 기반으로 합니다. 그러나 일반적인 오해와 달리 힙(heap)도 추상적인 데이터 구조이며 다양한 방식으로 구현될 수 있으며 각각의 장단점이 다릅니다.

대부분의 소프트웨어 엔지니어는 어레이 기반 바이너리 힙 구현에만 익숙합니다. 이는 가장 간단한 구현이지만 불행히도 가장 효율적인 구현은 아닙니다. 일반적인 임의 입력의 경우 더 효율적인 힙 유형의 두 가지 예는 4차 힙 및 페어링 힙 입니다. 힙에 대한 자세한 내용은 Wikipedia 및 이 문서 를 참조하십시오.

업데이트 메커니즘은 주요 설계 과제입니다.

우리의 논의는 설계에서 가장 도전적인 영역이자 동시에 API에 가장 큰 영향을 미치는 영역이 업데이트 메커니즘이라는 것을 보여주었습니다. 특히 문제는 고객에게 제공하려는 제품이 컬렉션에 이미 있는 요소의 우선 순위 업데이트를 지원해야 하는지 여부와 방법을 결정하는 것입니다.

이러한 기능은 예를 들어 Dijkstra의 최단 경로 알고리즘이나 변화하는 우선 순위를 처리해야 하는 작업 스케줄러를 구현하는 데 필요합니다. Java에는 업데이트 메커니즘이 없습니다. 예 를 들어 32,000번 이상 조회된 세 가지 StackOverflow 질문인 example , example , example 에서 엔지니어에게 실망스러운 것으로 나타났습니다. 이러한 제한된 가치의 API 도입을 피하기 위해 우리가 제공하는 우선 순위 대기열 기능에 대한 기본 요구 사항은 컬렉션에 이미 있는 요소에 대한 우선 순위 업데이트 기능을 지원하는 것이라고 생각합니다.

업데이트 메커니즘을 제공하려면 고객이 업데이트하려는 항목에 대해 구체적으로 설명할 수 있어야 합니다. 우리는 이것을 전달하는 두 가지 방법을 확인했습니다. b) 컬렉션에 있는 요소의 고유성 적용을 통해. 이들 각각은 다른 이점과 비용을 수반합니다.

옵션(a): 핸들. 이 접근 방식에서는 요소가 대기열에 추가될 때마다 데이터 구조가 고유한 핸들을 제공합니다. 고객이 업데이트 메커니즘을 사용하려는 경우 나중에 업데이트하려는 요소를 명확하게 지정할 수 있도록 이러한 핸들을 추적해야 합니다. 이 솔루션의 주요 비용은 고객이 이러한 포인터를 관리해야 한다는 것입니다. 그러나 이것이 우선 순위 대기열 내에서 핸들을 지원하기 위해 내부 할당이 필요하다는 것을 의미하지는 않습니다. 배열 기반이 아닌 모든 힙은 각 노드가 자동으로 자체 핸들이 되는 노드를 기반으로 합니다. 예를 들어 PairingHeap.Update 메서드의 API를 참조하십시오.

옵션(b): 고유성. 이 접근 방식은 고객에게 두 가지 추가 제약을 가합니다. i) 우선 순위 대기열 내의 요소는 새로운 클래스의 잠재적 사용자 버그를 가져오는 특정 평등 의미 체계를 따라야 합니다. ii) 두 개의 동일한 요소는 동일한 대기열에 저장할 수 없습니다. 이 비용을 지불함으로써 핸들 접근 방식에 의존하지 않고 업데이트 메커니즘을 지원하는 이점을 얻습니다. 그러나 고유성/동등성을 활용하여 업데이트할 요소를 결정하는 모든 구현에는 추가 내부 매핑이 필요하므로 O(n)이 아닌 O(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) 에서 열거가 발생할 수 있도록 정의되지 않은 순서로. 효율적인 구현은 요소가 순서대로 열거되도록 보장하면서 선형 시간에 힙을 열거하는 기능을 제공하지 않습니다. 이를 위해서는 O(n log n)이 필요합니다. 컬렉션에 대한 주문은 .OrderBy(x => x.Priority) 로 간단하게 달성할 수 있고 모든 고객이 이 주문으로 열거에 관심이 있는 것은 아니므로 정의되지 않은 열거 순서를 제공하는 것이 더 낫다고 생각합니다.

부록

부록 A: 우선 순위 대기열 기능이 있는 기타 언어

| 언어 | 유형 | 메모 |
|:-:|:-:|:-:|
| 자바 | 우선순위 큐 | 추상 클래스 AbstractQueue 확장하고 인터페이스 Queue 구현합니다. |
| 녹 | 바이너리힙 | |
| 스위프트 | CFBinary힙 | |
| C++ | 우선순위 대기열 | |
| 파이썬 | 힙Q | |
| 이동 | 힙 | 힙 인터페이스가 있습니다. |

부록 B: 검색 가능성

데이터 구조를 논의할 때 _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개의 결과

검토하고 피드백을 받고 계속 반복하십시오 :) 우리가 수렴하고 있다고 느낍니다! 😄 또한 질문을 받게 되어 기쁩니다. FAQ에 추가하겠습니다!

@pgolebiowski 핸들 기반 API를 사용하지 않는 경향이 있습니다(예제 2에 따라 이것을 래핑할 것으로 예상합니다. 기존 코드를 다시 맞추는 경우). 하지만 대부분 나에게 좋아 보입니다. 나는 당신이 언급한 구현을 사용하여 느낌이 어떤지 볼 수 있지만 다음은 박쥐에 대한 몇 가지 의견입니다.

• TryDequeue 가 노드를 반환하는 것은 이상해 보입니다. 그 시점에서 실제로 핸들이 아니기 때문입니다(두 개의 개별 매개변수를 선호합니다)
• 두 요소가 동일한 우선 순위로 대기열에 있으면 예측 가능한 순서로 대기열에서 제거된다는 점에서 안정적입니까? (재현성을 위해 가지고 있는 것이 좋으며, 그렇지 않으면 소비자가 충분히 쉽게 구현할 수 있음)
• 의 매개 변수 Merge 되어야합니다 PriorityQueue'2 하지 PriorityQueueNode'2 , 당신은 행동을 명확히 할 수 있습니까? 나는 페어링 힙에 익숙하지 않지만 아마도 두 힙이 그 이후에 겹칠 것입니다.
• 나는 2-매개변수 방법에 대해 Contains 라는 이름의 팬이 아닙니다. 그것은 TryGet 스타일 방법에 대해 추측할 수 있는 이름이 아닙니다.
• 클래스가 Contains 의 목적을 위해 사용자 정의 IEqualityComparer<TElement> 를 지원해야 합니까?
• 노드가 여전히 힙에 있는지 여부를 효율적으로 결정할 수 있는 방법이 없는 것 같습니다(언제 사용할지 잘 모르겠습니다.)
• Remove 반환이 bool ; TryRemove 하거나 던졌을 것으로 예상합니다(노드가 힙에 없는 경우 Update 가 수행한다고 가정합니다).

@VisualMelon 피드백 주셔서 감사합니다! 신속하게 해결할 것입니다. 확실히 동의합니다.

• TryDequeue 가 노드를 반환하는 것은 이상해 보입니다. 그 시점에서 실제로 핸들이 아니기 때문입니다(두 개의 개별 매개변수를 선호합니다)
• 의 매개 변수 Merge 되어야합니다 PriorityQueue'2 하지 PriorityQueueNode'2 , 당신은 행동을 명확히 할 수 있습니까? 나는 페어링 힙에 익숙하지 않지만 아마도 두 힙이 그 이후에 겹칠 것입니다.
• Remove 반환이 bool . TryRemove 하거나 던졌을 것으로 예상합니다(노드가 힙에 없는 경우 Update 라고 가정합니다).
• 나는 2-매개변수 방법에 대해 Contains 라는 이름의 팬이 아닙니다. 그것은 TryGet 스타일 방법에 대해 추측할 수 있는 이름이 아닙니다.

이 두 가지에 대한 설명:

• 두 요소가 동일한 우선 순위로 대기열에 있으면 예측 가능한 순서로 대기열에서 제거된다는 점에서 안정적입니까? (재현성을 위해 가지고 있는 것이 좋으며, 그렇지 않으면 소비자가 충분히 쉽게 구현할 수 있음)
• 노드가 여전히 힙에 있는지 여부를 효율적으로 결정할 수 있는 방법이 없는 것 같습니다(언제 사용할지 잘 모르겠습니다.)

첫 번째 요점으로, 목표가 재현성이라면 구현은 결정적일 것입니다. 그렇습니다. 목표가 _우선순위가 같은 두 개의 요소가 대기열에 배치되는 경우 대기열에 배치된 것과 동일한 순서로 나올 것입니다_ — 구현을 다음과 같이 조정할 수 있는지 확실하지 않습니다. 이 속성을 달성하면 빠른 대답은 "아마도 아니오"가 될 것입니다.

두 번째 요점의 경우 예, 힙은 요소가 컬렉션에 존재하는지 확인하는 데 적합하지 않습니다. 고객은 이를 별도로 추적하여 O(1)에서 달성하거나 핸들에 사용하는 매핑을 재사용해야 합니다. 그들은 업데이트 메커니즘을 사용합니다. 그렇지 않으면 O(n).

• 클래스가 Contains 의 목적을 위해 사용자 정의 IEqualityComparer<TElement> 를 지원해야 합니까?

흠... 아마 Contains 를 이 우선순위 큐의 책임에 맡기는 것이 너무 많을 수 있고 Linq 의 방법을 사용하는 것으로 충분할 수 있다고 생각하기 시작했습니다( Contains 어쨌든 열거에 적용되어야 함).

@pgolebiowski 설명 감사합니다

첫 번째 요점으로, 목표가 재현성인 경우 구현은 결정적입니다. 그렇습니다.

영원히 보장되는 것처럼 그다지 결정적이지 않습니다(예: 구현이 변경되더라도 동작은 변경되지 않음). 그래서 제가 추구했던 대답은 '아니오'라고 생각합니다. 괜찮습니다. 소비자는 시퀀스 ID가 필요한 경우 우선 순위에 시퀀스 ID를 추가할 수 있지만 그 시점에서 SortedSet 가 작업을 수행합니다.

두 번째 요점의 경우 예, 힙은 요소가 컬렉션에 존재하는지 확인하는 데 적합하지 않습니다. 고객은 이를 별도로 추적하여 O(1)에서 달성하거나 핸들에 사용하는 매핑을 재사용해야 합니다. 그들은 업데이트 메커니즘을 사용합니다. 그렇지 않으면 O(n).

Remove 필요한 작업의 하위 집합이 필요하지 않습니까? 나는 명확하지 않았을 수 있습니다. PriorityQueueNode 주어진 힙에 있는지 확인하는 것을 의미했습니다 ( TElement 아님).

흠... 나는 아마도 이 우선 순위 대기열의 책임에 포함을 넣는 것이 너무 많을 수 있다고 생각하기 시작했습니다.

Contains 가 없으면 불평하지 않을 것입니다. 핸들을 사용해야 한다는 사실을 모르는 사람들을 위한 함정이기도 합니다.

@pgolebiowski 당신은 핸들을 상당히 선호하는 것 같습니다. 효율성을 이유로 생각하는 것이 맞습니까?

효율성 관점에서 핸들이 고유성이 있는 시나리오와 없는 시나리오 모두에 대해 진정으로 최고라고 생각하므로 프레임워크에서 제공하는 기본 솔루션으로 괜찮습니다.

조금도:
사용성 관점에서 중복 요소는 거의 내가 원하는 것이 아니라고 생각합니다. 그래서 여전히 프레임워크가 두 모델을 PriorityQueue 대한 래퍼로 나중에 적어도 쉽게 추가할 수 있습니다. (수요가 존재한다면. 내가 생각하는 대로!)

현재 API 자체에 대해 몇 가지 생각/질문을 제안했습니다.

• TryPeek(out TElement element, out TPriority priority) 오버로드도 제공하는 것은 어떻습니까?
• 업데이트 가능한 중복 키가 있는 경우 'dequeue'가 우선 순위 대기열 노드를 반환하지 않으면 핸들 추적 시스템에서 정확한 노드가 제거되는지 어떻게 확인할 수 있을까요? 동일한 우선 순위를 가진 요소의 사본이 두 개 이상 있을 수 있기 때문입니다.
• 노드를 찾을 수 없으면 Remove(PriorityQueueNode) 가 발생합니까? 또는 false를 반환합니까?
• Remove가 throw되면 throw되지 않는 TryRemove() 버전이 있어야 합니까?
• Contains() api가 대부분의 경우 유용한지 잘 모르겠습니다. '포함'은 보는 사람의 눈에 보이는 것 같습니다. 특히 우선 순위가 다른 '중복' 요소가 있는 시나리오 또는 기타 고유한 기능이 있는 경우에 그렇습니다! 이 경우 최종 사용자는 어쨌든 자신의 검색을 수행해야 합니다. 그러나 적어도 중복이 없는 시나리오에서는 유용할 수 있습니다.

@pgolebiowski 시간을 내어 새 제안서를

• @TimLovellSmith 의 의견에 따라 Contains() 또는 TryGetNode() 이 현재 제안된 형식으로 API에 존재해야 하는지 잘 모르겠습니다. TElement 대한 평등이 중요하다는 것을 암시하며, 이는 아마도 핸들 기반 접근 방식이 피하려고 했던 것 중 하나일 것입니다.
• 아마도 public void Dequeue(out TElement element); 를 public TElement Dequeue(); 로 바꾸어 말하겠습니다.
• TryDequeue() 메서드가 우선 순위를 반환해야 하는 이유는 무엇입니까?
• 클래스도 ICollection<T> 또는 IReadOnlyCollection<T> 구현해야 하지 않습니까?
• 다른 PriorityQueue 인스턴스에서 반환된 PriorityQueueNode를 업데이트하려고 하면 어떻게 됩니까?
• 효율적인 병합 작업을 지원하고 싶습니까? AFAICT는 배열 기반 표현을 사용할 수 없음을 의미합니다. 이것이 할당 측면에서 구현에 어떤 영향을 미칩니까?

대부분의 소프트웨어 엔지니어는 어레이 기반 바이너리 힙 구현에만 익숙합니다. 이는 가장 간단한 구현이지만 불행히도 가장 효율적인 구현은 아닙니다. 일반적인 임의 입력의 경우 더 효율적인 힙 유형의 두 가지 예는 4차 힙과 페어링 힙입니다.

후자의 접근 방식을 선택하기 위한 절충안은 무엇입니까? 어레이 기반 구현을 사용할 수 있습니까?

'추가' 및 '제거' 등에 대한 올바른 서명이 없으면 ICollection<T> 또는 IReadOnlyCollection<T> 구현할 수 없습니다.

ICollection<KeyValuePair<T,Priority>> 훨씬 더 가깝습니다.

ICollection<KeyValuePair<T,Priority>> 훨씬 더 가깝습니다.

KeyValuePair<TPriority, TElement> 되지 않을까요? 순서는 Tpriority에 의해 이루어지는데, 이는 사실상 키잉 메커니즘입니다.

좋습니다. 전반적으로 Contains 및 TryGet 메서드를 삭제하는 데 찬성하는 것 같습니다. 다음 개정에서 제거하고 FAQ에서 제거 이유를 설명합니다.

구현된 인터페이스에 관해서는 — IEnumerable<PriorityQueueNode<TElement, TPriority>> 충분하지 않습니까? 어떤 종류의 기능이 빠져 있습니까?

KeyValuePair - .Element 및 .Priority 가 있는 튜플 또는 구조체가 더 바람직하다는 목소리가 몇 개 있었습니다. 나는 이것들에 찬성한다고 생각한다.

KeyValuePair<TPriority, TElement> 되지 않을까요? 순서는 Tpriority에 의해 이루어지는데, 이는 사실상 키잉 메커니즘입니다.

양측 모두에게 좋은 주장이 있습니다. 한편으로는 네, 방금 말씀하신 그대로입니다. 반면에 KVP 컬렉션의 키는 일반적으로 고유해야 하며 동일한 우선 순위를 가진 여러 요소를 갖는 것이 완벽하게 유효합니다.

반면에 KVP 컬렉션의 키는 일반적으로 고유해야 합니다.

나는 이 말에 동의하지 않습니다. 키-값 쌍의 모음이 바로 그것입니다. 모든 고유성 요구 사항은 그 위에 계층화됩니다.

IEnumerable<PriorityQueueNode<TElement, TPriority>> 충분하지 않습니까? 어떤 종류의 기능이 빠져 있습니까?

제공된 API가 이미 대부분 해당 인터페이스를 충족하기 때문에 개인적으로 IReadOnlyCollection<PQN<TElement, TPriority>> 가 구현되기를 기대합니다. 또한 다른 컬렉션 유형과도 일치합니다.

인터페이스 관련:

```
public bool TryGetNode(TElement 요소, out PriorityQueueNode마디); // 에)

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

공개 PriorityQueue(IEnumerable>컬렉션);
```

또한 IReadonlyCollection<> 인터페이스를 구현하기 위해 PriorityQueue 를 원합니다.

공개 API 표면 이외의 다른 항목으로 이동합니다.

이러한 기능은 예를 들어 Dijkstra의 최단 경로 알고리즘이나 변화하는 우선 순위를 처리해야 하는 작업 스케줄러를 구현하는 데 필요합니다. Java에는 업데이트 메커니즘이 없습니다. 예를 들어 32,000번 이상 조회된 3개의 StackOverflow 질문에서 엔지니어에게 실망스러운 것으로 나타났습니다. example, example, example. 이러한 제한된 가치의 API 도입을 피하기 위해 우리가 제공하는 우선 순위 대기열 기능에 대한 기본 요구 사항은 컬렉션에 이미 있는 요소에 대한 우선 순위 업데이트 기능을 지원하는 것이라고 생각합니다.

저는 동의하지 않습니다. 마지막으로 C++에서 Dijkstra를 작성했을 때 std::priority_queue로 충분했으며 우선 순위 업데이트를 처리하지 않습니다. 이 경우 AFAIK 공통 합의 는 우선 순위와 값이 변경된 대기열에 가짜 요소를 추가하고 값을 처리하는지 여부를 모니터링하는 것입니다. 작업 스케줄러도 마찬가지입니다.

솔직히 말해서 현재 대기열 제안에서 Dijkstra가 어떻게 보일지 잘 모르겠습니다. 업데이트 우선 순위가 필요한 노드를 추적하려면 어떻게 해야 합니까? TryGetNode()로? 아니면 다른 노드 모음이 있습니까? 현재 제안에 대한 코드를 보고 싶습니다.

Wikipedia를 살펴보면 우선 순위 대기열에 대한 우선 순위 업데이트에 대한 가정이 없습니다. 해당 기능이 없고 그 기능을 사용하지 않는 다른 모든 언어도 마찬가지입니다. 나는 "더 나은 것을 위해 노력한다"는 것을 알고 있지만, 실제로 그것에 대한 수요가 있습니까?

일반적인 임의 입력의 경우 더 효율적인 힙 유형의 두 가지 예는 4차 힙과 페어링 힙입니다. 힙에 대한 자세한 내용은 Wikipedia 및 이 문서를 참조하십시오.

나는 종이를 조사했고 이것은 인용문입니다.

결과는 구현의 최적 선택이 입력에 크게 의존함을 보여줍니다. 또한 주로 L1-L2 장벽에서 캐시 성능을 최적화하기 위해 주의를 기울여야 함을 보여줍니다. 이는 복잡한 캐시 인식 구조가 더 간단한 캐시 인식 구조에 비해 잘 수행되지 않을 수 있음을 시사합니다.

현재 대기열 제안은 배열이 아닌 트리 구현 뒤에 잠겨 있으며 메모리 주변에 흩어져 있는 트리 노드가 요소 배열만큼 성능이 좋지 않을 가능성이 있다는 것을 알 수 있습니다.

나는 배열에 따라 간단한 이진 힙을 비교하는 벤치 마크를 가지고와 힙, 적절한 결정을 내릴 그 전에, 나는 그것이 (내가 당신을 찾고 있어요 특정 구현 뒤에 잠금 디자인에 스마트 생각하지 않습니다 이상적 일 것이다 페어링 생각 Merge 메서드).

다른 주제로 넘어가면 개인적으로 KeyValuePair를 선호합니다.새로운 커스텀 클래스보다

• 적은 API 표면
• 다음과 같이 할 수 있습니다. `new PriorityQueue(새 사전() {{1, 1}, {2,2}, {3,3}, {4,4}, {5,5}}); 나는 그것이 키의 고유성에 의해 제한된다는 것을 알고 있습니다. 또한 IDictionary 기반의 컬렉션을 소비하는 것도 좋은 시너지를 낼 것이라고 생각합니다.
• 클래스가 아닌 구조체이므로 NullReference 예외가 없습니다.
• 어느 시점에서 PrioirtyQueue는 직렬화/역직렬화되어야 하고 이미 존재하는 객체로 무엇을 하는 것이 더 쉬울 것이라고 생각합니다.

단점은 TPriority Key 에 대해 만감이 교차하지만 좋은 문서로 해결할 수 있다고 생각합니다.
`

Dijkstra에 대한 해결 방법으로 대기열에 가짜 요소를 추가하면 작동하며 처리하는 그래프 가장자리의 총 수는 변경되지 않습니다. 그러나 처리 에지에서 생성된 힙에 상주하는 임시 노드의 수는 변경되며 이는 메모리 사용량과 대기열에 넣기 및 대기열에서 빼는 효율성에 영향을 줄 수 있습니다.

IReadOnlyCollection을 수행할 수 없는 것에 대해 틀렸습니다. 괜찮을 것입니다. 해당 인터페이스에는 Add() 및 Remove()가 없습니다. (내가 무슨 생각을 하고 있었는지...)

@Ivanidzo4ka 귀하의 의견은 두 가지 개별 유형을 갖는 것이 합리적이라는 것을 더욱 확신시킵니다. 하나는 단순한 바이너리 힙(즉, 업데이트 없음)이고 다른 하나는 제안 중 하나에 설명된 대로입니다.

• 바이너리 힙은 간단하고 구현하기 쉬우며 작은 API를 가지고 있으며 많은 중요한 시나리오에서 실제로 잘 수행되는 것으로 알려져 있습니다.
• 완전한 우선 순위 대기열은 일부 시나리오(즉, 조밀하게 연결된 그래프에서 검색을 위한 공간 복잡성 감소 및 시간 복잡성 감소)에 대한 이론적 이점을 제공하고 더 많은 알고리즘/시나리오에 대한 자연스러운 API를 제공합니다.

과거에는 10년 전 가장 좋은 부분을 작성한 바이너리 힙과 SortedSet / Dictionary 조합을 대부분 사용하지 않고 사용하는 시나리오가 있습니다. 두 가지 유형이 서로 다른 역할을 합니다(KSSP가 떠오름).

클래스가 아닌 구조체이므로 NullReference 예외가 없습니다.

나는 그것이 반대라고 주장하고 싶습니다. 누군가가 기본값을 전달하고 있다면 NRE를 보고 싶습니다. 그러나 나는 우리가 이러한 것들이 사용될 것으로 예상하는 곳을 명확히 해야 한다고 생각합니다. 노드/핸들은 아마도 클래스여야 하지만, 단지 한 쌍을 읽고/반환하는 것이라면 구조체여야 한다는 데 동의합니다.

핸들 기반 제안에서 요소와 우선 순위를 업데이트할 수 있어야 한다고 제안하고 싶습니다. 핸들을 제거하고 새 핸들을 추가하면 동일한 효과를 얻을 수 있지만 유용한 작업이며 구현에 따라 성능상의 이점이 있을 수 있습니다(예: 일부 힙은 상대적으로 저렴하게 무언가의 우선순위를 낮출 수 있음). 이러한 변화는 (예를 들어,이 정돈 많은 것을 구현할 수 것 이 기존 AlgoKit ParingHeap에 따라 다소 악몽 유도 예) 상태 공간의 알 수없는 지역에서 제품이 특히입니다.

우선순위 대기열 제안(v2.1)

요약

.NET Core 커뮤니티는 시스템 라이브러리 _priority queue_ 기능을 추가할 것을 제안합니다. 이 기능은 각 요소에 추가로 연결된 우선 순위가 있는 데이터 구조입니다. 특히 System.Collections.Generic 네임스페이스에 PriorityQueue<TElement, TPriority> 를 추가할 것을 제안합니다.

신조

우리의 설계에서 우리는 다음과 같은 원칙에 따라 진행되었습니다(더 나은 원칙을 알고 있지 않는 한).

• 넓은 범위. 우리는 .NET Core 고객에게 다양한 사용 사례를 지원하기에 충분히 다재다능한 귀중한 데이터 구조를 제공하고자 합니다.
• 알려진 실수로부터 배우십시오. 우리는 Java, Python, C++, Rust와 같은 다른 프레임워크 및 언어에 존재하는 고객 대면 문제가 없는 우선 순위 대기열 기능을 제공하기 위해 노력합니다. 우리는 고객을 불행하게 만들고 우선 순위 대기열의 유용성을 줄이는 것으로 알려진 디자인 선택을 피합니다.
• 일방통행 결정으로 극도의 주의를 기울입니다. API는 한 번 도입되면 수정하거나 삭제할 수 없으며 확장만 가능합니다. 우리는 고객이 영원히 고착될 차선의 솔루션을 피하기 위해 설계 선택을 신중하게 분석할 것입니다.
• 디자인 마비를 피하십시오. 우리는 완벽한 솔루션이 없을 수 있음을 인정합니다. 우리는 절충안의 균형을 맞추고 납품을 계속 진행하여 마침내 고객이 수년 동안 기다려온 기능을 제공할 것입니다.

배경

고객의 입장에서

개념적으로 우선 순위 대기열은 각 요소에 연결된 우선 순위가 있는 요소 모음입니다. 우선 순위 대기열의 가장 중요한 기능은 컬렉션에서 우선 순위가 가장 높은 요소에 대한 효율적인 액세스와 해당 요소를 제거하는 옵션을 제공한다는 것입니다. 예상되는 동작에는 다음이 포함될 수도 있습니다. 1) 이미 컬렉션에 있는 요소의 우선 순위를 수정하는 기능; 2) 여러 우선 순위 대기열을 병합하는 기능.

컴퓨터 과학 배경

우선 순위 대기열은 추상 데이터 구조입니다. 즉, 이전 섹션에서 설명한 대로 특정 동작 특성을 가진 개념입니다. 우선 순위 대기열의 가장 효율적인 구현은 힙을 기반으로 합니다. 그러나 일반적인 오해와 달리 힙(heap)도 추상적인 데이터 구조이며 다양한 방식으로 구현될 수 있으며 각각의 장단점이 다릅니다.

대부분의 소프트웨어 엔지니어는 어레이 기반 바이너리 힙 구현에만 익숙합니다. 이는 가장 간단한 구현이지만 불행히도 가장 효율적인 구현은 아닙니다. 일반적인 임의 입력의 경우 더 효율적인 힙 유형의 두 가지 예는 4차 힙 및 페어링 힙 입니다. 힙에 대한 자세한 내용은 Wikipedia 및 이 문서 를 참조하십시오.

업데이트 메커니즘은 주요 설계 과제입니다.

우리의 논의는 설계에서 가장 도전적인 영역이자 동시에 API에 가장 큰 영향을 미치는 영역이 업데이트 메커니즘이라는 것을 보여주었습니다. 특히 문제는 고객에게 제공하려는 제품이 컬렉션에 이미 있는 요소의 우선 순위 업데이트를 지원해야 하는지 여부와 방법을 결정하는 것입니다.

이러한 기능은 예를 들어 Dijkstra의 최단 경로 알고리즘이나 변화하는 우선 순위를 처리해야 하는 작업 스케줄러를 구현하는 데 필요합니다. Java에는 업데이트 메커니즘이 없습니다. 예 를 들어 32,000번 이상 조회된 세 가지 StackOverflow 질문인 example , example , example 에서 엔지니어에게 실망스러운 것으로 나타났습니다. 이러한 제한된 가치의 API 도입을 피하기 위해 우리가 제공하는 우선 순위 대기열 기능에 대한 기본 요구 사항은 컬렉션에 이미 있는 요소에 대한 우선 순위 업데이트 기능을 지원하는 것이라고 생각합니다.

업데이트 메커니즘을 제공하려면 고객이 업데이트하려는 항목에 대해 구체적으로 설명할 수 있어야 합니다. 우리는 이것을 전달하는 두 가지 방법을 확인했습니다. b) 컬렉션에 있는 요소의 고유성 적용을 통해. 이들 각각은 다른 이점과 비용을 수반합니다.

옵션(a): 핸들. 이 접근 방식에서는 요소가 대기열에 추가될 때마다 데이터 구조가 고유한 핸들을 제공합니다. 고객이 업데이트 메커니즘을 사용하려는 경우 나중에 업데이트하려는 요소를 명확하게 지정할 수 있도록 이러한 핸들을 추적해야 합니다. 이 솔루션의 주요 비용은 고객이 이러한 포인터를 관리해야 한다는 것입니다. 그러나 이것이 우선 순위 대기열 내에서 핸들을 지원하기 위해 내부 할당이 필요하다는 것을 의미하지는 않습니다. 배열 기반이 아닌 모든 힙은 각 노드가 자동으로 자체 핸들이 되는 노드를 기반으로 합니다. 예를 들어 PairingHeap.Update 메서드의 API를 참조하십시오.

옵션(b): 고유성. 이 접근 방식은 고객에게 두 가지 추가 제약을 가합니다. i) 우선 순위 대기열 내의 요소는 새로운 클래스의 잠재적 사용자 버그를 가져오는 특정 평등 의미 체계를 따라야 합니다. ii) 두 개의 동일한 요소는 동일한 대기열에 저장할 수 없습니다. 이 비용을 지불함으로써 핸들 접근 방식에 의존하지 않고 업데이트 메커니즘을 지원하는 이점을 얻습니다. 그러나 고유성/동등성을 활용하여 업데이트할 요소를 결정하는 모든 구현에는 추가 내부 매핑이 필요하므로 O(n)이 아닌 O(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) 에서 열거가 발생할 수 있도록 정의되지 않은 순서로. 효율적인 구현은 요소가 순서대로 열거되도록 보장하면서 선형 시간에 힙을 열거하는 기능을 제공하지 않습니다. 이를 위해서는 O(n log n)이 필요합니다. 컬렉션에 대한 주문은 .OrderBy(x => x.Priority) 로 간단하게 달성할 수 있고 모든 고객이 이 주문으로 열거에 관심이 있는 것은 아니므로 정의되지 않은 열거 순서를 제공하는 것이 더 낫다고 생각합니다.

2. Contains 또는 TryGet 메소드가 없는 이유는 무엇입니까?

힙의 요소를 찾는 것은 어떤 것을 의미, 전체 컬렉션의 열거를 필요로하기 때문에 이러한 방법을 제공하는 것은, 무시할 값을 가지고 Contains 또는 TryGet 방법이 열거 래퍼가 될 것입니다. 또한 컬렉션에 요소가 있는지 확인하려면 우선 순위 대기열에서 TElement 개체의 동등성 검사를 수행하는 방법을 알고 있어야 합니다. 이는 우선 순위 대기열의 책임에 속하지 않아야 합니다.

3. PriorityQueueNode 를 반환하는 Dequeue 및 TryDequeue 오버로드가 있는 이유는 무엇입니까?

이것은 Update 또는 Remove 방법을 사용하고 핸들을 추적하려는 고객을 위한 것입니다. 우선 순위 대기열에서 요소를 대기열에서 빼는 동안 핸들 추적 시스템의 상태를 조정하는 데 사용할 수 있는 핸들을 받습니다.

4. Update 또는 Remove 메소드가 다른 큐에서 노드를 수신하면 어떻게 됩니까?

우선 순위 큐에서 예외가 발생합니다. LinkedListNode<T> 가 자신이 속한 LinkedList<T> 인식하는 것처럼 각 노드는 자신이 속한 우선 순위 대기열을 인식합니다.

부록

부록 A: 우선 순위 대기열 기능이 있는 기타 언어

| 언어 | 유형 | 메모 |
|:-:|:-:|:-:|
| 자바 | 우선순위 큐 | 추상 클래스 AbstractQueue 확장하고 인터페이스 Queue 구현합니다. |
| 녹 | 바이너리힙 | |
| 스위프트 | CFBinary힙 | |
| C++ | 우선순위 대기열 | |
| 파이썬 | 힙Q | |
| 이동 | 힙 | 힙 인터페이스가 있습니다. |

부록 B: 검색 가능성

데이터 구조를 논의할 때 _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 메소드를 제거했습니다.
• FAQ #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) 의 오버로드를 추가했습니다.
• FAQ #3 추가: _ PriorityQueueNode 를 반환하는 Dequeue 및 TryDequeue 오버로드가 있는 이유는 무엇입니까?_
• FAQ #4 추가: _ Update 또는 Remove 메소드가 다른 대기열에서 노드를 수신하면 어떻게 됩니까?_

변경 사항을 알려주셔서 감사합니다 ;)

설명을 위한 작은 요청:

• 대기열에 없는 요소에 대해 유지되도록 FAQ 4를 검증할 수 있습니까? (즉, 제거된 것)
• 안정성에 대한 FAQ를 추가할 수 있습니까? 예를 들어 동일한 우선 순위를 가진 요소를 대기열에서 제거할 때 보장(있는 경우)을 추가할 수 있습니까?

@pgolebiowski 제안된 Merge 방법에 대해:

public void Merge(PriorityQueue<TElement, TPriority> other); // O(1)

분명히 그러한 작업에는 복사 의미 체계가 없으므로 this 및 other _after_ 병합이 수행된 후 변경하는 데 문제가 있는지 궁금합니다(예: 두 인스턴스 모두 실패 힙 속성을 만족시키기 위해).

@eiriktsarpalis @VisualMelon — 감사합니다! 제기된 사항, ETA 2020-10-04를 다룰 것입니다.

다른 사람들이 더 많은 피드백/질문/걱정/생각이 있는 경우 공유해 주세요 😊

우선순위 대기열 제안(v2.2)

요약

.NET Core 커뮤니티는 시스템 라이브러리 _priority queue_ 기능을 추가할 것을 제안합니다. 이 기능은 각 요소에 추가로 연결된 우선 순위가 있는 데이터 구조입니다. 특히 System.Collections.Generic 네임스페이스에 PriorityQueue<TElement, TPriority> 를 추가할 것을 제안합니다.

신조

우리의 설계에서 우리는 다음과 같은 원칙에 따라 진행되었습니다(더 나은 원칙을 알고 있지 않는 한).

• 넓은 범위. 우리는 .NET Core 고객에게 다양한 사용 사례를 지원하기에 충분히 다재다능한 귀중한 데이터 구조를 제공하고자 합니다.
• 알려진 실수로부터 배우십시오. 우리는 Java, Python, C++, Rust와 같은 다른 프레임워크 및 언어에 존재하는 고객 대면 문제가 없는 우선 순위 대기열 기능을 제공하기 위해 노력합니다. 우리는 고객을 불행하게 만들고 우선 순위 대기열의 유용성을 줄이는 것으로 알려진 디자인 선택을 피합니다.
• 일방통행 결정으로 극도의 주의를 기울입니다. API는 한 번 도입되면 수정하거나 삭제할 수 없으며 확장만 가능합니다. 우리는 고객이 영원히 고착될 차선의 솔루션을 피하기 위해 설계 선택을 신중하게 분석할 것입니다.
• 디자인 마비를 피하십시오. 우리는 완벽한 솔루션이 없을 수 있음을 인정합니다. 우리는 절충안의 균형을 맞추고 납품을 계속 진행하여 마침내 고객이 수년 동안 기다려온 기능을 제공할 것입니다.

배경

고객의 입장에서

개념적으로 우선 순위 대기열은 각 요소에 연결된 우선 순위가 있는 요소 모음입니다. 우선 순위 대기열의 가장 중요한 기능은 컬렉션에서 우선 순위가 가장 높은 요소에 대한 효율적인 액세스와 해당 요소를 제거하는 옵션을 제공한다는 것입니다. 예상되는 동작에는 다음이 포함될 수도 있습니다. 1) 이미 컬렉션에 있는 요소의 우선 순위를 수정하는 기능; 2) 여러 우선 순위 대기열을 병합하는 기능.

컴퓨터 과학 배경

우선 순위 대기열은 추상 데이터 구조입니다. 즉, 이전 섹션에서 설명한 대로 특정 동작 특성을 가진 개념입니다. 우선 순위 대기열의 가장 효율적인 구현은 힙을 기반으로 합니다. 그러나 일반적인 오해와 달리 힙(heap)도 추상적인 데이터 구조이며 다양한 방식으로 구현될 수 있으며 각각의 장단점이 다릅니다.

대부분의 소프트웨어 엔지니어는 어레이 기반 바이너리 힙 구현에만 익숙합니다. 이는 가장 간단한 구현이지만 불행히도 가장 효율적인 구현은 아닙니다. 일반적인 임의 입력의 경우 더 효율적인 힙 유형의 두 가지 예는 4차 힙 및 페어링 힙 입니다. 힙에 대한 자세한 내용은 Wikipedia 및 이 문서 를 참조하십시오.

업데이트 메커니즘은 주요 설계 과제입니다.

우리의 논의는 설계에서 가장 도전적인 영역이자 동시에 API에 가장 큰 영향을 미치는 영역이 업데이트 메커니즘이라는 것을 보여주었습니다. 특히 문제는 고객에게 제공하려는 제품이 컬렉션에 이미 있는 요소의 우선 순위 업데이트를 지원해야 하는지 여부와 방법을 결정하는 것입니다.

이러한 기능은 예를 들어 Dijkstra의 최단 경로 알고리즘이나 변화하는 우선 순위를 처리해야 하는 작업 스케줄러를 구현하는 데 필요합니다. Java에는 업데이트 메커니즘이 없습니다. 예 를 들어 32,000번 이상 조회된 세 가지 StackOverflow 질문인 example , example , example 에서 엔지니어에게 실망스러운 것으로 나타났습니다. 이러한 제한된 가치의 API 도입을 피하기 위해 우리가 제공하는 우선 순위 대기열 기능에 대한 기본 요구 사항은 컬렉션에 이미 있는 요소에 대한 우선 순위 업데이트 기능을 지원하는 것이라고 생각합니다.

업데이트 메커니즘을 제공하려면 고객이 업데이트하려는 항목에 대해 구체적으로 설명할 수 있어야 합니다. 우리는 이것을 전달하는 두 가지 방법을 확인했습니다. b) 컬렉션에 있는 요소의 고유성 적용을 통해. 이들 각각은 다른 이점과 비용을 수반합니다.

옵션(a): 핸들. 이 접근 방식에서는 요소가 대기열에 추가될 때마다 데이터 구조가 고유한 핸들을 제공합니다. 고객이 업데이트 메커니즘을 사용하려는 경우 나중에 업데이트하려는 요소를 명확하게 지정할 수 있도록 이러한 핸들을 추적해야 합니다. 이 솔루션의 주요 비용은 고객이 이러한 포인터를 관리해야 한다는 것입니다. 그러나 이것이 우선 순위 대기열 내에서 핸들을 지원하기 위해 내부 할당이 필요하다는 것을 의미하지는 않습니다. 배열 기반이 아닌 모든 힙은 각 노드가 자동으로 자체 핸들이 되는 노드를 기반으로 합니다. 예를 들어 PairingHeap.Update 메서드의 API를 참조하십시오.

옵션(b): 고유성. 이 접근 방식은 고객에게 두 가지 추가 제약을 가합니다. i) 우선 순위 대기열 내의 요소는 새로운 클래스의 잠재적 사용자 버그를 가져오는 특정 평등 의미 체계를 따라야 합니다. ii) 두 개의 동일한 요소는 동일한 대기열에 저장할 수 없습니다. 이 비용을 지불함으로써 핸들 접근 방식에 의존하지 않고 업데이트 메커니즘을 지원하는 이점을 얻습니다. 그러나 고유성/동등성을 활용하여 업데이트할 요소를 결정하는 모든 구현에는 추가 내부 매핑이 필요하므로 O(n)이 아닌 O(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) 에서 열거가 발생할 수 있도록 정의되지 않은 순서로. 효율적인 구현은 요소가 순서대로 열거되도록 보장하면서 선형 시간에 힙을 열거하는 기능을 제공하지 않습니다. 이를 위해서는 O(n log n)이 필요합니다. 컬렉션에 대한 주문은 .OrderBy(x => x.Priority) 로 간단하게 달성할 수 있고 모든 고객이 이 주문으로 열거에 관심이 있는 것은 아니므로 정의되지 않은 열거 순서를 제공하는 것이 더 낫다고 생각합니다.

2. Contains 또는 TryGet 메소드가 없는 이유는 무엇입니까?

힙의 요소를 찾는 것은 어떤 것을 의미, 전체 컬렉션의 열거를 필요로하기 때문에 이러한 방법을 제공하는 것은, 무시할 값을 가지고 Contains 또는 TryGet 방법이 열거 래퍼가 될 것입니다. 또한 컬렉션에 요소가 있는지 확인하려면 우선 순위 대기열에서 TElement 개체의 동등성 검사를 수행하는 방법을 알고 있어야 합니다. 이는 우선 순위 대기열의 책임에 속하지 않아야 합니다.

3. PriorityQueueNode 를 반환하는 Dequeue 및 TryDequeue 오버로드가 있는 이유는 무엇입니까?

이것은 Update 또는 Remove 방법을 사용하고 핸들을 추적하려는 고객을 위한 것입니다. 우선 순위 대기열에서 요소를 대기열에서 빼는 동안 핸들 추적 시스템의 상태를 조정하는 데 사용할 수 있는 핸들을 받습니다.

4. Update 또는 Remove 메소드가 다른 큐에서 노드를 수신하면 어떻게 됩니까?

우선 순위 큐에서 예외가 발생합니다. LinkedListNode<T> 가 자신이 속한 LinkedList<T> 인식하는 것처럼 각 노드는 자신이 속한 우선 순위 대기열을 인식합니다. 또한 노드가 대기열에서 제거된 경우 해당 노드에서 Update 또는 Remove 를 호출하려고 하면 예외가 발생합니다.

5. Merge 메서드가 없는 이유는 무엇입니까?

두 개의 우선 순위 대기열을 병합하는 것은 일정한 시간에 달성할 수 있으므로 고객에게 제공하는 매력적인 기능입니다. 그러나 우리는 그러한 기능에 대한 수요가 있음을 입증할 데이터가 없으며 이를 공개 API에 포함하는 것을 정당화할 수 없습니다. 또한 이러한 기능의 설계는 사소하지 않으며 이 기능이 필요하지 않을 수 있으므로 API 표면 및 구현을 불필요하게 복잡하게 만들 수 있습니다.

그럼에도 불구하고 현재 Merge 메서드를 포함하지 않는 것은 양방향 도어입니다. 향후 고객이 병합 기능 지원에 관심을 표명하면 PriorityQueue 유형을 확장할 수 있습니다. 따라서 아직 Merge 메서드를 포함하지 않고 출시를 진행하는 것이 좋습니다.

6. 컬렉션이 안정성을 보장합니까?

컬렉션은 기본적으로 안정성을 보장하지 않습니다. 즉, 두 요소가 동일한 우선 순위로 대기열에 있는 경우 고객은 특정 순서로 대기열에서 제거될 것이라고 가정할 수 없습니다. 그러나 고객이 PriorityQueue 사용하여 안정성을 얻으려면 TPriority 및 이를 보장하는 해당 IComparer<TPriority> 를 정의할 수 있습니다. 또한 데이터 수집은 결정적입니다. 즉, 주어진 작업 시퀀스에 대해 항상 동일한 방식으로 작동하여 재현성을 허용합니다.

부록

부록 A: 우선 순위 대기열 기능이 있는 기타 언어

| 언어 | 유형 | 메모 |
|:-:|:-:|:-:|
| 자바 | 우선순위 큐 | 추상 클래스 AbstractQueue 확장하고 Queue 인터페이스를 구현합니다. |
| 녹 | 바이너리힙 | |
| 스위프트 | CFBinary힙 | |
| C++ | 우선순위 대기열 | |
| 파이썬 | 힙Q | |
| 이동 | 힙 | 힙 인터페이스가 있습니다. |

부록 B: 검색 가능성

데이터 구조를 논의할 때 _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) 메소드를 제거했습니다.
• FAQ #5 추가: Merge 메서드가 없는 이유는 무엇입니까?
• 우선 순위 대기열에서 제거된 노드에 대해서도 유지하도록 FAQ #4를 수정했습니다.
• FAQ #6 추가: 컬렉션이 안정성을 보장합니까?

새로운 FAQ가 좋아 보입니다. 핸들 사전을 사용하여 제안된 API에 대해 Dijkstra를 코딩하면서 놀았고 기본적으로 괜찮아 보였습니다.

이 작업을 통해 얻은 작은 교훈 중 하나는 현재 메서드 이름/오버로드 집합이 out 변수의 암시적 입력에 대해 잘 작동하지 않는다는 것입니다. C# 코드로 하고 싶었던 것은 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. 평등 기반 접근 방식은 고유성을 강제로 적용하여 API 계약을 복잡하게 만들고 내부적으로 추가 장부를 필요로 합니다. 이는 사용자에게 우선 순위 업데이트가 필요한지 여부에 관계없이 발생합니다.
2. 핸들 기반 접근 방식은 대기열에 추가된 요소당 하나 이상의 추가 할당을 의미합니다. 이 고유성을 적용하지 않지만, 내 인상의 필요성을 scenaria이 불변 거의 확실 암시 적이다 (방법 예 : 공지 업데이트 있다는 것입니다 모두 예 요소 자체에 의해 색인 외부 사전에 저장 핸들 위에 나열된을).
3. 업데이트는 전혀 지원되지 않거나 힙의 선형 순회가 필요합니다. 중복 요소의 경우 업데이트가 모호할 수 있습니다.

일반적인 PriorityQueue 애플리케이션 식별

위의 접근 방식 중 대부분의 사용자에게 최상의 가치를 제공할 수 있는 방법을 식별하는 것이 중요합니다. 그래서 가장 일반적인 사용 패턴이 무엇인지 더 잘 이해하기 위해 Heap/PriorityQueue 구현의 인스턴스에 대해 Microsoft 내부 및 공용 .NET 코드베이스를 살펴보았습니다.

대부분의 애플리케이션은 힙 정렬 또는 작업 스케줄링의 변형을 구현합니다. 토폴로지 정렬 또는 허프만 코딩과 같은 알고리즘에 몇 가지 인스턴스가 사용되었습니다. 그래프에서 거리를 계산하는 데 더 작은 숫자가 사용되었습니다. 조사된 80개의 PriorityQueue 구현 중 9개만이 우선 순위 업데이트의 일부 형태를 구현한 것으로 나타났습니다.

동시에 Python, Java, C++, Go, Swift 또는 Rust 핵심 라이브러리의 Heap/PriorityQueue 구현은 API에서 우선 순위 업데이트를 지원하지 않습니다.

권장 사항

이 데이터에 비추어 볼 때 .ΝΕΤ에는 필수 API(heapify/push/peek/pop)를 노출하고 특정 성능 보장(예: 대기열당 추가 할당 없음)을 제공하고 강제하지 않는 기본 PriorityQueue 구현이 필요하다는 것이 분명합니다. 고유성 제약. 이것은 구현이 _O(log n) 우선 순위 업데이트를 지원하지 않을 것임을 의미합니다_.

또한 _O(log n)_ 업데이트/제거를 지원하고 동등 기반 접근 방식을 사용하는 별도의 힙 구현을 따르는 것을 고려해야 합니다. 이것은 특수화된 유형이므로 고유성 요구사항은 그다지 문제가 되지 않습니다.

저는 두 가지 구현을 모두 프로토타이핑하는 작업을 하고 있으며 곧 API 제안에 대한 후속 조치를 취할 것입니다.

@eiriktsarpalis, 분석에 감사드립니다! 특히 Microsoft 내부 코드베이스를 분석하여 관련 사용 사례를 찾고 데이터에 대한 논의를 지원하는 시간을 주셔서 감사합니다.

핸들 기반 접근 방식은 대기열에 추가된 요소당 하나 이상의 추가 할당을 의미합니다.

이 가정은 거짓이며 노드 기반 힙에 추가 할당이 필요하지 않습니다. 페어링 힙은 어레이 기반 이진 힙보다 일반적인 임의 입력에 대해 성능이 더 우수합니다. 즉, 업데이트를 지원하지 않는 우선 순위 대기열에 대해서도 이 노드 기반 힙을 사용할 인센티브가 있습니다. 앞서 언급한 논문 에서 벤치마크를 볼 수 있습니다.

조사된 80개의 PriorityQueue 구현 중 9개만이 우선 순위 업데이트의 일부 형태를 구현한 것으로 나타났습니다.

이 작은 샘플을 감안하더라도 전체 사용량의 11-12%입니다. 또한 이 비율이 더 높을 것으로 예상되는 비디오 게임과 같은 특정 영역에서는 이 비율이 과소 표시될 수 있습니다.

이 데이터에 비추어 볼 때 [...]

핵심 가정 중 하나가 거짓이고 고객의 11-12%가 충분히 중요한 사용 사례인지 여부가 논쟁의 여지가 있다는 점을 감안할 때 그러한 결론이 명확하지 않다고 생각합니다. 귀하의 평가에서 제가 누락된 것은 이 메커니즘에 관심이 없는 고객을 위한 "업데이트를 지원하는 데이터 구조"의 비용 영향에 대한 평가입니다. 핸들 메커니즘의 영향을 받지 않습니다.

원래:

| | 11-12% 사용 사례 | 88-89% 사용 사례 |
|:-:|:-:|:-:|
| 업데이트에 대한 관심 | 네 | 아니 |
| 핸들에 의해 부정적인 영향을 받습니다 | N/A(원하는 것) | 아니 |
| 핸들에 의해 긍정적인 영향을 받습니다 | 네 | 아니 |

나에게 이것은 88-89%뿐만 아니라 100% 사용 사례를 지원하는 데 찬성하는 것은 당연합니다.

이 가정은 거짓이며 노드 기반 힙에 추가 할당이 필요하지 않습니다.

우선 순위와 항목이 모두 값 유형인 경우(또는 둘 다 소유하지 않거나 기본 유형을 변경할 수 없는 참조 유형인 경우) 추가 할당이 필요하지 않음을 보여주는 구현에 연결할 수 있습니까? 달성 방법을 설명하십시오)? 보시면 도움이 될 것입니다. 감사 해요.

더 자세히 설명하거나 말하려는 내용을 말씀해 주시면 도움이 될 것입니다. 나는 명확해야 하고 탁구를 할 것이고 그것은 긴 토론으로 바뀔 것입니다. 또는 전화를 주선할 수 있습니다.

호출자 측에서든 구현 측에서든 할당을 필요로 하는 Enqueue 작업을 피하고 싶다고 말하고 싶습니다(예를 들어 구현에 사용되는 배열을 확장하기 위해 분할 내부 할당은 괜찮습니다). 노드 기반 힙에서 이것이 어떻게 가능한지 이해하려고 합니다(예: 해당 노드 개체가 호출자에게 노출되는 경우 부적절한 재사용/앨리어싱에 대한 우려로 인해 구현에 의한 풀링을 금지함). 나는 다음과 같이 쓸 수 있기를 원한다.
C# pq.Enqueue(42, 84);
할당하지 않도록 합니다. 당신이 참조하는 구현은 어떻게 그것을 달성합니까?

또는 당신이 말하려는 것을 말하십시오

나는 내가 생각했다.

할당이 필요한 Enqueue 작업을 피하고 싶습니다. [...] 저는 pq.Enqueue(42, 84); 를 쓰고 할당하지 않도록 하고 싶습니다.

이 욕망은 어디에서 오는가? 99.9% 고객이 만족해야 하는 요구 사항이 아닌 솔루션의 부작용이 있다는 것은 좋은 일입니다. 솔루션 간에 설계를 선택하기 위해 왜 이 영향이 적은 차원을 선택하는지 모르겠습니다.

다른 차원의 12%의 고객에게 부정적인 영향을 미치는 경우 0.1%의 고객을 위한 최적화를 기반으로 설계를 선택하지 않습니다. "할당 없음에 신경쓰지 않음" + "두 가지 값 유형 다루기"는 극단적인 경우입니다.

저는 지원되는 동작/기능의 차원이 훨씬 더 중요하다는 것을 알았습니다. 특히 광범위한 청중과 다양한 사용 사례를 위한 범용 다목적 데이터 구조를 설계할 때 그렇습니다.

이 욕망은 어디에서 오는가?

성능을 고려하는 시나리오에서 핵심 컬렉션 유형을 사용할 수 있기를 원합니다. 노드 기반 솔루션이 사용 사례의 100%를 지원한다고 말합니다. List<T> , Dictionary<TKey, TValue> , HashSet<T> 등과 같이 모든 enqueue가 할당하는 경우는 그렇지 않습니다. 모든 Add에 할당되는 경우 on은 많은 상황에서 사용할 수 없게 됩니다.

왜 이러한 방법의 할당 오버헤드에 관심이 있는 것이 "0.1%"라고 생각하십니까? 그 데이터는 어디에서 오는가?

"할당 없음에 신경쓰지 않음" + "두 가지 값 유형 다루기"는 극단적인 경우입니다.

그렇지 않다. 또한 "두 가지 값 유형"만이 아닙니다. 내가 이해하는 바에 따르면 제안된 솔루션은 a) 관련된 T에 관계없이 모든 대기열에 할당하거나 b) 요소 유형이 알려진 기본 유형에서 파생되어야 하므로 많은 수의 가능한 사용을 금지해야 합니다. 추가 할당을 피하십시오.

@eiriktsarpalis
따라서 옵션을 잊지 마십시오. 귀하의 목록에서 옵션 1, 2 및 3에 추가할 수 있는 실행 가능한 옵션 4가 있다고 생각합니다. 이는 절충안입니다.

1. 12% 사용 사례를 지원하는 구현과 동등 가능한 요소에 대한 업데이트를 허용하여 나머지 88%에 대해 거의 최적화하고 업데이트 메서드가 처음 호출될 때 이러한 업데이트를 수행하는 데 필요한 조회 테이블을 _lazily_ 구축합니다( 및 하위 시퀀스 업데이트+제거에서 업데이트). 따라서 기능을 사용하지 않는 앱에 대해 더 적은 비용이 발생합니다.

업데이트 가능한 데이터 구조가 필요하지 않거나 처음에 최적화된 구현에서 88% 또는 12%에 사용할 수 있는 추가 성능이 있기 때문에 옵션 2와 3을 제공하는 것이 더 낫다고 여전히 결정할 수 있습니다. 옵션 4. 하지만 다른 옵션이 있다는 사실을 잊어서는 안 된다고 생각했습니다.

[또는 이것을 더 나은 옵션 1로 보고 1에 대한 설명을 업데이트하여 부기가 강요되지는 않지만 게으르고 올바른 동등 동작은 업데이트가 사용될 때만 필요하다고 말하도록 업데이트할 수 있다고 가정합니다...]

@stephentoub 딱 제가 하고 싶은 말을 하려고 마음

왜 이러한 방법의 할당 오버헤드를 신경 쓰는 사람이 0.1%에 불과하다고 생각합니까? 그 데이터는 어디에서 오는가?

직관에서, 즉 "업데이트 수행 능력"보다 "추가 할당 없음"에 우선 순위를 두는 것이 더 중요하다고 생각하는 동일한 소스입니다. 적어도 업데이트 메커니즘의 경우 11-12%의 고객이 이 동작을 지원하는 데 필요한 데이터가 있습니다. 나는 원격으로 가까운 고객이 "추가 할당 없음"에 관심을 가질 것이라고 생각하지 않습니다.

두 경우 모두, 어떤 이유로 인해 메모리 차원에 고착하기로 선택하고 다른 차원(예: 선호하는 접근 방식에 대한 또 다른 절충안)은 잊어버리게 됩니다. "추가 할당 없음"을 제공하는 어레이 기반 구현은 노드 기반 구현보다 느립니다. 다시 말하지만, 속도보다 메모리를 우선시하는 것은 임의적이라고 생각합니다.

한발 물러서서 고객이 원하는 것에 집중합시다. 우리는 고객의 12%가 데이터 구조를 사용할 수 없게 만들 수도 있고 사용하지 않을 수도 있는 디자인을 선택할 수 있습니다. 지원하지 않기로 결정한 이유를 제공하는 데 매우 신중해야 한다고 생각합니다.

"추가 할당 없음"을 제공하는 어레이 기반 구현은 노드 기반 구현보다 느립니다.

비교를 수행하는 데 사용하고 있는 두 가지 C# 구현과 그 결론에 도달하는 데 사용된 벤치마크를 공유하십시오. 이론적인 논문은 확실히 가치가 있지만 퍼즐의 작은 조각일 뿐입니다. 더 중요한 것은 고무가 도로를 만날 때 주어진 플랫폼과 주어진 구현의 세부 사항을 고려하고 특정 구현 및 일반적/예상 데이터 세트/사용 패턴으로 특정 플랫폼에서 유효성을 검사할 수 있다는 것입니다. 당신의 주장이 옳을 수도 있습니다. 또한 그렇지 않을 수도 있습니다. 더 잘 이해할 수 있도록 구현/데이터를 보고 싶습니다.

비교를 수행하는 데 사용하는 두 가지 C# 구현과 해당 결론에 도달하는 데 사용된 벤치마크를 공유하세요.

내가 인용한 논문은 C++에서 구현을 비교하고 벤치마크만 하고 있다는 점입니다. 다양한 데이터 세트 및 사용 패턴으로 여러 벤치마크를 수행합니다. 나는 이것이 C#으로 이전될 수 있다고 확신하지만 이것이 우리가 두 배로 줄여야 할 필요가 있다고 생각한다면 동료에게 그러한 연구를 수행하도록 요청하는 것이 가장 좋은 조치라고 생각합니다.

@pgolebiowski 귀하의 이의 제기의 성격을 더 잘 이해하고 싶습니다. 제안서는 두 가지 개별 유형을 지지하는데, 이것이 귀하의 요구 사항을 충족하지 않습니까?

1. 12%의 사용 사례를 지원하는 구현과 동등할 수 있는 요소에 대한 업데이트를 허용하고 업데이트 메서드가 처음 호출될 때 이러한 업데이트를 수행하는 데 필요한 조회 테이블을 느리게 구축하여 나머지 88%에 대해 거의 최적화합니다( 및 하위 시퀀스 업데이트+제거에서 업데이트). 따라서 기능을 사용하지 않는 앱에 대해 더 적은 비용이 발생합니다.

옵션 1에 대한 성능 최적화로 분류할 수 있지만 특정 접근 방식에는 몇 가지 문제가 있습니다.

• 이제 업데이트가 _O(n)_이 되어 사용 패턴에 따라 예측할 수 없는 성능이 발생할 수 있습니다.
• 고유성을 검증하기 위해 룩업 테이블도 필요합니다. Update를 호출하기 _전에_ 동일한 요소를 두 번 대기열에 넣는 것은 허용되고 틀림없이 대기열을 일관성 없는 상태로 만듭니다.

@eiriktsarpalis 그것의 유일한 O(n) 한 번, 그리고 O(1) 이후에 상각되는 O(1)입니다. 그리고 첫 번째 업데이트까지 고유성 검증을 연기할 수 있습니다. 그러나 이것은 지나치게 영리한 것일 수도 있습니다. 2개의 클래스가 더 설명하기 쉽습니다.

저는 지난 며칠 동안 두 가지 PriorityQueue 구현을 프로토타이핑하는 데 보냈습니다. 업데이트 지원이 없는 기본 구현과 요소 동등성을 사용하여 업데이트를 지원하는 구현입니다. 나는 전자의 이름을 PriorityQueue 로, 후자를 PrioritySet 지었습니다. 내 목표는 API 인체 공학을 측정하고 성능을 비교하는 것입니다.

구현은 이 리포지토리에서 찾을 수 있습니다. 두 클래스 모두 어레이 기반 쿼드 힙을 사용하여 구현됩니다. 업데이트 가능한 구현은 요소를 내부 힙 인덱스에 매핑하는 사전도 사용합니다.

기본 우선순위 큐

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());

업데이트 가능한 PriorityQueue

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;
    }
}

성능 비교

가장 기본적인 애플리케이션에서 두 가지 구현을 비교하는 간단한 힙 정렬 벤치마크 를 작성했습니다. 또한 비교를 위해 Linq를 사용하는 정렬 벤치마크도 포함했습니다.

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

| 방법 | 크기 | 평균 | 오류 | 표준 개발 | 비율 | 비율SD | 0세대 | 1세대 | 2세대 | 할당됨 |
|---------------- |------ |-------------:|-------------: |-------------:|------:|--------:|--------:|-------- :|--------:|----------:|
| 링크 정렬 | 30 | 1.439 우리 | 0.0072 우리 | 0.0064 우리 | 1.00 | 0.00 | 0.0095 | - | - | 672B |
| 우선순위 큐 | 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 B |
| 우선순위 큐 | 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 B |
| 우선순위 큐 | 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 B |
| 우선순위 큐 | 30000 | 5,688.625미국 | 53.0746 우리 | 49.6460 미국 | 1.09 | 0.01 | - | - | - | 2B |
| 우선순위 설정 | 30000 | 8,124.306 우리 | 39.9498 미국 | 37.3691 우리 | 1.55 | 0.01 | - | - | - | 4B |

예상할 수 있듯이 추적 요소 위치의 오버헤드는 기준 구현에 비해 약 40-50% 느린 상당한 성능 저하를 추가합니다.

모든 노력에 감사드립니다. 많은 시간과 에너지가 필요했습니다.

1. 나는 하나가 다른 것의 열등한 버전인 2개의 거의 동일한 데이터 구조에 대한 이유를 알지 못합니다.
2. 게다가 2가지 버전의 우선순위 대기열을 갖고 싶어도 20일 전의 우선순위 대기열 제안(v2.2) 보다 "우수" 버전이 얼마나 좋은지 모르겠습니다.

박사:

• 이 제안은 흥미진진합니다!! 그러나 아직 내 고성능 사용 사례에는 맞지 않습니다.
• 내 계산 지오메트리/모션 계획 성능 로드의 >90%는 알고리즘에서 지배적인 N^m LogN이기 때문에 PQ enqueue/dequeue입니다.
• 저는 별도의 PQ 구현에 찬성합니다. 나는 일반적으로 우선 순위 업데이트가 필요하지 않으며 2배 더 나쁜 성능은 허용되지 않습니다.
• PrioritySet은 혼란스러운 이름이며 PriorityQueue와 비교하여 검색할 수 없습니다.
• 우선 순위를 두 번(내 요소에 한 번, 대기열에 한 번) 저장하는 것은 비싸게 느껴집니다. 구조체 복사본 및 메모리 사용량.
• 컴퓨팅 우선 순위가 비싸면 단순히 (priority: ComputePriority(element), element) 튜플을 PQ에 저장하고 우선 순위 getter 함수는 단순히 tuple => tuple.priority 입니다.
• 성능은 작업별로 또는 대안적으로 실제 사용 사례에서 벤치마킹되어야 합니다(예: 그래프에서 최적화된 다중 시작 다중 끝 검색).
• 순서가 지정되지 않은 열거 동작은 예기치 않은 것입니다. 큐와 같은 Dequeue() 순서 의미 체계를 선호합니까?
• 클론 작업 및 병합 작업 지원을 고려하십시오.
• 정상 상태 사용에서 기본 작업은 0-할당이어야 합니다. 이 대기열을 풀링하겠습니다.
• 풀링을 돕기 위해 heapify를 수행하는 EnqueueMany 지원을 고려하십시오.

저는 로봇 공학과 게임 모두와 관련된 고성능 검색(모션 계획) 및 계산 기하학 코드(예: 스윕라인 알고리즘)에서 일하며 사용자 지정 수동 우선 순위 대기열을 많이 사용합니다. 내가 가지고 있는 다른 일반적인 사용 사례는 업데이트 가능한 우선 순위가 유용하지 않은 Top-K 쿼리입니다.

두 가지 구현(예 및 업데이트 지원 없음) 토론에 대한 몇 가지 피드백입니다.

명명:

• PrioritySet은 집합 의미 체계를 의미하지만 대기열은 ISet을 구현하지 않습니다.
• 내가 PriorityQueue를 검색하면 더 쉽게 찾을 수 있는 UpdatablePriorityQueue 이름을 사용하고 있습니다.

성능:

• 우선 순위 대기열 성능은 내 기하학/계획 알고리즘에서 거의 항상 내 성능 병목 현상(>90%)입니다.
• Func 전달 고려또는 비교Tpriority를 ​​복사하는 것보다 ctor에(비싼!) 컴퓨팅 우선 순위가 비싸면 PQ에 (우선 순위, 요소)를 삽입하고 캐시된 우선 순위를 살펴보는 비교를 전달합니다.
• 내 알고리즘의 상당수는 PQ 업데이트가 필요하지 않습니다. 업데이트를 지원하지 않는 내장 PQ를 사용하는 것을 고려하고 싶지만, 내가 필요하지 않은(업데이트) 기능을 지원하기 위해 성능 비용이 2배라면 나에게 쓸모가 없습니다.
• 성능 분석 / 트레이드오프의 경우 @eiriktsarpalis 작업당 대기열에 넣기/
• 생성자가 Heapify를 수행하는 것을 보고 기뻤습니다. 열거형 할당을 피하기 위해 IList, List 또는 Array를 사용하는 생성자를 고려하십시오.
• PQ가 초기에 비어 있는 경우 Heapify를 수행하는 EnqueueMany를 노출하는 것을 고려하십시오. 고성능에서는 컬렉션을 풀링하는 것이 일반적이기 때문입니다.
• 요소에 참조가 포함되지 않은 경우 Clear를 0이 아닌 배열로 만드는 것을 고려하십시오.
• enqueue/dequeue의 할당은 허용되지 않습니다. 내 알고리즘은 풀링된 스레드 로컬 컬렉션을 사용하여 성능상의 이유로 0 할당입니다.

아피스:

• 우선 순위 대기열 복제는 구현 시 간단한 작업이며 자주 유용합니다.
  
  
  
  • 관련: 우선 순위 대기열을 열거하는 데 대기열과 유사한 의미 체계가 있어야 합니까? Queue가 하는 것과 유사한 dequeue-order 컬렉션을 기대합니다. new List(myPriorityQueue)가 priorityQueue를 변경하지 않고 방금 설명한 대로 작동할 것으로 예상합니다.
  
  
• 위에서 언급했듯이 우선적으로 삽입하는 것보다 Func<TElement, TPriority> 것이 좋습니다. 컴퓨팅 우선 순위가 비싸면 (priority, element) 를 삽입하고 func tuple => tuple.priority 제공하면 됩니다.
• 두 개의 우선 순위 대기열을 병합하는 것이 때때로 유용합니다.
• Peek이 TItem을 반환하지만 Enumeration & Enqueue에는 (TItem, Tpriority)가 있다는 것이 이상합니다.

즉, 상당한 수의 내 알고리즘에서 우선 순위 대기열 항목에 우선 순위가 포함되어 있으며 두 번(PQ에 한 번, 항목에 한 번) 저장하는 것이 비효율적으로 들립니다. 이것은 특히 내가 수많은 키로 주문하는 경우입니다(OrderBy.ThenBy.ThenBy와 유사한 사용 사례). 이 API는 또한 Insert가 우선 순위를 갖지만 Peek이 반환하지 않는 많은 불일치를 정리합니다.

마지막으로 배열 요소 자체가 아니라 배열의 인덱스를 우선 순위 큐에 삽입 하는 있습니다 . 그러나 이것은 지금까지 논의된 모든 API에서 지원됩니다. 예를 들어, x축 라인에서 간격의 시작/끝을 처리하는 경우 우선 순위 대기열 이벤트 (x, isStartElseEnd, intervalId) 있고 x 순으로 정렬된 다음 isStartElseEnd 순으로 정렬될 수 있습니다. 이는 인덱스에서 일부 계산된 데이터로 매핑되는 다른 데이터 구조가 있기 때문인 경우가 많습니다.

@pgolebiowski 제안한 페어링 힙 구현 을 벤치마크에 포함하여 세 가지 접근 방식의 인스턴스를 직접 비교할 수 있도록 했습니다. 결과는 다음과 같습니다.

| 방법 | 크기 | 평균 | 오류 | 표준 개발 | 중앙값 | 0세대 | 1세대 | 2세대 | 할당됨 |
|---------------- |-------- |-------------------:|---- ----------:|-----------------:|---------------- ---:|----------:|------:|------:|-------------:|
| 우선순위 큐 | 10 | 774.7ns | 3.30ns | 3.08ns | 773.2ns | - | - | - | - |
| 우선순위 설정 | 10 | 1,643.0ns | 3.89ns | 3.45ns | 1,642.8ns | - | - | - | - |
| 페어링힙 | 10 | 1,660.2ns | 14.11ns | 12.51ns | 1,657.2ns | 0.0134 | - | - | 960B |
| 우선순위 큐 | 50 | 6,413.0ns | 14.95ns | 13.99ns | 6,409.5ns | - | - | - | - |
| 우선순위 설정 | 50 | 12,193.1ns | 35.41ns | 29.57ns | 12,188.3ns | - | - | - | - |
| 페어링힙 | 50 | 13,955.8ns | 193.36ns | 180.87ns | 13,989.2ns | 0.0610 | - | - | 4800B |
| 우선순위 큐 | 150 | 27,402.5ns | 76.52ns | 71.58ns | 27,410.2ns | - | - | - | - |
| 우선순위 설정 | 150 | 48,485.8ns | 160.22ns | 149.87ns | 48,476.3ns | - | - | - | - |
| 페어링힙 | 150 | 56,951.2ns | 190.52ns | 168.89ns | 56,953.6ns | 0.1831 | - | - | 14400B |
| 우선순위 큐 | 500 | 124,933.7ns | 429.20ns | 380.48ns | 124,824.4ns | - | - | - | - |
| 우선순위 설정 | 500 | 206,310.0ns | 433.97ns | 338.81ns | 206,319.0ns | - | - | - | - |
| 페어링힙 | 500 | 229,423.9ns | 3,213.33ns | 2,848.53ns | 230,398.7ns | 0.4883 | - | - | 48000B |
| 우선순위 큐 | 1000 | 284,481.8ns | 475.91ns | 445.16ns | 284,445.6ns | - | - | - | - |
| 우선순위 설정 | 1000 | 454,989.4ns | 3,712.11ns | 3,472.31ns | 455,354.0ns | - | - | - | - |
| 페어링힙 | 1000 | 459,049.3ns | 1,706.28ns | 1,424.82ns | 459,364.9ns | 0.9766 | - | - | 96000B |
| 우선순위 큐 | 10000 | 3,788,802.4ns | 11,715.81ns | 10,958.98ns | 3,787,811.9ns | - | - | - | 1B |
| 우선순위 설정 | 10000 | 5,963,100.4ns | 26,669.04ns | 22,269.86ns | 5,950,915.5ns | - | - | - | 2B |
| 페어링힙 | 10000 | 6,789,719.0ns | 134,453.01ns | 265,397.13ns | 6,918,392.9ns | 7.8125 | - | - | 960002 B |
| 우선순위 큐 | 1000000 | 595,059,170.7ns | 4,001,349.38ns | 3,547,092.00ns | 595,716,610.5ns | - | - | - | 4376 B |
| 우선순위 설정 | 1000000 | 1,592,037,780.9ns | 13,925,896.05ns | 12,344,944.12ns | 1,591,051,886.5ns | - | - | - | 288B |
| 페어링힙 | 1000000 | 1,858,670,560.7ns | 36,405,433.20ns | 59,815,170.76ns | 1,838,721,629.0ns | 1000.0000 | - | - | 96000376 B |

핵심 테이크아웃

• ~페어링 힙 구현은 배열 지원 구현보다 점근적으로 훨씬 더 잘 수행됩니다. 그러나 작은 힙 크기(< 50개 요소)의 경우 최대 2배 느리고 약 1000개의 요소를 따라잡을 수 있지만 크기가 10^6~인 힙의 경우 최대 2배 빠릅니다.
• 예상대로 페어링 힙은 상당한 양의 힙 할당을 생성합니다.
• "PrioritySet" 구현은 일관되게 ~세 경쟁자 중 가장 느립니다~, 그래서 우리는 결국 그 접근 방식을 추구하고 싶지 않을 수도 있습니다.

~위의 관점에서 나는 여전히 기준 어레이 힙과 페어링 힙 접근 방식 사이에 유효한 절충점이 있다고 믿습니다~.

편집: 내 벤치마크에서 버그 수정 후 결과를 업데이트했습니다. @VisualMelon 감사합니다.

@eiriktsarpalis PairingHeap 대한 귀하의 벤치마크는 잘못된 것 같습니다. Add 대한 매개변수는 잘못된 방향입니다. 교환하면 이야기가 달라집니다. https://gist.github.com/VisualMelon/00885fe50f7ab0f4ae5cd1307312109f

(처음 구현할 때와 똑같은 작업을 수행했습니다.)

이것은 페어링 힙이 더 빠르거나 느리다는 의미가 아니라 제공된 데이터의 배포/순서에 크게 의존하는 것 같습니다.

@eiriktsarpalis re: PrioritySet의 유용성...
시나리오에서 우선 순위 업데이트가 없기 때문에 업데이트 가능이 heapsort에 대해 더 느리다는 것 외에 다른 것을 기대해서는 안 됩니다. (또한 힙 정렬의 경우 중복을 유지 하기를 원할 가능성이 높으므로 세트가 적절하지 않습니다.)

PrioritySet이 유용한지 알아보기 위한 리트머스 테스트는 우선 순위 업데이트를 사용하는 벤치마킹 알고리즘과 동일한 알고리즘의 비업데이트 구현, 큐에서 중복 값을 큐에 넣고 큐에서 제거할 때 중복을 무시해야 합니다.

@VisualMelon 감사합니다. 제안된 수정 사항 이후에 결과와 의견을 업데이트했습니다.

오히려 제공된 데이터의 배포/순서에 크게 의존하는 것 같습니다.

대기열에 있는 우선 순위가 단조롭다는 사실에서 이점을 얻었을 수 있다고 생각합니다.

PrioritySet이 유용한지 알아보기 위한 리트머스 테스트는 우선 순위 업데이트를 사용하는 벤치마킹 알고리즘과 동일한 알고리즘의 비업데이트 구현, 큐에서 중복 값을 큐에 넣고 큐에서 제거할 때 중복을 무시해야 합니다.

@TimLovellSmith 여기에서 제 목표는 가장 일반적인 PriorityQueue 애플리케이션의 성능을 측정하는 것이었습니다. 업데이트의 성능을 측정하기보다 업데이트가 전혀 필요하지 않은 경우에 미치는 영향을 보고 싶었습니다. 그러나 페어링 힙을 "PrioritySet" 업데이트와 비교하는 별도의 벤치마크를 생성하는 것이 합리적일 수 있습니다.

@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 | - | - | 480B |
| 우선순위 설정 | 50 | 7.394 우리 | 0.0527 우리 | 0.0493 우리 | 7.380 우리 | - | - | - | - |
| 페어링힙 | 50 | 8.587 우리 | 0.1678 우리 | 0.1570 미국 | 8.634 우리 | 0.0305 | - | - | 2400B |
| 우선순위 설정 | 150 | 27.522 우리 | 0.0459 우리 | 0.0359 우리 | 27.523 우리 | - | - | - | - |
| 페어링힙 | 150 | 32.045 우리 | 0.1076 우리 | 0.1007 우리 | 32.019 우리 | 0.0610 | - | - | 7200B |
| 우선순위 설정 | 500 | 109.097 우리 | 0.6548 우리 | 0.6125 우리 | 109.162 우리 | - | - | - | - |
| 페어링힙 | 500 | 131.647 우리 | 0.5401 우리 | 0.4510 우리 | 131.588 우리 | 0.2441 | - | - | 24000B |
| 우선순위 설정 | 1000 | 238.184 우리 | 1.0282 우리 | 0.9618 우리 | 238.457 우리 | - | - | - | - |
| 페어링힙 | 1000 | 293.236 우리 | 0.9396 미국 | 0.8789 미국 | 293.257 우리 | 0.4883 | - | - | 48000B |
| 우선순위 설정 | 10000 | 3,035.982 미국 | 12.2952 우리 | 10.8994 미국 | 3,036.985미국 | - | - | - | 1B |
| 페어링힙 | 10000 | 3,388.685미국 | 16.0675 우리 | 38.1861 우리 | 3,374.565 미국 | - | - | - | 480002 B |
| 우선순위 설정 | 1000000 | 841,406.888 미국 | 16,788.4775 미국 | 15,703.9522 미국 | 840,888.389 미국 | - | - | - | 288B |
| 페어링힙 | 1000000 | 989,966.501미국 | 19,722.6687 미국 | 30,705.8191 미국 | 996,075.410미국 | - | - | - | 48000448 B |

별도의 메모에서 안정성 부족이 사람들의 사용 사례에 대한 문제(또는 문제가 아님)에 대한 토론/피드백이 있었습니까?

안정성 부족이 사람들의 사용 사례에 대한 문제(또는 문제가 아님)에 대한 토론/피드백이 있었습니다.

어떤 구현도 안정성을 보장하지 않지만 사용자가 삽입 순서로 서수를 보강하여 안정성을 얻는 것은 매우 간단해야 합니다.

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 소스 코드의 일반적인 우선 순위 대기열 사용 패턴입니다.
• 경쟁 프레임워크의 핵심 라이브러리에서 PriorityQueue 구현.
• 다양한 .NET 우선 순위 대기열 프로토타입의 벤치마크.

결과는 다음과 같습니다.

• 우선 순위 대기열 사용 사례의 90%는 우선 순위 업데이트가 필요하지 않습니다.
• 우선 순위 업데이트를 지원하면 API 계약이 더 복잡해집니다(핸들 또는 요소 고유성 필요).
• 내 벤치마크에서 우선 순위 업데이트를 지원하는 구현은 그렇지 않은 구현에 비해 2-3배 느립니다.

다음 단계

앞으로 .NET 6에 대해 다음 작업을 수행할 것을 제안합니다.

1. 단순하고 대부분의 사용자 요구 사항을 충족하며 가능한 한 효율적인 System.Collections.Generic.PriorityQueue 클래스를 소개합니다. 어레이 지원 4차 힙을 사용하며 우선 순위 업데이트를 지원하지 않습니다. 구현의 프로토타입은 여기 에서 찾을 수

2. 효율적인 우선 순위 업데이트를 지원하는 힙의 필요성을 인식하고 있으므로 이 요구 사항을 해결하는 특수 클래스를 도입하기 위해 계속 노력할 것입니다. 우리는 각각 고유한 장단점이 있는 몇 가지 프로토타입 [ 1 , 2 ]을 평가하고 있습니다. 디자인을 마무리하는 데 더 많은 작업이 필요하므로 나중에 이 유형을 도입하는 것이 좋습니다.

현재 이 스레드의 기여자, 특히 @pgolebiowski 와 @TimLovellSmith에게 감사의 인사를 전하고 싶습니다. 귀하의 피드백은 디자인 프로세스를 안내하는 데 큰 역할을 했습니다. 업데이트 가능한 우선 순위 대기열의 디자인을 다듬는 동안 계속해서 귀하의 의견을 받기를 바랍니다.

앞으로 .NET 6에 대해 다음 작업을 수행할 것을 제안합니다. [...]

좋은 소리 :)

단순하고 대부분의 사용자 요구 사항을 충족하며 가능한 한 효율적인 System.Collections.Generic.PriorityQueue 클래스를 소개합니다. 어레이 지원 4차 힙을 사용하며 우선 순위 업데이트를 지원하지 않습니다.

코드베이스 소유자가 이 방향을 승인하고 원한다고 결정한 경우 해당 비트에 대한 API 설계를 계속 이끌고 최종 구현을 제공할 수 있습니까?

현재 이 스레드의 기여자, 특히 @pgolebiowski 와 @TimLovellSmith에게 감사의 인사를 전하고 싶습니다. 귀하의 피드백은 디자인 프로세스를 안내하는 데 큰 역할을 했습니다. 업데이트 가능한 우선 순위 대기열의 디자인을 다듬는 동안 계속해서 귀하의 의견을 받기를 바랍니다.

나름 여행이었습니다 :D

System.Collections.Generic.PriorityQueue<TElement, TPriority> 대한 API가 승인되었습니다. 우선 순위 업데이트를 지원하는 잠재적인 힙 구현에 대한 대화를 계속하기 위해 별도의 문제 를 만들었습니다.

이번 호를 마치겠습니다. 여러분의 기여에 감사드립니다!

누군가가 이 여행에 대해 글을 쓸 수 있을지도 모릅니다! 하나의 API에 대해 총 6년. :) 기네스를 획득할 기회가 있습니까?