Talk:Perfect hash function

message: Bob Jenkins' "Minimal Perfect Hashing" looks good, but I have not tried it yet.
Regards!
Alan
I'm not sure if "perfect" and "ordered" qualifiers shouldn't each go to separate pages,
possibly even wiktionary pages. Also I see on definition on web that says ordered means i<=j
implies F(i)<=F(j) (note the equal signs) but that sounds wrong to me--too weak.  If only there
were an expert somewhere to consult with...
JMCorey 18:30, 23 Mar 2005 (UTC)
thread_title: Unnamed section

message: A set by definition contains distinct elements. So, why the statement "maps distinct elements in S to distinct integers"? Should be "maps each element in S to a distinct integer".  —Preceding unsigned comment added by Tbtietc (talk • contribs) 19:53, 3 August 2010 (UTC)
thread_title:  "distinct elements in S"? 

message: I added the reference below because it predates all the ones listed and is, we believe, the first article about perfect hash functions published with useful results.
Richard J. Cichelli. Minimal Perfect Hash Functions Made Simple, Communications of the ACM, Vol. 23, Number 1, January 1980.
19:40, 27 June 2011 (UTC)
thread_title: Chichelli ref

message: It's not clear to me what the difference is between "order preserving" and "monotone". They sound like the same thing. Am I missing something? If so, it might help to clarify the distinction.
Secondly, do "order preserving" and "monotone" only apply to minimal perfect hash functions, or can the terms also be used for perfect hash functions?
Cmcqueen1975 (talk) 01:41, 3 August 2011 (UTC)
replies: text: Order Preserving minimal Perfect Hashing can be used with perfect hash functions as well. The term was coined by Fox, Chen, Heath, Daoud in their seminal paper SIGIR 1990 (later published in ACM Transactions on Information Systems; included the reference in Further Reading). I introduced the term in my Ph.D. thesis and it stands for "any priora order" and lexographical key order is a special case. Many examples are given for both. Applications include efficient Hash Join, efficient deduplication, and efficient access for variable length keys as records can maintain their current locations while the OPMPHF provide O(1) access. Used extensively to reference seismic lines and vector data that were stored on online tapes.   — Preceding unsigned comment added by Daoudamjad (talk • contribs) 11:03, 5 March 2013 (UTC)
thread_title:  Order preserving and monotone 

message: It seems patently obvious that deletions from a set of dynamic keys do not cause a new hash function to be needed. Though the source doesn't explicitly say this, it's implicit in some of the formulations.  Can I add this without having to quote or point to some part of the source? Sbalfour (talk) 16:27, 6 October 2019 (UTC)
thread_title:  Dynamic perfect hashing 

message: When I consider (or have actually attempted) finding a perfect hash function, the immediate consideration is that it is daunting: the necessary conditions are stringent, computational effort is factorially steep, and there is no deterministic procedure for finding one.  Most attempts end in failure after a prolonged period of enumerative search, trial and error, and guesswork about what to try next.  Sometimes, it cost days of cpu time with no end in sight.  Success usually yields a computationally complex function, or a multi-tiered array of hash functions, and/or a substantially sparser table than I'd need with a standard hash function.  For ~1000 keys, I found one with 3 modulos(divides) and two multiplies.  This is versus the alternative (i.e., a binary search: one may consider the 'hash function' to be ten integer comparisons).  And the table for binary search is contiguous, so the ten comparisons are a minimal perfect hash function. How often do we need a perfect hash function for more than 1000 keys?
There is a reasonably deterministic way of guaranteeing a perfect hash function will be found: if the number of slots in the table is at least n2 where n is the number of keys mapped, more than one out of every two random universal hash functions is collisionless.  The ONLY reason finding such a function is factorially hard is because we insist that the table size remain O(n).  It's a classic time-space tradeoff on a factorial scale.  
Here's a table of the trade off for 32 keys and power of 2 table sizes:
table size   odds
*32          1 / 5.6e12           (minimal perfect hash function)
*64          1 / 1.3e4   
*128         1 / 6.9e1
*256         1 / 7.6e0
*512         1 / 2.7e0          
*1024        1 / 1.6e0      
where odds is the probability of picking a perfect hash function out of all possible mappings.  A standard hash table for 32 items might be about 41 slots, and the odds of picking a perfect hash function for it are roughly 1 in 45 million.  If we're singularly concerned about worst case performance, the problem is trivial.  Here, a 1024-slot table is negligible - if the data items are huge, we don't put them in the table, but pointers to them instead.  But I don't think worst case performance is the driving factor behind selecting a perfect hash function.  Expected (statistical) worst case performance (as opposed to theoretical or absolute worst case performance of all keys mapping to the same index) for a universal hash function is already reasonably small.
None of this is mentioned in the article, as if "Aren't PHF's great! Let's use them all the time".Sbalfour (talk) 21:54, 7 October 2019 (UTC)
thread_title:  Missing info, emphasis? 

message: Throughout the article (as well as in the reference [1] and its reference [2]) the short form log is used for binary logarithm (logarithm to the base of 2), generally abbreviated either with log2 or lb.  Shouldn't this be corrected or at least clarified?
[1] https://cmph.sourceforge.net/papers/esa09.pdf
[2] K. Mehlhorn. Data Structures and Algorithms 1: Sorting and Searching. SpringerVerlag, 1984. 37.138.90.29 (talk) 17:23, 28 February 2024 (UTC)
thread_title:  logarithm