Develop Reference

are there an efficent way to sort a parametermap?

I have a parameter map incoming from a post in a web form. The problem I have is that I want to have the key values sorted.
I have two keys incoming j_idt40:j_idt41:0:score and j_idt40:j_idt41:0:scoreID These I would either want to find without resorting to loop through the map for every row I iterate again. Is there a better way to do this?
j_idt40:j_idt69 = Uppdatera
j_idt40:j_idt41:3:score = 200
j_idt40:j_idt41:0:scoreID = 1
j_idt40:j_idt41:4:scoreID =
j_idt40:j_idt41:3:scoreID = 4
j_idt40:j_idt41:2:scoreID = 3
j_idt40:j_idt41:0:score = 203
j_idt40:j_idt41:2:score = 200
j_idt40:j_idt41:1:score = 200
j_idt40 = j_idt40
j_idt40:j_idt41:4:score = 800
j_idt40:j_idt41:1:scoreID = 2

Natural sorting you need to write your own comparator. The existing comparators in jdk will fail on the following scenario.
TreeMap<String,String> treeMap = new TreeMap<String, String>();
treeMap.put("key1", "value");
treeMap.put("key2", "value");
treeMap.put("key20", "value");
treeMap.put("key10", "value");
treeMap.put("key11", "value");
treeMap.put("key21", "value");
The sorting will happen like this.
key1,key10,key11,key2,key20,key21
Natural sorting is implemented in Java 8 see here
or
Use apache commons ComparatorUtils.NATURAL_COMPARATOR

will TreeMap help you in this regard ?
TreeMap Keeps everything sorted. This is built-in class in Java collection API.
You can use this constructor to convert your map to sorted map.
TreeMap(Map m) // this is from 'java.util.TreeMap'

You can pull all the Map.Entries out into a list, sort that, then loop through it once. You've have to make a Comparitor for Map.Entries.

You can sort the keys like this:
Collection<?> keys = params.keySet();
String[] array = keys.toArray(new String[keys.size()]);
Arrays.sort(array);
Or if you want the entries of the map to be ordered, you can achieve this by inserting them into a TreeMap. When you iterate the TreeMap's key set they come out in order.
Which approach is more "efficient" depends on what measure of efficiency you are talking about (CPU, memory, developer time).
It also depends on how often various things are performed by your application. For example:
lookup, insert and delete operations are on average O(1) for a HashMap and O(logN) for a TreeMap
iterating a TreeMap's key set is O(N)
extracting and sorting a Hashmap's keys is O(NlogN)

which datastructure for this hashmap scenario

I have a scenario where i store values in a hashmap.
Keys are strings like
fruits
fruits_citrus_orange
fruits_citrus_lemon
fruits_fleshly_apple
fruits_fleshly
fruits_dry
and so on.
Values are some objects. Now for a given input say fruits_fleshly i need to retrieve all cases where it starts with "fruits_fleshly"
In the above case I need to fetch
fruits_fleshly_apple
fruits_fleshly
One way to do this is by doing String.indexOf over all the keys. Is there any other effective way to do this instead of iterating over all the keys in a map

though these are strings, but to me, it looks like these are certain categories & sub categories, like fruit, fruit-freshly, fruit-citrus etc..
If that is a case you can instead implement a Tree data-structure. This would be most effective for search operation.
since Tree has a parent-child structure, there is a root node & child node. You can have a structure like this:
(0) (1) (2)
fruit
|_____citrus
| |_____lemon
| |_____orange
|
|_____freshly
|_____apple
|_____
in this structure, say if you want to search for citrus fruit, you can just go to citrus, and list all its child. And finally you can construct full name by concatenating the name as a path from root to leaves.

Iterating the map seems quite simple and straight-forward way of doing this. However, since you don't want to iterate over keys on your own, you can use Guava's Maps#filterEntries, if you are ok with using 3rd party library.
Here's how it would work:
Map<String, Object> = Maps.filterEntries(
yourMap,
Predicate.containsPattern("^fruits_fleshly"));
But, that would too iterate over the map in the backyard. So, iteration is still there, if you are bothered about efficiency.

Since HashMap doesn't maintain any order for its keys it's not a very good choice for this problem. A better choice is the TreeMap: it has methods for retrieving a sub map for a range of keys. These methods run in O(log n) time (n number of entries) so it's better than iterating over the keys.
Map subMap = myMap.subMap("fruits_fleshly", true, "fruits_fleshly\uffff", true);

The nature of a hashmap means that there's no way to do a "like" comparison on keys - you have to iterate over them all to find where key.startsWith(input).
I suppose you could nest hashmaps and split up your keys. E.g.,
{
"fruits":{
"citrus":{
"orange":(value),
"lemon":(value)
},
"fleshly":{
"apple":(value),
"":(value)
}
}
}
...etc.
The performance implications are probably horrific on a small scale, but that may not matter in a homework context but maybe not so bad if you're dealing with a lot of data and only a couple layers of nesting.
Alternatively, create a Category object with a List of Categories (sub-categories) and a List of entries.

I believe Radix Trie is what you are looking for. It is similar idea as #ay89 solution.
You can just use this open source library Radix Trie example. It perform better than O(log(N)). You will be able to find a hashmap assigned to a key in average constant time (number of underscores in your search key string) with a decent implementation of Radix Trie.fruits
fruits_citrus_orange
fruits_citrus_lemon
fruits_fleshly_apple
fruits_fleshly
fruits_dry
Trie<String, Map> trie = new PatriciaTrie<>;
trie.put("fruits", hashmap1);
trie.put("fruits_citrus_orange", hashmap2);
trie.put("fruits_citrus_lemon", hashmap3);
trie.put("fruits_fleshly_apple", hashmap4);
trie.put("fruits_fleshly", hashmap5);
Map.Entry<String, Map> entry = trie.select("fruits_fleshy");
If you just want one hashmap to be return by select you might be able to get slightly better performance if you implement your own Radix Trie.

Efficient way to subtract values in two HashMaps by key

I am wondering how to efficiently subtract the values of two maps when their keys match. Currently I have 2 HashMap<String,Integer> and do it like this:
for (String key: map1.keySet()){
if (map2.keySet().contains(key)){
//subtract
}
}
Is there a better way to do it?

Theoretically speaking, this is about as fast as it can be done unless you can somehow do a faster than O(n) way of finding the matching keys between the two HashMaps.
Iterate over keys in first map's keySet() - O(n)
See if key is in other map - O(1)
Do your operation - O(1)

Realise this is an old thread but do check out guava from google
https://code.google.com/p/guava-libraries/wiki/CollectionUtilitiesExplained#Maps
You can use Map.difference and then get the entries in common, only in left, right etc.

I think there isn't a better method unless you use a different approach, and/or different data structures. You can for example create a class named ValuePair that can contain (up to) two values, which represent the values you are currently storing in two different maps, but you instead store all the pairs in a single map, and when it comes to "subtract" you can iterate in a single set of keys. Please note that a pair can be incomplete, so that no subtraction is done.
But that's probabily overkill.

have you considered using Apache Commons Collections?
CollectionUtils.subtract( collection1, collection2 );

Extracting top recommendations from multiple recommendation lists

I have four lists of recommendations and lets say the lists are A,B,C,D.
Every list has the same number of items and are represented as key-value pairs. But I need to give more priority(weights) for the elements of list A than list B, so on. Ultimately I need to select the best set of items from the four lists for the final recommendation.
Here is a use case:
List_A:
{item1,weight1}
{item2,weight1}
{item3,weight1}
{item4,weight1}
{item5,weight1}
List_B:
{item8,weight2}
{item5,weight2}
{item7,weight2}
{item2,weight2}
{item6,weight2}
List_C:
{item11,weight3}
{item23,weight3}
{item34,weight3}
{item24,weight3}
{item5,weight3}
List_D:
{item9,weight4
{item7,weight4
{item3,weight4
{item2,weight4
{item5,weight4
Suppose weight1=10, weight2=5, weight3=3, weight1=2
According to these lists the final list should have "item5" as the first item, because it exists in all four lists. How can I get the other best recommendations for these four lists?
Thanks.

If I understand you right, this should be a bit simple. On a higher level you need a data structure as
Map<Item, Map<List, Integer>> where the final integer is number_of_occurrences. Once you have it is straightforward to multiply number_of_occurrences * weight and throw it along with generated value in a TreeMap (a priority queue can also be used here)
Now you can have the top-n list from the TreeMap.

nth item of hashmap

HashMap selections = new HashMap<Integer, Float>();
How can i get the Integer key of the 3rd smaller value of Float in all HashMap?
Edit
im using the HashMap for this
for (InflatedRunner runner : prices.getRunners()) {
for (InflatedMarketPrices.InflatedPrice price : runner.getLayPrices()) {
if (price.getDepth() == 1) {
selections.put(new Integer(runner.getSelectionId()), new Float(price.getPrice()));
}
}
}
i need the runner of the 3rd smaller price with depth 1
maybe i should implement this in another way?

Michael Mrozek nails it with his question if you're using HashMap right: this is highly atypical scenario for HashMap. That said, you can do something like this:
get the Set<Map.Entry<K,V>> from the HashMap<K,V>.entrySet().
addAll to List<Map.Entry<K,V>>
Collections.sort the list with a custom Comparator<Map.Entry<K,V>> that sorts based on V.
If you just need the 3rd Map.Entry<K,V> only, then a O(N) selection algorithm may suffice.
//after edit
It looks like selection should really be a SortedMap<Float, InflatedRunner>. You should look at java.util.TreeMap.
Here's an example of how TreeMap can be used to get the 3rd lowest key:
TreeMap<Integer,String> map = new TreeMap<Integer,String>();
map.put(33, "Three");
map.put(44, "Four");
map.put(11, "One");
map.put(22, "Two");
int thirdKey = map.higherKey(map.higherKey(map.firstKey()));
System.out.println(thirdKey); // prints "33"
Also note how I take advantage of Java's auto-boxing/unboxing feature between int and Integer. I noticed that you used new Integer and new Float in your original code; this is unnecessary.
//another edit
It should be noted that if you have multiple InflatedRunner with the same price, only one will be kept. If this is a problem, and you want to keep all runners, then you can do one of a few things:
If you really need a multi-map (one key can map to multiple values), then you can:
have TreeMap<Float,Set<InflatedRunner>>
Use MultiMap from Google Collections
If you don't need the map functionality, then just have a List<RunnerPricePair> (sorry, I'm not familiar with the domain to name it appropriately), where RunnerPricePair implements Comparable<RunnerPricePair> that compares on prices. You can just add all the pairs to the list, then either:
Collections.sort the list and get the 3rd pair
Use O(N) selection algorithm

Are you sure you're using hashmaps right? They're used to quickly lookup a value given a key; it's highly unusual to sort the values and then try to find a corresponding key. If anything, you should be mapping the float to the int, so you could at least sort the float keys and get the integer value of the third smallest that way

You have to do it in steps:
Get the Collection<V> of values from the Map
Sort the values
Choose the index of the nth smallest
Think about how you want to handle ties.

You could do it with the google collections BiMap, assuming that the Floats are unique.

If you regularly need to get the key of the nth item, consider:
using a TreeMap, which efficiently keeps keys in sorted order
then using a double map (i.e. one TreeMap mapping integer > float, the other mapping float > integer)
You have to weigh up the inelegance and potential risk of bugs from needing to maintain two maps with the scalability benefit of having a structure that efficiently keeps the keys in order.
You may need to think about two keys mapping to the same float...
P.S. Forgot to mention: if this is an occasional function, and you just need to find the nth largest item of a large number of items, you could consider implementing a selection algorithm (effectively, you do a sort, but don't actually bother sorting subparts of the list that you realise you don't need to sort because their order makes no difference to the position of the item you're looking for).