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".

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".

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