I'm going to disagree a bit with Scara95. With out context of your answer this seems like whether or not your answer is wrong could possibly be a matter of pedantry. Technically, yes, its not O(N) + O(log(N)) because it is possible to find the location of elements in constant time. However, this requires an entirely different data-structure to go along with your binary heap. You have to map inserted elements to a hash table, such that when you insert elements into the priority you also insert a new entry into the hashtable, a unique hash of the element you just inserted, with the location as the value.
To update, you query the hashtable with the ID of the element in the priority queue you want to update, and grab the hashtable elements value to find out where to update the priority queue element, where you percolate up/heapify up / down
But at this point, you no longer have just a binary heap, you have a binary heap and a hash-table, arguably a new data structure as the actual functions to update the heap can't be separated from the two data-structures. You can actually implement binary heaps where the update complexity can't get better than O(N) given that you simply don't include a hashtable. Often you'll even find papers on new algorithms/data-structures are actually the same data structures but with new components often other datastructures mixed in the same way the hash-table would have to be, so this makes this whole exercise extra confusing.
Bottom line is that if the question asked you about what the best possible update complexity would be for a binary heap, your answer was wrong, no questions asked, but if the question was more specific in terms of what you guys talked about in class, talking about a binary heap formed in a specific way, things get a lot more complicated.
decrease-key
, it is O(log n) according to en.wikipedia.org/wiki/…. Apparently it assumes you already know where the vertex is located, so no need for the linear search.decrease-key
operation. When you delete a node out of a binary tree, you don't count "finding the node" in the complexity; that's already a separate operation having its own complexity assignment. All complexities for "delete" operations assume that you already have knowledge of the node that you want to delete.