$ifac{sprintf "%.3f" $factor}
[download]

In your case, your issue begins with your hash creation:

use Data::Dumper;
my %ifac= (
14.152 => "JCI",
9.334 => "JHEP",
5.745 => "JIMM",
6.270 => "JID",
1.480 => "JRN",
6.105 => "KI"
);
print Dumper \%ifac;
[download]

$VAR1 = {
          '6.105' => 'KI',
          '1.48' => 'JRN',
          '9.334' => 'JHEP',
          '5.745' => 'JIMM',
          '6.27' => 'JID',
          '14.152' => 'JCI'
        };
[download]

my %ifac= (
'14.152' => "JCI",
 '9.334' => "JHEP",
 '5.745' => "JIMM",
 '6.270' => "JID",
 '1.480' => "JRN",
 '6.105' => "KI"
);
[download]

Thank you for your fast reply.

So even if it would work with a direct access, it is always better to translate the hash keys to a string.

Just an idea: Another solution would be to cut the last 0 from $factor - which should then also work?

The hash key is a string. If you don't do explicit stringification, Perl does it for you. In your case, it does it inconsistently between your construction and access.

You would get identical functionality by trimming trailing zeroes (s/0+$//), but I think that behavior is less obvious, in which case you are setting yourself up for painful maintenance. Another option would be to multiply your factors by 1000, and thus deal with integers instead of decimals.

Update: An improvement on the "trim trailing zeroes" front would be to use the same mechanism that mangled the input in the first place. If you swap to

$jour=$ifac{0+$factor};
[download]

you'll invoke the internal Perl conversion to a number and reconvert back to a string for hash access, and hence should hit the correct record.

---

#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.

Hi,

To add to the post above, a simple use of Data::Dumper highlights the issue

use strict;
use warnings;
use autodie;
    #these 3 above are a must -have
use Data::Dumper;


my %ifac= (
14.152 => "JCI",
9.334 => "JHEP",
5.745 => "JIMM",
6.270 => "JID",
1.480 => "JRN",
6.105 => "KI"
);

print Dumper(\%ifac);
[download]

displays:

$VAR1 = {
          '6.105' => 'KI',
          '1.48' => 'JRN',
          '9.334' => 'JHEP',
          '5.745' => 'JIMM',
          '6.27' => 'JID',
          '14.152' => 'JCI'
        };
[download]

Cheers

Arnaud

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.