> Floating point keys just seem like a terrible idea.

I don't see why floating point (with a defined precision) keys are any worse fundamentally than any finite-domain scalar keys. The applications for which they are useful may be limited, and they may be the wrong choice for some uses, but that's true of anything.

> floating point (with a defined precision)

If it's fixed-precision it's not floating point, it's basically an integer we interpret with a decimal point somewhere when we display it. If you didn't mean fixed-precision, then I'm not sure how actual floating points could sanely act as a hash key.

> If it's fixed-precision it's not floating point

I'm not referring to fixed point, but fixed-size representation.

> If you didn't mean fixed-precision, then I'm not sure how actual floating points could sanely act as a hash key.

I don't see what the problem is. Certainly, there's problems if you do certain floating point calculations and blindly look for the result as a key in a mapping, but that's not a problem with floats as keys, its a problem with that particular usage pattern.

> I'm not referring to fixed point, but fixed-size representation.

I'm still not sure what you mean as any IEEE floating point (which in reality all anyone uses) is fixed-size. If you decide to truncate, round, do w/e to this value, you may still not get exactly the same answer for similar computations or even the same computation on different machines. There isn't a reason you can't (well, shouldn't) do float_val == 0.0 -- it won't work in all circumstances.

Please explain your method of making sure float_val == 0.0 while retaining the essence of being floating point (i.e. not using fixed-point).

Even with a defined precision they're weird in that they "ought to" be modeling the reals and therefore lack computable equality.

Which makes it hard to write a well-defined hash.