Just curious, but without my references im not really sure but what kind of heap is that? Fibonnacci?
Assuming you are referring to the EoPwP heap that educated_foo
points to, then (as stated by educated_foo, who refers to me in the
plural :-) it is strictly a simple, array-based implementation of a
binary heap. It isn't documented except as it is built in the book.
A main difference between this and the Heap model is that
this one contains the comparison routines internally and works on the
model of selecting a comparison method on heap creation and supplying
a suitable key and satellite data for each inserted element (it is
easy to use any objects for which you can supply a key) --- to use
objects with the Heap version you need all of your objects
to supply their own cmp() method for comparing themselves with any
other object type in the heap. The latter is more flexible because
the comparison routines may be arbitrarily complex, but does require
that all your objects either inherit or supply their own common
comparison method.
| [reply] |
Which "that"? Heap implements normal ("binary"), binomial, and fibonnacci heaps. The "Elements of" version is a normal binary heap.
/s | [reply] |
| [reply] |
I'd guess because (1) they're simple, and (2) they're fast enough. Fibonnacci heaps are probably one of the most complicated data structures known to man. Second, O(log N) is not that bad, so there's relatively little to be gained. Even though Fib heaps are O(1) amortized where binary heaps are O(log N), the constants are large enough that especially in Perl, they'll probably cause them to lose for most reasonable values of N. There isn't that much difference between O(log N) and O(1) (or O(log log N) for binomial), so constants can easily outweight the gains. For example:
log N log log N 1
256 8 3 1
1K 10 3.3 1
1M 20 4.3 1
So if inserting an item in a fibonnacci heap is 10 times as complicated as inserting one in a binary heap (not entirely unlikely), the binary heap is faster for 1000 elements.
/s | [reply] |
