It is my understanding, and I think that the last post confirms it, that the key for any hash is always “a string.”   Numbers get converted by some means into “a string,” and particularly in the case of floats, that can get dicey.   I frankly wouldn’t try to use a float, for fear of failing to locate a value that really is supposed to be “in” the hash.

What to do .. how much complexity is actually appropriate to invest in this .. depends on your situation, but one strategy that you might wish to consider is to use int() to extract the integer portion of the number (or perhaps, the integer portion of some agreed-upon multiple of it), then have the hash-bucket actually consist of a list of, say, hashes that contain (key, value) pairs.   (Which can be fairly-efficiently searched through using grep().)   So, a dump of what I’m talking about here might look like this:

[
  '1' => [
    { 'value' : 1.61803398874, 'name' : 'golden_ratio' },
    { 'value' : 1.30357, 'name' : 'conways_constant' },
  '2' => [ 
    { 'value' :  2.71828, 'name' : 'E' },
  ],
  '3' => [
    { 'value' : 3.14159, 'name' : 'pi' },
  ]
]
[download]

And if we had hashed by int($key * 10), we would have had four distinct buckets with keys (13, 16, 27, 31) with only one entry apiece.   So it goes.)

You would, of course, embed all of this messy-ness into a class ... but, now you have a data structure that can store floating-point values exactly, yet find them reasonably quickly by using a hash to reduce the search time.