Lines Matching refs:hash
11 # or changing, the hash algorithm. In which case it's usually also
106 # platforms with hash codes of the same bit width.
109 got = hash(t)
112 msg = f"FAIL hash({t!r}) == {got} != {expected}"
125 # Earlier versions of the tuple hash algorithm had massive collisions
171 hashes = list(map(hash, xs))
172 tryone_inner(tag + f"; {NHASHBITS}-bit hash codes",
180 tryone_inner(tag + "; 32-bit upper hash codes",
187 tryone_inner(tag + "; 32-bit lower hash codes",
198 # A previous hash had systematic problems when mixing integers of
203 # Note: -1 is omitted because hash(-1) == hash(-2) == -2, and
204 # there's nothing the tuple hash can do to avoid collisions
212 # bit - the middle bits are all zeroes. A decent hash has to
225 # And even worse. hash(0.5) has only a single bit set, at the
226 # high end. A decent hash needs to propagate high bits right.
232 # to hash randomization for strings. So we can't say exactly
235 # random mean. Even if the tuple hash can't achieve that on its
236 # own, the string hash is trying to be decently pseudo-random
238 # that the tuple hash doesn't systematically ruin that.
244 # Ensures, for example, that the hash:
419 # Notes on testing hash codes. The primary thing is that Python doesn't
420 # care about "random" hash codes. To the contrary, we like them to be
422 # distributed as possible. For integers this is easy: hash(i) == i for
430 # catastrophic pileups on a relative handful of hash codes. The dict
431 # and set lookup routines remain effective provided that full-width hash
435 # hash would do, but don't automate "pass or fail" based on those
441 # When global JUST_SHOW_HASH_RESULTS is True, the tuple hash statistics
444 # old tuple test; 32-bit upper hash codes; \
449 # "32-bit upper hash codes" means this was run under a 64-bit build and
450 # we've shifted away the lower 32 bits of the hash codes.
452 # "pileup" is 0 if there were no collisions across those hash codes.
453 # It's 1 less than the maximum number of times any single hash code was
454 # seen. So in this case, there was (at least) one hash code that was
455 # seen 50 times: that hash code "piled up" 49 more times than ideal.
457 # "mean" is the number of collisions a perfectly random hash function
463 # of collisions a perfectly random hash function would suffer. A
466 # for a hash function that claimed to be random. It's essentially
471 # Knowing something about how the high-order hash code bits behave
476 # old tuple test; 32-bit lower hash codes; \
481 # 0..99 << 60 by 3; 32-bit hash codes; \
485 # random". On a 64-bit build the wider hash codes are fine too:
487 # 0..99 << 60 by 3; 64-bit hash codes; \
492 # 0..99 << 60 by 3; 32-bit lower hash codes; \
496 # collisions out of a million hash codes isn't anywhere near being a
497 # real problem; and, (b) the worst pileup on a single hash code is a measly
498 # 1 extra. It's a relatively poor case for the tuple hash, but still
507 # [0, 0.5] by 18; 64-bit hash codes; \
509 # [0, 0.5] by 18; 32-bit lower hash codes; \