the default hash function for floats/doubles is not very good.

[nicebyte]

the default hash for floats works by casting the value to size_t:

	template <> struct hash<float>
		{ size_t operator()(float val) const { return static_cast<size_t>(val); } };

this is quite bad because anything that is between two integers gets hashed to the same value. my hash table essentially turned into a linear array because most of the values happened to be in the [0; 1] range.

the same applies to hashes for other floating point types (double, long double etc.).

when fixing this, keep in mind that floating point numbers have two representations for 0 (0 and -0) - those two bit patterns should hash to the same value because they represent the same number.

[SirNate0]

Counterpoint. -0 and 0 are not the same value: They have different behavior when you, for example, do 1.0/-0.0 vs 1.0/+0.0 (giving negative vs positive infinity). But since -0.0==+0.0 (in IEEE 754 at least), it does seem reasonable to make them hash to the same value. Though since NAN == NAN is false, but hash(NAN) == hash(NAN) would be true, there will always be at least that case* where (hash(x) == hash(y)) != (x == y), so it doesn't seem too ridiculous to have hash(-0.0) != hash(+0.0). In other words, replacing the static_cast with a bit_cast doesn't seem too unreasonable.

* Actually many cases when you consider there are many possible bit values for NAN.

[jhopkins-ea]

Hi. Thanks for raising this. We will have a fix for this in the next public release (no plan for when that is). The approach we've taken is to map hash 0 and -0 to the same value (Clang, MSVC and GCC all do this) and effectively bit cast the value to size_t.