Consider that 5.0, 5.5 and 0.1 have not an exact representation inside the computer, due to its binary nature and finite bits per number; given the fact that your cycles start from different starting points (5.0 the first, 5.5 the second), you end up having slightly different number in $mag in the first and second loop, i.e. different keys in the hash.

I would suggest that you fix the magnitudes somewhere (an array, for example), then use some integer index just to be sure not to mess things up.

5.0 and 5.5 do have exact representations; 0.1 does not.

Touché :-) Another case of "negative laziness"...

Flavio

Don't fool yourself.

Thanks, Falvio. I had completely forgotten about the issues with using floating point numbers.

Seconded on the using floats as hash keys being a bad idea. Run this version to see why:

my @keys = qw( 0 0.1 0.3 1 3 10 30 1000 );
my %n;

for ( my $mag = 5.0 ; $mag < 9.0 ; $mag += 0.1 ) {
  @{ $n{ $mag } }{ @keys } = ( 0 ) x @keys;
}

for ( sort { $a <=> $b } keys %n ) { 
  print "mag: $_\t$n{$_}->{30}\n";
}
[download]

Perhaps if you step back and described what you're trying to accomplish with this hash . . .

To expand a bit on frodo72's reply, if you change your code slightly to:

for ($mag=5.0;$mag<9.0;$mag=$mag+0.1){
 $n{$mag}{0}=$n{$mag}{0.1}=$n{$mag}{0.3}=$n{$mag}{1}=0;
$n{$mag}{3}=$n{$mag}{10}=$n{$mag}{30}=$n{$mag}{1000}=0;
}

for ($mag=5.5; $mag<9.0; $mag=$mag+0.1){
 print"$mag $n{$mag}{30}\n";
}
[download]

5.5 0
5.6 0
5.7 0
5.8 0
5.9 0
6 0
6.1 0
6.2 0
6.3 0
6.4 0
6.5
6.6
6.7
6.8
6.9
6.99999999999999 0
7.09999999999999 0
7.19999999999999 0
7.29999999999999 0
7.39999999999999 0
<truncated>
[download]

use strict;

my @bin_labels = qw( 0 0.1 0.3 1 3 10 30 1000 );

{
  my $step_size  = 0.1;
  my $start      = 5.0;
  my $finish     = 9.0;

  sub index_to_mag {
    my $i = shift;
    return $start + $i * $step_size;
  }

  sub mag_to_index {
    my $mag = shift;
    return sprintf "%.f", ($mag - $start) / $step_size;
  }
}

my @n;
for ( my $i = 0; $i < mag_to_index( 9.0 ); ++$i ) {
  $n[ $i ]{ $_ } = 0 for @bin_labels;
}

for ( my $mag = 5.5;
      $mag < 9.0;
      $mag = sprintf "%.1f", $mag + 0.1 ) {
  printf "%.1f %f\n", $mag, $n[ mag_to_index( $mag ) ]{ 30 };
}
[download]

# first, generate fixed-precision strings for magnitudes
# and bin values:

my @mag_keys = map { sprintf("%.1f", $_/10) } ( 50 .. 89 );
my @bins = qw/0 0.1 0.3 1 3 10 30 1000/;

# now initialize hash bins for counting:
# (this is probably unnecessary, unless you're re-using
# the hash on multiple separate data sets)

my %n;
for my $mag ( @mag_keys ) {
    for my $bin ( @bins ) {
        $n{$mag}{$bin} = 0;
    }
}
[download]

I'm still scratching my head about the "0, 0.1, 0.3, ..." series -- that jump from 30 to 1000 seems odd.

As I just said to Flavio, I had completely forgotten about issues with floating point numbers. Your suggestions work beautifully and are brief. Thank you! The values 0.1 to 30 cover logarithmic time intervals during which I assume my data to be complete. 1000 is an arbitrary default value for aftershocks outside my time intervals. I could have used any other name, maybe 'outside'. The '0' collects foreshock data. I hope the explanation saves your head from being scratched. ;-)

What got me, specifically, was %.1f. I thought the 1 (one) was an l (ell). Dur...

**********

Those new to the x operator (aka repetition operator) may want to have a look at this explanation of the x operator.

20050404 Unconsidered by Corion. Was considered by holli: clean up link (edit:11 keep:7 del:0)