Please check that carefully; I think you are getting a List of the values. I thought OP wanted a List of the keys.Tyoma Sakurakoji wrote:. . .. . .
Marcello Lippi wrote: Hi all,
Then I should sort array list of strings in descending order comparing to its equivalent in hashmap
Marcello Lippi wrote:Then I should sort array list of strings in descending order comparing to its equivalent in hashmap.
Carey Brown wrote:
Marcello Lippi wrote:Then I should sort array list of strings in descending order comparing to its equivalent in hashmap.
Sorry, I can't quite parse this sentence. "Equivalent" based on what? The key? The Value? It's hash order?
Tyoma Sakurakoji wrote:
Marcello Lippi wrote: Hi all,
Then I should sort array list of strings in descending order comparing to its equivalent in hashmap
It seems I doesn't get the whole problem. Are you need to preserve the original order of the input hashmap entries and just reverse it afterwards? If so, then remove sorted call and reverse the resulting list:
Tyoma Sakurakoji wrote:Are you need to preserve the original order of the input hashmap entries and just reverse it afterwards? If so, then remove sorted call and reverse the resulting list
Try to enjoy your work while doing it,it will Automatically convert in Hard Work...
Carey Brown wrote:
Try to enjoy your work while doing it,it will Automatically convert in Hard Work...
praveen kumaar wrote:
Carey Brown wrote:
How can you guarantee ordering for any map...
Try to enjoy your work while doing it,it will Automatically convert in Hard Work...
Yes, I think you are right, but I don't think it answers OP's original question.Tyoma Sakurakoji wrote:Input map is Map<String, Integer>, code is filter using value and map using key. I think it's correct...
praveen kumaar wrote:Well i think their is a design issue inherent in the problem. OP has declared a map as a parameter and what he wants is this map to retain the input order which i think is a strong precondition in terms of contract of a Map and thus failing Liskov Substitution principle. But i will like it to be reviewed by some staff members like Junilu, Campbell.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
I thought the resultant List was to be sorted backwards by the “V”s in the Map. That is different from encounter order.praveen kumaar wrote:. . . Their is no such thing like order for HashMap . . . .
Tim wrote:Not sure if it's strictly applicable, but I like the meme, anyway.
Try to enjoy your work while doing it,it will Automatically convert in Hard Work...
Campbell Ritchie wrote:
I thought the resultant List was to be sorted backwards by the “V”s in the Map. That is different from encounter order.praveen kumaar wrote:. . . Their is no such thing like order for HashMap . . . .
Tyoma Sakurakoji wrote:In the original code also values were added in the list.
praveen kumaar wrote:
Tyoma Sakurakoji wrote:Are you need to preserve the original order of the input hashmap entries and just reverse it afterwards? If so, then remove sorted call and reverse the resulting list
Their is no such thing like order for HashMap as it is a unordered data structure, even HashSet is unordered and and streams also does not guarantee any ordering(Encounter order) for such objects. if you really want to preserve ordering LinkedHashMap preserves the same.
Carey Brown wrote:
Marcello Lippi wrote:Then I should sort array list of strings in descending order comparing to its equivalent in hashmap.
Sorry, I can't quite parse this sentence. "Equivalent" based on what? The key? The Value? It's hash order?
Junilu Lacar wrote:It seems to me a concrete example is needed to clarify the requirements. Plain English descriptions can be inexact and ambiguous and open to individual interpretation.
What I understand is this:
Given a Map<String, Integer> {
"English" -> 90,
"Spanish" -> 70,
"Bahasa" -> 50,
"Japanese" -> 62,
"Tamil" -> 5,
"French" -> 73,
"German" -> 79
}
The first step of filtering results in a String array containing everything except Bahasa and Tamil since these have values less than 60.
Next step is to sort them in descending order by value in the Map so:
["English", "German", "French", "Spanish", "Japanese"]
That is final result.
Is this the correct interpretation of the requirements?
Marcello Lippi wrote:Then I should sort array list of strings in descending order comparing to its equivalent in hashmap
Campbell Ritchie wrote:
I thought the resultant List was to be sorted backwards by the “V”s in the Map. That is different from encounter order.praveen kumaar wrote:. . . Their is no such thing like order for HashMap . . . .
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
I think we need to hear more from OP, because nobody seems sure how he intends the resultant List to be ordered/sorted.Tim Holloway wrote:. . . Hashcodes are integers, so no "V". You're thinking of the default output of toString . . .
Campbell Ritchie wrote:I think we need to hear more from OP, because nobody seems sure how he intends the resultant List to be ordered/sorted.
Marcello Lippi wrote:Honestly, I would love to see solution for my initial code. Yes, it is extremely ugly, but at least I do understand it. In the same time, your solutions are brilliant, but I don't understand streams completely yet.
Yes, I did. Sorry. But I'm almost 100% sure my interpretation is the same as yours.Junilu Lacar wrote:. . . I guess you missed the part where I said "I'm almost 100% sure my interpretation is correct." . . .
Tim Holloway wrote:There is no iterator for a Map. Instead you have to get the keySet, entrySet or valueSet and iterate that. Sets iterate in no guaranteed order, and while you might assume that a HashSet might iterate its keys in ascending hashvalue order, there are no assurances, and even if there were, you'd have to consider whether overflows were handled depth-first or not.
In brief:
A) you cannot iterate a Map, only retrieve a Set of data (keys, values, or Entries) from the Map.
B) As Sets have no natural order, you should treat them just like database tables. If you want an order, you have to enforce an order.
Tim is correct; if you look at the Map interface, you won't find an iterator() method.Tim Holloway wrote:There is no iterator for a Map. . . .
Tim Holloway wrote:
Campbell Ritchie wrote:
I thought the resultant List was to be sorted backwards by the “V”s in the Map. That is different from encounter order.praveen kumaar wrote:. . . Their is no such thing like order for HashMap . . . .
Hashcodes are integers, so no "V". You're thinking of the default output of toString, which is actually based on heap internal storage location or something like that, I think.
Campbell Ritchie wrote:
Tim is correct; if you look at the Map interface, you won't find an iterator() method.Tim Holloway wrote:There is no iterator for a Map. . . .
Tyoma Sakurako wrote:Also values are returned from Map as Collection and not as Set since map can hold equal values.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.