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
