John Machin wrote:
> Perhaps you should, if you profess an interest in hashed lookup -- it
> gives some interesting commentary on the second aspect: collision
> handling. What matters is the *total* time to return an answer.
>
Time or algorithm complexity is merely one aspect of a hash function
des
On 17/07/2006 10:13 PM, Arash Partow wrote:
> John Machin wrote:
>> Who is likely to bother? In timbot we trust. Have you read the comments
>> at the start of Objects/dictobject.c?
>>
> No I haven't probably wont be anytime soon,
Perhaps you should, if you profess an interest in hashed lookup -- i
I would like to but I think my lack of language and time will
be a barrier. Also I don't believe there is much material there
to warrant a technical write up.
Arash Partow
Be one who knows what they don't know,
Instead of being one who kno
John Machin wrote:
> Who is likely to bother? In timbot we trust. Have you read the comments
> at the start of Objects/dictobject.c?
>
No I haven't probably wont be anytime soon, as far as time, well
people interested, as is how started my original port, would be more
than willing to try/assess the
On 17/07/2006 5:52 PM, Arash Partow wrote:
> 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
Arash Partow wrote:
> I've ported various hash functions to python if anyone is interested:
> [snip]
Ok, so if you think they are useful, what about writing up an article for the
Python Cookbook that describes their usage and specific
advantages/disadvantages?
http://aspn.activestate.com/ASPN/Py
That is true, but I'm not about to do something
that might potentially prove my point 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 ab
Trial and error - how else? :)
I believe finding a perfect hash function for
every kind and combination of data is a very
very time consuming operation. Also there is
the common case where the data is online
(ie: stateless) that said it doesn't mean you
can't make assumptions about the kind of dat
Arash Partow wrote:
> 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
"Arash Partow" <[EMAIL PROTECTED]> writes:
> For different data types different hash functions work
> better/worse aka fewer or more collisions.
But you give no indication of which of those hashes works best for
what kind of data. How is the user supposed to figure out which one
to choose?
--
ht
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 s
"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
Hi all,
I've ported various hash functions to python if anyone is interested:
def RSHash(key):
a= 378551
b= 63689
hash = 0
for i in range(len(key)):
hash = hash * a + ord(key[i])
a = a * b
return (hash & 0x7FFF)
def JSHash(key):
hash = 131
13 matches
Mail list logo
