This question already has answers here:
What's the difference between set<pair> and map in C++?
(7 answers)
Closed 9 years ago.
I'm relatively new to c++ programming and was wondering if someone could help clarify a few questions for me.
http://www.cplusplus.com/reference/set/set/
http://www.cplusplus.com/reference/map/map/
I've been reading on how to implement STL binary search trees and I keep noticing that std::set and std::map are constantly mentioned as the methods for accomplishing such a task. What exactly is the difference between the two however? To me both seem almost identical and I'm not sure if there's something I'm not noticing that makes one better than the other for specific tasks. Is there any advantage of using std::set over std::map for implementing a STL binary search tree that takes values from an array or vector (such as speed for example)?
If someone could help me understand this concept I'd greatly appreciate it!
Both std::set and std::map are associative containers. The difference is that std::sets contain only the key,
while in std::map there is an associated value , that is if A -> B , then map[A]=B , this works like hashing but not O(1) , instead O(log N).
You can further look unordered_map which provides the operation in O(1) time.
std::set keeps data in sorted format .
Implementation of both is done by balanced trees (like AVL or Red-Black trees ) giving O(logN) time complexity.
But important point to note is that both can store unique values . To overcome that you must see also multimap and multiset .
Hope this helps !
update: In the case of Red-Black tree re-balancing rotation is an O(1) operation while with AVL this is a O(log n) operation, making the Red-Black tree more efficient in this aspect of the re-balancing stage and one of the possible reasons that it is more commonly used.
Related
Can anyone help me with the time complexity involved in finding a value in various STL Containers
Vectors
deque
list
string
set
multiset
map
multimap
stack
queue
priority queue.
I think, the search/find time should be based on how these STL containers are implemented internally. So it would help if information about same can be provided as well. It might vary from implementation to implementation, so answers based on commonly used data structures behind these STL containers would also help.
Thanks in advance..
This question already has answers here:
Binary search tree over AVL tree
(4 answers)
Closed 7 years ago.
It seems to me like an AVL tree is always more efficient than an BST. So why do people still use BST? Is there a costs incurred in an AVL implementation?
AVL Trees have their advantages and disadvantages over other trees like Red-Black trees or 2-3 Trees or just plain BST.
AVL Trees:
Advantage:
Simple. Fairly easy to code and understand
Extra storage: fairly minimal, 2 bits per node (to store +1,0,-1). There is also a
trick where you can use 1 bit per node by using your children's
single bit.
The constant for lookup (look in your favorite
analysis book: Knuth, etc.) is 1.5
(so 1.5 log). Red-Black trees have a constant of 2 (so 2*log(n) for a lookup).
Disadvantages:
Deletions are expensive-ish. It is still logarithm to delete a node, but you may have to "rotate" all the way up to the root of the tree. In other words, a bigger constant. Red-Black trees only have to do 1 rotate.
Not simple to code. They are probably the "simplist" of the tree family, but there are still a lot or corner cases.
If you expect your data to be sorted, a BST devolves into a linked list. BUT if you expect your data to be fairly random, "on average", all of your operations for a BST (lookup, deletion, insertion) will be about logarithmic. It's VERY easy to code up BSTs: AVL trees, although fairly straightforward to code up, have a lot of corner cases and testing can be tricky.
In summary, plain Binary Search Trees are easy to code and get right, and if your data is fairly random, should perform very well (on average, all operations would be logarithmic). AVL Tree are harder to code, but guarantee logarithmic performance, at the price of some extra space and more complex code.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How is a C++ multimap implemented?
C++ reference mentions
Multimaps are typically implemented as binary search trees.
But what is their typical internal representation?
Is it like std::map<Key, std::list<Value> > or similar?
My concern is complexity of insertion and iteration over a set of elements with the same key.
If you want to know the complexity of specific operations, you need look no further than to the standard. The standard has guarantees on the complexity, but implementations are free to satisfy those guarantees any way they wish.
For insertion the complexity is O(lg n), unless you specify an optimal hint every time, in which case the complexity is O(1) amortized. (See details here: http://en.cppreference.com/w/cpp/container/multimap/insert)
For iteration over a set of elements with the same key, the complexity is the same as iteration from any iterator to another. Given that you have already found the iterators, the iteration is linear in the count of items you are iterating over. (Sorry, unable to find a reference for this right now)
I'm looking for a binary data structure (tree, list) that enables very fast searching. I'll only add/remove items at the beginning/end of the program, all at once. So it's gonna be fixed-sized, thus I don't really care about the insertion/deletion speed. Basically what I'm looking for is a structure that provides fast searching and doesn't use much memory.
Thanks
Look up the Unordered set in the Boost C++ library here. Unlike red-black trees, which are O(log n) for searching, the unordered set is based on a hash, and on average gives you O(1) search performance.
One container not to be overlooked is a sorted std::vector.
It definitely wins on the memory consumption, especially if you can reserve() the correct amount up front.
So the key can be a simple type and the value is a smallish structure of five pointers.
With only 50 elements it starts getting small enough that the Big-O theoretical performance may be overshadowed or at least measurable affected by the fixed time overhead of the algorithm or structure.
For example an array a vector with linear search is often the fastest with less than ten elements because of its simple structure and tight memory.
I would wrap the container and run real data on it with timing. Start with STL's vector, go to the standard STL map, upgrade to unordered_map and maybe even try Google's dense or sparse_hash_map:
http://google-sparsehash.googlecode.com/svn/trunk/doc/performance.html
One efficient (albeit a teeny bit confusing) algorithm is the Red-Black tree.
Internally, the c++ standard library uses Red-Black trees to implement std::map - see this question
The std::map and hash map are good choices. They also have constructors to ease one time construction.
The hash map puts key data into a function that returns an array index. This may be slower than an std::map, but only profiling will tell.
My preference would be std::map, as it is usually implemented as a type of binary tree.
The fastest tends to be a trei/trie. I implemented one 3 to 15 times faster than the std::unordered_map, they tend to use more ram unless you use a large number of elements though.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
STL like container with O(1) performance.
I always thought that std::map is a hashed list. In that case shouldn't lookup be O(1). The documentation says it's O(logn). What's an appropriate data structure in STL that mimics a hashed map the best with O(1) insertion and lookup.
std::map is implemented as a binary search tree. So lookups are not O(1). TR1 and C++0x are adding a hash map to the STL called an unordered_map. See http://en.wikipedia.org/wiki/Unordered_map_(C%2B%2B)
Depending on your compiler, you might have unordered_map or possible hash_map in the STL.
There is no official STL container with constant lookup. However, several library implementations provide a non-standard hash_map container which does O(1) lookups (http://www.sgi.com/tech/stl/hash_map.html)
You are looking for std::hash_map.