Hello kzwiz,

Personally I've never seen `-` used as the comparison operator in a custom sort. This doesn't mean anything other than I've never seen it, but I do find the standard numerical comparison operator (`<=>`) provides your expected results:

$ perl -E'
$h={foo=>{bar=>13908480193},baz=>{bar=>771918754},qux=>{bar=>288170793
+399}};
say "$_: $h->{$_}->{bar}" for sort { $h->{$b}->{bar} - $h->{$a}->{bar}
+ } keys %$h;
'
foo: 13908480193
baz: 771918754
qux: 288170793399
[download]

$ perl -E'
$h={foo=>{bar=>13908480193},baz=>{bar=>771918754},qux=>{bar=>288170793
+399}};
say "$_: $h->{$_}->{bar}" for sort { $h->{$b}->{bar} <=> $h->{$a}->{ba
+r} } keys %$h;
'
qux: 288170793399
foo: 13908480193
baz: 771918754
[download]

in fact, Perl does what we tell to do, and is difficult to spot some valid Perl code that was not what we intended,but it still compile.
The tricky part is that, contrarly to what i remembered, the sort sub must not returns -1 or 0 or +1, but:returns an integer less than, equal to, or greater than 0 so all the subtractions of octets are valid return value when choosing if $a or $b must be returned.

L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

The danger is there might be some kind of magic at work with $a, $b and the comparison operators that gets disrupted when going off book. In the case of the each function that is certainly the case.

One world, one people

There is a bug on the perl interpreter. Internally, it expects the result of the comparison operator to fit in an integer, but in that case, it doesn't. It is represented as an NV (a double float) that at some point is forcedly coerced into an integer and that operation overflows returning a bad result.

As a workaround, just use the comparison operator (<=>) which knows how to handle any Perl internal representation for numbers correctly.

Precious as always salva!
Notice that two of mines 32bit versions are compiled (thanks syphilis as i understand is the patcher) using config_H.gc_64int and strawberry release notes says "32bit Strawberry Perl is compiled with USE_64_BIT_INT enabled but there exists a version without USE_64_BIT_INT"



# testing the following oneliner
perl -MConfig -E "say for $Config{archname},$Config{version}, sort {$a
+ - $b} qw(10000000000 3 2)"


 | MSWin32-x86-multi-thread
 |  5.14.2
 |  10000000000
 |  2
 |  3
[OK] strawberry\perl\bin\perl.exe
 
 | MSWin32-x86-multi-thread-64int
 |  5.20.0
 |  2
 |  3
 |  10000000000
[OK] straw5.20-32b\perl\bin\perl.exe
 
 | MSWin32-x64-multi-thread
 |  5.16.2
 |  2
 |  3
 |  10000000000
[OK] straw64\perl\bin\perl.exe
 
 | MSWin32-x86-multi-thread-64int
 |  5.22.0
 |  2
 |  3
 |  10000000000
[OK] strP5.22-32\perl\bin\perl.exe
[download]


L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

Nope, Sir. I do run it on a 64bit server (linux), and the Perl I use on it shows the following first line when using '-v':

This is perl 5, version 16, subversion 0 (v5.16.0) built for x86_64-linux-thread-multi

Also, I think that my "-" implementation should have been within the limits of the "sort" specifications (by the way, I don't know who I should contact about it, but it is somewhat sketchy. I mean, telling us we should provide a negative, null, or positive integer is all well and good, but telling us WHAT IT MEANS (like "a null value means that both elements have the same rank", and so on) would have been a huge improvement.

Anyway, yes, it now works correctly when using <=>, so I'm guessing that, despite the version being a 64b Perl, there is indeed a problem with the huge negative numbers I got (possibly some kind of negative overflow, or merely a bug where the function doesn't expect as much data, and "loses" important parts, like the first characters (including the sign). I really don't know.

Hey, there are actually 2 bugs on perl!!!

The first is the one I described before where any number returned by the comparison subroutine is coerced into an IV, but then, there is a C function that just wraps that sub and which has a return type of I32, so the result is coerced again into a 32bit number.

Allow me to disagree.

I mean, obviously, it's not "breaking specifications", as there does NOT seem to be available specifications (because the documentation does NOT seem to mention how "sort" orders elements), but still, it furiously looks like an unwanted behaviour, or, at the very least, a caveat worth mentioning.

I'm guessing that adding a single paragraph to the documentation, telling that a positive result orders in the following way, a negative result orders in the other way, and a null result keeps the same order, and that it is STRONGLY RECOMMENDED to use the binary comparison operator for this, to avoid potential problems, would do the trick.

Because, I'll be blunt, but I had no recollection whatsoever of having previously worked with the "comparison" operator. And if it's not explained why one should use it, then... why not use something more familiar, and doing the same thing ? I mean, this is Perl, and "There is more than one way to do it", right ?

Perl often defers to C, or underlying platform, when it comes to specifications. (Sort of a hand-wave.) This seems to be the case here, as well. Read the page on qsort and compare to sort. Here's the pertinent quote:

If SUBNAME is specified, it gives the name of a subroutine that returns an integer less than, equal to, or greater than 0, depending on how the elements of the list are to be ordered.

So the behaviour is documented, and there is a discrepency in perl. You could try to fix the perl sources to address this issue. (But be sure then to run all tests. I've no clue why it's coded that way; there might be a reason.)

Read more... (992 Bytes)