FAQ
# New Ticket Created by Ira Byerly
# Please include the string: [perl #74334]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=74334 >


Hello,

I noticed that certain uses of sort no longer work in Rakudo after the ng
merge in February 2010. For example, this line in the table tennis example
in the Perl 6 book...

my @sorted = @names.sort({ %sets{$_} }).sort({ %games{$_} }).reverse

fails, as does this trivial example,

$ rakudo -e '<1 3 4 2>.sort({-$^a}).say'
Too many positional parameters passed; got 2 but expected 1...

The attached patch fixes the problem as follows:

1. In Seq.pm, the sort method is modified to make a ResizablePMCArray to
use with Parrot's sort method. The original code said that it did so in the
comments, but it actually made a Parcel instead. This first patch doesn't
fix anything by itself, but without it, the change to Parcel.pm would cause
an infinite loop.
2. In Parcel.pm, a sort method is added, which uses the sort in Seq.pm.
This fixes both of the examples above.
3. Hash.pm is also modified to use the sort in Seq.pm. This allows the
"%hash.sort returns a List of Pairs" test in t/spec/S32-list/sort.t to work.
4. Subroutine versions of sort are provided in Seq.pm and Hash.pm. (But
not in Parcel.pm.... the distinction between Parcel and Seq is lost in
subroutine calls. The subroutines in Seq.pm work for both parcel and array
parameters.)

Note that one test in t/spec/S32-list/sort.t fails...

not ok 4 - array of mixed numbers including Inf/NaN
# got: [-Inf, -61/20, -1e-07, 1/10, 11/10, 2, 42, Inf, NaN]
# expected: [NaN, -Inf, -61/20, -1e-07, 1/10, 11/10, 2, 42, Inf]

This is due to NaN sorting greater than Inf, rather than less than -Inf.
Since this is consistent with the Rakudo spaceship operator...

$ perl6 -e 'say NaN <=> Inf'
1

... I'm not sure that is appropriate to "fix" it in the code; it might be
better to change the test to match Rakudo's behavoir, or perhaps the test
should accept either >+Inf or <-Inf. The IEEE 754 standard just specifies
that than NaN should be "unordered".

Please let me know if you have any comments or concerns or would rather see
a different approach.

Best regards,
Ira Kevin Byerly
quester (on #perl6 and perlmonks)
quester.pm@gmail.com

Search Discussions

  • Geoffrey Broadwell at Apr 13, 2010 at 4:08 pm

    On Tue, 2010-04-13 at 05:42 -0700, Ira Byerly wrote:
    Note that one test in t/spec/S32-list/sort.t fails...

    not ok 4 - array of mixed numbers including Inf/NaN
    # got: [-Inf, -61/20, -1e-07, 1/10, 11/10, 2, 42, Inf, NaN]
    # expected: [NaN, -Inf, -61/20, -1e-07, 1/10, 11/10, 2, 42, Inf]

    This is due to NaN sorting greater than Inf, rather than less than -Inf.
    Since this is consistent with the Rakudo spaceship operator...

    $ perl6 -e 'say NaN <=> Inf'
    1

    ... I'm not sure that is appropriate to "fix" it in the code; it might be
    better to change the test to match Rakudo's behavoir, or perhaps the test
    should accept either >+Inf or <-Inf. The IEEE 754 standard just specifies
    that than NaN should be "unordered".
    In that case, the spec test should not care where the NaN sorts -- it
    should be implementation-dependent (unless $Larry has declared
    otherwise). However, that does not mean you should take NaN out of the
    sort testing -- you still want to test that it can be "sorted" against
    any other numeric value without invoking HCF (Halt and Catch Fire).

    Probably the easiest solution is just to do the sort, check that it
    contains a NaN somewhere, then grep the NaN out of the results and
    compare the cleaned results against an expected list with no NaN in it.


    -'f
  • Mark J. Reed at Apr 13, 2010 at 9:51 pm
    Seems like both NaN <= $x and NaN >= $x should return false for any
    $x, which makes me think NaN <=> $x should maybe return something
    undefined?
    On Tuesday, April 13, 2010, Geoffrey Broadwell wrote:
    On Tue, 2010-04-13 at 05:42 -0700, Ira Byerly wrote:
    Note that one test in t/spec/S32-list/sort.t fails...

    not ok 4 - array of mixed numbers including Inf/NaN
    #      got: [-Inf, -61/20, -1e-07, 1/10, 11/10, 2, 42, Inf, NaN]
    # expected: [NaN, -Inf, -61/20, -1e-07, 1/10, 11/10, 2, 42, Inf]

    This is due to NaN sorting greater than Inf, rather than less than -Inf.
    Since this is consistent with the Rakudo spaceship operator...

    $ perl6 -e 'say NaN <=> Inf'
    1

    ... I'm not sure that is appropriate to "fix" it in the code; it might be
    better to change the test to match Rakudo's behavoir, or perhaps the test
    should accept either >+Inf or <-Inf.  The IEEE 754 standard just specifies
    that than NaN should be "unordered".
    In that case, the spec test should not care where the NaN sorts -- it
    should be implementation-dependent (unless $Larry has declared
    otherwise).  However, that does not mean you should take NaN out of the
    sort testing -- you still want to test that it can be "sorted" against
    any other numeric value without invoking HCF (Halt and Catch Fire).

    Probably the easiest solution is just to do the sort, check that it
    contains a NaN somewhere, then grep the NaN out of the results and
    compare the cleaned results against an expected list with no NaN in it.


    -'f

    --
    Mark J. Reed <markjreed@gmail.com>
  • Kyle Hasselbacher at Apr 13, 2010 at 9:56 pm

    On Tue, Apr 13, 2010 at 4:51 PM, Mark J. Reed wrote:
    Seems like both NaN <= $x and NaN >= $x should return false for any
    $x, which makes me think NaN <=> $x should maybe return something
    undefined?
    That reminds me of a bug I wrote in C++ one time. I had overloaded
    comparisons in a way that didn't make any sense and caused the STL
    QuickSort to run off the end of the array. Whether that's relevant to
    Perl 6, I don't know. I'm just musing.

    Kyle.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl6-compiler @
categoriesperl
postedApr 13, '10 at 12:43p
activeApr 13, '10 at 9:56p
posts4
users4
websiteperl6.org

People

Translate

site design / logo © 2021 Grokbase