Talk:Hash table

message: In the section "Choosing a good hash function", a (presumably integer) "s" is repeatedly referred-to.  However this is as far as I can see totally undefined in the wikipedia article.  Although (some) computer scientists might infer s from context, other readers may not.  This is bad form.  Suggest to change.
152.3.68.83 (talk) 18:39, 22 November 2013 (UTC)
thread_title:  Omitted definition in article: what is "s"? 

message: :In computer science, a hash table, or a hash map, is a data structure that associates keys with values.
Already the first sentence is misleading, if not even wrong. A hash map associates keys with values (i.e. maps) and is implemented using a hashtable, though a hashtable itself does not necessarily do any mapping or association of keys and values. Just consider a hashtable where all you do is to store integers, there are no values here.  —Preceding unsigned comment added by 91.36.112.7 (talk) 14:51, 23 January 2008 (UTC)
replies: text: This comment was already posted once and was moved to #Confusing a hash table and a hash map because newer entries are supposed to go to the *end*. -- intgr [talk] 23:08, 23 January 2008 (UTC)
thread_title:  Table vs Map 

message: If when adding to a table the hashing function leads to a collision for 2 particular keys, a and b, then using probing b will be stored somewhere after a. When then looking up the value associated with b, won't the table actually return the value associated with a. How does it know which of the two values to return, and how to get to the index associated with b?
I hope that makes sense. Iae 11:22, 8 June 2006 (UTC)
replies: text: Providing we're not using perfect hashing, we must search through all the places the desired element could be, comparing our search key with each one, until we hit the end of the list. This is why hash tables require not only a hash function but a means of comparing for equality. This only works efficiently because in a hash table with enough room, these lists are overwhelmingly very short. Deco 11:27, 8 June 2006 (UTC)
replies: text: Ah I see, thanks very much. Iae 11:49, 8 June 2006 (UTC)
thread_title:  Something i don't understand from the article 

message: :::How do you know that you have hit the end of the list.  Or to cut to the gist of the matter; How do you delete from a hash table that uses probing.
You know you hit the end of the list in a (probed) hash table when you hit a empty "not occupied" slot.
In theory, one could have a "occupied" bit for each row of the hash table that is initially 0.
(In practice, typically each slot that is not occupied begins with a NULL byte. If it *is* occupied, that byte is the first byte of the key).
I know of 2 very different ways to delete from a hash table: the "deleted bit" method", and the "move stuff around" method.
(My understanding is that the "move stuff around" method is impossible to implement with "quadratic probing" or "double hashing" hash tables (and probably a few other types). Those hash tables are forced to use the "deleted bit" method.)
Let me try to explain those 2 methods
"deleted bit" method: works with any kind of hash table.
Every row of the hash table (in addition to the key, value pairs) has a "deleted" bit that starts out 0. To delete a record from the hash table, use the key to find it (using find_slot), then set the "deleted" bit to 1.
(Some hash tables cram the "deleted" bit and the "occupied" bit into the "key" part of the record, reserving 1 special key to indicate "unoccupied", another special key to indicate "deleted", and any other value to indicate a real occupied "key" ).
"move stuff around" method: only works with linear probing.
The function remove(key) in the article is supposed to describe the "move stuff around" method. How could we make it easier to understand?
Often when the application deletes a record, the following slot is already not occupied. In that case you can wipe out the record by marking that record as not occupied -- overwriting the key with a NULL byte -- and you are done.
Unfortunately, there are a bunch of special cases the application needs to be able to handle, even though they rarely happen.
As the article says, "For all records in a cluster, there must be no vacant slots between their natural hash position and their current position (else lookups will terminate before finding the record)."
The application needs to scan through *all* the records between the record you want to delete, and the next "not occupied" slot, and make sure the above requirement is met.
In some cases, you must move all those records up 1 slot.
In other cases, you must move some (but not all) of those records.
In yet other cases, you must not move any of them, just mark the deleted slot "not occupied" just like the simple case. (For example, if you want to delete the record in slot 870, and you see that the "key" in slot 871 actually hashes to "871", and slot 872 is "not occupied" -- you must mark slot 870 "not occupied", and leave the record in slot 871 alone).
Once you understand how it works, please update the article to make it easier to understand for the next person.
--68.0.120.35 07:42, 5 March 2007 (UTC)
thread_title:  how do you delete from a hash table that uses probing? 

message: Hi, I've implemented the joaat_hash function which is described in pseudocode on this page in my C Program, and encountered an error. Better said I produced one, since I misunderstood len as the len of the hashtable, and not as len of the key. 
here is my (correct) function implemented in C, please consider updating the article: 
 int joaat_hash(char *key, size_t len) //len is the size of the hashtable
 {
     unsigned int hash = 0;
     unsigned int i;
     
     for (i = 0; i < strlen(key); i++)
     /* [...] as in the article */ 
     
     return (hash % len);
 }
--88.76.141.17 03:43, 2 January 2007 (UTC)
thread_title:  joaat_hash function error 

message: A recent edit deleted most of the following paragraph, claiming it was "verbiage":
::"Cryptographic hash functions are believed to provide good hash functions for any table size s, either by modulo reduction or by bit masking. They may also be appropriate if there is a risk of malicious users trying to sabotage a network service by submitting requests designed to generate a large number of collisions in the server's hash tables.[citation needed] However, these presumed qualities are hardly worth their much larger computational cost and algorithmic complexity, and the risk of sabotage can be avoided by cheaper methods (such as applying a secret salt to the data, or using a universal hash function)."
This paragraph is explaining that *cyptographic* hash functions (a different concept altogether, see lead section) are not necessarily good choices for hash tables, because their only advantage (probabilistically guaranteed good performance even on data submitted by hostile clients) can be obtained at smaller cost by using ordinary (non-crypto) hash functions with secret salt (as discussed above).  The recent edit removed this information.  But perhaps the wording is not clear and needs to be improved. All the best, --Jorge Stolfi (talk) 21:28, 6 February 2010 (UTC)
thread_title: Verbiage?

message: I'm considering merging the open hashing article with this article, as has already been done for closed hashing. For that I think we should rename the section on Chaining to Open hashing and make more clear the already mentioned fact that linked lists are only one way, though perhaps the most popular one, of organizing hash buckets and introduce a mention of buckets allocated in a contiguous memory/disk space that is presently discussed in open hashing. Jyotirmoyb 05:16, 20 February 2007 (UTC)
replies: text: I agree -- let's keep all the different types together in this one article until the article gets too big. At that time, it will (hopefully) be easier to look at the article and decide the "natural" breaking points to split it up into multiple articles. Big Buckets First. --68.0.120.35 07:42, 5 March 2007 (UTC)

text: I agree, too.  It makes more sense to contrast "closed hashing" with "open hashing".  I'd like to see the two sections so labeled.Anjin\\talk 02:23, 25 April 2007 (UTC)

text: I agree, too. I can see no good reason why not to incorporate such a strongly related topic into this article. I find the question of length of the article largely irrelevant as long as the topics in it are relevant. I'd rather read one long coherent article (possibly skipping sections) than having to jump back and forth in Wikipedia. My 5 cents...  TFJ 09:54, 14 June 2007 (UTC+1)
Makes sense - can't have it both ways - with closed hashing merged (thought it's hard to find any content called "closed hashing" in the article) and open hashing in its own article. On the other hand, there is no problem with an article on "open" and "closed" and other types of hashing if there is enough content to justify. Does wikipedia ave guidelines on article length??--121.45.246.110 14:10, 9 April 2007 (UTC)

text: I agree with all this, because open hashing is simply irrelevant in any context outside of hash tables. Dcoetzee 01:13, 15 June 2007 (UTC)

text: The Wikipedia guideline on article length is the Wikipedia: article size guideline. --DavidCary (talk) 20:02, 18 November 2021 (UTC)
thread_title: Open hashing

message: The remove function will loop indefinitely if the hash table is full, since it only exits when it finds an unoccupied slot.  I think adding the following after the j := (j+1) line should fix it:
  if j = i
    exit loop
32.97.110.142 20:36, 11 April 2007 (UTC)
thread_title:  Bug in 'remove' Pseudocode 

message: In the discussion of the costs of resizing the hash, there seems to be an ambiguity in the amortized running time analysis:
... If in the end it contains n elements, then the total add operations performed for all the resizings is:
1 + 2 + 4 + ... + n = 2n - 1. 
Because the costs of the resizings form a geometric series, the total cost is O(n)....
 
The n in "2n - 1" is actually the value of the nth element, not the number of elements. The sentence that follows makes it seem that the sum of a geometric series is linear, which is clearly not the case.
Guray9000 00:47, 16 April 2007 (UTC)
replies: text: Actually, it is the number of elements. I'm not sure what makes you think it's the value of the nth element - it's not. And the sum of a geometric sequence is linear in n, if n is the last term of the sequence. Dcoetzee 11:34, 9 June 2007 (UTC)
thread_title:  Ambiguity in amortized analysis 

message: The article states:
To see why this is true, suppose a hash table using chaining begins at the minimum size of 1 and is doubled each time it fills above 100%. If in the end it contains n elements, then the total add operations performed for all the resizings is:
1 + 2 + 4 + ... + n = 2n - 1. 
This does not seem right. The expected number of steps it takes to double the table size from (1) to (n>1) at each overfill should be: truncate(LOG2(n-1))+1 (whare LOG2 means logarithm base 2 of n). Also, if my math is correct 1 + 2 + 4 + ... + n = n(n+1)/2, but this does not seem the right computation to make: we're not supposed to add the values corresponding to each step but to count them.
If this reasoning is correct the total cost should read O(LN(n)) rather than O(n), which should mean this method scales very well with n.
:I can't understand your reasoning at all. First of all 1 + 2 + 4 + ... + n is in fact 2n - 1, and not n(n+1)/2 (this is 1 + 2 + 3 + ... + n). Second, this is summing the add operations performed during the resizings. During each resizing, all elements currently in the table have to be added again to the new table, and each resizing occurs at a power of 2 number of elements, so the numbers being added are correct. I really don't understand what you're saying. Dcoetzee 10:29, 9 June 2007 (UTC)
thread_title:  Mistake in table resizing section ? 

message: In that section it is written: "Like arrays, hash tables provide constant-time O(1) lookup on average, regardless of the number of items in the table." (*)
Searching in sorted list of keys by using binary search can be done in O(log N). Average running time of binary search is also log N (this is according to http://planetmath.org/encyclopedia/BinarySearch.html). I don't know any better algorithm for non special sorted data. So I think statement (*) isn't true in asymptotic sense.
However if we know that N is bounded by some number we can say that O(log N) = O(1). But this would be wrong... But in some philosophical (or maybe practical) sense we could be right (we have large but fixed maximum amount of RAM, HDD space, maximum amount of hash table entries etc). But this would be not right in asymptotic sense where N not bounded but free.
What I don't understand?
:Really, in a fairly real sense, hash tables don't search, they go straight to the right place in the table.WolfKeeper 22:56, 28 June 2007 (UTC)
replies: text: At a maximum table utilisation factor (say 80%), the Hash table will do on average a constant number of comparisons (k= ~2 at 80%) which is still an O(1) operation, as k is independent of n, the size of the table. In other words, at 80% full, there's going to be only about 2 colliding entries. Hope this helps.WolfKeeper 22:56, 28 June 2007 (UTC)
replies: text: Thanks, WolfKeeper and sorry for my ignorance. Your answer made me do more searching and I understood that, I was confusing hash_map with map (in C++ terminology). map permits lookup, insertion and removal in logarithmic time on average. And hash_map permits these operations in constant time on average. 78.56.1.150 12:37, 29 June 2007 (UTC)
thread_title:  How this can be true (question about statement in section 'Time complexity and common uses of hash tables')? 

message: This section is quickly devolving into yet another trivia list.  MegaHasher 19:45, 11 July 2007 (UTC)
thread_title: Implementations

message: Are there any references on a data structure that implements a hash table and binary tree
at the same time? MegaHasher 20:04, 3 August 2007 (UTC)
replies: text: Um, huh? It's not clear to me why you'd want to do that, or how that even makes sense. Can you expand a bit on why you're asking? Dcoetzee 02:45, 4 August 2007 (UTC)
replies: text: Seems that a treap could be combined with a hash table.  I wasn't able to come up with any citations though. MegaHasher 06:11, 14 August 2007 (UTC)
replies: text: I still have no idea what you mean. Combined in what way, for what purpose? Dcoetzee 08:13, 14 August 2007 (UTC)
replies: text: to provide O(1) read access, and ordered traversal at the same time MegaHasher 08:19, 14 August 2007 (UTC)
replies: text: You could certainly do that by merely keeping a hash table and a binary tree at the same time with the same contents - but on modern systems, I don't think the lookup cost of hash tables compared to an effective cache-aware tree data structure is significantly better (it may even be worse). Considering the space overhead and time overhead for other operations, I wouldn't consider this an effective solution. Dcoetzee 21:50, 20 August 2007 (UTC)

text: I think the ordered searching and hashing ideas can be combined in the hash table algorithm itself, as seen in this paper, but it does not seem to be exactly what you want. Also, instead of linked lists for buckets, you can use any other data structure that implements the necessary operations, even trees, but that may still be not what you want. Honeypot95 (talk) 12:29, 20 April 2020 (UTC)
thread_title: Hash table and binary tree in one data structure

message: This article could be improved with more direct citations. MegaHasher 06:11, 14 August 2007 (UTC)
thread_title: Citations

message: I am suspicious of the random table based hash function.  This seems to be a variation on Pearson's hash function, except there are multiple tables, therefore much worse cache misses. Pearson's hash function is not all that fast to start with. MegaHasher 03:22, 18 August 2007 (UTC)
replies: text: Wikipedia generally does not accept original research, but you are welcome to publish your algorithm in a different location, and submit to Wikipedia as a cited work of concise length. The article of Hash function is probably a better location. MegaHasher 04:19, 29 August 2007 (UTC)

text: Wikipedia's policy is very simple.  Please look at the welcoming material in your user talk page.  You need to publish your full article in a location off Wikipedia, then write an one paragraph summary of it on Wikipedia, and give a citation link to your full article. MegaHasher 18:20, 30 August 2007 (UTC)
replies: text:  As far as I can tell, the hash function that was deleted 02:46, 29 August 2007 is an implementation of Zobrist hashing, a topic which has more than enough references to prove its Wikipedia:Notability. The joaat_hash function has been moved from this article to Jenkins hash function#one-at-a-time. Further discussion of those functions should probably go on those respective specific talk pages, or on the more general hash function talk page. --DavidCary (talk) 04:32, 13 August 2016 (UTC)
thread_title: Random table based hash function

message: I have seen two separate referenced articles that had measurements that show under separate chaining, an increase of load factor by 1 has the impact of increasing CPU instruction count around 4 to 5%.  This is much better than what I would have guessed. The first reference is "Dynamic Hash Tables" by Larson (1988), and the second reference is "Main-memory linear hashing" by Pettersson (1993). Have I completely mis-read these articles? MegaHasher 21:33, 20 August 2007 (UTC)
thread_title: Load factor

message: Like arrays, hash tables provide constant-time O(1) lookup on average, regardless of the number of items in the table. However, the very rare worst-case lookup time can be as bad as O(n).
This is essentially wrong. In a non buggy implementation which is when the table is a reasonable size, and the table is never too full and the hash function is working correctly n-collisions cannot occur.WolfKeeper 14:36, 16 October 2007 (UTC)
replies: text: But Big-Oh notation is based on the worst case and the worst case for hash tables would be poor or incorrect implementation/small n. The only reason hash tables never 'feel' like that is because only good implementations would be kept and reused. You can't ignore possibilities just because they aren't likely to occur when you're talking with Big-Oh.199.111.229.133 18:47, 16 October 2007 (UTC)
replies: text: But O(n) on a 50% full table with 1000 entries and a good hash function, it's not just "very rare" as in the text, it just never happens and never would happen before the end of the universe. If it has never been seen, and never would be seen, then it isn't rare, it just never happens.WolfKeeper 19:12, 16 October 2007 (UTC)

text: It really is O(n) in the worst case - regardless of the table size or hash function, you can artificially construct a set of keys that all map to the same hash bucket. It never happens in practice - but a worst-case formal analysis must consider this case. Dcoetzee 21:33, 7 December 2007 (UTC)

text: similarity --- quicksort is also O(n*n) in a similar manner (for few special cases) . 84.16.123.194 (talk) 15:44, 28 January 2008 (UTC)
thread_title:  Not really O(n) 

message: This article is terrible - someone needs to make this article clearer for beginners or even intermediates. It barely explains anything at first. How about a simple example instead of jumping into advanced theory???
129.128.241.131 (talk) 17:53, 7 February 2008 (UTC)
replies: text: I agree. A gentle introduction describing a specific example could be very useful. I'll write something up. Dcoetzee 22:41, 4 March 2008 (UTC)
thread_title:  For beginners 

message: I can't access it at the moment, but this paper is probably also relevant to the robin hood hashing:
Munro, J. I., and Celis, P. 1986. Techniques for collision resolution in hash tables with open addressing. In Proceedings of 1986 ACM Fall Joint Computer Conference (Dallas, Texas, United States). IEEE Computer Society Press, Los Alamitos, CA, 601-610.  —Preceding unsigned comment added by 75.71.67.71 (talk) 17:02, 15 April 2008 (UTC)
thread_title:  Additional references? 

message: The description of "open hashing" seems quite inaccurate.
That "data indexed by the hash is 'stored externally' to the hash table" may be *required* for this data  structure, but does not define it. To store variable length data open addressing may be used in conjunction with storing references to the actual data in the hash table. Open addressing is used synonymously to closed hashing, which results in a contradiction.
The example which follows the first sentence seems at least incomprehensible to me (By the way: Examples should be separated from a general description.) Key-value pairs are added to the group/bucket according to the hash value of the key. (The hash of the key defines the group.)
"The key that identifies a bucket is now put into the hash table (in this case it is as simple as the bucket number)" seems wrong to me. Actually, a reference to the group is 'put into' the hash table. And this is not equal to the key (Hash keys are generally not stored in hash tables, the values are stored).
Separate chaining should be characterized as a form of open hashing.
Sorry for the extensive criticism. This part of the article really confused me...
--Whzlt (talk) 03:24, 18 May 2008 (UTC)
replies: text: I've removed it. It was just simply terrible, and seemed to be a duplication of the chaining section anyway, and was unreferenced.- (User) WolfKeeper (Talk) 04:11, 18 May 2008 (UTC)
thread_title:  Open Hashing: inaccurate description 

message: The page points to some page that claims multiplicative hashing has poor clustering. But that page doesn't get Knuth's multiplicative hashing right -- it falls into the trap that many people do of thinking that it works as (k*a) mod m for some a. In fact, multiplicative hashing does fine if you implement it correctly, by taking only the high bits of k*a.  —Preceding unsigned comment added by AndrewCMyers (talk • contribs) 16:45, 13 January 2009 (UTC)
thread_title:  Info about multiplicative hashing is wrong 

message: For the x-th time, 1+2+4+8+...+n = 2n-1, not 2^n-1; you're thinking of 1+2+3+4+...+n. Just put in values for n and you will see this, or do you need a formal proof? Please people, actually read the text you edit. Adrianwn (talk) 17:22, 26 March 2009 (UTC)
replies: text: You should add a comment explaining why it is that, I misread the termination condition myself.- (User) Wolfkeeper (Talk) 17:33, 26 March 2009 (UTC)
replies: text: Yes, that is probably a good idea; I will think of something. Adrianwn (talk) 05:34, 27 March 2009 (UTC)

text: I rewrote it and tried to clearly distinguish between the ops for the resizing and the ops for adding elements to the table. Please check the formulas for mistakes. Adrianwn (talk) 08:17, 31 March 2009 (UTC)
thread_title:  Sum over sequence 

message: This sentence has been removed:
: In most cases the hash function is deliberately chosen to have pseudo-random properties, so that small changes of a key give a large and apparently random (although of course reproducible) effect on the hash returned. Because of this random effect, in some cases,
Hash functions need not be pseudo-random, they need only spread the keys as evenly as possible.  Moreover collisions are not due to pseudo-randomness of the function. --Jorge Stolfi (talk) 05:59, 3 April 2009 (UTC)
replies: text: Congratulations! You seem to have successfully removed every part of the description of how hash tables in general work from the article!!! Well done indeed!- (User) Wolfkeeper (Talk) 23:03, 3 April 2009 (UTC)
replies: text: Perhaps you can remove the collision resolution algorithms as well?- (User) Wolfkeeper (Talk) 23:03, 3 April 2009 (UTC)
replies: text: Is this comment still relevant, or did you just look at the article between edits?  I have tried to keep all the pertinent information, deleting only some details that can be found in the articles specific to each method. Is there anything in particular that you think should remain here? --Jorge Stolfi (talk) 00:46, 12 April 2009 (UTC)
replies: text: Yes, I can only continue to congratulate you on removing how they work, and adding more on what they are used for.- (User) Wolfkeeper (Talk) 14:23, 12 April 2009 (UTC)
replies: text: Um, forgive me for being dense... Are you being ironic, or do you mean it?  If the former, please be more specific. There are gazillions of hash table algorithms, methinks that is is best to give a general survey and leave the details to specific articles.  Do you think that the general description of how they work is not adequate?  All the best, --Jorge Stolfi (talk) 16:53, 12 April 2009 (UTC)
replies: text: Yes, I was being ironic. People don't come here simply to read in-depth comparisons about something and something else. They come here primarily to find out what something is. What it can be used for, and how it compares and the history is also important, but are not usually the primary reason.- (User) Wolfkeeper (Talk) 16:58, 17 April 2009 (UTC)
replies: text: Well, first, I dont't think that is quite true.  But it does not matter.  What matters is that the lead section and the accompanying figure already give enough information about what a hash table is and how it works --- enough to satisfy the curiosity of most people who don't know that already.  Anything beyond that will have to go into gory technical details, and will be of interest only to people who implement hash tables --- which is a very small set indeed, much smaller than those who need to choose between a hash table or a balanced tree.  I also cannot believe that the average reader wants to know the details of chained versus open addessing before knowing what hash tables are good for. All the best, --Jorge Stolfi (talk) 22:40, 17 April 2009 (UTC)
replies: text: With very few very clearcut exceptions (like birthdates), the lead isn't supposed to contain anything not in the body of the article.- (User) Wolfkeeper (Talk) 23:36, 17 April 2009 (UTC)

text: Sorry again, I don't understand your complaint. When I last looked, the lead section had a sufficiently clear and complete explanation of how a hash table works, and that explanation was throughly expanded in the body of the article. So what, exactly, was wrong with the latter?  All the best, --Jorge Stolfi (talk) 02:09, 18 April 2009 (UTC)
thread_title:  Pseudo-randomness is not necessary 

message: The article claimed that
:Some older hashes are even worse, requiring table sizes to be a prime number rather than a power of two, again computing the bucket index as the hash value modulo the table size. In general, such a requirement is a sign of a fundamentally weak function; using a prime table size is a poor substitute for using a stronger function.
This statement sounds rather biased. What matters is the actual hash function, that maps the key to a bucket index.  A "raw" hash function that gives good results when taken modulo a prime is OK as long as the table size s is a prime.  One can do dynamic resizing with tables of prime size, with liltle extra cost.  The above statement can be turned around to say "using tables whose size is a prime number increases the chance that the hashes will be unformly distributed, since some popular hash functions are known to perform badly when the table size is a power of two and the hash index is obtained by bit masking."  So, how should we rephrase this sentence?  --Jorge Stolfi (talk) 00:40, 12 April 2009 (UTC)
thread_title:  Why are prime-sized tables bad? 

message: There is a misunderstanding in the recnt edits. The "modulo the table size"  step is technically a part of the hash function, not of the hash table algorithm. If the bucket array has size s, the hash functiion must return a number in 0..s-1.  See Talk:Hash function.  Briefly, the mod-s trick is not always a good idea, and cannot be discussed separately from the "raw" hash function.  More importantly, all discussion about the hash function (desired properties, meaning of "perfect", etc.) assume that there is no external mod-s step.  All the best, --Jorge Stolfi (talk) 02:21, 18 April 2009 (UTC)
thread_title:  The "mod N" trick is inside the hash function, not outside it 

message: The "Basic algorithm" section does not seem to add to what has aleady been said in the lead section.  Considering that the "mod N" trick does not belong here, the section seems redundant. --Jorge Stolfi (talk) 03:01, 18 April 2009 (UTC)
replies: text: It's really bad style to only mention something in the lead; and in this case it's the fundamental algorithm the whole thing rests upon.- (User) Wolfkeeper (Talk) 16:14, 18 April 2009 (UTC)
thread_title:  Is the "Basic algorithm" section needed? 

message: From the lead paragraph of "Choosing a good hash function": 
A good hash function is essential for good hash table performance... However, since poor hashing usually degrades hash table performance by a constant factor, and hashing is often a small part of the overall computation, such problems commonly go undetected.
If the latter is true, how can the former be true? If the problems caused by poor hashing commonly go undetected, and the hashing is a small part of the overall performance, it seems that a good hash function can't be called "essential for good performance" but is rather an aesthetic preference at most. One might distinguish between 'adequate' and 'bad' functions, where 'bad' might run slowly and produce uneven distributions, but if your problems are going undetected, I'd say you've at least struck 'adequate', and improving to 'good' would be an exercise in lily-gilding.But perhaps I'm missing something. --Fader (talk) 14:51, 24 July 2009 (UTC)
replies: text: Well, it seems that the text can be improved. The intended meaning is: the difference between a good and a not-so-good hash function may be a factor of 10 or more in the average operation cost; so, if you want the hash table to have good performance, you'd better pay attention to that item.  However, performance aside, the table will work correctly with any hash function; and, in many applications, making the lookup 10 times slower will probably make little difference in the overall processing time, because other costs will probably dominate the bill. For example, some shells use a hash table to map command names to directories in the command search path.  A bad hash function there may add a few milliseconds to the command startup time, which is usually dwarfed by the cost of loading the program into memory.  Such a bug is likely to go undetected for a long time; and even if i is detected, fixing it will be very low in the shell maintainer's priority list.  On the other hand, some interpreted languages like Gawk use hashing to map variable names to values; in that context, even a 50% increase in the lookup cost will have a noticeable impact on the performance of every Gawk program.  Hope this helps. All the best, --Jorge Stolfi (talk) 23:42, 25 July 2009 (UTC)
thread_title:  "Good" hash functions  

message: The following text was recently added to the article:
begin text
----
An example of a simple hash function with good behavior is:
 unsigned long f(char key[], int arrayLength) {
   unsigned long h = 0, v = 401;
   int i;
   if (arrayLength >= 2) {
     h ^= (0xffUL & key[0]);
     h ^= (0xffUL & key[1]) << 8;
     h = ((h + 9) * (h + 2) * v) >> 1;
   }
   for (i = 2; i < arrayLength; i += 2) {
     h ^= (0xffUL & key[i]);
     h ^= (0xffUL & key[i + 1]) << 8;
     h ^= ((h + 9) * (h + 2) * v) >> 1;
   }
   if ((arrayLength & 1)) {
     h ^= (0xffUL & key[arrayLength - 1]);
     h ^= ((h + 9) * (h + 2) * v) >> 1;
   }
   return h % N;
 }
This function has the recommendable property that if arrayLength is 2, and N is 216, then the function is almost a perfect hash, filling 65531 of 65536 slots.
----
end text
This example needs more context before it is put in the article.  Is there a reference for it? Also the comment below the code is confusing. All the best, --Jorge Stolfi (talk) 12:47, 17 February 2010 (UTC)
replies: text: "Also the comment below the code is confusing.": No, the comment below the text is not confusing.  —Preceding unsigned comment added by Paulsheer (talk • contribs) 11:05, 18 February 2010 (UTC)

text: *Well, what is N and what is arrayLength? Anyway we need a reference that explains this code and analyzes it performance, etc.. Wikipedia does not publish original research. --Jorge Stolfi (talk) 07:26, 19 February 2010 (UTC)
thread_title:  Example of a good hash function? 

message: I agree, although I think that the following quote "Poor hashing usually degrades hash table performance by a constant factor,[citation needed] but hashing is often only a small part of the overall computation" was unnecessarily marked as needing a citation, as the truth of the assertion is self-evident. Consider a hash function f such that f(x) = 0 for all objects x. Obviously, this is the worst hash function possible, but it illustrates my point. Clearly, if the keys are comparable, then insertion and lookup will always have time complexity O(log n) rather than O(1). If the keys are not comparable, then insertion will have time complexity O(1) and lookup will have time complexity O(n) (since you can't binary search a list of items without an ordering).  —Preceding unsigned comment added by 24.69.148.22 (talk) 01:39, 11 April 2010 (UTC)
replies: text: No, it is not self-evident, as you have shown in your example. The change from O(1) to O(n) complexity is a performance degradation by a linear factor, not by a constant one (as claimed in the article). The statement, that performance degradation due to a poor (but not pathologically bad) hash function is constant, does need a citation. – Adrianwn (talk) 05:28, 11 April 2010 (UTC)

text: Actually, I think that the original author meant a performance degradation by a constant factor k, as long as the hash function is suboptimal (and leads to more collisions than a better one) but not purposefully bad (like mapping all inputs to the same hash value). If that is the case, this statement needs a more detailed explanation. If no citation can be found, it should be deleted, although it appears somewhat plausible. – Adrianwn (talk) 06:40, 12 April 2010 (UTC)
thread_title:  Citations (April 2010) 

message: Any objections to me setting up auto-archive on this page? It's getting rather lengthy, and I'd rather set it up to work automatically than keep doing it by hand. me_and 16:46, 23 September 2010 (UTC)
thread_title:  Auto archive 

message: Currently, it turns out from this article that open addressing is absolute nonsense (except, perhaps, because of caching). Actually it's not better so much because of insertion, deletion etc. speed, but because iteration speed (over whole table) is very good even with very non-uniform hashes. Thus, it's good for example to do duplicate check for values, which you do not insert too often, where the common operation is iterating over all values (for example if you want to iterate over table of size 100 000 each time you have added 20 elements). Consequently, rehashing can also be faster. qtvali --83.178.58.29 (talk) 22:03, 3 July 2011 (UTC)
thread_title:  Open addressing time 

message: "For example, a chained hash table with 1000 slots and 10,000 stored keys (load factor 10) is five to ten times slower than a 10,000-slot table 
(load factor 1); but still 1000 times faster than a plain sequential list, and possibly even faster than a balanced search tree."
This example and comment in the article seems to suggest that balanced search tree is even slower than a sequential list (linear search). This is absurd! :)  — Preceding unsigned comment added by 151.197.168.146 (talk) 16:15, 9 July 2011 (UTC)
replies: text: I don't see the problem. The claim is plausible as a lookup in the "load factor 10" scenario involves computing a hash then linear searching 10 items. Apart from the fact that such an operation is probably faster than a balanced tree search of 10,000 items (13 comparisons), searching 10 contiguous items can be much faster than accessing memory in different pages if page swapping is involved. Johnuniq (talk) 01:25, 10 July 2011 (UTC)

text: "This example and comment in the article seems to suggest that balanced search tree is even slower than a sequential list (linear search)." -- No it doesn't.  A hash table at load factor 10 might be 1000 times faster than a sequential search, and 1% faster than a balanced search tree.  The balanced search tree in that case is also approximately 1000x faster than a sequential search.  And besides, it said "possibly". Theclapp (talk) 20:06, 9 August 2013 (UTC)
thread_title:  Separate chaining section -- Sequential Lookup is slower than Balanced Tree Search?? 

message: You should define k to be the size of the hash table (the size of the underlying array ) and n to be the number of elements in the hash table, and unless you make the hypothesis that k < n, the space complexity should be O(k+n) rather than simply O(n).
By the way, this page has a more detailed complexity analysis for hash table that is much clearer than the mess on the wiki page
:Worse than that, the complexity table is inconsistent with the Performance Analysis section of the article.  In the complexity table, the search and delete operations are O(1 + n/k).  In the Performance Analysis section, the article states: "For the best possible choice of hash function, a table of size n with open addressing has no collisions and holds up to n elements, with a single comparison for successful lookup, and a table of size n with chaining and k keys has the minimum max(0, k-n) collisions and O(1 + k/n) comparisons for lookup."  If these two parts of the article are in fact discussing different things, that should be made apparent.
:Furthermore, the Performance Analysis section is completely missing the derivation and justification of the time complexity expressions in the complexity table.  This doesn't need to be an exhaustive treatment, but should serve to remove ambiguity in the variables shown in the table. 12.9.138.10 (talk) 23:17, 16 October 2012 (UTC)
replies: text: I already wrote above about the problem. I think thay hash tables are often teached wrongly, and most of the so called "hash table" examples have only O(n). However, a real hash function takes the input data to get the key! It makes some operations on the input "key" (i.e. giving a integer representation of a string), afterwards a modulo over the hash table length, and then you get the real hash table key ("index"). Then the value is inserted at the index number's slot, together with the original key. If there is already another value there, the original keys are compared, and then the value is added to that slot if the original keys aren't equal, or the value will be overwritten. That's how you get O(n2/m), where m is the table size. All this works well only if you use an intelligent operation to transform original keys into table keys/indexes, and it certainly should't take a long time to calculate the index out of the original key (otherwise you would be faster to implement a linear search). While the tables themselves are just normal lists with an incremental index, nothing more, so the trick behind everything is the hash function. Or am I wrong in thinking that many people don't understand that correctly? But then why are they talking about log(n) or making crap hash table examples?? (Don't understand me wrong, this wiki article has correct graphic examples, but the explanations are somehow not clear...a clear explanation would be like what I just wrote here!) 178.197.232.59 (talk) 11:37, 22 October 2012 (UTC)
thread_title:  The complexity table at the beginning does not define its variables 

message: The section needs to justify the use of a hash function: Why is a hash function even needed? Why not, for example, just store with each key the address of (pointer to) the value?
:"The idea of hashing is to distribute the entries (key/value pairs) across an array of buckets."
The diagram above shows buckets separate from the keys, but this sentence seems to say each (full) k-v pair is in a bucket.
:"Given a key, the algorithm computes an index that suggests where the entry can be found: [...]"
"Suggests"? Surely that's far too gentle a word. How about "gives" or "tells"?
:"A non-uniform distribution increases the number of collisions and the cost of resolving them."
Given the definition of collisions in the introduction, it's not clear why they are a problem that requires resolution. It's also not clear how uniformity has anything to do with them (apart from the mysterious hash function); it would seem that either two keys point the same value or they do not.
JKeck (talk) 17:14, 31 July 2013 (UTC)
replies: text: JKeck: I'm not sure if you really have no idea how hash tables work, as it seems to be in reading your first sentence, or if the "Hashing" section really needs a better explanation. Of course linear search (unsorted) or binary search (if sorted) is slower than a lookup through a hashed index and then linear search through the collisions.
2nd problem: keys vs bucket vs entries. Each bucket stores one entry or a linked list of entries. Each entry stores k-v pairs. Both, the sentence and the graphics do make sense. I have no idea how to improve the wording to make it clearer to confused people. More graphics probably.
3rd: "Suggests" is a proper word, since the key is not always found at the calculated index. Sometimes it has to search for more locations, either in the same array (open addressing) or in a separate bucket list of colliding entries. Also your forth complain makes not much sense. It's very "clear why there is a problem that requires resolution", dependent on the quality of the initially calculated index, which is dependent on the hash function, the fill factor and the uniformity of the distribution.  ReiniUrban (talk) 16:47, 28 August 2016 (UTC)
thread_title:  "Hashing" section needs improvement 

message: Can anyone explain what the following is trying to get at??  The reference seems to be off line.
For open addressing schemes, the hash function should also avoid clustering, the mapping of two or more keys to consecutive slots. Such clustering may cause the lookup cost to skyrocket, even if the load factor is low and collisions are infrequent. The popular multiplicative hash[3] is claimed to have particularly poor clustering behavior.[7]
* Any competent hash function will map two or more keys to consecutive slots, given the right keys.
* It appears to imply the slowdown ("skyrocket"!?) is caused physical storage concerns rather than collisions.  Given typical memory swapping schemes, adjacent physical addresses are more likely to available than not.
* In an open addressing scheme, the location of the data record is independent of the location of the slot.
Hew Johns (talk) 17:44, 19 August 2013 (UTC)
thread_title:  "Clustering concern?" 

message: "Python's built-in hash table implementation, in the form of the dict type, as well as Perl's hash type (%) are highly optimized as they are used internally to implement namespaces."
This statement is misleading. Perl used a simple and especially insecure but fast form of a Jenkins OOAT hash until 5.6, when it was attacked by collisions against the simple linear chaining. The proposed fix was to use universal hashing, to keep performance and add security against hash collisions. Implemented was randomized seeding on rehashing instead. This trick was found to be broken with 5.17.6, and so all optimizations were thrown overboard and a rather slow and secure hash function was selected, SipHash, instead of choosing an optimized and proper hash function (like City or Murmur) and a fast and secure collision strategy. Python choose the same road and changed to SipHash. Perl went back before the 5.18 release to a bit faster JenkinsOOAT hash function, but this still didn't solve the problem of the wrong collision resolution. Optimized strategies would have been open addressing, universal hashing or perfect hashing. There are furthermore no other possible optimizations implemented, like using SIMD or HW assisted crc32 intrinsics on Intel processors, as CRC32 turns out to be the fastest and best hash function for the average case (least number of collisions). See http://blogs.perl.org/users/rurban/2014/04/statistics-for-perl-hash-tables.html
I propose to use the wording 
"Python's built-in hash table implementation, in the form of the dict type, as well as Perl's hash type (%) are used internally to implement namespaces and therefore need to pay more attention to security, i.e. collision attacks."
Highly optimized and concurrent hashes can be studied with Clojure, the Hopscotch table or Robin Hood. ReiniUrban (talk) 17:01, 12 April 2014 (UTC)
replies: text: Right.  Using your own post as evidence - FAIL.  — Preceding unsigned comment added by 68.183.92.186 (talk) 00:27, 14 May 2014 (UTC)
replies: text:  Show me one counter-example of a hash implementation worse then perl5. You'll find none in open source. Claiming "highly optimized" for highly deoptimized is grossly misleading. I implemented many improvements in my fork, but it's still worse than ruby or any other typical naive unoptimized implementation. ReiniUrban (talk) 16:30, 28 August 2016 (UTC)
thread_title:  Wrong "highly optimized" Perl claim 

message: Perl is not interpreted.  — Preceding unsigned comment added by 68.183.92.186 (talk) 00:17, 14 May 2014 (UTC)
thread_title:  Associative arrays 

message: Why link to an non-existent article?  — Preceding unsigned comment added by 75.79.3.84 (talk) 20:09, 15 May 2014 (UTC)
replies: text: Some of the good reasons for linking to an article that does not yet exist are listed at Wikipedia: red link. --DavidCary (talk) 04:25, 24 May 2015 (UTC)
thread_title:  array hash table 

message: This article needs simple examples up front so that novices can get the general idea. 2602:306:35FA:D540:2487:9F59:8A65:3095 (talk) 04:44, 27 January 2017 (UTC)
thread_title:  Examples 

message: Right now Robin Hood hashing and 2-choice hashing are listed as a direct children of "Collision Resolution". They seems to fit the definition of Open Addressing resolution strategies. Since all other open addressing strategies are listed under the Open Addressing subsection, shouldn't these two techniques be moved there too?
Andreas Lundblad (talk) 07:13, 10 July 2019 (UTC)
thread_title:  Nest Robin Hood hashing and 2-choice hashing under Open Addressing? 

message: The lead says: Ideally, the hash function will assign each key to a unique bucket, but most hash table designs employ an imperfect hash function, which might cause hash collisions...Such collisions must be accommodated in some way. .
We don't live in an ideal world, so starting out with a statement about ideal is supercilious.  The implication is that if a hash function is 'imperfect', like an assembly line making imperfect parts, why don't we fix it so it's 'perfect'?  An imperfect hash function might cause hash collisions, but the sense of this statement is vague, and beggars the question, why don't we build one that 'might not' cause hash collisions?   Easy enough to postulate, eh?
We might lead a novice into actually attempting to do that.  I wish him luck.
How about this in place of the whole paragraph: Hash functions are designed to be efficient to compute and minimize collisions, duplicate hash codes resulting from distinct keys. 19 words versus 48.  And it's very informative.  The lead is not the place to go into what happens in a collision: we may assume, and indeed we find, a whole section talking about just that.  Hmmm... or we could add, Hash functions are accompanied by an adjunct collision-resolution method. Now I think we've got a substantial digest. Scholarly diction is an art. Sbalfour (talk) 21:47, 24 September 2019 (UTC)
thread_title: Lead

message: Robin hood hashing is entirely analogous to the three ways the chains may be ordered in chained hashing: as unordered lists, as serially ordered lists (alphabetically or by some other key-dependent criteria), or as self-ordering lists by probe frequency (i.e. key-independent criteria).  So, we reshuffle the bucket sequences for collided keys just as we reshuffle the chains.  Yeh?  I think we lost sight of the forest for the trees on this one. Sbalfour (talk) 22:38, 24 September 2019 (UTC)
thread_title:  Robin hood hashing - clarity 

message: Recently someone used the
"Inside the latency of hash table operations" by Andy Ke as a reference for this article.
I feel this is perilously close to becoming a WP:REFLOOP,
because many sentences and illustrations in that article are a word-for-word identical to (an earlier version of) this "hash table" Wikipedia article.
(A few of of those sentences are sentences I wrote for Wikipedia).
What should we do about this? --DavidCary (talk) 23:24, 6 May 2020 (UTC)
thread_title:   circular reference 

message: I spent several hours documenting a simple example of a hash table (), only to have it deleted one week later with the edit summary "rm unsourced code, we don't need that here". I agree that it's unsourced, but I disagree with the assessment that we don't need a code example here. I'll never forget my first visit to this article many years ago -- before I had experience with hash tables -- and found the article seriously lacking because it didn't show a single functional example of an actual hash table. I realize that my example may not be acceptable because -- even though I personally tested it and determined that it functions exactly as explained -- it might be considered OR and therefore verboten. Having said that, I don't really care if my example is restored or some other example is used instead, but I would argue that simple functional example is essential to help explain this topic. Lambtron talk 22:50, 7 February 2022 (UTC)
replies: text: You shouldn't be using your favorite programming languages for writing samples; it should be written in language agnostic way at its dedicated article. If you found a C example to be helpful, maybe you can host a blog or take private notes. But such things aren't utilitarian in our Wikipedia articles. WikiLinuz🍁(talk) 23:52, 7 February 2022 (UTC)
replies: text: Thanks for the friendly and supportive reply. I should have known that simple C examples are not useful in Wikipedia, and that only language agnostic examples are permitted. Per your advice, I will abandon my unworthy attempts to improve your article and instead start a blog. Hopefully, someone more enlightened will -- at some time in the future -- add an acceptable, actual example to help explain this topic. Lambtron talk 14:32, 8 February 2022 (UTC)
replies: text: You're welcomed to try again at Perfect hash function article, but not in C. There are language agnostic ways to write pseudocode that involve bitwise operations. If your example was notable enough, it wouldn't be hard to find a scholarly journal article where the code might be discussed (and we could source it from there). WikiLinuz🍁(talk) 15:03, 8 February 2022 (UTC)

text: Hash table (and other data structure-related articles) are candidates for WP:GA. Your source code should be sourced, and "trust me bro" isn't constructive; it's also WP:UNDUE in this article, that's why I said that you could try again at the dedicated article. A source code certainly doesn't fall under WP:Routine calculation. Wikipedia is not a repository, if you really want C code samples, maybe WikiBooks is appropriate for you. WikiLinuz🍁(talk) 17:06, 8 February 2022 (UTC)
replies: text: You have successfully found 10000 reasons for excluding examples from this article (apologies to Edison). Apparently examples in specific languages are prohibited; these must be translated to pseudocode before they can be considered for inclusion. The translated code would require a citation from a scholarly journal, because a straightforward explanation alone cannot be trusted. Even after translating and citing, a sole example is inherently WP:UNDU because it implements a particular type of hash function, and therefore it cannot be used here, to explain hash tables. Finally, after clearly stating that my goal is to have a basic illustrative example in this article, you flippantly assume that what I really want is C samples -- and suggest that I visit WikiBooks to satisfy that need. I suggest a different approach: proactively work with me to enhance this article with a simple example that helps to make hash tables easier to understand. Lambtron talk 19:47, 8 February 2022 (UTC)
replies: text: Like I precisely stated, if you can't cite a scholarly source, and wanted me to comply with your "trust me bro" policies, we have nothing to talk about. Any user, including an IP, can challenge an unsourced OR. If you find a source that implements your example in XYZ programming language, and you translate that into pseudocode, it isn't OR in this case. You cannot publish your own thought, no matter how much you're in love with the example. I'm all ears if you could find a source. - WP:VERIFYOR WikiLinuz🍁(talk) 20:01, 8 February 2022 (UTC)
replies: text: I'm glad to hear that you've been listening, with open mind, to my concerns about the need for a simple practical example to meet readers' needs. Lambtron talk 04:36, 9 February 2022 (UTC)
thread_title:  Concrete example needed 

message: This explanation in section  is unclear because the term hash digest is not explained and M does not appear in the equation above it. (Also, it should probably not be capitalized because it is not a complete sentence.)
In the following section, , it is the other way around: M appears in the equation but is not explained. Gnib Bnil (talk) 14:55, 5 June 2024 (UTC)
thread_title:  Hash digest