Associative Arrays as i understood it stores key value pairs and it is of variable length. Like we can add any number of key value pairs to Associative array.
Also i read to use
while loop to traverse sparese Associative array and
For loop to traverse Dense Associative array.
How can an associative array be sparse it is dynamic and we are adding values to it
Associative arrays are sparse because they are stored in the order of the hash of their key and not in the order they were inserted. An array is dense because elements are always appended to the end as they are added. When you preform operations like insert on an array you are actually creating a new array and appending values. This makes inserts "expensive" in that they require more CPU time to find the insertion point and more memory to store the intermediate copies while insertion is taking place. With an assocative array insertion (as long as it doesnt expand the size of the associative array beyond the hash key size) is fast in that it takes a predictably small amount of CPU and memory. The other thing that is expensive with arrays is looking up a specific value by its key. With associative arrays you can quickly lookup any element (or know immediately that there is no element with that key) while with an array you have to test every index to know where or if an element exists. On small sets this might not seem like a big deal but these problems only get worse the larger your sets become. Don't think associative arrays are the best and only way though. They get their speed by using more memory. Also iterating over all keys in an associative array (depending on the data type implementation) can be slower than iterative through a dense array. As is always the best advice try to choose the best tool for the job.
Associative array are dense and sparse depending how you index it.
If you index it with a primary key or pls_integer or something which can pack data densely then the assosiative array becomes dense. And it will be fast to fetch data.
Where as if you index by some varchar2 column or others which wont be easy to fetch then that specific assosiative array is sparse.
Related
public class Entry{
int key;
String value;
}
If you have an array of Entry.
Entry[]
You can do a binary search on this array to find, Insert or remove an Entry all in O(Log(n)). I can also do a range search in O(log(n)).
And this is very simple.
What does a comparatively complicated data structure like a red-black balanced search tree, give me over a simple sorted key value array?
If data is immutable, the tree has no benefit.
The only benefit of the array is locality of reference, e.g. data is close together and CPU may cache it.
Because the array is sorted, search is O(log n)
If you add / remove items things changed.
For small number of elements, the array is better (faster) this is because of the locality of reference.
For larger number of items Red Black Tree (or another self balanced tree) will perform better, because the array will need to shift the elements.
e.g. insert and delete will take O(log n) + huge n/2 for the shift.
Going over some interview info about data structures etc.
So, as I understand, arrays are O(1) for indexing, which I believe means finding the specific element contained at space x in the array. Just want to confirm this as I am second guessing myself.
Also, hash maps are O(1) for indexing, searching, insertion and deletion. Does that not kind of make any data structure question pointless, since a hash map will always be the best solution?
Thanks
Well indexing is not only about arrays,
according to this - indexing is creating tables (indexes) that point to the location of folders, files and records. Depending on the purpose, indexing identifies the location of resources based on file names, key data fields in a database record, text within a file or unique attributes in a graphics or video file.
For your second question hash maps are not absolute or best data structures for various reasons, mainly:
Collisions
Hash function calculation time
Extra memory used
Also there's lots of Data Structure questions where hashmaps are not superior:
Data structure for finding k-th minimum element and supporting updates (Hashmap would be like bruteforce because it does not keep elements sorted, so we need something like Balanced binary search tree)
Data structure for finding if word is in dictionary (Sure hashmap works but Trie is so much faster & less memory)
Data structure for finding minimum element in any range of an array with updates (Once again hashmap is just too slow for this, we need something like segment tree)
...
I just had a software interview. One of the questions was to design any datastructure with three methods insert, delete and getRandom in a highly optimized way. The interviewer asked me to think of a combination of datastructures to design a new one. Insert can be designed anyway but for random and delete i need to get the position of specific element. He gave me a hint to think about the datastructure which takes minimum time for sorting.
Any answer or discussion is welcomed....
Let t be the type of the elements you want to store in the datastructure.
Have an extensible array elements containing all the elements in no particular order. Have a hashtable indices that maps elements of type t to their position in elements.
Inserting e means
add e at the end of elements (i.e. push_back), get its position i
insert the mapping (e,i) into `indices
deleting e means
find the position i of e in elements thanks to indices
overwrite e with the last element f of elements
update indices: remove the mapping (f,indices.size()) and insert (f,i)
drawing one element at random (leaving it in the datastructure, i.e. it's peek, not pop) is simply drawing an integer i in [0,elements.size()[ and returning elements[i].
Assuming the hashtable is well suited for your elements of type t, all three operations are O(1).
Be careful about the cases where there are 0 or 1 element in the datastructure.
A tree might work well here. Order log(n) insert and delete, and choose random could also be log(n): start at the root node and at each junction choose a child at random (weighted by the total number of leaf nodes per child) until you reach a leaf.
The data structure which takes the least time for sorting is sorted array.
get_random() is binary search, so O(log n).
insert() and delete() involve adding/removing the element in question and then resorting, which is O(n log n), e.g. horrendous.
I think his hint was poor. You may have been in a bad interview.
What I feel is that you can use some balaced version of tree like Red-Black trees. This will give O(log n) insertion and deletion time.
For getting random element, may be you can have a additional hash table to keep track of elements which are in the tree structure.
It might be Heap (data structure)
Is it possible to store multidimensional array in Redis hash
For example
HMSET('Marray','Name'=>"test12",
"Age"=>"45",
"Salary"=>"50000",
"GENDER"=>array("M"=>"1","F"=>"2"))
Or is any other possibility to store the above values
You can serialize that sub-array (as JSON, for example) and store it in a hash field. Redis doesn't support arbitrarily nested structures.
Or you can even serialize the whole structure and store it as plain string.
I'd suggest storing the array in its own key (as a hash, sorted set, or list) and storing its key in your hash/records. You'll presumably want to assign a prefix to all of those keys (so you can manage the keyspace.
This page talks about this. Redis may not be the best suit for multidimensional data though.
https://redis.io/topics/indexes
I have a plist with 3200 dictionaries. Each dictionary has 20 key/values. What's the best way to search through it?
I have a string called "id" and what I am doing right now is, iterating through all the elements of the array, asking each element (dictionary) for the value of key "id", comparing that id with other id i have, and if it's found, break.
This is really slow, like I can see a lag of about 1-2 seconds. Is there a better way?
Thanks
What you're doing now is an O(n) operation (linear in the number of items in the list). You can get a "constant time" O(1) lookup if you keep another "lookaside" data structure that helps you index into your list.
Before you write the 3200 item list of dictionaries, create one more special dictionary that maps your IDs to indexes in the big array. In other words, each key will be an ID and its value will be an NSNumber with the index number into the big array. Then save this also (either in the same plist or a separate one).
Then when you need to do a lookup, just do -objectForKey: in the lookaside dictionary, which will immediately give you back the index of the entry you're looking for.
Just make sure your lookaside dictionary is always in sync if you update them with live data. Note that this also assumes your IDs are unique (it sounds like they are).
Why don't you use a SQLite database?
The first thing I notice is that it seems you're always searching on the same id key. If that's the case, then you should sort your array of dictionaries according to id. You can then do a binary search on the sorted array. Result: finding any dictionary by id takes a maximum of 12 operations. By contrast, a linear search through 3200 items averages 1600 operations and might need as many as 3200.
Core Data might be a very good solution here if you need to search on several different keys, and if all those dictionaries have the same keys. NSManagedObject works a lot like NSMutableDictionary, but the framework will take care of indexing for you, and searching is fast and relatively easy.