JuliaCollections / JuliaCollections/DataStructures.jl

Should PriorityQueue allow duplicates?

Open
#246 3 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Julia
Stars
745
Forks
261
PR merge metrics
No merged PRs in 30d

Description

Note: This issue was originally filed in Base Julia by John Myles White at https://github.com/JuliaLang/julia/issues/4372. In addition to the issue text I've also reproduced the existing comments on the issue.


@johnmyleswhite:

My understanding of priority queues is that they should allow duplicate keys: this is, for example, how the STL and Java priority queue implementations work as far as I can tell (cf. http://stackoverflow.com/questions/251438/stl-priority-queue-with-duplicate-keys-is-it-possible, http://stackoverflow.com/questions/10469701/how-to-configure-java-priority-queue-to-ignore-duplicates). Right now, our implementation doesn't do this because it acts more like a Dict than a queue.

Could we possibly rename our current implementation to PriorityQueueDict and then implement a more standard PriorityQueue that behaves like a queue/array?


@stevengj:

Note that you can use heappush! etcetera if you don't want it to act like a Dict.


@dcjones:

The intention with making it behave like a Dict was to make things like Dijkstra or A* that require updating element priorities easier to write, which is an idea from clojure's priority-map. That struck me as a more common problem than needing to have multiple copies of the same element in the queue. Searching stack overflow for questions about updating priorities in C++ or Java, you get a bunch of answers suggesting you write your own priority queue.

So I'd like to keep the current priority queue in some form. Two priority queue types is one way to address this, we could also change the semantics of the current implementation so that duplicates are allowed q[x] = 100, changes the priority of just one occurrence of x (i.e. most recently enqueued).


@lindahua:

Two different things are involved here: (1) the priority weight/value, which should allow duplicates, and (2) the handle that refers to a particular node in the heap (I think that's what @dcjones mentioned as the key).

The DataStructures.jl package takes a different approach, implementing both a non-mutable heap and a mutable heap. The mutable heap returns a handle when you push an element, with which the user can update the value later (e.g. in Dijkstra's algorithm).

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue discusses the PriorityQueue implementation, heappush!, and mutable versus non-mutable heaps, but names no source files or tests. First inspect the current PriorityQueue API and its duplicate-key behavior; this issue is not complete until the project chooses and documents a specific queue and handle model.

Written by the indexing model from the issue text.

Assessment

Tech stack
julia
Domain
data
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.