hash_uint: simplify definitions

[StefanKarpinski]

Experimenting with simplifying and slightly speeding up hash_uint.

[vtjnash]

Suggested change

	c = a ⊻ b # bitrotate(a, 43) ⊻ bitrotate(b, -17)
	c = a ⊻ b

[StefanKarpinski]

Not sure if this is worth all the doctest churn. On the other hand, it's kind of bad that so many doctests depend on the internals of hashing. Another argument for ordered dicts...

[jakobnissen]

It's worse than that though, the doctests also depend on the internals of Dict and Set, which presumably should be free to change. Perhaps, instead of defaulting to ordered dicts, it's better to fix all the docstrings that assumes on well-defined iteration order for Dict and Set?

[KristofferC]

Why? We can just update them whenever needed. It's a single command to do it. It's not different from any other case where we slightly tweak the printing and then have to fix up the doctests.

[jakobnissen]

We could do that, too, but changing the doctests whenever the computed result don't fit with the documentation does sort of defeat the purpose of doc-tests. Ideally, they should only be updated if the documented behaviour changes. Of course, changes to the documentation itself or printing will necessitate updating the docs, so that is an exception.

[KristofferC]

We could do that, too, but changing the doctests whenever the computed result don't fit with the documentation does sort of defeat the purpose of doc-tests.

No, it doesn't. The point of a doctest is to ensure that the examples in the documentation looks roughly correct, and don't become outdated as changes accumulate. A doctest will by itself never block a change from going in, it can just serve as a hint/warning of how a change affects the printing of stuff. If it still looks ok from a manual look then the doctest is just updated. This happens pretty much all the time.

[JeffreySarnoff]

+1 for simplifying the core hash logic

[oscardssmith]

This seems worth reviving given the potential performance implications.