Hello all Im trying to construct hashtable that contains hashtables as values and hashCode of the hash tables as the keys The thing is that the hashCode() values are always negative numbers and they are not unique even so the values of the hashtable Different. how can it be ? Doesn�t it suppose to be unique number? And not negative?
A hash code can be any value that will fit in an "int". That includes negative numbers.
There is no guarantee that different objects will have different hash codes. The guarantee is that equal objects will have equal hash codes. It is in fact legal (but inadvisable) for a class to return the same hash code for all instances.
Basically, when implementing hashCode(), one first ensures that equal objects generate the same hash code, then tries to ensure that different objects produce a reasonable spread of hash codes. But one is constrained by a need for hashCode() to run quickly, so sometimes one compromises hashing quality for speed.
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
Joined: Apr 27, 2006
So this leads me to the question how can I generate unique identifier to hashtable object When its keys and values are fixed what I mean is when the hashtable have N keys and corresponding X values The generated identifier will always be the same
Originally posted by Meir Yan: Im trying to construct hashtable that contains hashtables as values and hashCode of the hash tables as the keys
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Apr 27, 2006
i need unique key to the hashtable can it be Produced from the hashtable itself based on its content?
Using hash codes for mutable objects, such as collections but also many user defined objects, is in most cases a BAAAAAD idea. If the object changes, its hash code may change, and as a result it will never be found again when retrieving it from a hash set. (The same goes for compareTo / comparators and tree sets - I've tried ).
Let's say you use the hash code as the key. Then you add something to the hash table. As a result, its hash code changes. You use that hash code, and you will not get the object you were looking for. The same holds for any other value you derive from the hash table's contents.
You need something that will never change within the lifetime of the hash table, and truth be told I couldn't think of any property it has. You might want to subclass the hash table, give it a read-only name field, then use that as the key, but I don't see any non-similar approach working.
And using a hashcode as a unique identifier is also a bad idea. It's true that two equal objects must have equal hashcodes, but it isn't true that two objects that are not equal must have different hashcodes. So there's no guarantee of uniqueness.
Originally posted by Meir Yan: i need unique key to the hashtable can it be Produced from the hashtable itself based on its content?
So, you have a Hashtable and you want to compute a unique key based on the content of the Hashtable.
That is theoretically impossible if the unique key has less bits than the bits of the data in the Hashtable together. Here's the proof:
Suppose you want to make a key with 32 bits. Then there are 2^32 possible keys. Suppose that you have some data in your Hashtable, and that data takes up more than 32 bits - for example, you have three integers, which is 96 bits.
Now you can see that the data in the Hashtable can be in 2^96 different states, and you need a unique key for each state. But your key only has 32 bits, so you can't assign a unique key for each possible state. You would need a key of at least 96 bits (the size of the data itself), if you need a unique key for every possible state.
So if the object has N bits of data then you cannot compute a unique key that is less than N bits from the data itself. [ September 05, 2007: Message edited by: Jesper Young ]