Hi Paul, For different data types different hash functions work better/worse aka fewer or more collisions.
I believe the more choice people have and also the more ways people see how a particular thing can be done, then the easier it will be for them to come up with their own specific efficient solutions. That said, I believe at least one (most likely more) of the hash functions in the group above will most always work better (ala less collisions) than the standard default hash available in the built-in dict for any random set of strings. Please feel free to prove me wrong :) Arash Partow ________________________________________________________ Be one who knows what they don't know, Instead of being one who knows not what they don't know, Thinking they know everything about all things. http://www.partow.net Paul Rubin wrote: > "Arash Partow" <[EMAIL PROTECTED]> writes: > > I've ported various hash functions to python if anyone is interested: > > Are these useful for any particular interoperability purposes? > Otherwise I'd say just one such hash is plenty, or maybe don't even > bother, since Python's built-in dicts are sufficient for most > applications that call for hashing, and the cryptographic hashes are > available for when you really care about uniformity of the hash > output. > > > for i in range(len(key)): > > hash = hash * a + ord(key[i]) > > a = a * b > > As a stylistic issue, I'd write this: > > for c in key: > hash = hash * a + ord(c) > a *= b > > and similarly for the other similar loops. -- http://mail.python.org/mailman/listinfo/python-list
