heapsort

As an exercise in Haskell, I'm trying to implement heapsort. The heap is usually implemented as an array in imperative languages, but this would be hugely inefficient in purely functional languages. So I've looked at binary heaps, but everything I found so far describes them from an imperative viewpoint and the algorithms presented are hard to translate to a functional setting. How to efficiently implement a heap in a purely functional language such as Haskell? Edit: By efficient I mean it should still be in O(n*log n), but it doesn't have to beat a C program. Also, I'd like to use purely

At school we are currently learning sorting algorithms in Java and I got for my homework the Heap Sort. I did my reading, I tried to find out as much as I could, but it seems I just can't grasp the concept. I'm not asking you to write me a Java program, if you could just explain to me as simply as you can how the Heap Sort works. Matt Fellows Right, so basically you take a heap and pull out the first node in the heap - as the first node is guaranteed to be the largest / smallest depending on the direction of sort. The tricky thing is re-balancing / creating the heap in the first place. Two

Hi I've looked around a bit and haven't been able to find any direct discussion of this question. Most seem to cover time complexity and the big O notation. I'm wondering if and how the order of input into a heapsort algorithm will impact the number of comparisons needed to sort the input. For example, take a heapsort algorithm that sorts in ascending order (smallest to largest)....if I input a set of integers already ordered in this way (ascending) how many comparisons would it require compared to a set of input that is ordered in a descending manner (largest to smallest)? How about compared

I'm trying to understand why heapsort isn't stable. I've googled this, but haven't found a good, intuitive explanation. I understand the importance of stable sorting - it allows us to sort based on more than one key, which can be very beneficial (i.e., do multiple sortings, each based on a different key. Since every sort will preserve the relative order of elements, previous sortings can add up to give a final list of elements sorted by multiple criteria). However, why wouldn't heapsort preserve this as well? Thanks for your help! The final sequence of the results from heapsort comes from

It's well-known that the worst-case runtime for heapsort is Ω(n lg n), but I'm having trouble seeing why this is. In particular, the first step of heapsort (making a max-heap) takes time Θ(n). This is then followed by n heap deletions. I understand why each heap deletion takes time O(lg n); rebalancing the heap involves a bubble-down operation that takes time O(h) in the height of the heap, and h = O(lg n). However, what I don't see is why this second step should take Ω(n lg n). It seems like any individual heap dequeue wouldn't necessarily cause the node moved to the top to bubble all the way