I'm familiar with potential problems with floating point inequality when the values are the results of some computation. But if I assign 1.2345 to $var_a and then assign 1.2345 to $var_b, then perform the equality check, I would expect them to be equal. Direct assignments should not cause different floating point representations, as far as I know.
Once that value is used in any sort of arithmetic, all bets are off.
As an additional test, I wrote a short script (which I should have done earlier, but it still doesn't really explain anything):
#!/usr/bin/perl
use strict;
use warnings;
my %values;
while (my $line = <DATA>) {
if ($line =~ /(\w)_(r|ch)ange\s(\S+)/) {
$values{$1}{$2."ange"} = $3;
}
}
for my $ key(sort keys %values) {
if ($values{$key}{'change'} != $values{$key}{'range'}) {
print "Not ";
}
print "Equal:\nChange: $values{$key}{change}\nRange : $values{$key
+}{range}\n\n";
}
__DATA__
var_a_change 101.945484
var_a_range 101.945484
var_b_change -80.5498336616321
var_b_range -80.5498336616321
var_c_change 45142.388774415
var_c_range 45142.388774415
var_d_change -159.905028384
var_d_range -159.905028384
var_e_change -159.905028384
var_e_range -159.905028384
var_f_change 181.019658002611
var_f_range 181.019658002611
var_g_change 1.57615706403821
var_g_range 1.57615706403821
Every single comparison there passes the equality check. And the only thing this script is doing differently than my actual script is reading the values from Excel. That may be key, I don't know.