I use to store much in hashmap since it's fast and easy to do. But my HashMap keys are really bad. Normally I have something like. String key = x + "." + y + "." + z; to make sure every object have it's own key.I have been thinking of using << and .hashCode() instead. But I have no idea if that's a good way to do it if I want unique keys.

Sorry. Maybe I don't simply get it or something... but it doesn't really make sense to me - what You want to do. HashMap stores key - value pairs, where the key can be any type. So why do You create a String hash in order to use it as a key? It clearly seems that there You have x, y and z coordinates, so why not just use for example Vector3 class as the key type in HashMap? That's what the HashMap is designed for.

No you clearly don't get it, and it's so simple. I created this topic to get help with my keys in HashMap, since I knew I didn't need to use Strings as keys, but I didn't know how to create a good key with numbers, since x + y + z wouldn't work.

Also, The are no Vector3, Vector3d, or Vector3D in java2D, so I couldn't possibly know about it. Now when I do i need something that works in java2D

Cute girl wants to do groceries with car.Cute girl has no car.Cute girl goes to car dealer to purchase said car.Car dealer chats about cilinder volume.Car dealer warns about CO levels in city traffic.Car dealer strongly suggests to buy a hybrid.Cute girl points at pink car.Car dealer BEGINS TO SHOUT MORE WARNINGS.Cute girl walks off confused.Cute girl is wondering how to get those groceries home.Car dealer didn't make a sale - despite his expertise.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

I can also imagine that the hashCode generated would be sub-optimal with regards to some mathematical properties, e.g. distribution or the number of collisions (had to read up on this). Are these mathematical properties the reason to use a hash library such as Murmur?

Also, I kind of see how the function above might not solve the OP's problem as I can imagine the positions of objects would change, which may result in undefined behaviour for Java Hash collections.

Using primitives as keys is a bad idea, because it will lead to a lot of autoboxing while using the hashmap (the java buildin Map implemtations need Objects as keys, so they will convert ints to Integers and back as needed, causing a lot of short lived objects and therefore garbage collection runs)

Other than that, the << operator shifts the left argument bitwise by the value of the right argument wrapping around, so what you listed above probably won't work, since e.g 64 shifted by 40 would result in the same key like 128 shifted by 39 etc.

So if you want to use this approachm you would need to go for something like

As you can see, your img-ids are limited to 256 values now and if you want to get the alpha value into the key, you are screwed anyway (or need to switch to long).

Now here comes, why lukasz1985 don't get your question. You didn't explain the use-case for which you need this key and the hashmap. If you want them for managing your objects, then you will probably be better of by just using names to identify them, because using the coordinates would mean the keys will constantly change when you move your object around the screen. If you don't need the keys for fast retrieval, then there is no point in storing the objects in a HashMap at all...

If you really need to and you want to avoid String keys, then a custom key object like Grunnt posted above would do the trick.

EDIT: And actually overriding the built in Object.hashCode() is a very bad idea - that solution will require that the elements stored is HashSet for example will have to immutable. Actually it's really evil idea....

Maybe this statement is out of context, but overriding the built in Object.hashCode() method (along with the equals() method) is exactly what you need to do when creating custom keys...

@Riven: The thing is: I don't have any vested interest in anyone listening to me. If someone does great.

Anyone tempted to toss together their own hashing function I suggest you do the following. Do a web search for: survey, non-cryptograhic hash...or something similar...grab a research paper and count the number of functions they talk about. It'll be a really really small number and ask yourself: With so many programmers and researcher over some many years of computing...why are there so few functions being talked about? There's a story about Knuth (if you don't know who that it...please go look it up now...thanks) attempting to create a random number generator and it being a massive failure. This stuff is hard and specialized.

There's no margin is goofying around with it. Pick an accepted "reasonable" hashing function, use it and call it a day (at least for a 5 years or so) unless you have some specific reason to rethink that choice.

I can also imagine that the hashCode generated would be sub-optimal with regards to some mathematical properties, e.g. distribution or the number of collisions (had to read up on this). Are these mathematical properties the reason to use a hash library such as Murmur?

Actually I had no clue that anyone here wrote that code. I glanced at it for less than 2s and closed the window. Most homebrew hash function look somewhat like this.

But I think you've answered your own question. Oddly enough the "mathematical properties" of a hashing function are rather (read: all) important.

@Riven: The thing is: I don't have any vested interest in anyone listening to me. If someone does great.

In my opinion it's of no use to throw expertise at newbies. It both confuses them and actually hurts their learning capability, as they are suddenly confronted with details they can't correctly interpret and will most likely misinterpret as a result, only adding to their confusing.

In this case, the OP doesn't seem to understand hashing and hash maps in the first place, because if your key contains all the information that is stored in the value, you don't need the value, and/or you don't need to lookup anything to start with, because you already have the information you are about to lookup. It's much more expensive (in CPU terms) to generate the key through string concatenation, than it is to create a new Vec3 object, which is even GC friendlier because it only creates one instance, instead of almost half a dozen, for string concat.

So, as always, maybe one shouldn't try to strictly answer the question, but to unravel the problem, which might lead to a much better fitting solution. If the question is wrong, a highly detailed answer, showing your expertise to the world - hoping somebody else entirely will learn from it - won't help anybody.

Having said all that - what is the problem the original poster (Yemto) is trying to solve? I'm sure it has very little, if anything, to do with hashing, let alone picking the best hashing algorithm.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

It's one of the things I find hardest to do: take good time to look at the problem, instead of starting to thing in solutions right away.. This thread may be a good example... So what IS Yemto trying to achieve with his/her HashMap? I have no clue really... To make it easy to locate objects by location? Just for shits and giggles? Heh. I'm curious though, so maybe Yemto can enlighten us.

@Riven: The thing is: I don't have any vested interest in anyone listening to me. If someone does great.

In my opinion it's of no use to throw expertise at newbies. It both confuses them and actually hurts their learning capability, as they are suddenly confronted with details they can't correctly interpret and will most likely misinterpret as a result, only adding to their confusing.

...

Having said all that - what is the problem the original poster (Yemto) is trying to solve? I'm sure it has very little, if anything, to do with hashing, let along picking the best hashing algorithm.

This is very interesting perspective. It's once again the question of giving a fish or teaching to fish, but I have never thought about adding to the confusion with too much, too complex information. When You think about it, it's logical, You need some basic understanding before moving up to the advanced setup.

I bow to Your wisdom, mr Riven.

Anyway, back to the topic, indeed noone has yet asked what the poster is trying to do. Given that he has 'x', 'y' and 'z' even a simple

1

Object[][][]

might be a better solution than a hashmap.

“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson

If You read carefully You will see that most people here asked OP about what he want to achieve. Also - clearly speculating - using a multidimensional array would be very not effective here as HashMap implements many optimization techniques, for example in order to search elements it uses binary trees - as far as I remember, not mentioning that arrays aren't dynamic.

You asked and Riven asked. Arrays vs HashMap is irrelevant as the extend of the usage is not defined here. There are different tools for different tasks.

“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson

using a multidimensional array would be very not effective here as HashMap implements many optimization techniques

Depends on how you are locating the object. The hashmap mentioned in the OP can basically only be used to locate objects based on their X,Y and Z values. Locating an object in a threedimensional array is actually quite a bit faster in this case (at least I think so, didnt test it but I assume its basically a single instruction directly fetching the value/object) than locating it in a HashMap (which would involve some searching and invoking of hash functions at least). Anyway, this is all TheoryCraft..

The duration of searching a node in a tree, increases with the depth of the tree, therefore you can't have binary trees, or binary searches in general, with constant time performance. Trees generally have O(log n) performance characteristics.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org