using an entity's serial as hashcode

[Arahil]

using an entity's serial as hashcode

while writing an essay about hash-functions for school i stumbled over some text about hashtables in the wikipedia, and it says:

The generally impossible/impractical ideal for a hash table's hash function is to map each key to a unique index (see perfect hashing), because this guarantees access to each data record in the first probe into the table.

but since runuo's entities (mobiles & items) use the serial as a unique identifier already, wouldn't using the serial as create such a 'perfect hashtable' and maybe speed up runuo a little bit?

just like

public override int GetHashCode() {
    return (int)this.m_Serial;
}

in both mobile.cs and item.cs.

so, what do you think?

 

[snicker7]

That already is in there... and that is how it works I believe..

However, hashtables are slower to access than arraylists.

 

[Arahil]

ah, never mind...
just noticed i was thinking in a totally wrong direction...

 

[Phantom]

Mobile.Serial would bea HORRIBLE hashcode, since numbers are used again, it would create conflict.

If you wanted to use information from a user's hd ( like the serial of the hd or something like that ) then it ( would require a client to do this ) then you could create a true unique identification number.

 

[Jeff]

However, hashtables are slower to access than arraylists.

Pure comedy, who told u that?

 

[Phantom]

Pure comedy, who told u that?

He might be talking about an unsorted hashtable, but even then just because of the nature of a hashtable and how it works, your able to get to a given key's value faster then a given element.

Thats at least what I have noticed...

 

[noobie]

Mobile.Serial would bea HORRIBLE hashcode, since numbers are used again, it would create conflict.

If you wanted to use information from a user's hd ( like the serial of the hd or something like that ) then it ( would require a client to do this ) then you could create a true unique identification number.

wt??

serials are unique. thats the best way of doing that.

but you dont need to override hashcode method in Mobile class unless you use Mobiles as the key values.

 

[noobie]

He might be talking about an unsorted hashtable, but even then just because of the nature of a hashtable and how it works, your able to get to a given key's value faster then a given element.

Thats at least what I have noticed...

un/sorted hashtable?? that must be new! lol

for a specific index, arraylists are faster. (but still both O(1))
but if you are looking for a value (search) hashtables are faster. O(1) vs O(N)