std::unordered_set::load_factor，为什么是 float 而不是 double？
std::unordered_set::load_factor, why float instead of double?
我了解到 float 和 double 之间最快的类型取决于本机 ALU 实现，它通常基于双精度。当你根据逆向精度进行计算时，ALU必须一直做相应的精度转换。
那么，为什么标准选择float来代表load_factor呢？我想这是为了节省对哈希表容器的内存思考，但我想知道是否有更充分的理由。
这发生在 revision 3 of the original proposal:
Changed load factor operations to use float instead of double
稍后给出理由（在"E. Control of Hash Resizing"下）：
Should the floating-point parameter be of type float, or of type double? It makes very little difference. On the one hand, double is typically the "natural" floating-point type that is used in the absence of a strong reason to the contrary. On the other hand, float may allow the hash table implementation to save some space, and may alert users to the fact that the value will not be used in any context that involves high precision. I have chosen float.
基本上就是你说的。
至于性能，有人提到了这一点以及它在事物的宏伟计划中并不重要（尽管在捍卫使用浮点数的背景下与整数）：
The cost of a runtime floating-point parameter is one floating-point multiplication at every rehash (not every insertion). Even with incremental hashing, this is almost certain to be dwarfed by the cost of a rehash.
我了解到 float 和 double 之间最快的类型取决于本机 ALU 实现，它通常基于双精度。当你根据逆向精度进行计算时，ALU必须一直做相应的精度转换。
那么，为什么标准选择float来代表load_factor呢？我想这是为了节省对哈希表容器的内存思考，但我想知道是否有更充分的理由。
这发生在 revision 3 of the original proposal:
Changed load factor operations to use
floatinstead ofdouble
稍后给出理由（在"E. Control of Hash Resizing"下）：
Should the floating-point parameter be of type
float, or of typedouble? It makes very little difference. On the one hand,doubleis typically the "natural" floating-point type that is used in the absence of a strong reason to the contrary. On the other hand,floatmay allow the hash table implementation to save some space, and may alert users to the fact that the value will not be used in any context that involves high precision. I have chosenfloat.
基本上就是你说的。
至于性能，有人提到了这一点以及它在事物的宏伟计划中并不重要（尽管在捍卫使用浮点数的背景下与整数）：
The cost of a runtime floating-point parameter is one floating-point multiplication at every rehash (not every insertion). Even with incremental hashing, this is almost certain to be dwarfed by the cost of a rehash.