in reply to Problem with a sort result

You are running the script on a 32bit machine, right?

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.

Replies are listed 'Best First'.
Re^2: Problem with a sort result
by Discipulus (Canon) on Jan 15, 2016 at 09:23 UTC
    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.
[reply]
[d/l]
Re^2: Problem with a sort result
by kzwix (Sexton) on Jan 15, 2016 at 09:46 UTC

    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.

[reply]
      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.

[reply]

In Section Seekers of Perl Wisdom