If you use the pack 'd', $value; approach you will likely end up with every key in your hash having a value of 1. Even a single bit difference in the lowest significant bit will prevent 2.0 & 2.000000000000000001 being considered the same.

Your best bet might be to use sprintf to truncate and stringify the values into a standardised format to whatever precision fits with your needs. Eg.

$hash{ sprintf '%.6e', $number };
[download]

This will rationalise the continuous range of inputs into a set of discrete bands to whichever precision you need. This shows the effect of using 6 and 11 digits of precision on a range of pairs of values that have a small difference between them as input (and would be different keys using pack 'd'):

printf "%20s becomes %.6e\n", $_, $_ for map{ 
    ( $_, ( $_ + 1e-10 ) ) 
} map{ 
    "2e$_" 
} -300, -30, -3, 0, 3, 30, 300;

              2e-300 becomes 2.000000e-300
              1e-010 becomes 1.000000e-010
               2e-30 becomes 2.000000e-030
              1e-010 becomes 1.000000e-010
                2e-3 becomes 2.000000e-003
        0.0020000001 becomes 2.000000e-003
                 2e0 becomes 2.000000e+000
        2.0000000001 becomes 2.000000e+000
                 2e3 becomes 2.000000e+003
     2000.0000000001 becomes 2.000000e+003
                2e30 becomes 2.000000e+030
              2e+030 becomes 2.000000e+030
               2e300 becomes 2.000000e+300
              2e+300 becomes 2.000000e+300

printf "%20s becomes %.11e\n", $_, $_ for map{ 
     ( $_, ( $_ + 1e-10 ) ) 
} map{ 
    "2e$_" 
} -300, -30, -3, 0, 3, 30, 30

              2e-300 becomes 2.00000000000e-300
              1e-010 becomes 1.00000000000e-010
               2e-30 becomes 2.00000000000e-030
              1e-010 becomes 1.00000000000e-010
                2e-3 becomes 2.00000000000e-003
        0.0020000001 becomes 2.00000010000e-003
                 2e0 becomes 2.00000000000e+000
        2.0000000001 becomes 2.00000000010e+000
                 2e3 becomes 2.00000000000e+003
     2000.0000000001 becomes 2.00000000000e+003
                2e30 becomes 2.00000000000e+030
              2e+030 becomes 2.00000000000e+030
               2e300 becomes 2.00000000000e+300
              2e+300 becomes 2.00000000000e+300
[download]

Typically, when I build histograms for floating point numbers, I have some level of binning required (ie, determining what the size of each catchment area is).

For instance, although the values might have 6 significant figures past 0, I don't want that the graph to deal with 10^6 datapoints -- I might only want 10^4, so rather than hashing on $value, I'll hash on &bin($value), where 'bin' is a function to strip the value to the precision I want. (which may not be a linear function)

If you really need the precision -- It's possible that PDL might be what you're looking for (at least, for the estimation of spectra, as I know there are folks that do physics number crunching with it, although I have no idea what it actually entails, not being a physicist myself).

Update I don't know why we got accused of graphing -- I guess you could graph in PDL, but unless there's a terminology difference, and you're using histogram differently than I'm used to, it is impossible to build a histogram of a continuously variable value -- you have to build a series of intervals -- and it's true for database indexing, you just don't get to see the implementation (it's actually computing what the appropriate sizes of the intervals are)

Is there some way (module, idiom) to represent real numbers such that the same real number gets the same floating point representation, so that I can use them as hash keys for the approach above?

If you want it portable, you may need something like Math::BigFloat, which, IIRC, should be portable.

The graphical representation of a histogram is not my concern.

And my reply had nothing to do with graphical representation.