6 ms·
Simplest Hash Functions
- bryanrasmussen 7mo agoa hash function that produce hashes that are already in the hash table should, IMO, not be called a hash function. I get why technically it is a hash function, but still, no.
- phinnaeus 7mo agoHere is a hash function that does not have hash collisions: fn hash(data): return data
- Charon77 7mo agoWell it no longer constrains the data in a fixed output length.
- dbdr 7mo agoSure, but if you constrain to fixed output length, you will definitely have collisions (Pigeon Hole Principle). There's no way around that.
- hsbauauvhabzb 7mo agopadding with zeroes to a fixed length and prepending the original length would suffice, but you’d have to have a fixed length of double infinity to account for both the length information and the hash information, and the hash is less efficient than the original information.
- oliver236 7mo agowhat programming language is this?
- tux3 7mo agoThat is a function, but not a hash function!
- ahazred8ta 7mo agoA perfect hash function https://en.wikipedia.org/wiki/Perfect_hash_function https://en.wikipedia.org/wiki/Perfect_hash_function has to be specially constructed for each desired set of inputs. Generic hash functions cannot be 'perfect'.
- baruch 7mo agoIt is mathematically impossible for a proper hash function (one with an output range smaller than its input range) to not have collisions. The proof uses the Pigeon Hole Principle https://en.wikipedia.org/wiki/Pigeonhole_principle https://en.wikipedia.org/wiki/Pigeonhole_principle
- bryanrasmussen 7mo agook damn, I did not know this, obviously. Thanks. I guess I've never actually had this problem because was always hashing things that were static, or specialty cases like password hashes where the salt obviously guarantees uniqueness.
- kro 7mo agoIt's very very unlikely to get collisions there, but still not impossible. Whenever you map data of arbitrary length (infinite possibilities) to a limited length collisions are possible.
- eru 7mo agoDoesn't even have to be arbitrary length. Whenever you map into a smaller space, you get collisions. The bigger space doesn't have to be infinite.
- bryanrasmussen 7mo agowith a password you may be mapping into a smaller space or a bigger space, because what you want is to get them all same length, but yeah you may in some cases be mapping into a smaller space, hadn't thought of that, although I sort of also think it is unlikely. But there it doesn't matter anyway because the password is put together with the email to identify the user so in practicality passwords will never collide even if they could in theory.
- eru 7mo ago
- Charon77 7mo ago> Like addition I'm perplexed to the claim that addition is cheaper than XOR, especially since addition is built upon XOR, am I missing anything? Is it javascript specific?
- pjscott 7mo agoThe wording was a bit unclear. The previous paragraph mentions wanting something cheaper than "those pesky XORs and multiplications". The multiplication is the expensive part; the (very cheap) XORs are just mildly annoying because you have to think about what they're doing.
- 4k0hz 7mo agoAt least on x86, multiple additions and multiplications can be done with a single `lea` instruction so it's preferable to XOR. Though I have no idea about other architectures, compiler implementations, any interpreters...
- ygra 7mo agoThat only helps with multiplications by statically known word sizes (4x, 8x, etc.) and not arbitrary x·y. It can help with many smaller constant multipliers if the complete is clever, but it has to be known at compile time.
- purplesyringa 7mo agoI work on the machine code level, so the only characteristic I'm interested in is how many ticks it takes to compute the result, not how many transistors it requires or anything like that. All modern CPUs take 1 tick to compute both XOR, addition, and many other simple arithmetic operations, so even though addition is technically more complicated in CPU designs, it never surfaces in software. In the context of this post, I preferred addition instead of XOR to reduce cancel-out and propagate entropy between bits.
- johanvts 7mo agoThis is a excellent article for anyone looking for some more in-depth analysis of tabulation based hashing methods: https://arxiv.org/abs/1505.01523 https://arxiv.org/abs/1505.01523
- jandrewrogers 7mo agoA “simplest” hash function is completely dependent on what you are using the hash function for and the guarantees you want a hash function to make. An optimal permutation of an integer is different from a small string hash is different from a block checksum. Literally, you are optimizing the algorithm for entirely different properties. No algorithm can satisfy all of them even approximately. The full scope of things hash functions are commonly used for requires at least four algorithms if you care about performance and optimality. It is disconcertingly common to see developers using hash algorithms in contexts where they are not fit for purpose. Gotta pick the right tool for the job.
- eru 7mo agoYou are right! For example, when you know that your input is uniformly randomly distributed, then truncation is a perfectly good hash function. (And a special case of truncation is the identity function.) The above condition might sound too strong to be practical, but when you are eg dealing with UUIDs it is satisfied. Another interesting hash function: length. See https://news.ycombinator.com/item?id=6919216 https://news.ycombinator.com/item?id=6919216 for a bad example. For a good example: consider rmlint and other file system deduplicators. These deduplicators scan your filesystem for duplicates (amongst other things). You don't want to compare every file against every other file. So as a first optimisation, you compare files only by some hash. But conventional hashes like sha256 or crc take O(n) to compute. So you compute cheaper hashes first, even if they are weaker. Truncation, ie only looking at the first few bytes is very cheap. Determining the length of a file is even cheaper.
- guenthert 7mo agoNow I'm no expert in that matter, but the fs deduplicators I've seen were block, not file, based. Those can clearly not use the file length as they are blissfully unaware of files (or any structure for that matter). Those use a rather expensive hash function (you really want to avoid hash collisions), but (at least some ten years ago) memory, not processing speed, was the limiting factor.
- 7mo ago
- teo_zero 7mo agoWhile I generally like to reinvent the wheel, for hash functions I strongly recommend to use a proved good one. Djb2 by the venerable Daniel Bernstein satisfies all the requirements of TFA. h = 5381 while still has data: h = h * 33 + next_byte() return h PS of course if you think the multiplication is overkill, consider that it is nothing more than a shift and an addition.
- purplesyringa 7mo agoDjb2 is hardly a proven good hash :) It's really easy to find collisions for it, and it's not seeded, so you're kind of screwed regardless. It's the odd middle ground between "safely usable in practice" and "fast in practice", which turns out to be "neither safe nor fast" in this case.
- kuzivaai 7mo agoThe point about hash tables using top bits instead of bottom bits is the kind of thing that feels obvious once someone says it and yet here we are. Genuine question: have you seen any real-world hash table implementations that actually do this, or is it purely "this is what we should have done 40 years ago"?
- SkiFire13 7mo agoI think older processors used to have a slower implementation for shifts, which made this slower. Nowadays swisstable and other similar hashtables use the top bits and simd/swar techniques to quickly filter out collisions after determining the starting bucket.
- teo_zero 7mo agoSorry, I've read and reread TFA but the concept still evades me. Is it that, since it's easier for a hash function to have higher entropy in the higher bits than in the lower ones, it would be more logical for hash tables to discard the lower bits and keep the higher ones?
- purplesyringa 7mo agoYes, that's my point. It's not true that all hash functions have this characteristic, but most fast ones do. (And if you're using a slow-and-high-quality hash function, the distinction doesn't matter, so might as well use top bits.)
- adrian_b 7mo agoHigher entropy in the higher bits is a property of addition and multiplication when the result has the same size as the operands (i.e. the result is taken modulo 2^N, which folds back the values exceeding the size of the result). When other operations are used, there may be other bits with higher entropy. For example, when full-length multiplication is used (i.e. where the length of the result is the sum of the lengths of the operands), the middle bits have the highest entropy, not the top bits. On CPUs like the Intel/AMD x86-64 CPUs, where fast long multiplication instructions are available, this can be exploited in more performant hash functions and PRNGs. In hash functions, additions and multiplications are frequently used together with rotations, in order to redistribute the entropy from the top bits to the bottom bits, during the following operations.
- benob 7mo agoI just realized that a hash function is nothing less than the output of a deterministic random number generator xored with some data
- eru 7mo agoSorry, what? That might we one very particular way to write a hash function, but it's far from the only one. Believe it or not, for some purposes taking the first few bytes of a string or even just the length of the string are good hash functions.
- andai 7mo agoWell, that's technically also a deterministic random number generator! (I want to say it's not a great one, but... that's apparently context-dependent!) What are those purposes?
- eru 7mo agoIf your input is i.i.d. random, then truncating works great. Eg if your keys are UUIDs then truncating can work well. Another use: Suppose you write a tool like rmlint that is looking for duplicate files. Generally, you compute some hash for each file, see if you got any duplicates, and then compare the relevant files directly. A traditional hash like crc or sha256 takes O(n) to compute. But for files you can start with some cheaper hashes, like file length. After all, files of different length can't have the same content. Taking the first few bytes of your file is another cheap 'hash' you can compute. Only when these cheap 'hashes' show that you have a potential duplicate, do you go and pay for a more expensive hash.
- derriz 7mo agoCould you explain what you mean here? Hashes are _functions_ so provide the same output given the same input. If you don't reseed the RNG after every hash computation, then you break this vital property of hashes. And if you do reseed, then your claim boils down to "every hash function is just an XOR against a contstant" which certainly is not true either.
- Sharlin 7mo agodef hash(str): len(str) O(1), baby!
- zimpenfish 7mo agoO(1) only if you're working in a language with length-stored strings (like Pascal[0]), right? In something like C with its generic strings[1], it would surely have to be O(n) since you have to scan the entire string to calculate its length? (I have always been terrible at big-O, mind.) [0] There's probably more of them by now. [1] ie. not a specific length-stored string type.
- Sharlin 7mo agoYes. But that's a known misfeature of C and no other language does it like that. Plus I kind of meant arbitrary byte strings where you can have embedded zeroes and thus have to know the length.
- eru 7mo agoYou'd probably want 'return len(str)', if this is Python? In any case, for some applications this is indeed a great hash function. Programs like rmlint use it as part of their checks for duplicate files: if files have different lengths, they can't have the same content after all.
- andai 7mo agoRe: missing return keyword Actually, in Python, None is a valid key... (I'm so sorry. JavaScript has ruined me.)
- tetha 7mo agoAny `return c` for some constant is a valid and correct hash function. It just has a lot of collisions and degenerates hash-maps to terrible performance. That was in fact my first thought when I read "simplest hash functions".
- 7mo ago