The issue is, plain and simple, that @Notes is not being assigned to. Here's further evidence:
I put the comparison checks back in and logged them this way:
my $tmp1 = ""; @Notes = sort { $tmp1 .= $b->{terms}.$a->{terms}; my $r = $b->{terms} <=> $a->{terms}; $tmp1 .= "($r) "; return $r; } @Notes; my $tmp2 = ""; my @Sorted = sort { $tmp2 .= $b->{terms}.$a->{terms}; my $r = $b->{terms} <=> $a->{terms}; $tmp2 .= "($r) "; return $r; } @Notes; open(LOG,">/var/www/dump/tmp.txt"); print LOG "$tmp1\n$tmp2\n"; if ($tmp1 ne $tmp2) { print LOG "UNEQUAL" }
$tmp1 does equal $tmp2, demonstrating that the sort operation occurred and occurred exactly the same way both times. I have also compared @Notes to a copy made before the operation, and it does not change. So again, the issue is, plain and simple, that @Notes is not being assigned to by sort @Notes. Sorry to be stubborn and assertive here, but what else is there to believe at that point? It is not that @Notes gets sorted wrongly, or that the one sort operation differs from the other.
Of course, it's not a big deal as using the @Sorted array is fine and I can undef @Notes afterward. But if anyone thinks this looks like a bonified perl bug (first one I'll have found), and wants to give me some tips about how that could be verified using my existing code, I'd probably be willing to investigate. Otherwise...
ps. I also did this using both "use sort _mergesort" and "use sort _quicksort". The quicksort does slightly fewer comparisons (kind of a surprise, considering the 11111111121111111112111 nature of the data) but otherwise the result is exactly the same.
In reply to Re^5: sort != sort
by halfcountplus
in thread sort != sort
by halfcountplus
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |