Talk:Hash table/Archive 1

message: Can somebody please help me understand why this is?
:Hash table array sizes are sometimes chosen to be prime numbers. This is done to avoid any tendency for the large integer hash to have common divisors with the hash table size, which would otherwise induce collisions after the modulus operation.
I mean, assuming the output of the hash function is random uniform, how is its output modulus 11 any more uniform than its output modulus 12?
:I'll try to. If your assumption was correct then yes.
:Historically, hashing is often done using equations of the form:
:f(a1,a2,a3...) = a1 * n1 + a2 * n2 + a3 * n3 +...  where n1, n2, n3... are carefully chosen primes.
:However if any of the n's divide into the length of the table, or they are a common factor with it, then since datasets not uncommonly differ by a single variable, then collisions occur much more often than you would naively expect. Also, if you use n's where varying the a's in a common way for the dataset causes a hash to appear that varies only by one or only a few places, then large amounts of clustering and very poor performance occurs for open addressed hash tables.WolfKeeper
Ok, here's an example. Let's say that you have a table size of 6. And you're hashing a single variable, called v.
To show how it all messes up let's use the following function:
f(v) = v*3
Now, because 3 divides evenly into 6, this is a bad idea...
Let's put numbers 1-5 into the hash table. They hash 3,0,3,0,3 respectively (after taking the remainder for the table length.) So we have 3 collisions. Which is much more than we should have had.
But if we had used:
f(v) = v*5
Then 5 doesn't divide into 6 at all; and doesn't share any factors with 6.
The hashes would have been: 5,4,3,2,1; absolutely no collisions. (This example is a bit forced because I used consecutive numbers, but rest assured even using random numbers would the second hash would have worked much better, since the first hash always lands on 0 or 3 everytime.) WolfKeeper
: I can now see the light, thanks for taking the time. I think that the article doesn't make it clear that there are (for a typical hash function) two nested modulus operations involved. Mind you I should have done my homework and read the hash functions section. Also I finally understand that a hash function that outputs random uniform indices is not necessarily an "ideal" one. An "ideal" hash function, as the article points out, changes half the bits of the output when one bit of the input changes, and does so independently from the rest.PizzaMargherita 08:49, 25 October 2005 (UTC)
thread_title:  Prime number array size 

message: I would like to question the following
:statistically and in practice, even with excellent hash functions, and even if the array were to be allocated with space for a million entries, there is a 95% chance of at least one collision occurring before it contains 2500 items
I find it dubious, since it is not stating the cardinality of the key space. For instance, if there are only one million possible keys and we are using a perfect hash, the above is clearly false. I suggest we remove the quantitative figures.
:Please explain further, I do not see how that could work. Note that there is a difference between an excellent hash function and a perfect hash function.WolfKeeper
::True, bad argument. Let me try again. I guess my point is: either we quantify "excellent", or all the other figures are dropped, because I strongly doubt that they hold for every hash function and every cardinality of the key space. Or is it 95% is a theoretical lower bound of some sort that can be calculated from the numbers 1 million and 2500 alone? Even if that is the case, a reference/explaination would be called for.
:::The thing about 'excellent' hash functions is that they behave psuedo-randomly, and hence statistics may be sensibly applied. The 95% is a theoretical result based on, yes 2500 and 1 million and the birthday paradox, which is already linked to. There's an equation in the linked article that gives 0.9561, when n=2500 N=1000,000, near enough 95%.WolfKeeper
::::I see, thanks for the explaination and sorry for missing the link. I propose rephrasing though:
:::::The hash function should be designed so as to minimise the number of collisions for any index returned. However, even when an ideal hash function produces indices with a uniform probability distribution over the range of an array with, for instance, 1 million elements, the probability of at least one collision occurring before a mere 2500 records are inserted can be calculated to be around 95% (see birthday paradox). Note that real hash functions cannot perform better.
::::What do you think?
:::::I wouldn't use phrases like 'ideal'. And the final 'real hash function' sentence doesn't make sense to me, it raises questions like 'what do you mean, the example is not real?'.
::::::Of course it's not real (hence "ideal"), because in our mental experiment (or if you prefer, statistical analysis) we are assuming that the output of the hash function is a uniformly distributed random variable.
:::::::Many real-world hashes can achieve this to measurable accuracy in all but deliberate sabotage cases (e.g. md5). And I wouldn't use 'ideal' because it raises questions about perfect hashes, which really are ideal, and that's not what we're about at this point in the article.WolfKeeper
:::::Also, it's a statistical result, so sometimes you will get better results.
::::::No, if by performance you mean "probability of at least a conflict" as opposed to "number of conflicts for a given sequence". Shall we say that explicitly? "It's possible to calculate (see bd paradox) a lower bound for the probability of having at least a conflict, given the number of records to be inserted and the size of the array. <example>"
:::::::No, because of concepts like perfect hashes, and optimisation of hashes for particular input sequences or populations. It's not a lower bound. The lower bound is zero.WolfKeeper
::::::::But doesn't this contradict the "even with excellent hash functions" part? It's not a lower bound. So what is it then? And what is the relevance of that sentence at this point of the article? Right now, to me, it sounds like this:
:::::::::If a uniform random number generator were to generate 2500 indices for a 1million array, p=95%. However, there is absolutely no relationship between this object and a generic hash function.
::::::::As you say, we are not talking about perfect hashes here, and I'm not convinced that, under this benchmark, optimised hashes perform better than a uniform random number generator. Though I could be persuaded that that's actually the case. Could you please provide a simple example?
::::::::Another thing. I think that in this sentence the reference to the birthday attack (as opposed to the birthday paradox) is not relevant.
::::::::You raise an interesting point about optimisation of hashes given statistical properties of the keys. Is this mentioned anywhere in the article? I think it should...
::::::::Hey, it's me again (I got myself an account). If I don't hear any objections to my comments immediately above, I'm gonna edit as explained. I'll make it clear that by "ideal hash" I don't mean "perfect hash".--PizzaMargherita 19:18, 6 October 2005 (UTC)
thread_title:  Theoretical conflict probability 

message: The main article states "Hash tables are also not persistent data structures." This is false. There have been many database implementations that use on-disk (persistent) datastrcutres. Both chaining and open addressing may be used, though the latter is more common.
See, for example
*J. D. Ullman, Principles of Database Systems. 1982
*R Sedgewick, Algorithms in C. 1992
:I am not referring to "persistent" in the sense of disk-based, but in the sense in which a purely functional data structure is persistent. If you clicked the link "persistent data structure", you would've seen that it was being used in this sense - this term is overloaded. Your new text, using this link, is misleading. I will clarify this point. Deco 19:28, 31 October 2005 (UTC)
thread_title:  Hash tables may be persistent datastructures 

message: Would it be more correct to rename the article "Hash map"? Maybe hash table is more appropriate for the array that the hash map uses, i.e. some people confusingly refer to the whole hash map as "hash table".--PizzaMargherita 10:24, 24 October 2005 (UTC)
replies: text: I strongly disagree. I have been programming as a hobby since 1982 and worked as a programmer since 1993 and also teached computer science. I always known these structures as "Hash tables" not as "Hash maps". I did the Google check: "Hash table" = 1,7 million hits, "Hash map" = Only 54 thousand hits. I also checked my computer science algorithm books, they call it "hash table". However, since "Hash map" seems to mean the same thing it is correct as it is now that "Hash map" redirects to this article. So in Wikipedia tradition I will add something to the effect "also sometimes called Hash map" to the first paragraph. --David Göthberg 16:11, 31 October 2005 (UTC)

text: I agree with David. "Hash table" is technically less accurate than "hash map", but far more commonly used, and it is our policy to name articles after the most familiar name rather than the most technically accurate. Deco 19:38, 31 October 2005 (UTC)
thread_title:  Hash Table vs. Hash Map 

message: "** They utilize more of the table slots. Even with elements distributed uniformly at random, a chaining table must contain several times more elements than slots before most of the slots are used, and it does not perform well at this load. At more typical table densities, such as 1, about 37% of the table slots remain unused."
I've read this several times. It makes no sense at all. The more times I read it, the less sense it makes.
Utilisation of slots is not a useful metric in this sense- who in their right mind cares? Speed or space or complexity or cost are useful metrics.
Uhh.. guys... slow down...WolfKeeper 19:28, 8 November 2005 (UTC)
replies: text: For small elements, unused table slots have a direct impact on space usage, since the space occupied by these slots is wasted. This penalty is roughly the same as that open addressing requires to maintain a small load factor. This was the point I was attempting to make. I'm sorry if I was unclear. Deco 22:16, 8 November 2005 (UTC)
replies: text: The above is sort of true but not precise enough. See my argument above. Deco 03:22, 9 November 2005 (UTC)
thread_title: Ummm...

message: Hey, has anyone besides me actually read NPOV?
:I am striving to be accurate and have made numerous contributions regarding both the disadvantages and advantages of both collision resolution mechanisms. You can hardly accuse me of being pro-open addressing with the work I put into that diagram, which is quite disparaging to open addressing. If anyone has a bias here, it isn't me. Deco 22:14, 8 November 2005 (UTC)
thread_title: NPOV- it's not just a good idea it's the law!!