added heappeek, heappushpop!, heapreplace! to collections, + tests

[fabianlischka]

These functions are mostly for convenience, but heappushpop! (push, then pop) and heapreplace! (pop, then push) are a smidgen faster then their equivalents, because the array gets "percolated" only once (and the percolate functions are not exported).

heapreplace! is nice for example if you want to keep a running list of the N "best" elements seen so far.

Plus, systematic tests for heapify!, heappeek, heappop!, heappush!, heappushpop!, heapreplace!, for small heaps, doubling the runtime of the "priorityqueue.jl" test from 1 to 2 seconds on my MacBook Air.

[StefanKarpinski]

This is good but the very large number of heap* functions exported from base makes me feel that this really ought to be moved out of base Julia and into DataStructures.

[tkelman]

Agreed, it looks like the only place outside of base/collections.jl that heap functions are used is in base/quadgk.jl?

[ViralBShah]

Would we remove Heaps altogether from Base then?

It seems useful to have a Heap in Base, and perhaps some of these functions could live in a Heap module so that we don't need all the heap* functions.

[fabianlischka]

Note that there appears to be a second, totally i dependent heap implementation in Datastructures, which also doesn't have the combined commands (pushpop, replace).
What do you suggest:

1. Implementing them on the Datastructures heap instead
2. Trying and unify the heaps?

[tkelman]

Would we remove Heaps altogether from Base then?

Not for 0.4. Maybe unexport but leave the implementation available in base for 0.4, and if that goes relatively painlessly, then move it out to the package during 0.5-dev?

How widely used is the base heap vs the DataStructures one?

[timholy]

One datapoint: I only use the one in Base.

[fabianlischka]

What do you suggest then? Would you accept it if I unexport (then I can still access in my code via qualified name, right)? Or implement on Datastructure heap instead?
Thanks :-)

[tkelman]

if I unexport (then I can still access in my code via qualified name, right)

Right, functions that are implemented in Base but not exported from Base can be accessed via Base.heappeek etc. Actually I think the way you have it here, it's exported from Base.Collections (which is itself exported, so you can just do Collections.heappeek) but not from Base, the only reason it's usable in test/priorityqueue.jl without qualification is because that file starts with a using Base.Collections. There's no importall .Collections in base/sysimg.jl, so I think this is fine. It adds functionality and exports to the collections module, but doesn't clutter the default namespace with new Base exports.

Or implement on Datastructure heap instead?

If you've got interesting applications built on heap functionality, either the Base.Collections heap or the DataStructures.jl heap, it would be interesting and worthwhile to compare the two I think. Up to you of course.

[tkelman]

Closing as stale. Would be worth revisiting as part of DataStructures.